MIDI Remote: Recognize whether Cubase 12 or Cubase 13 is installed?

If I could use MIDI Remote to query whether Cubase 12 or Cubase 13 is installed, I would be able to program my scripts to use the commands available for each Cubase version correctly.

Is there a way to do this and if not a special trick for it? :innocent:

Hi, though the API exposes the app name, it doesn’t expose its version. I think there should be a feature-request for this one, it’s useful.

Now, as a workaround, you can sequence the commands like this:

var aButton=surface.makeButton(0,0,1,1)

var aDummyButton=surface.makeCustomValueVariable("aDummyButton")

var aPage=deviceDriver.mMapping.makePage("aPage")

aPage.makeCommandBinding(aButton.mSurfaceValue,'Marker', 'Add Position Marker on Selected Track').mOnValueChange=function(activeDevice,activeMapping,value){

    console.log("trying to trigger command")


aPage.makeCommandBinding(aDummyButton,'Transport','Insert Marker').mOnValueChange=function(activeDevice,activeMapping,value){
    console.log("alternative command triggered")

The trick here is that the mOnValueChange is triggered even if the command does not exist. So if you’re on CB12, the event will be raised, the original (new) command won’t be executed obviously, but then it will trigger a customVar to execute the “old” command.

If you’re on CB13, the command will get triggered, the customVar will again be changed, however, the “old” command just won’t be executed since it’s not available.

That looks interesting, m.c

And do you think on Selected Track or on Active Track suits better to the old command?

Another question:
In the API I find the function
getAppName () : string

Have you done anything with it?

The on Active Track is behaving identically to the old command. The on Selected Track can be used when we want to add a marker to the selected markers track, which can be one that is not currently active. We could use a “shift” for choosing this one.

We just get the app name, Cubase or Nuendo. Unfortunately it doesn’t return a version code. An addition of the form getAppVersion() would be good to have.

Another thing you could do, is to add a flag inside a settings file for the script, for example

var appVersionPrimary=12

and work with it inside the core script. However, users then would have to edit this settings file based on their version, and if they constantly switch (at least until they fully move to the new version) between versions, they would have to edit this file all the time.

Yes, I do that too. So far I have 7 things that can be set directly in the script.

If there are significantly more, I might program an extra application with checkboxes etc. so that the user doesn’t have to edit the settings in the script file. Maybe this application will then also have a cool name, e.g. “magic script control cockpit”. :slight_smile:

Sure, this is actually a good choice. Currently I have moved this a step further but not necessarily better, when it comes to user experience. I’m setting the midi remote to talk with an external app, and then users can select such preferences using their controller instead of a UI. It just gives the feel that we’re doing something in a hardware way :slight_smile:

I would not do that, better simply publish two versions. One for 12 and one for 13. Hassle free for the user and less work for you. To be honest, it is a shame (for Steinberg), that (power)-users need to find out version incompatibilities AND to fix that on their own. Undocumented fixes and (known) issues, just shows how much love they put into the midi remote and how much they care for people like you. Safe to say “Saftladen”.

Huge respect and KUDOS to you (CKB) and user m.c going through this and finding solutions for the rest of us.

1 Like