[Stk] Sequencing with the STK

[Morgan Packard]

Stephen,
It's interesting to hear you describe this way of "connecting" unit
generators. I've recently cracked open STK after years of using
SuperCollider and have been confused by the fact that there's no obvious way
to plug one ugen into another, as there is in SuperCollider, and, presumably
just about every other high-level patching system. Is there a strong reason
not to design a lower-level tool such that ugen objects can be explicitly
plugged in to one another? Is there some sort of performance cost to storing
the ugen graph in a separate data structure, rather than as interconnections
between the ugen objects themselves?
thanks,
-Morgan

On Sun, Sep 19, 2010 at 9:44 AM, Stephen Sinclair
<sinclair at music.mcgill.ca>wrote:

> On Sun, Sep 19, 2010 at 10:43 AM, Carlos Viejo
> <carlos.viejo.muros at googlemail.com> wrote:
> > Hi all,
> > i'm developing a system that uses audio generating objects based on the
> STK
> > and openFrameworks to represent these objects visually and let the user
> > define their interactions. So far so good, but i'm having trouble
> creating
> > a high resolution sequencer object, that would trigger other nodes. It
> does
> > not need to be very sophisticated, pretty much deliver an accurate tick
> with
> > a given bpm. Any hints? Maybe i'm overlooking something in the STK?
>
> The use of STK is basically to define how each sample of audio is
> calculated in an audio callback.  So if you want to make the signal
> flow dynamic, the general idea is to allocate STK objects on the heap
> using "new", and keep the pointers in some sort of data structure
> indicating a signal graph.  You then call their tick() functions and
> feed them along to the input of other tick() functions, according to
> whatever network of unit generators you want.
>
> How you decide to organize this in terms of a sequencer is up to you,
> and probably depends on the class structure of openFrameworks (which
> I'm unfamiliar with), so it's hard to answer your question.
>
> As for determining a BPM, you just have to figure out how many samples
> per beat to expect (which could be a float if you want to be
> accurate), and call the unit generators noteOn() functions or set
> their parameters at the appropriate sample tick.  Keep a global tick
> count to maintain a clock.
>
> The "crtsine.cpp" example is the best place to start imho.
>
> Steve
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20100919/2c366e77/attachment.html