1. Currently, EventStreamPlayer uses its protoEvent directly, so patterns that mess with the event must make a copy.
Feeding a copy of the protoEvent to the EventStream instead of the original would eliminate the need for these copies
(which are found in various Pattern definitions), simplifying code a bit and clarifying what is going on.
a = Pbindf(Pfunc { | ev | ev}, \a, 333);
b = a.asStream;
e = ();
b.next(e).postln; e.postln;
2. Nil is no longer used as to mark an early termination event. So there are no
(correct) situations where an event pattern returns from yielding its Event "upwards" with a nil.
(Substreams may return a nil, but not the main EventStream.)
So, there are a lot of tests for nil in the code that could go away.
Losing the nil tests implies that EventStream's receiving a next message
without an event would throw an error.
comments:
I am committed to 1 - it simplifies the code in a fundamental way and makes it more secure. However,
it means that any homemade event stream players have to copy their proto events. (Are there any homemade
event stream players?)
2. is more of a judgement call, it would get rid of some cruft and make the distinction between substreams and
the main event stream a bit clearer, but it also exposes misuse with error messages.