Access current event inside play method

semiquaver · November 16, 2019, 10:08pm

Is there a way to pass the current event to it’s play function?

I have an array of Events associated with the key \parts and want to make them children of the current Event. play: {~parts.do {|I|I.parent = …?

Is there a way to use the {|self| notation inside the play function?

Q2: is it possible to call psuedo-methods of an event within the play function? My efforts have been unsuccessful, perhaps because the function is being called in the wrong environment…

jamshark70 · November 16, 2019, 11:13pm

You don’t have to pass it. Just use currentEnvironment.

For the other questions, it’s not clear how you’re currently trying to use those features, so it isn’t clear what the problem could be. More details, please.

hjh

semiquaver · November 16, 2019, 11:23pm

thanks for the speedy reply!

re: pseudo methods here is an example

e=(n:1,m:{|self| self.n+1},play:{~m})

e.m returns 1 but e.play does not

any way to do this?

(the reason is that I’ve already written a bunch of pseudo-methods but want the Events to be “played” by for example Pseq …

semiquaver · November 17, 2019, 5:30am

OK figured out the above at least!!.

need to write (n:1,m: {|self| self.n+1}, play: { ~m.(currentEnvironmemt)})

I have to say I wish the syntax was consistent between play and pseudomethods!! ie that I might write
play:{|self|self.m} instead!

jamshark70 · November 17, 2019, 8:28am

Event:play predates pseudomethods by some years, so it did not take future programming interface developments into account.

github.com

supercollider/supercollider/blob/36cbdde009871818de78fcf7f7d6c842bf94ff29/SCClassLibrary/Common/Collections/Event.sc#L73


      
          		// implemented by primitive for speed
          		var delta;
          		delta = this.at('delta');
          		if (delta.notNil, { ^delta },{ ^this.at('dur') * this.at('stretch') });
          		*/
          	}
          	play {
          		if (parent.isNil) {
          			parent = defaultParentEvent;
          		};
          		this.use {
          			this[\play].value;
          		};
          		//		^this.delta
          	}
          
          	isRest {
          		_Event_IsRest
          		// In theory, we should never get here unless the Event object is corrupted.
          		^this.primitiveFailed;
          	}

Here, the event being played is used, meaning that it becomes the current environment. In the next line, the play function is evaluated, without passing the environment as an argument, because the play function already has access to the currentEnvironment – hence (at that time, without any anticipation of pseudomethods that were some years in the future), the argument was redundant and omitted.

You could make a case that the redundancy would be desirable now, because we have pseudomethods and play could now mimic that interface.

I’d submit this counterexample:

~a = 1;
~b = (a: 10, printA: { ~a.postln }, play: { ~a.postln });

~b.printA;
-> 1

~b.play;
-> 10

Pseudomethods access outside environment variables by James McCartney’s design. But play does not.

So, play is and always will be not just a pseudomethod, because it has a special purpose and a distinct implementation. That cannot change without breaking events’ base functionality. Hence play cannot be truly compatible with pseudomethods and probably shouldn’t pretend to be.

hjh

semiquaver · November 17, 2019, 10:57pm

Thanks for that James - and indeed for all the help I’ve gotten from resources you have provided here and elsewhere!

… Now I’m at the point where ~myEvent.play and Pseq([~myEvent])play produce different results!

I’m having to write Pseq([~myEvent]).play(t,~funs) where ~funs is the parent of ~myEvent and has the now working play method…

Ill have to read up on the difference and precedence of parent, proto, and Event type play methods to get a handle on this…

jamshark70 · November 17, 2019, 11:45pm

I’m curious, then, how you’re defining the parent event? If myEvent already includes the prototype, I don’t think you should have to specify it again in play.

hjh

semiquaver · November 18, 2019, 1:00am

Without dragging you through my spaghetti code try this:

a=(x:1,play:{~x.postln})
b=(parent:a)
b.play //1
Pseq([b]).play //?
Pseq([b]).play(TempoClock,a) //1

jamshark70 · November 18, 2019, 4:35am

Oh ok, I remember now. Events hardcoded into a pattern don’t just yield directly, so the parent values don’t go through.

When evaluating an event stream, there’s always an “event in progress.” So, what happens if the pattern puts a few values into the event-in-progress, and then something else returns a hardcoded event?

If we just go with the hardcoded event, then you lose all the other items already put in… that’s not good. So in this case we copy values from the hardcoded event into the event-in-progress… but we copy only from the top layer, not recursively through parent and proto. So it uses the parent from the event prototype passed into play.

Sorry that I had forgotten this.

Have a look at Event.addEventType. This can save a parent event in a global collection, associated with an event type name. So you would specify the play function and parent here, and then recall them both by type: \myEvent in an event, or \type, \myEvent in a Pbind. This should be better than trying to manage it yourself.

hjh