[Stk] Sequencing with the STK

[Carlos Viejo]

Hi Morgan,

the system we're working on has a design based on pluggable objects that are
based on STK classes. A generic AudioNode class with an _output field of
type AudioNode* and a virtual tick function. Each time you ask a node for
the tick value it first feeds its tick value to its AudioNode* field and
returns the resulting StkFloat. You also have to define a (very small)
wrapper that inherits from AudioNode for the STK classes that you use.
Using an output field of type vector<AudioNode*> would also give you the
possibility of feeding the output of one object into multiple other objects
à la max/msp, but i have just experimented with linear chains so far.
Not sure i explained it clearly, the point is with little work involved you
can make the STK classes dynamically pluggable.

@stephen: you are right, a global tick count will do the job. thanks!


On Sun, Sep 19, 2010 at 8:02 PM, Morgan Packard <morgan at morganpackard.com>wrote:

> Thanks Steve,
> 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.
> -Morgan
>
>
> On Sun, Sep 19, 2010 at 11:29 AM, Stephen Sinclair <
> sinclair at music.mcgill.ca> wrote:
>
>> 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
>>
>
>
> _______________________________________________
> 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/f4dfc345/attachment.html