Hi Spencer Thanks 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

On Mon, Dec 15, 2014 at 5:14 AM, vilbjørg broch wrote: hi

I have problems getting shreds to spread load over multiple cpus neither from miniAudicle nor commandline chuck Running linux Debian 3.2.0-4-amd64, chuck 1.3.4.0 jack, miniAudicle 1.3.2 jack

I just tested the same .ck files on a mac and it looks like that the sporked shreds automatically spreads over at least 2 of 4 (4 of 8) cores.

Is there any more information to find about how to handle or understand these issues, or does anyone have any tricks to share?

Much greetings Vilbjørg

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Spencer Salazar Doctoral Candidate Center for Computer Research in Music and Acoustics Stanford University

spencer@ccrma.stanford.edu +1 831.277.4654 https://ccrma.stanford.edu/~spencer/

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users