Sorry for the lack of updates this past week, I've been obsessed with "RC-505 mode", and this
brought up a number of interesting issues related to scripting and visualizing things in the display
area. It's taking a while to finish, but I think this is going to be a very interesting foundation
for customization in the future.

Basically the issue is this...

The RC-505 has a button called Undo/Redo that toggles. When it is "lit" it changes the behavior
of the buttons. This can be simulated using MSL "static variables". These are variables that hold their value across executions of the script:

 export variable 505UndoRedo

With that variable defined, in a binding or through some other means set that variable to 0 or 1. The script can then test this to decide what to do:

if 505UndoRedo equals 0 {
     ...do Record/Overdub
}
else {
    ...do Undo/Redo
}

We have done things like this in the past. But the problem is that there is no way for the performer to see what the value of that variable is. You have to remember that you pressed the Undo/Redo footswitch at some time in the past and that some of the other footswitches are now going to behave differently. Imagine if that 505 button didn't light up when it was active. How would you know it is on? Maybe you didn't press it hard enough and it's not actually on. Maybe some other switch sent a command to turn it off by accident. These kinds of visual clues are important for buttons that have modal behavior.

There are similar issues with "sequential switches", switches that do something different each time you press it: Record/Overdub/Reverse/Halfspeed/Reverse/Fullspeed...whatever. Unless you pay close attention to what you're doing, it can be hard to remember where you are in this sequence, to know what that switch is going to do the next time you press it.

What is needed is something you can place in the Mobius UI that shows the value of an MSL variable. This is conceptually similar to the Instant Parameters that show the values of a few selected looping parameters. But for customizations like 505 Mode, Mobius can't build those kinds of display widgets into the application. It doesn't know what "505 Mode" is. It's just a user script that sets some variables and there is no knowledge of what those variables mean or how they should be displayed.

It's the same issue that configurable control surfaces like TouchOSC have. You have to program it to know that when certain things happen, the color of a button shown on the screen needs to be red. Mobius is inching toward this by allowing UI elements to be defined in scripts and associated with an MSL variable. Those elements then be added to the main Mobius status area, or within each track strip, just like the built-in elements. These elements continually monitor the value of MSL variables you configure and when those variables change, the element changes its appearance.

There will eventually be a UI to configure all this, but it's actually easier to define these
inside the script along with the variables you want to use. A simple example:

init {
  InstallUIElement("505 Undo/Redo Mode" "Light" "505UndoRedo" ["onColor" "red" "offColor" "blue"])
}
export variable 505UndoRedo = 0

The init{} is called an Initialization Block. It is script code that is run every time this script
is loaded from the file file system. It can be used to prepare things for use, without actually running any of the functions in the script. In this case it is calling the system function InstallUIElement
to register a custom UI element whose name is "505 Undo/Redo Mode" and that is visualized by something called "Light". It monitors the MSL variable named "505UndoRedo". The part in [] brackets are options that can be set in the "Light" visualizer. It has two properties, onColor and offColor which can be any color name. Other visualizers may have different properties.

The visualizers are built in to the Mobius application. There are a set of these like Light, Text,
Thermometer, Button, and Slider. You can't add new custom visualizers but you can control how they display with visuaiizer properties, and tell them what variables they need to watch. We'll start with a few basic visualizers but add more over time. These can be placed anywhere in the Mobius UI, dragged around, resized, hidden, etc. This is somewhat like how TouchOSC is configured, except that you're not dealing with MIDI or OSC messages flying back and forth over a network, it is directly integrated with the MSL scripting engine.

Once the palette of visualizers becomes powerful enough, you could completely replace the current Mobius user interface. We're months away from that, but this is the direction I'd like to go.

If you want to combine this with something like TouchOSC on an iPad, what is being put into place
here provides a foundation for making that easier. This is an evolution of what has been called
"event scripts". I'm still finalizing the details around that, but imagine this:

init {
  OnChange("505UndoRedo" "DoMyThing")
}
function DoMyThing() {
  MidiOut(...)
}

OnChange establishes a "listener" for the variable named 505UndoRedo. Whenever that variable
changes it calls the function DoMyThing. This function sends a MIDI message to TouchOSC.

So you might be wondering, Where the heck is 505 Mode in all this? Well I got side tracked on
parts of the infrastructure to make that happen so an actual 505 Mode won't be ready for awhile.
But I believe the pieces are falling into place.