Build 43

jeff

Build 43 is mostly bug fixes for 42 with a few new features

Fixes

Fix "set bindings..." in MOS scripts
Fix !focusLock in MOS scripts
Fix Threshold Recording
Fix UI display of Alt Feedback
MIDI Program Change can now be used with #repeat scripts
Maybe fixed script MidiOut going through the host by default
Detect script renames and fix bindings to have the new name

New Features

Better snapshot management with Ordered Snapshots
#focused directive for MSL scripts
Functions ActivateBindings, DeactivateBindings, ToggleBindings to control bindings in MSL
Simplify the Configuration->Options window to make it easier to see things
Improvements to the binding UI for function arguments

Ordered Snapshots

Ordered Snapshots is a concept that replaces the previous thinking about snapshot order which was strictly chronological. When you create a snapshot, it will be automatically added to the session folder using a generated name consisting of the date and time, and will sort to the bottom of the snapshot list as shown in the Snapshot->Browse window.

Once you have snapshots created, you now control both their names, and the order they appear in the snapshot table and this order will persist as you create new snapshots. To change a snapshot name, right click on it and select Edit. This will change both the name displayed in the UI and the folder name on the file system to make it easier to find it.

To change snapshot order, simply click-hold-drag on rows in the browser table. This order is persisted and will be retained across Mobius runs.

Controlling snapshot order is mostly of interest if you plan to use the LoadSnapshot function in a script where the argument may be an index into the snapshot list.

MSL Focused Scripts

If you are familiar with Mobius 2.x MOS scripts, adding #focused to the top of an MSL script is the same as adding !focusLock to a MOS script.

Scripts by default run "globally" meaning the live above tracks, there is only one copy of them running, and they can send commands to any track using the in statement.

Scripts that use #focused behave more like built-in functions. A copy is made and sent to each track that has focus, meaning the Active Track and any tracks that have Focus Lock enabled. Focused scripts are expected to operate on one track only and do not need to use in to target specific tracks.

Binding Set Activation

A very few of you have made use of multiple binding sets, but if you did there was not a good way to select those from an MSL script. The three new functions for managing binding sets all take a binding set name as an argument.

  ActivateBindings("MIDI Fighter Twister")

  DeactivateBindings("FCB1010")

  ToggleBindings("MIDI Captain")

The decision about which function to use will depend on whether the binging set was created as an Exclusive set or an Overlay set. Only one Exclusive set may be active at a time, but multiple Overlay sets may be active at once.

ActivateBindings is normally used to select an exclusive binding set, since the others will be deactivated automatically.

DeactivateBindings and ToggleBindings are normally used to turn overlays on and off.

Binding Function Arguments

You will notice some slight changes to the function arguments are shown in the binding editor popup. This is in preparation for a much larger feature for parameter overrides in bindings, as well as the ability to pass arguments to scripts using a more guided way to specify arguments than just typing them into one long text box.

alexs1

Thanks, Jeff!

Is there currently a way to set a parameter in an MSL script so that it takes whichever value is inputted into the argument field in a binding?

For example,
#name Track Select
SelectTrack( argument )

... then set 1, 2, 3, etc., in the argument box when binding the script? So then it would SelectTrack(1) if I put 1 in the binding argument.

alexs1

Speaking of SelectTrack, it looks like the "Track to Select" option in the binding window is missing from b42. And while I'm there, I'm curious: what is the new "Change Action" button?

jeff

"Speaking of SelectTrack, it looks like the "Track to Select" option in the binding window is missing from b42. And while I'm there, I'm curious: what is the new "Change Action" button?"

I'm seeing Track To Select in b43, are you not seeing it in b43 or b42?

The Change Action button wasn't ready, but it will be what you've asked for in the past. A way to edit a binding and keep all the trigger related stuff, just change what it does. I hit this all the time testing scripts. A binding starts out doing one thing, but I want to replace that with a script that does it differently, but don't want to go through all the trigger capture gunk again.

For your other question about passing arguments to scripts and then passing those to functions like SelectTrack, the answer is yes, but I need to be AFK for awhile so I'll post an example later.

alexs1

jeff I'm seeing Track To Select in b43, are you not seeing it in b43 or b42?

Weird. Went away and came back.

jeff The Change Action button wasn't ready, but it will be what you've asked for in the past. A way to edit a binding and keep all the trigger related stuff, just change what it does.

Awesome!

jeff o for a binding argument string "6 7 8" inside the script $1 will be 6, $2 will be 7, and $3 will be 8.

Think that makes sense. Would the string inside the script look like SelectTrack($1 $2 $3), i.e., also with spaces?

jeff What is in progress, is a way to give scripts a "signature" like the built-in functions have, where you can specify the names of the arguments the script expects, and have those presented with more detail than just a text box:

Good idea!

jeff

Okay, here is an example of using script arguments. Start by creating a script like this:

#name IndirectSelectTrack
SelectTrack($1)

What $1 is is a positional reference to an argument passed to the script from the binding. since these don't (yet) have names, you have to reference them by numbers: $1, $2, $3 etc.

Where those values come from is the binding arguments which for script will be shown as a single text box labeled Arguments. Words or numbers you type in here separated by spaces become the numbered arguments. So for a binding argument string "6 7 8" inside the script $1 will be 6, $2 will be 7, and $3 will be 8.

If you want to pass the name of something that has spaces in it, you need to surround it in quotes in the binding string:

Binding Editor:

     Arguments: "My Snapshot Name"

Script:

LoadSnapshot($1)

jeff

What is in progress, is a way to give scripts a "signature" like the built-in functions have, where you can specify the names of the arguments the script expects, and have those presented with more detail than just a text box:

#name IndirectSelectTrack
#signature trackNumber:int phoneNumber:string

SelectTrack(trackNumber)
DialThePhone(phoneNumber)

Then in the binding editor instead of just "Arguments" with a text box, you would see two text boxes, the first labeled "Track Number" and the second labeled "Phone Number" where you can type the two values knowing what they mean.

jeff

alexs1 "Would the string inside the script look like SelectTrack($1 $2 $3), i.e., also with spaces?"

For functions that take multiple arguments, yes. There aren't many of those though, SelectTrack only takes one arg. LoadLoop is the only one right now, it takes three: file name, track number, loop number.

Argument string:

      "my file.wav" 3 1

Script:

   LoadLoop($1 $2 $3)

Related note for this example. For any function that takes a file name, you can shorten what you have to type in the argument box by using the User File Folder. When LoadLoop sees a filename, if it is not an absolute path like "c:\Users\jeff\whatever\my file.wav", it will look for the name you give it under the User File Folder. First at the top level, then under a subfolder named "loops". So if my UFF is set to c:\Users\jeff\mobius\userfiles and I have some .wav files like c:\Users\jeff\mobius\userfiles\loops\loop1.wav, I only need to type in loop1.wav in the arguments box for LoadLoop.

jeff

alexs1 Weird. Went away and came back.

If you saw this in build 42, there were some bugs in the binding editor popup that could have caused this if you were editing several bindings one after the other. Internally the same popup is used for each binding, with some fields being shown or hidden depending on what the binding needs. Should have been fixed in b43

alexs1

I'm getting a bug in b43 when saving a new MSL script in Win11 to the UFF/scripts. It saves as "File" type rather than "MSL File." The extension is missing, and I need to add it manually after saving or during the naming.

jeff

alexs1 I think this broke because when I was doing some MOS testing, I needed to use the script editor to save a file with the .mos extension and it wasn't letting me. So I relaxed the extension requirement to allow both, but now it won't automatically add one unless you type it in. I'll fix it to automatically add .msl if it isn't there.

What I'd like is one of those file choosers that gives you a drop-down menu of the possible extensions and auto-selects the first one. But I'm not sure I can get there through Juce.

zerocrossing

I've come across a bug in Bitwig v5.3.13, Windows 11 (latest). It's fine when I'm controlling it via MIDI, but the moment I use one of the interface buttons, the plugin crashes.

jeff

zerocrossing Strange, I don't test with Bitwig, so it's possible it has something to do with the way they manage the popup windows for plugins where I have to inject my UI. But if that were the case I'd expect other things in the UI not to work like right-click menus and other things.

Try making a keyboard binding to the same thing and see if that works. Key bindings to through a different path than MIDI bindings and are close to what the UI buttons do.

Also, let's rule out the binding action, is there anything complicated in it like arguments, Send To, etc. Make a button for plain old Record without anything extra and see if that works.