Button-Centric Functions

dani

I would have a suggestion, which in my opinion could make Mobius more accessible for people with no programming experience. For me personally it would not make much of a difference because I have a CS background, but it would be interesting how other people feel about it.

One of the main reasons for using scripts is to assign multiple, different, functions to one button. E.g. single press is focusLock, double press is Mute, long press Overdub. At the moment, everybody who wants to achieve something like this, has to learn about the MSL syntax, learn how and where to create scripts, learn about positional arguments and functions and then test it, all for something fairly easy and standard like:

#sustain 350
#repeat 500

function OnRepeat(){ Mute}

function OnSustain(x y){ if x==1 and y > 350 {Overdub}}

function OnRelease(){FocusLock}

What I would suggest is to allow users to create "Buttons", similar to creating a button in the UI. The user can choose in a drop-down menu which functions he wants to have assigned on release (X), double click (Y) and sustain (Z) of this "button". The user then can create a midi-binding (or just show it in the UI). I would imagine, a possible way to solve this would be to create a script replacing X,Y,Z with the chosen functions (and arguments passed to the function) and store it in the scripts folder - so it could be edited afterwards.

#name XYZ
#sustain 350
#repeat 500

function OnRepeat(){Y}

function OnSustain(x y){ if x==1 and y > 350 {Z}}

function OnRelease(){X}

I know, that this would not solve everything and that it would fall short when creating more complex scripts, e.g. when making the behavior of the script react to the current mode. But creating even a very basic script would facilitate the process for new users, because the backbone of the function is already created, part of the syntax is self-explanatory, the most complicated and intimidating part of the syntax is already there and the rest could probably be solved using chatgpt and the documentation.

But I don't want to add anything to your probably already very long todo-list! Thank you for everything you do with mobius, it is bringing joy to my life every day I jam with it, which is almost every day.

jeff

Yes, you are absolutely right. This is something that I've long considered but never get around to because scripts "get you there" and it's easy to fall back on them.

You're a CS person so you'll know what I mean when I say that Mobius lacks a declarative model for describing behavior. That's what most of the more complicated apps use when they don't want to go all the way into scripting. As I go along I do look for ways to reduce the need for scripts. Binding Parameter Overrides were one of those because it was very common to have a script that did nothing but set a few parameters and call a function.

Being able to say that this binding actually does two or three things in this order, is another that would be really helpful.

And then beyond that a "long" binding that kicks in when the button is held down. "Release" bindings exist now, but I haven't talked about them much and don't think they're used often.

So yes, some kind of guided UI where you can sketch out a sequence of operations and responses to long, release and repeat that is stored as a data structure in the binding and then interpreted. It's kind of a very high level script, but you don't think of it that way in the UI, and you're not typing text so it's less error prone.

It's certainly on the list.

Your "templated script" idea is very intriguing. I had not thought of that.

jeff

This is....brilliant.

Scripts do support arguments and you can pass arguments in bindings, But it never occurred to me that you could use this to pass names of functions you wanted to plug into different parts of the script.

It would need a few enhancements, the equivalent of eval(string) in the script interpreter. A better way for scripts to declare a "signature" to guide the presentation of a UI that can select the appropriate things for each argument. But the control flow is defined by the script rather than having to write another mini-interpreter for a declarative model.

This is an elegant way to approach the problem.

Thanks for the kind words, if I can make a few people happy that's all I hope to achieve.

Howldin

Sounds very appealing to this troglodyte-level user.