<div>Stephen,</div>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?<div>
thanks,</div><div>-Morgan<br><br><div class="gmail_quote">On Sun, Sep 19, 2010 at 9:44 AM, Stephen Sinclair <span dir="ltr"><<a href="mailto:sinclair@music.mcgill.ca">sinclair@music.mcgill.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Sun, Sep 19, 2010 at 10:43 AM, Carlos Viejo<br>
<<a href="mailto:carlos.viejo.muros@googlemail.com">carlos.viejo.muros@googlemail.com</a>> wrote:<br>
> Hi all,<br>
> i'm developing a system that uses audio generating objects based on the STK<br>
> and openFrameworks to represent these objects visually and let the user<br>
> define their interactions. So far so good, but i'm having trouble creating<br>
> a high resolution sequencer object, that would trigger other nodes. It does<br>
> not need to be very sophisticated, pretty much deliver an accurate tick with<br>
> a given bpm. Any hints? Maybe i'm overlooking something in the STK?<br>
<br>
</div></div>The use of STK is basically to define how each sample of audio is<br>
calculated in an audio callback. So if you want to make the signal<br>
flow dynamic, the general idea is to allocate STK objects on the heap<br>
using "new", and keep the pointers in some sort of data structure<br>
indicating a signal graph. You then call their tick() functions and<br>
feed them along to the input of other tick() functions, according to<br>
whatever network of unit generators you want.<br>
<br>
How you decide to organize this in terms of a sequencer is up to you,<br>
and probably depends on the class structure of openFrameworks (which<br>
I'm unfamiliar with), so it's hard to answer your question.<br>
<br>
As for determining a BPM, you just have to figure out how many samples<br>
per beat to expect (which could be a float if you want to be<br>
accurate), and call the unit generators noteOn() functions or set<br>
their parameters at the appropriate sample tick. Keep a global tick<br>
count to maintain a clock.<br>
<br>
The "crtsine.cpp" example is the best place to start imho.<br>
<br>
Steve<br>
<br>
_______________________________________________<br>
Stk mailing list<br>
<a href="mailto:Stk@ccrma.stanford.edu">Stk@ccrma.stanford.edu</a><br>
<a href="http://ccrma-mail.stanford.edu/mailman/listinfo/stk" target="_blank">http://ccrma-mail.stanford.edu/mailman/listinfo/stk</a><br>
</blockquote></div><br></div>