Is there a simple way to stack-quantize functions?

alexs1

In a nutshell, I'm trying to write a #repeat script where multiple presses of the trigger will stack-quantize any function/script in order to delay how far in advance I want something to cue something in.

For example, I want to stack-quantize Mute, so that if I rapid-press 5 times, it will wait the duration of 5 loops/cycles/subcycles until it Mutes. essentially, the Mute gets cued for as many times as I want it to defer.

#name Stack Quantize Mute #focused #repeat 400 if repeatCount + 1 {wait loop} Mute

All this does is stack "wait" text on the UI meter, but even that seems limited to three, and the Mute executes after only one loop wrap. This applies to any function/script, ideally, so I could in theory have it wait 5 loops, then rapid press "Overdub" so it comes in 2 loops after the Mute.

jeff

I don't have time to go into this in detail right now, but this is a very interesting idea. It's kind of like how NextLoop works if you quantize it, and every time you push it it changes the loop number of the existing NextLoop rather than stacking a bunch of individual NextLoops.

There are two approaches to this I see 1) deferred event scheduling, and 2) post-scheduling event editing.

With 1, the script doesn't schedule the Mute right away, it waits for you to click more times and when you're done, it counts the number of clicks and puts the Mute where you want it.

With 2, the Mute gets scheduled immediately, but when you click again it modifies the Mute that is already there rather than scheduling another one. The way quantization works now, if you have a Mute (or anything else) already quantized, doing Mute again will put it on the next quantization point after the one that is already there. This has been used for years to stack a sequence of Replace functions to create a list of "punch ins" that happen automatically as the loop plays once. That's behavior I want to keep, and this new thing conflicts with that so we'll need to work out how to allow both behaviors to be accessible.

alexs1

jeff

jeff With 2, the Mute gets scheduled immediately, but when you click again it modifies the Mute that is already there rather than scheduling another one.

Weighing the two, my impression is that 2 feels more intuitive, but does that also cover overlapping functions? For example, if I wanted to cue Mute 5 loops ahead, Reverse 7 loops ahead, and Halfspeed also 7 loops ahead, would they all be able to fire in the sequence I set with post-scheduling event editing? Or would it depend on the function type?

Also, on a different yet related note, in an earlier thread, someone was trying to use the wait statement to set up a sequence in MSL, and I wasn't able to get it to work as simply as I thought. In the end, I hacked out a solution with some creative problem-solving, but any more loops than 2 using wait wasn't scheduling as expected.

To bring it back on topic, would stacking wait with a #repeat directive, i.e. setting a variable for each #repeat click to add another wait, be a viable solution for MSL to accomplish this sort of cue-ing/scheduling idea?

Also, FWIW, I think it would be nice if any function were applicable, including NextLoop and PrevLoop. For instance, being able to focus 5 tracks and then schedule them to NextLoop after x event deferrals (where x is number of clicks).