[Stk] Sequencing with the STK

[Morgan Packard]

Thanks Carlos,

Along with the capacity for non-linear connections of audio signals, a
polished plugging/patching system will also have a nice way of handling
control data, perhaps allowing the same ugens to be used for control or
audio data, and optimizing the control communication by calculating it at a
slower rate than audio data. Such a thing is a non-trival project (for me,
at least). Perhaps such a thing exists, but I've only been able to find the
higher-level tools (Pd, ChucK, SC) which don't seem to be designed for easy
integration into other software. I think there's some murmuring in the PD
community about packaging PD up in a way so that it's easy to use as a code
library, not necessarily tied to the graphical interface, but I don't think
it's there yet.

Sorry to clutter the stk list with this somewhat off-topic stuff.

-Morgan

On Sun, Sep 19, 2010 at 1:33 PM, Carlos Viejo <
carlos.viejo.muros at googlemail.com> wrote:

> 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/1b8e43ca/attachment.html