[Stk] Sequencing with the STK

[Stephen Sinclair]

On Sun, Sep 19, 2010 at 12:25 PM, Morgan Packard
<morgan at morganpackard.com> wrote:
> 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.

Well, perhaps that's because STK is not a patching system, just a
collection of C++ classes with a tick() function to produce and
consume samples.  You "connect" them by just feeding the output of one
into the input of another.

Perhaps STK needs a simple ring modulator example to demonstrate this
or something.

Of course you can use the STK/Pd objects or a language like ChucK to
do higher level "patching" of STK objects.  I'm not as familiar with
SC, but there must be some port of STK to SC ugens.

> Is there a strong reason not to design a lower-level tool such that
> ugen objects can be explicitly plugged in to one another?

Not sure what you mean by "lower-level tool" here, but STK's pretty
low level as it is.  If you mean "higher level", see my previous
comments about Pd, ChucK, and SC.

> 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?

There could be actually.  Gary recently moved a lot of the tick()
functions from the cpp files to the header files so that the compiler
would have the possibility of inlining them.  This will only happen if
the data types are all known at compile time.  I don't know if any
formal profiling has been done to assess gcc's ability to do this.

Anyways, if you have a generalized ugen graph which can point to any
Instrument class for example, the compiler won't be able to inline
calls to tick(), so an extra indirection and function call overhead
will be needed for each Instrument or other class in the graph, for
each sample.  This can add up when calculating samples 44 thousand
times a second.

Another consideration is that when making indirect function calls, it
becomes more likely that the code is also positioned further away than
it would be if it were inlined, so it could conceivably cause memory
cache misses as well.

Of course, I really wouldn't worry about this unless speed really
becomes a problem for you.

Steve