[chuck-users] instrument in function - good idea, or?
signal.automatique at gmail.com
Thu Oct 8 22:22:26 EDT 2009
I think what you meant was "When the shred a UGen was defined in exits
> *NORMALLY* the UGen will be disconnected from anything it connected to..."
> To test that, we simply let the player shred exit (without unchucking the
I think I'd go as far as saying "When the shred a UGen was defined in exits
the UGen *SHOULD* be disconnected from anything it connected to..." :-)
In the last version, for example, it wasn't true in all cases, particularly
not when multiple connections existed. There is at least one exception,
which is Ugens that are static members of public classes (these are useful).
I believe the general case might be that UGens that can no longer be
addressed are disconnected but that's not true for something like this;
SinOsc s => dac;
.3 => s.gain;
Std.rand2f(200, 2000) => s.freq;
second => now;
In that particular case you get three UGens that can't be addressed any more
after this yet will run while the shred does. I'm not 100% sure that should
be desired behaviour but there is no big issue with it either as hopefully
people won't do this if that behaviour is unwanted.
> And yep, sure enough, the sound stops after 1 second.
> So the moral of the story: if you terminate a shred via exit(), it does NOT
> get the benefit of a standard shred clean-up.
Hmmmmm, right now I'm inclined to say that the moral of this story is "take
care of the sense and the sounds will take care of themselves" and ChucK
isn't taking care of the sense in all cases.
This case, for example, seems downright nonsensical to me; this is a plain
bug. In the Mini in both the new and the last version the sound keeps going
even after the mother shred exited.
So; the "slight exception" should not be with me but with ChucK and you
found a bug. Congratulations!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users