[chuck-users] Returning a Shred and crashing Chuck

[mike clemow]

> In fact; with my
> edit of the Forkable class I can start your code, stop it, and often a tone
> will keep sounding without a single shred running (!!!).

Yes, I forgot to mention that!  Crazy...  I guess I'll manually
unchuck the SinOsc for now.  I'll have to check if that happens with
other UGens...

Meanwhile, if I unchuck that SinOsc from the dac it works in the sense
that the SinOsc objects don't add up, however, only if the shreds
finish executing.  If I remove the parent while one of the sporked
shreds is still running, one sine keeps going.  Ostensibly because the
last shred hasn't finished and the unchuck line hasn't run.  This
makes me really wish I could define code that would be called when a
shred exits.  That would be a neat feature...

Strange stuff indeed!

Thanks!

-Mike

On Fri, Jun 13, 2008 at 7:40 AM, Kassen <signal.automatique at gmail.com> wrote:
> Mike;
>>
>> What gives?  It apparently doesn't like the return of the Shred
>> object.  I'm not sure what's happening here.  It's not *really* that
>> important to me, but it would be nice to have the option of killing
>> that process later.
>>
>> Any ideas?  Am I doing something wrong???
>
> Weird. Adding a single line like this;
>
> class Forkable {
>    // I am a process
>    fun void run() {
>        // sporkable code here...
>        SinOsc s => dac;
>        100::ms => now;
>
> //unchuck!
>        s =< dac;
>        me.yield();
>    }
> }
>
> Makes the first example behave as well. The difference seems to be that the
> SinOsc's aren't automatically unchucked from the dac when the their shred
> exits in the first example.... and this seems due to the existance of that
> reference. This leads to clipping and a high cpu load, resulting in that
> weird noise because you are still creating 20 SinOsc's per second.
>
> My bet would be that this might be a case of reference counting gone wrong.
> At least it's fixable with a manual unchuck though it's quite odd that
> SinOsc's that aren't attached to a Shred can keep running. In fact; with my
> edit of the Forkable class I can start your code, stop it, and often a tone
> will keep sounding without a single shred running (!!!).
>
> Strange stuff, good catch!
>
> Yours,
> Kas.
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>



-- 
http://semiotech.org
http://deadlylittlepills.com/michael