2010/1/7 Stefan Blixt
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/