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 > <[email protected]> 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 > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > > > -- > Spencer Salazar > Doctoral Candidate > Center for Computer Research in Music and Acoustics > Stanford University > > [email protected] > +1 831.277.4654 > https://ccrma.stanford.edu/~spencer/ > > _______________________________________________ > chuck-users mailing list > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list [email protected] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
