Huge latency spikes when using Plambda

Hey!

I’m trying to share a random-generated \dur between two patterns in a Plambda like this:

Pdef(\p1,
	Plambda(
		Ppar([
			Pbind(
				\type, \set,
				\id, ~bassoon,
				\instrument, \orangoEffects,
				\args, #[],
				\lpf, Pwhite(500,5000,inf),
				\dur, Plet(\dur1, Pwrand([0.7894, 0.7894/2], [0.3, 0.7], inf), 0)
			),
			Pbind(
				\type, \midi,
				\midiout, ~synth,
				\midicmd, \control,
				\ctlNum, 43,
				\control, Pwhite(30,105,inf),
				\dur, Pget(\dur1, 0, inf)
			);
		]);
	);
);

The thing is I remember being able to do something very similar, sending MIDI to a synth and using the same \dur value to change an effect on an instrument with the \set type. But not now.
Does anybody have insight on this?

Martin

Without running your example – it may or may not be safe to do this with Ppar.

Your example requires that the \set pattern evaluates before the MIDI pattern. But if the two are scheduled for the same time, this may not be guaranteed. (Ppar uses an internal scheduling queue. Both patterns start at 0 on this queue – which one runs first?)

One solution proposed in the documentation is to use Ptpar with a timingOffset: http://doc.sccode.org/Tutorials/A-Practical-Guide/PG_06g_Data_Sharing.html#Communicating%20values%20between%20separate%20event%20patterns (last example). I’m pretty sure timingOffset doesn’t apply to MIDI events, but that’s ok here because the offset should belong to the pattern that’s generating the rhythmic values (\set, which should respect it).

hjh

Oh, wait, here’s the problem: do not add , 0 at the end of this argument list!

So you’re replacing all your durations with 0.

hjh

1 Like

Ahaaa, that makes sense!
Thank you so much!!