Not with exactly the same syntax. run is not an action; it’s a function in the function library. This was required in order to get the result from the call.
[(press){launch:“Cubase_GoToLeftLocatorJ.app”}]
[(press){@l_result:#run("Cubase_GoToLeftLocatorJ.app")#}]
@Gunnar May I ask you what are the benefits of storing the user variables in lowercase? Why not saving them as user writes it?
It’s not that one principle is superior to the other. Case sensitivity lets you have variables with the “same” name, differing only in case, which can cause confusion when you think you’re accessing the same variable but, by mistake, use a different case. Case-insensitivity gives you a more relaxed syntax where case doesn’t matter, with the restriction that you can’t have variables that differ only in case.
I had to choose one or the other, and to be honest, I don’t fully remember why I chose case-insensitive variables. Looking at it now, I think it makes sense in the midiScript world since everything (more or less) is case-insensitive there. And I cannot recall anyone having any problems with that.
In JavaScript, it might feel a bit out of place, since JavaScript, by definition, IS case-sensitive. But because global variables are shared between midiScript and JavaScript, I think the best solution is to keep the same principle in both worlds.
In my view, the issue is that I overlooked one or two instances where the variable name given to the OnGlobalVariableChanged function remained in its original case rather than being converted to lowercase.
Agree. I never had any problem with the lowercase conversion. I think that the first time you explain it (at least to me) was during the beta development where the variables window was implemented. As all vars are shown in lowercase, you explained the reason was the conversion to lowercase.
Agree it is not a problem in midiscript, as you sayd.
But IMO is very weird to not find a variable “myCamelCase“ correctly written, but find it “wrongly written“ as “mycamelcase“ in js. Frankly speaking, this weird behaviour has been the trigger to ask myself: “why the midi plugin is doing this conversion? what are the benefits?“
Don’t know if it’s feasable or a bad idea, but I was thinking of storing the variables as pairs instead of single vars.
Now the variable “myCamelCase“ is stored as “mycamelcase“.
What do you think of storing it as {“mycamelcase”,”myCamelCase”} ?
This would be useful to show the variables in the variables window in the format that user entered every character.
And also you could use the pair for the comparisons in “OnGlobalVariableChanged“.
So what should I do when you spell it wrong and use ”MyCamelCase” and other variations?
When I type correctly “myCamelCase“ → the midi plugin stores {“mycamelcase”,”myCamelCase”}
When I type wrongly “MyCamelCase“ → the midi plugin stores {“mycamelcase”,”MyCamelCase”}
In both cases, the midi plugin is storing “mycamelcase“ as it is doig now. But in addition is storing the user “format”.
If the user types a wrong format, it is the user responsability.
Anyway, I think nowadays it is easy to type vars correctly if you use a proper application. Also, in the case you type something wrong, it is very easy to detect it also.
I can’t have a system where variables have two names, where one name changes depending on the last writer.
The variable system must be either case-sensitive or not, not some odd hybrid of both.
As I understand it, the main drawback of the current setup is the need to use lowercase when checking the variable name in OnGlobalVariableChanged. While I realize this isn’t aligned with JavaScript’s default case-sensitivity, I don’t see it as a major issue. Rewriting the whole variable system to handle case sensitivity would be time-consuming and cause significant breaking changes for midiScript. Honestly, I believe there are more pressing priorities for the plugin.
I could add it to the wish list and see if I have time later to implement a configurable system so users can choose which version they want.
I dont’ want to break your balls @Gunnar but as far as I have understood the variable system, the new js script sytem is not a case-sensivity system except for OnGlobalVariableChanged. That makes the current js scripting system “a little bit hybrid”.
I have dozens of midiScripts and zero javascripts of he Midi plugin, so it is not an issue that affects to me. I’m just trying to give you some feedback from outside, in benefit of the plugin, not in my benefit.
If you think it will be difficult to “improve“ the OnGlobalVariableChanged case-sensivity, or it will be hard to implement an option to enable/disable the “auto-conversion-to-lowercase-variable-storage-system”, just don’t do it.
Maybe a recommendation for new users to declare variables in lowercase in the documentation would be useful. If new users store all variables in lowercase, this kind of problems are gone.
I will not say nothing more regarding OnGlobalVariableChanged. Sorry if I have been boring, that was not my intention.
I have been testing deeply the new run “action”, mainly in midiScripts.
It works perfectly for sending and receiving values to/from BetterTouchTool, for triggering macros in Keyboard Maestro, for triggering Performs and Timers in Bome Midi Translator Pro, and for running background apps without stealing the focus from the frontmost app.
Thanks for this addition!