[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