Thanks Carlos,<div><br></div><div>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.<br>
<br></div><div>Sorry to clutter the stk list with this somewhat off-topic stuff.</div><div><br></div><div>-Morgan</div><div><br><div class="gmail_quote">On Sun, Sep 19, 2010 at 1:33 PM, Carlos Viejo <span dir="ltr"><<a href="mailto:carlos.viejo.muros@googlemail.com">carlos.viejo.muros@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Morgan,<div><br></div><div>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.</div>
<div>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.</div>
<div>Not sure i explained it clearly, the point is with little work involved you can make the STK classes dynamically pluggable.</div><div><br></div><div>@stephen: you are right, a global tick count will do the job. thanks!</div>
<div><br><br><div class="gmail_quote"><div><div></div><div class="h5">On Sun, Sep 19, 2010 at 8:02 PM, Morgan Packard <span dir="ltr"><<a href="mailto:morgan@morganpackard.com" target="_blank">morgan@morganpackard.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">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<div><div></div><div><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" target="_blank">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>On Sun, Sep 19, 2010 at 12:25 PM, Morgan Packard<br>
<<a href="mailto:morgan@morganpackard.com" target="_blank">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><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><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></div></div>
<br></div></div><div class="im">_______________________________________________<br>
Stk mailing list<br>
<a href="mailto:Stk@ccrma.stanford.edu" target="_blank">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>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>