Quantizing Pdef and Pbind and t.sched and Events?

Hi list,

I am trying to quantize a wild mix of Pdef, Pbind, t.sched and Events.

I have discovered that for Pdef().play(quant: 1) by default. For
Pbind().play; it is not set.

Furthermore I am trying to quantize t.sched because I want to use its
delta offset, rather than using t.play. But it seems .sched can not be
quantized without some wrappers…

The following minimal working example demonstrates my attempt:

(
t=TempoClock.new(tempo: 130/60/4)
t.sched(0, {t.beatsPerBar=1}); // one beat is one bar.
Pdef(\inC, Pbind(\dur, 1/4)).play(t);
)

(
t.play({ Pdef(\inC).stop; }); // stops at barline thanks to t.play(quant:1) default
Pbind(\dur, 1/8, \degree, Pn(4,16)).play(t, quant:1); // Starts quantized, but Pbind's quant: has to be set explicitely...
t.sched(2, { // this is not quantized
	(degree: 7).play(t); // plays unquantized, does not know quant keyword arg.
	t.play((degree: 5).play); // also plays unquantized, unexpectedly.
	Pdef(\inC).play(t); // plays quantized.
});
)

I would like to use single Events as (degree: 7).play(t) for single
notes rather than short patters. How would I go about quantizing single
Events? Neither of the two ways exemplified above seem to work.
Events seem to understand .synchWithQuant() but I can’t get it to work.

How can I schedule things using delta times AND have them quantized? I
know that .play(quant:[1,2]) is one possible way, albeit I find it hard to read.

Looking forward to all ideas!
best, Peter

The first thing, I think, is to define what “quantized delta times” means.

In fact, everything has to be scheduled according to an absolute time value – nothing is ever scheduled by delta.

(
// I'll schedule something for 2 beats later.
// Then, inspect the queue.

t = TempoClock.default;

t.sched(2, { "something".postln });

"Time is now: %\nAnd the queue is:\n".postf(t.beats);

t.queue;
)

Time is now: 92.306982081
And the queue is:
-> [ 1, 94.306982081, a Function, 0 ]

So, scheduling according to a delta time just takes the current time, adds the delta, and that’s the absolute time to wake up. That is: sched is only a wrapper around schedAbs.

Scheduling by quant takes the current time and rounds up to the next “beat in the bar” multiple of quant, then adds phase, and schedules according to this absolute time. (See nextTimeOnGrid.)

I guess that you want to add delta to the current time, then quantize this. But maybe you have something else in mind.

Then: In your other thread, I had suggested a general methodology: If the class library doesn’t provide the exact behavior you want, you can write the exact behavior into a function, and then refer to the behavior by the name to which the function is assigned.

(
// (`clock(TempoClock.default)` is an expression initializer for the arg)

~quantizedDelta = { |delta = 0, quant = 1, clock(TempoClock.default)|
	quant.nextTimeOnGrid(clock, clock.beats + delta)
};

~schedQuantDelta = { |func, delta = 0, quant = 1, clock(TempoClock.default)|
	clock.schedAbs(~quantizedDelta.(delta, quant, clock), func);
};

~playPatAtQuantDelta = { |something, delta = 0, quant = 1, clock(TempoClock.default)|
	~schedQuantDelta.({
		something.play(clock: clock, quant: 0)
	}, delta, quant, clock)
};

~playEventAtQuantDelta = { |event, delta = 0, quant = 1, clock(TempoClock.default)|
	~schedQuantDelta.({ event.play }, delta, quant, clock)
};
)

This, btw, is what programming is: The thing doesn’t do everything you wanted out of the box, so you give names to pieces of the behaviors you want, and then build on top of those names.

If functions such as these don’t appeal to you, you could create class extensions: quantizedDelta for Quant, SimpleNumber and SequenceableCollection, and playAtQuantDelta for whatever other objects you need. It’s the same idea: packaging behaviors into names. But this message is already long enough for now, could come back to that later.

hjh