Actually, I thought of a more dangerous case with this.
t = Task({
inf.do({ |i|
i.postln;
0.5.wait;
});
}).play;
t.stop;
// this plays the Routine, not the Task, so...
t.reset.play;
// ... this doesn't stop it
t.stop;
// you have to do this instead
t.originalStream.stop;
Well, of course, the "right" way to reset-and-play is t.play(doReset:
true), but if you're live coding, and your brain slips and you write
t.reset.play instead, that's not a good time to have to figure out how
the internals of PauseStream / Task work.
If it's OK to put this in for RC5 (!), I think it would avoid a source
of confusion. I just can't imagine a good reason why .reset would
return anything other than the receiver, anyway.
Comments? Yes? No?
hjh
On Feb 7, 2008 9:00 AM, James Harkins <jamshark70@xxxxxxxxx> wrote:
I know it's past the deadline, and maybe this is for post-3.2,
but this
seems odd:
reset { ^originalStream.reset }
--
James Harkins /// dewdrop world
jamshark70@xxxxxxxxxxxxxxxxx
http://www.dewdrop-world.net
"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel