One of the things I've always hated is the massive number of parameters you can tweak to do things. Not that what they do is bad or useless, but the way you have to think about them is confusing. They live in a global ocean of parameters and you have to set them all up before you start doing anything with functions.
But you don't want them all to use the same settings forever, so then there were Presets you could swap between. This made sense for the EDP which being hardware had a very limited user interface, and only had one "track" to deal with.
Mobius carried this basic concept forward to multiple tracks, where each track could have a different Preset and behave differently than other tracks. But the problem with Presets is that they contained everything. If you wanted two tracks to behave the same except for one parameter, you would have to duplicate the entire Preset and change just that one parameter. So now, you've got 8 different Presets for each track that are almost exactly the same and
decide you want to change "Switch Quantize" for the day. You have to go edit 8 different Presets to have that change in every track.
Mobius 3 attempted to solve this by adding the concept of "track overrides" where you could start with a set of Global Parameters that were shared by all tracks, then for each track add an override for just those parameters you wanted to be different in that track. Then you could change the shared value for Switch Quantize and every track would get it without having to edit 8 different things.
That worked well enough on paper, but in practice I think many found this confusing. While the concept is simple, the UI to present that is hard. Then to make it even worse, to help those comming from Mobius 2 Presets I added the concept of Overlays which are like Presets in that they contain bundles of parameters you want to change all at the same time. No one ever understood those and they even make my brain bleed when I think about them.
The result is that there are many things you can do that no one ever uses, or even knows about, because they're buried under a mountain of parameters in the Session Editor, in multiple tree views, and duplicated in two places (three if you use overlays!). As always, if you have suggestions on how to improve the UI for this, bring it on! It is a simple concept with a deceptively difficult UI.
I think the fundamental problem with all this is the is the notion that you have to think about all the parameters and the way they are organized before you actually start pushing buttons and looping. The Mute button doesn't just Mute, it has to look at the parameters QuantizeMode, and Subcycles, and MuteMode to figure out what will actually happen. A lot of functions are like this, Record has a lot of options, and NextLoop is the worst.
For people coming from the EDP, or any hardware looper really, this is a familiar way of thinking about parameters. But it's worse in Mobius because of the sheer number of them, with more on the way, and the fact that you're juggling 8 loopers at a time with tracks.
In the past we've used scripts to help simplify this. If you want Mute to behave in a certain way, then write a script that sets all the parameters to what you want and then call Mute. But this requires scripts which is another hurdle for many.
So, what's the point of all these words? I'd like to try something that grew out of the work that was done for Function Specific Quantization, and may actually replace that. The notion is allowing parameter settings to be added to the Binding. You want a MIDI note bound to Mute? Sure, what kind of Mute would you like? Do you want it quantized? If so where? Do you want Unmute to start over from the beginning? All of these decisisions can be made
at the point where you are defining what the footswitch button does, in the binding. Rather than just saying I want to Mute, but I'll leave it up to the whims of the Session to decide exactly what that does.
Even if people decide not to use this, a nice thing about allowing parameters in the binding is that it shows you exactly what the parameters are that may have an effect on that function. So if you wanted to play with Slip but didn't know SlipMode existed, you could see that in the binding and either select it right in the binding, or go back to the Session Editor and hunt for it there.
For some parameters like Quantize Mode, this is actually a more flexible and simpler way of doing Function Specific Quantization that I added in build 42. Instead of setting quantize mode for Stop in yet another global configuration window, just set it in the binding for Stop when you make the binding.
Thoughts?