[chuck-users] instrument in function - good idea, or?

Kassen signal.automatique at gmail.com
Thu Oct 8 12:39:31 EDT 2009

Normally UGens are defined within the scope of a shred, this may be a
sporked function or the "main shred", being the code in a file outside of
any functions or classes.

When the shred a UGen was defined in exits the UGen will be disconnected
from anything it connected to (I'm not sure everything that connects to the
Ugen on the other end will also be disconected but that doesn't matter much
here). Because of this the DAC will no longer poll it for new samples so it
won't take any CPU anymore. This, in adition to calculation order, is the
big advantage of the "pull through" model we use for the UGens.

CPU-wise you should be fine but the memory used for these UGens probably
still won't be freed. I think that in this case you should be able to free
the memory by assigning "null" to the UGen instances; I never tried that
myself in practice but it was supposed to work.

That leaves object creation as a potential source of CPU spikes. You
certainly *can* cause glitches by creating objects but it doesn't need to
happen. I think results will depend on the complexity of a single voice, the
amount of voices in use at the time, the speed of the CPU and the size of
your buffer (which also affects latency). I don't think there is a
substitute for simply trying it out and seeing how far you get. In this case
I'd take that route, if/when you also add note-off signals instead of
knowing the length at the start you will need a infrastructure for that that
will likely also make voice cycling more easy.

Hope that help,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091008/c36f23b4/attachment.htm>

More information about the chuck-users mailing list