I have made a midi remote script that is sending the names of all the functions I have assigned to each button to my midi device via sysex. This means my device can display this info, and it works.
However, If I assign a macro to a button, I can’t figure out how to obtain the name of the macro. objectTitle just comes up as blank.
These functions you’re referring to, are actually hostValues in terms of the midi remote, so various mOn events work.
When it comes to commands and macros, we need to use a different approach.
Say we want that upon triggering the “Duplicate” command to send “Duplicate” to our controller.
Upon binding, we can do this:
//hard-code the message, in our case this can be Duplicate
//send Your Sysex Here. Value is NOT the name of the command, you have to supply it.
Thanks for the reply, much appreciated. I will try this out later when I have it in front of me.
My initial reaction is that having the names of the macros hard coded in the script is undesirable, or am i misunderstanding what you are suggesting?
One of the very cool things I have working now with the regular Cubase functions (eg transport controls) is that if the user re-assigns the buttons and changes things around to suit them, the display on my device updates immediately to match. And I was hoping to get that same behavior on macros too. I know not everyone even uses macros, but I do.
Another annoyance is that some functions like the Edit Instrument window, are only relevant on instrument tracks. so if I assign that function to one of my buttons it appears and works fine on an instrument track, but if I select an audio track the button name goes blank. It would be cooler if there was a way to keep the button name, but detect that this function wont work on this track type and so I can grey it out or something rather than it go blank.
Please note that this is not just for macros. All Key commands behave this way too. The reason it may seems that they work is because there is an overlap between some key commands and hostValues, for example the command “Start” is actually the page.mHostAccess.mTransport.mValue.mStart. But when you bind this one, it’s not the command that sends its title, but the hostValue.
Currently you have to use the hard-coded workaround for your own assignments in the script and I totally understand this is unfortunate when it comes to users altering the assignments.
In this case, a json file is generated in the dir …Cubase\Midi Remote\User Settings.
If you open this one, you’ll see the user bindings.
IF you could import this json to your script, it would be trivial to do exactly what you want by carefully parsing it. However, this is not possible (at least for now), since the compiler doesn’t contain the --resolveJsonModule param.
At the end of the day, though I do too send the commands to one of my controllers upon execution, I’m not sure this is really useful. It’s much more useful that the user sees the bound commands in the UI. After some time, we all get to memorise our assignments, and isn’t this the point of “shortcuts”?
I am building a controller based around a RP2040 (raspberry pi pico). It has a 320x240 display and a 4x4 grid of mechanical RGB illuminated keys. It’s still on breadboard but it’s a fun project that’s progressing well.
It is a midi device, so sadly it cannot access the file system on the host computer where the json file is.
Couple of ideas though:
Maybe I could make a small application that reads the json and sends the important bits of info via sysex to the midi port.
If I define some pages within the script, I am able to detect when each one activates and deactivates, and send midi sysex at that moment. This works fine, I don’t have it in front of me, but I think I was using mOnActivate (or something similar).
I cant figure out how to do the same when a user defined page activates or deactivates, is there a way to do that?
Also is there a way to fetch the user defined name?
As far as I know, no, there’s no way of knowing this one, because we’re talking about mapping pages not defined inside the script.
The way I dealt with this one, was to create blank user pages, the size of this array is defined in a config file users have access to, so I can have the control on their mOnActivate and deactivate events. If a user decides to add more user pages, without editing the config file first, is perfectly fine, but out of the context of the script.