<br><br><div class="gmail_quote">2008/6/13 mike clemow <<a href="mailto:gelfmuse@gmail.com">gelfmuse@gmail.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>Yes, I forgot to mention that! Crazy... I guess I'll manually<br>
unchuck the SinOsc for now. I'll have to check if that happens with<br>
other UGens...<br>
</blockquote><div><br>Unchucking unused Ugens it good form anyway. Wherever you can afford to I'd do that because it saves CPU. IT tisn0/t alway appropriate because with some Ugens or systems of Ugens the code need not be aware of when the Ugen is "done", for example with the physical models in the STK.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Meanwhile, if I unchuck that SinOsc from the dac it works in the sense<br>
that the SinOsc objects don't add up, however, only if the shreds<br>
finish executing. If I remove the parent while one of the sporked<br>
shreds is still running, one sine keeps going. Ostensibly because the<br>
last shred hasn't finished and the unchuck line hasn't run. This<br>
makes me really wish I could define code that would be called when a<br>
shred exits. That would be a neat feature...<br>
</blockquote><div><br>Yes, quite weird and I can't remember this being like that in the past. This is truely arcane stuff and likely only Ge knows.... But I have a suspicion. Clearly a outside reference to a shred affects how it deals with cleanup. I suspect this has to do with Ge having been working at garbage collection (which also works with references... or at least will). I suspect what we are seeing might be a trace of the start of a GC framework. In that case we found a bug in a feature that's not even here yet... That would be quite funny.<br>
<br>Disclaimer; this is complete speculation and not of any practical use.<br><br>Code to be run when a shred exits is a interesting idea but I suspect it's asking for trouble. Because a shred has it's own namespace which is obviously gone when the shred is such code would probably need to be run *before* it exits and after it get's it's exit notice.... but then what if this code does stuff like advance time or (worse yet!) call for the exit of the same shred? I suspect this would be asking for stuck VM's and confused shredulers. I'd rather have proper cleanup. I'd also be quite interested in Shred type objects giving access to that shred's name-space like this;<br>
<br>fun void foo()<br>{<br>3 => int value;<br>while (second => now) <<< value >>>>;<br>}<br></div></div><br>spork ~ foo() @=> Shred bar;<br><br>4::second => now;<br><br>//modest proposal starts here<br>
5 => bar.value;<br>hour => now;<br><br>This would also enable us to run manual cleanup; either from the last lines of the shred's code (asuming it's not a infinite loop) or from the shred that calls for it's exit, right before the exit call. <br>
<br>Kas.<br>