Midi Remote Problems Can't Load UI Created Script

The first go around making a MIDI Remote with the GUI seemed to work.

Edit: content not important to issue

Here is what I did. I created MRs for both a Launchpad mini, and a Launch Control XL.
I copied the JSON file to another computer and … nothing.

So @Jochen_Trappe said to export the .midiremote file… So I exported and tried to import on the other machine. NOTHING.

So I unplugged the two devices and went back to the other computer, plugged them in, and, NOTHING.

Maybe I need to map them. I get this:

So I enter the info for the XL… I get an empty surface, as if it has never seen this surface before.

Does this mean that you can’t assign the port for the already created script?

Why can’t I connect my already created script to the device?

Here are the files.

E.zip (38.0 KB)

Hi @oqion ,

I didn’t reference Logic :wink:

Sharing scripts between Mac and Windows doesn’t work at the moment, because the port names differ. Our first maintenance update will have a fix for that. Are you sharing between two different Operating Systems?

Sorry again, I’m frustrated. I had a big high, and then a big letdown, and now I’m having issues.

No, I’m on two PCs.

1 Like

When I unplug and then re-plug in the devices it looses the ability to connect the MR to them.
Even on the same PC

There was no actual scripting here. Just through the UI.

I was writing scripts, but since the features I intended to use are not there, everything that is available to do, that I feel the need for can be done with the UI version of script writing.

Still learning the scripting, but at the moment, I just want to get the vanilla MRs working again and make music.

I made some progress. The USB port you connect the device to matters.

When I reconnect the device to the same USB port [AND reboot] on the computer where the MR was created it works again. But that does not fix the issue with transferring scripts between computers.

Is there a way to tell Cubase to use a particular port?
Is it possible to create the script using the UI and then edit it in Code?
My guess is that it is looking for an exact string.

I lost Non-Script created MR when swapping from one port to another.

The “_globalmappings.json” file reset to 1KB which was concerning. I’m now backing up the folder each time I make a save - just incase!

I had blocked and then enabled the script in-between, so it may be related? But I’ve certainly experienced losing mappings already, just need to recreate to report as a bug(?).

1 Like

Windows renames the device every time it is plugged in to a different USB port. It was “Launchpad Control XL”, but it became “2-Launchpad Control XL”. It looks like the default script which uses the JSON file is saving the name, but not putting it in the JSON file. If it were there, I could move it to the other computer and change the name, and I bet it would work.

However for the LPmini that isn’t going to be a solution, (I have 3 I use for various things.) and it means that it isn’t going to work to share GUI generated scripts because they are always going to look for the specific name, rather than the MIDI ID + Instance ID.

I also validated that there is no way to assign as script to a specific port, which makes things difficult if you are coding. You can change the identification code later, but basing the identification primarily on the name, and not an assignment to a port is unfortunate. Seems like a lot of work to code for something that could have just been ‘use this port’.

This happens with Generic Remotes too. I have had to go and change the assignment a number of times, and usually when moving things around, and reconnecting, or buying a new USB hub.

I expected to be able to double click on the script and assign it, or to go to where the Generic Remotes are in Studio Setup and set the port there. No such luck.

I could try and create a new MR on the other computer and then edit the JSON and _globalmappings.json file and restart or something… I wonder if that will work.

If the script it creates were in plain js (or better yet ts) then I could just edit that. This would be really great as well because editing an existing script that is already mapped out would be easier than writing one from scratch.

no need to change that file

This is very “hacky”, but please try this:

  1. open the scripts json file in a text editor (Visual Studio Code is my recommendation)
    • search for “DetectionInputNameFilterEquals”.
    • replace it with “DetectionInputNameFilterContains”.
      The same for the output:
    • search for “DetectionOutputNameFilterEquals”
    • replace it with “DetectionOutputNameFilterContains”.

I haven’t even tried it. Would be interesting to see if that works.


Unfortunately that did not work.

In fact, editing that file made the script not show up any more which surprised me, so I did it 3 times.

Reimported the .midiremote file from the laptop, and that would come up, but not work properly.
Then I edited the lines you suggest, and reload the scripts.

Reimported the .midiremote file.
Tried stopping Cubase, editing the file, then restarting Cubase, and reload the scripts.

Reimported the .midiremote file
stopping Cubase, editing the file.
Tried putting it back to “equals” with the value it is showing up as this time around.
Then restarting Cubase, and reload the scripts.

The Script simply does not show up.

I don’t understand why port detection needs to occur within the JS. Surely this is better dealt with by the MR interface within Cubase?

I appreciate that the automated task of recognising a device and loading a script is nice. However, could this not just be an option in the API to leave it to end user choice? i.e. they enable a script and then pick the ports it will use - simplicity!

The other issue is for sharing scripts whereby the user already has a device using that port - surely it’s easier to offer the option to pick a script and set the in/out port via the MR interface in Cubase?

Much easier for a user to diagnose and fix any issues in future, and offers free choice to pick a script as a comparison to what they use already(?).

@oqion I noticed the Jochen named those methods as ‘detection’ prefixes, you didn’t accidentally use that did you? Looking at the docs they’re all ‘expect’ prefix:-

  • expectInputNameContains (filterValue : string ) : this
  • expectInputNameEquals (filterValue : string ) : this
  • expectInputNameStartsWith (filterValue : string ) : this
  • expectInputNameEndsWith (filterValue : string ) : this
  • expectOutputNameContains (filterValue : string ) : this
  • expectOutputNameEquals (filterValue : string ) : this
  • expectOutputNameStartsWith (filterValue : string ) : this
  • expectOutputNameEndsWith (filterValue : string ) : this

Edit: Oops, ignore me - Just read below that Jochen was refering to .json file edits, not .js :slight_smile:


the json-scripts work differently. The names are without the method-name-prefix there. But PLEEEEEAAAAAASE do not edit the json files. It’s only meant for machine reading/writing. The object-id solution is VERY LIKELY TO DO WRONG when modifying as a human.

1 Like

I just wanted one user to make a “hacky” test for me, it’s not a use case
:point_up: :nerd_face: