[chuck-users] machine.add issue
Ge Wang
gewang at CS.Princeton.EDU
Fri Jul 7 18:18:57 EDT 2006
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!
More information about the chuck-users
mailing list