[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] Re: calling the stream upon EventStreamPlayer-stop
On Jan 2, 2006, at 2:04 PM, rkuivila@xxxxxxxxxxxx wrote:
I went back and looked at your original email and I think you mean that
the EventStreamPlayer
cannot be resumed once it is stopped. Use 'pause' and the EventStream can
be resumed (either
with 'play' or 'resume').
Not true. From PauseStream -- pause === stop, resume === play. That may well be a bug.
<x-tad-smaller> pause { </x-tad-smaller><x-tad-smaller>this</x-tad-smaller><x-tad-smaller>.stop }
resume { </x-tad-smaller><x-tad-smaller>arg</x-tad-smaller><x-tad-smaller> argClock, quant=1.0;
^</x-tad-smaller><x-tad-smaller>this</x-tad-smaller><x-tad-smaller>.play(clock ? argClock, </x-tad-smaller><x-tad-smaller>false</x-tad-smaller><x-tad-smaller>, quant)
}
</x-tad-smaller>
Actually, the fact that a PauseStream can be resumed after it is stopped
seems like a bug,not a feature. For example, this makes it impossible to
stop a Task that is blocked waiting for MIDI input using the MIDIIn-waitNoteOn style methods.
Not sure I follow you there. A MIDI Task will sit in MIDIIn's noteOnList/noteOffList, even when it's been .stopped, until its next invocation. At that point, it gets scheduled and .next gets called. The stream var is nil, so stream.next returns nil and the event doesn't get put back into the noteOnList. You can stop it and it will have the intended effect, but the GC doesn't happen immediately.
I can think of lots of cases where pausable Tasks etc. are highly musically useful. I wouldn't write it off as a bug so quickly. Or maybe a better question is, how should .pause be implemented to distinguish it from .stop?
hjh
: H. James Harkins
: 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