Hi Atte!
I investigated, and it seems it was partly my fault. Attached are three files.
Thanks for tracking this down.
To reproduce a problem similar to what I had, run "chuck --loop instruments", then do "chuck + eats_cpu.ck". Because the call to Instruments.analog.bd() is not sporked (but called) chuck will eat cpu rapidly. Why is that? Is it my mistake or is this a bug in chuck?
This is a chuck bug (a chug) and it has to do with the incomplete garbage collection in the current release. We plan to fix precisely this type of problems and more in 1.2.0.6. In this case, the function analog_bd( ... ) instantiates and connects a patch
fun static void analog_bd(float dynamic, dur length) {
[snip]
sinosc s => ADSR env => dac;
[snip] Due to the bug, the UGen's are neither automatically disconnected nor garbage-collected (both should happen when the function exits). The former causes the gradual CPU overload, and the latter causes the memory explosion over time. To manually workaround the disconnect/CPU issue in 1.2.0.5, disconnect the patch before leaving the function: s =< env =< dac; To manually workaround the memory explosion, make the UGen's static members of the Instrument class (so they don't have to be recreated every time analog_bd is called). However, this runs into the other long-standing static member bug, which forces one to instantiate the object outside: public class Instrument { // declare static reference to sinosc // (due to 'static' not fully implemented for objects) static sinosc @ s; } // instantiate out here // (due to 'static' not fully implemented for objects) new sinosc @=> Instrument.s; Sorry for this horrid hack. We hope to resolve these chugs as soon as we can. Best, Ge!