Quant and Pdefn redefintion

I’m experiencing instability trying to use quant to have redefinitions of sequences using Pdefn happen at the proper timing:

First, evaluating the following plays two lines to demonstrate a 8-note line lining up with a 4-note line (such that the first note of the 8-note line always plays with the first note of the 4-note line):

TempoClock.tempo = 2;


While that is playing, evaluating the following simply changes the 8-note line.


The expectation is that after redefinition, it would continue to line up with the 4-note sequence. Instead at times it transitions at a more or less random spot.

Any hints on how to lock this down?

It appears that if I reset TempoClock.default the problem is resolved, i.e. have the code above start with TempoClock.default = TempoClock(2).

Ultimately, quant.nextTimeOnGrid relies on a clock whose beats value is lined up with pattern initialization, which is used by PfinQuant via PatternProxy to compute the stream change.

Now my question would be whether clobbering TempoClock.default is the best way to handle this.

Then the problem is that your time grid is defined inconsistently in different parts of the code.

.quant=8 means that Pdefn(\a) should use 8-beat units as its base time.

Ppar( ... ).play means that the pattern’s base time is purely arbitrary – could happen at any time, without respect to any beat multiples.

If you start Ppar at, say, beat 67.373 and then update Pdefn(\a) at an 8-beat multiple, the update will not be synced with the audible 2x barlines (75.373, 83.373 etc).

// using LCM of shown quant values = 8

	Pn(Pbind(\degree,Pdefn(\b),\octave,4),inf)]).play(quant: 8);

(It’s a weakness in the baseline pattern system that important playback properties, such as quant, must be specified every time you .play. Pdef maintains its own quant and clock but not protoEvent so you might get better mileage by wrapping your Ppar in a Pdef.)


1 Like