Calling .play on a Pbind returns an EventStreamPlayer, and only that stored player can be stopped or resumed

A Pbind is a score — a recipe for sound events — with no knowledge of start or stop. Sending .play to a Pbind creates a new EventStreamPlayer object (the ‘performer’ of that score) and starts it. If you do not store the returned player in a variable, you have no handle to control it later, and only ctrl+. (which kills everything) can stop it. Storing the player — e.g. ~player = myPbind.play — lets you call .stop, .resume, .start, and .reset on it individually, without disturbing other running players. Crucially, sending .stop to the Pbind variable itself does nothing: the Pbind is the score, not the player. Multiple Pbinds can run at once from a single code block, and {}.fork lets you start players in a timed sequence.

Examples

p = Pbind(\degree, Pseq([0,1,2,3], inf), \dur, 0.3);
~player = p.play;   // EventStreamPlayer
~player.stop;
~player.resume;
~player.stop.reset;
~player.start;

Assessment

Write a patch with two independent Pbinds playing simultaneously, each stored as an EventStreamPlayer. Stop only the first while the second keeps playing (or stop only the second after 5 seconds). Explain why p.stop on the Pbind itself does not work.