[chuck-users] wishlist for the new year

[Tom Lieber]

2010/1/7 Stefan Blixt <stefan.blixt at gmail.com>:
> I don't know all the jargon, but intuitively something like a UGen feels
> like you should be able to run it in a thread of its own - all it needs to
> share are its inputs and outputs... but if Ge says its hard to do I'm not
> the one to debate against.

I think there are two main barriers to multi-threading UGen
processing. UGens are fairly independent, but 1) changes to the graph
need to be synchronous with ChucK time and 2) the minimum block size
you can use is dependent on how much virtual time there is before the
VM needs to wake up again, and how tight a feedback loop a particular
UGen is in.

(1) means UGen processing needs to start and stop in time with the VM
(synchronization overhead). The naive solutions for (2) have weird
side-effects that make it worth doing right, which would involve
making guesses about the next time external messages (like from Hid or
MIDI) could wake a shred (window size is a convenient guess and
probably wouldn't decrease timing accuracy by much), and analyzing the
graph to find feedback loops and set block sizes accordingly.

-- 
Tom Lieber
http://AllTom.com/
http://ckvlang.org/