[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Re: calling the stream upon EventStreamPlayer-stop

Hi James,

  OK, I see.

Maybe we should have yieldTestForTermination(terminationFunction) to trap the nil returns.
That way, you can use embedInStream.  It seems to be generally useful.


On Dec 27, 2005, at 4:34 PM, James Harkins wrote:

On 12/27/05, ronald kuivila <rkuivila@xxxxxxxxxxxx> wrote:
What are you doing, exactly?

Can you give an example of where using Prout breaks?

If you play a Prout, you get an EventStreamPlayer. (This is legal if
the Prout yields events rather than other types of data.) Then, when
you stop the player, the routine gets invoked one extra time with a
nil input. This is a simplified example (including some odd
workarounds that have to be employed in the old Windows version for
output in routines -- you can replace them with simple postln's).

o = List.new;
p = Prout({
	var i = 0;
	loop {
		i = i + 1;
		o.add("Iteration " ++ i ++ "\ttime " ++ thisThread.clock.beats);
		(play:0, delta: 1.0).yield

// after some seconds...

Iteration 1	time 191
Iteration 2	time 192
Iteration 3	time 193
Iteration 4	time 194
Iteration 5	time 195
Iteration 6	time 360938.735665

Iteration 6 should not appear.

I think your argument is predicated on the assumption that all event
streams will terminate immediately if a nil event prototype is passed
in. In the case of Prout, that's true only if I check for it
explicitly after every .yield.

(Prout doesn't have child streams, so there is no need to pass the nil
further in this specific case.)

Prt (which I'm not asking to commit) is probably the best approach,
since it specifies a unique type of event pattern and makes that
type's behavior consistent with other event patterns with respect to
the input proto-event.

My composition framework creates EventStreamPlayers for all processes
for consistency. If the underlying pattern is a Prout, it has the side
effect that an extra event gets fired when I stop or free the process.
I know I could bypass the problem by not using EventStreamPlayer, but
I gain so many other benefits from my framework that it isn't worth it
to me to work outside the framework.


James Harkins /// dewdrop world

"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal."  -- Whitman

sc-dev mailing list