Hi SpencerThanks a lot for the answer. It is very clear. You could almost insert it in the documentation, I was looking for this for a while, maybe more people would too. The hint about running several instances of chuck is a good one, for some reason I did not think about it and for some stuff for sure useful. (just chuck from different commandline taps)
-- Yes by closer thought one can imagine that the calculations in chuck must be kept tight together,, very different than for instance generating images with 'Processing'
Chuck is fabulous and the first place to try out new ideas for algorithms at sample accuracy. This week I was looking at waveforms generated from quaternions rotating around each other. One need at least 4 quaternions to move beyond periodicity, but this is actually not doable on a high-end PC at audio sample rate. Too many multiplications. Got to go back to the 70ties style and generate a dataset over night I guess.
greetings
On Dec 15, 2014, at 11:20 PM, Spencer Salazar wrote:
Hi
Vilbjørg,
ChucK does not spread processing load for multiple shreds over multiple CPUs/cores -- all shred and audio processing occurs on a single logical core. This is mainly because ChucK makes several strong guarantees about the timing between shreds and audio processing, and these are difficult to maintain across multiple cores.
Its not uncommon to run multiple chuck instances if multiple-core utilization is necessary, using OSC to communicate data between them. You lose a lot of the power of shreds in ChucK, but as I mentioned these attributes are difficult to implement with multi-core awareness anyways.
spencer
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users