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 dac):

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;

repeat(3)
{
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!

Yours,
Kas.