Is there a way to select a set of tracks before starting a function?

alexs1

For example, if I have 8 tracks in total and am trying to line up a particular set of tracks at that moment for a function like Mute, is there a way to do that? I don't think focus lock or track groups are what I'm looking for, since those seem like they would need to be configured prior to performance. Basically, I would need a way to select multiple tracks at once so they could all respond to the same function. Is there already something like that?

jeff

Scripts are always an option, but you need to design them with particular tracks in mind, if the tracks you want to "arm" are random at any given time, then scripts don't necessarily help unless they can test things like "all tracks that are playing something" or "all tracks that are muted".

FocusLock and TrackGroup are functions you can bind to a MIDI button to set track focus or assign a group randomly as you perform, but you would need to allocate buttons for them. For example, I sometimes have buttons assigned to toggle focus lock on each of the 8 tracks, then when getting ready to do something to a set of them, I can press the focus button for each track I want to operate on, then the function I want to have sent to all of them.

One annoyance with that is that focus lock doesn't turn off after you use it for something once, so you have to remember to turn it off. Scripts can do that, say Mute all focus locked tracks then turn off focus lock in those tracks.

alexs1

jeff

Hm, I wonder what is the path of least resistance? As you mention, I can create an explicit condition in a script that would automatically turn off focus lock after executing a function. Although I'm not always sure which function I want to use, so I would most likely create a bunch of them for some of the more common ones. Plus, I sometimes like to use clickable buttons in the GUI when convenient, so that option might be a little too steep.

I think the best way to go about it currently would be binding a focus lock toggle. I already have buttons mapped out for SelectTrack for all 8 tracks in the strip. Those bindings are PC Pads, so the script I would write to replace them with would probably include a !multiclick condition: on first press, SelectTrack, and if there's a rapid second press, toggle Focus Lock. Does !multiclick work the same way in MSL?

Alternatively, maybe down the line could there be a possibility for something like a "Temporary Focus Lock" that is disabled after functions are run? Then in the "Function Behavior" category, maybe a column next to Quantize that you could check for functions that you would want to be compatible with disabling Focus Lock after they execute.

alexs1

@jeff

I decided to stick with FocusLock. Do you know if there's a way to set it with a !muticlick trigger?

Relatedly, does the !focuslock command still work at the beginning of scripts to enable them to run on focused tracks?

alexs1

@jeff

Is there an MSL !focuslock equivalent in the documentation? Something that allows scripts to be targeted and executed by Focus Lock.

jeff

Not yet. This is related to another recent post about scripts not working with group bindings.

At the moment, scripts are like global functions, they can't be given a track or group scope and they won't use focus lock.

In the beginning that's all I needed because it's possible to achieve multi-track scripts using in statements like:

    in 2 Record
    in focused {...stuff...}
    in myGroupName {...stuff...}

For scripts that operate on tracks with in you don't want those to obey binding scopes since the scoping is handled inside the script. But it's also very common to want a script that's just a function-with-benefits, and that should behave like any other function and obey binding scope.

We're going to need some keyword declarations like the old !focuslock to allow this. I'm not sure what the right combo is, it could be a single #scopable that implies all of track, group, focus scoping in the bindings. Or these could be split out with #focus meaning obeys focus lock and #scope meaning it obeys binding scope.

Binding scopes could also be implicit, if you bother to set up a script binding that has a track or group, then that always means to use that and it's up to the script author to avoid the use of in within those scripts. I suppose we could get fancy and provide something that could be tested by the script to see how it is being called...

    if bindingScope is empty {
          // no scope specified, go to town with in 
    }
   else {
        //  scope specified, limit what is done to the single target track
    }