Thanks Steve,<div>I'll admit, much of this is over my head. But my head is rising, bit by bit. My interest in STK is mainly for iPhone development. So speed is definitely important! I'm looking for a set of low-level components that are designed to be easily pluggable, and as efficient as possible. I realize that's not what stk was designed for, though it gets me a good part of the way there.</div>
<div>-Morgan<br><br><div class="gmail_quote">On Sun, Sep 19, 2010 at 11:29 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 class="im">On Sun, Sep 19, 2010 at 12:25 PM, Morgan Packard<br>
<<a href="mailto:morgan@morganpackard.com">morgan@morganpackard.com</a>> wrote:<br>
> Stephen,<br>
> It's interesting to hear you describe this way of "connecting" unit<br>
> generators. I've recently cracked open STK after years of using<br>
> SuperCollider and have been confused by the fact that there's no<br>
> obvious way to plug one ugen into another, as there is in<br>
> SuperCollider, and, presumably just about every other high-level<br>
> patching system.<br>
<br>
</div>Well, perhaps that's because STK is not a patching system, just a<br>
collection of C++ classes with a tick() function to produce and<br>
consume samples. You "connect" them by just feeding the output of one<br>
into the input of another.<br>
<br>
Perhaps STK needs a simple ring modulator example to demonstrate this<br>
or something.<br>
<br>
Of course you can use the STK/Pd objects or a language like ChucK to<br>
do higher level "patching" of STK objects. I'm not as familiar with<br>
SC, but there must be some port of STK to SC ugens.<br>
<div class="im"><br>
> Is there a strong reason not to design a lower-level tool such that<br>
> ugen objects can be explicitly plugged in to one another?<br>
<br>
</div>Not sure what you mean by "lower-level tool" here, but STK's pretty<br>
low level as it is. If you mean "higher level", see my previous<br>
comments about Pd, ChucK, and SC.<br>
<div class="im"><br>
> Is there some sort of performance cost to storing the ugen graph in<br>
> a separate data structure, rather than as interconnections between<br>
> the ugen objects themselves?<br>
<br>
</div>There could be actually. Gary recently moved a lot of the tick()<br>
functions from the cpp files to the header files so that the compiler<br>
would have the possibility of inlining them. This will only happen if<br>
the data types are all known at compile time. I don't know if any<br>
formal profiling has been done to assess gcc's ability to do this.<br>
<br>
Anyways, if you have a generalized ugen graph which can point to any<br>
Instrument class for example, the compiler won't be able to inline<br>
calls to tick(), so an extra indirection and function call overhead<br>
will be needed for each Instrument or other class in the graph, for<br>
each sample. This can add up when calculating samples 44 thousand<br>
times a second.<br>
<br>
Another consideration is that when making indirect function calls, it<br>
becomes more likely that the code is also positioned further away than<br>
it would be if it were inlined, so it could conceivably cause memory<br>
cache misses as well.<br>
<br>
Of course, I really wouldn't worry about this unless speed really<br>
becomes a problem for you.<br>
<br>
Steve<br>
</blockquote></div><br></div>