Logic for multiple repeatCount, sustainCount in MSL

alexs1

I'm looking for a way to execute this and have tried these two approaches:

function OnRepeat {
if repeatCount == 1 Reset
else if repeatCount == 2 TrackReset
}

function OnRepeat {
if repeatCount == 1 Reset
if repeatCount == 2 TrackReset
}

and similar for sustainCount. When I write it like this, I'm only getting the first "double-click" Reset and nothing on the triple-click TrackReset, but also no compilation errors. Is there some logic I'm missing?

jeff

This is something I added recently that got buried among all the other b42 release notes.

You have to pick a limit now for a #repeat script, and it defaults to 1. This was to prevent OnRepeat from being called an unexpected number of times if you're an aggressive tapper. A lot of posted examples were doing this:

function OnRepeat {
   if repeatCount == 1 ...do something
}

That repeatCount test was necessary to reject any clicks after the first one so you wouldn't do the repeat behavior over again by accident. Since I think single-repeat is by far the most common way to use this, it's a shame you always have to put that guard in there.

So now, you will get a repeatCount greater than 1 only if you allow it. You do that with an argument in the #repeat directive.

#repeat limit 2

The same applies to #sustain.

alexs1

@jeff

Is there a way to tell scripts to bypass whichever function is executed in previous clicks?

So like in this script,

#repeat 400 limit 2
function OnRepeat {
in $1
if repeatCount == 1 Mute
if repeatCount == 2 InstantMultiply
}

Double-clicking Mutes and triple-clicking does InstantMultiply, but on triple-click, it also adds a quantized Mute from the double-click. Is there a way to skip/cancel the first action (Mute) if there's a triple click (and so forth)? I thought "else" might work in front of repeatCount == 2, but it didn't change anything.

jeff

alexs1

For repeat behavior, think of each click as being the same as what would happen if you weren't using a multi-click script, but just had separate buttons for Mute and InstantMultiply. You're effectively pressing the Mute button first, then the InstantMultiply button, they're unrelated things that happened one after the other.

What's different about a script is that in the repeatCount == 2 block, it can assume that a Mute had been done previously and try to cancel it. This is possible with Undo but it's sensitive to the environment. If the Mute was quantized, and is happening far enough in the future that you get that third click in on time, then Undo should cancel the Mute event.

if repeatCount == 2 { Undo InstantMultiply}

The problem is that this is sensitive to there being quantization enabled for the Mute. If quantize was off, then there would be no Mute event since the Mute happened instantly, and the Undo would probably Undo the entire layer you were in the middle of recording. Undo works by taking future quantized events away one at a time and when there are no more events it undoes the layer.

So you could test for quantization like this:

if repeatCount == 2 {if quantize != :off Undo InstantMultiiply}

If quantize was indeed off it won't undo the Mute so you would have to add more logic to turn Mute off since it has already happened, probably this but I'd have to test it.

if repeatCount == 2 {if quantize != :off Undo else Mute InstantMultiply}

It's not 100% robust but should work most of the time. What would be better is something that could ask "do you have a mute scheduled and if so undo it" without having to make assumptions about quantize. Maybe Undo(:Mute) that does nothing if there isn't actually a Mute scheduled.

Depending on what you're doing on the earlier clicks, it may not be possible to use Undo to make it like it never happened. In those cases, you can use OnTimeout rather than OnRepeat to make decisions after all the clicks have come in, rather than while they are coming in.

function OnTimeout {
     ...same as what you started with...
}

The tradeoff of course is that there will be lag before anything happens, determined by the repeat timeout which is 400 milliseconds in your example. For some things that may not matter, but it isn't great if the second click does something that needs to be timed accurately.

alexs1

jeff

I’ll try those lines, thanks. If I remember correctly, there was a “cancel” statement in MOS, right? Did that tranfer to MSL, or is Undo the new cancel?

alexs1

jeff if repeatCount == 2 {if quantize != :off Undo else Mute InstantMultiply}

That does the trick, thank you!

jeff

Cancel was used to cancel script Wait statements. It was pretty obscure and MSL doesn't have anything like it yet. If it did, it would behave something like this:

wait loop Mute

function OnRepeat {
  Cancel wait
}

What that would do is start waiting for the end of the loop, then do a Mute. If for some reason you didn't have a dedicated button for Mute and this script was the only way to Mute, and you wanted to Mute without waiting, you could double-click the script button, the "wait loop" would be ended, the main body of the script would continue, and the Mute would happen at that moment. You could also use Cancel without the "wait" after it to cancel the entire script so that nothing more would happen. It was an experiment that never got very far, and there are other things it should be able to do to make it more useful. I originally intended it work work like "End Task" in the Windows Task Manager so you could cancel a runaway script that was in an infinite loop, or crashed in some way.

Undo is sort of like Undo in a word processor. It tries to remove the last change you made to the loop. It does some other things too derived from the EDP, and some things the EDP didn't do so it's kind of a mess describing exactly what it does. But most of the time you can think of it as canceling any events you have scheduled for the future (quantized functions, loop switch, synchronized record endings). It does those one at a time in reverse order, and you would see them disappearing from the loop meter. When there are no more events to remove, it starts trying to remove any "edits" you made to the loop during the most recent pass. This is where it gets fuzzy. Most of the time time what this means is to throw away the current layer you have been working on, and returning to the previous layer, you would see the little yellow rectangle in the Layer Bar move backward. This is how you can undo the effects of a previous edit like Overdub, Replace, InstantMultiply etc.

It isn't perfect though, there are many things you can do that aren't added to a history list for Undo. Doing a Halfspeed or Reverse or changing the Output level are all technically changes you made that you might want to undo, but since those aren't "edits" there is no history of them. The EDP has some very specific behavior around Undo, and even has several variants of Undo, so whenever I change that I sometimes get complaints. It's been a low-priority goal to revisit this and come up with a list of all the things Undo might do and let you pick and choose those so you can either have it work more like the EDP, or more like a word processor, or something in between.

alexs1

jeff Cancel was used to cancel script Wait statements. It was pretty obscure and MSL doesn't have anything like it yet.

There are a few mos scripts I had where I needed cancel for that reason. They're still working, but it would be nice to translate them fully with an MSL cancel in the future.