Fancy Quantization

dani

Apologies if this has already been discussed in the forum.
Generally I have most of my functions (like Mute, NextTrack,...) quantized to cycle. This way, I don't have to time them as accurately. However I tend to be a bit chaotic and forget to do it in the previous cycle, this often leads to the function taking effect one cycle to late.
So I wrote a script, which will happen instantaneously when I just miss the quantization point, but will be quantized on the cycle when I activate it the cycle earlier:

#name MuteFancy

function modulo(x y) { x - ((x / y) * y) }
var grace_frac = 2                                                   // 2 = half of a tick (beat)
var ticknumber = autoRecordUnits*subcycles*grace_frac                // total number of ticks (assumption: autoRecordUnits =number of cycles)
var scaled_frame = ScaleRange(loopFrame loopFrames ticknumber)       // current tick-position of playback
var reltick = modulo(scaled_frame subcycles*grace_frac)              // current tick-position in cycle; ticks per cycle = subcycles*grace_frac

if reltick == 0 {
  Mute(quantize=:off)
} else {
  Mute(quantize=:cycle)
}

So what this script does, is if pressed in the first half of the first tick (so on 1 until the upbeat), it will activate Mute instantaneously, similar to padded record.

Some questions I have:

The number of cycles in a loop are not always equal to the autoRecordUnits. Is there a way to get them in msl? Or is there an easier way to return the current position within a cycle?
Also, how to do float division/calculate with floats in msl/typecasting?
Is there a way to override (loop) switch quantization other than changing the global option? I see the parameters in bindings, but changing quantize does not affect it, it always seems to follow the switch quantize option.

jeff

dani I need to digest this some more, but I love this. Great use of scripts. Yes, it's like late start padded record but could be generalized for any type of quantization. I'm thinking this should be something built-in. The EDP had something similar, though I don't know if it applied to every function or just a few. I forget what they called it, I thought of it as "quantization gravity" where if you're close enough it pulls you back in. It works well for things like Mute where it doesn't really matter what happened during that gap period, it's a little harder for Multiply and Replace where the start point is more significant. It would add a few more knobs to the space shuttle, but I think it's broadly useful.

"The number of cycles in a loop are not always equal to the autoRecordUnits. Is there a way to get them in msl? Or is there an easier way to return the current position within a cycle?"

You can get the number of cycles with the cycleCount variable. That plus math with loopFrames can get the location within the current cycle. Something like:

  var cycleLength = loopFrames / cycleCount
  var cycleLocation = modulo(loopFrame cycleLength)

I've noticed that the cycle count after sync or auto recording is inconsistent and unpredictable. There are a few schools of thought there. Does the entire first recording constitute one cycle, or is it broken up by sync unit or auto record unit? For auto-record of larger units, like track cycles, it makes sense to have multiple cycles as they are added, but for host bar recording, it ends up with a cycle per bar which feels too fine grained. Definitely need more control over this.

"Also, how to do float division/calculate with floats in msl/typecasting?"

Floats aren't fully supported in MSL yet. There is a model for them internally, but the expression interpreter usually auto-casts to an int since floats aren't really a thing for parameter values and function arguments. As we start doing more complex math in scripts though I can see where they could be necessary to avoid roundoff errors.

Currently the result of a / will be an truncated integer.

Is there a way to override (loop) switch quantization other than changing the global option? I see the parameters in bindings, but changing quantize does not affect it, it always seems to follow the switch quantize option.

This was something inherited from the EDP where there is a separate parameter for switch quantization. Currently in a script you would need to override that parameter rather than quantize:

  NextLoop(switchQuantize=:off)

If would be nice if within scripts and bindings quantize was just treated as the universal argument for specifying quantization, but I need to retool some of the parameter resolution logic. The old Mobius code only looks at switchQuantize.