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?
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(?).
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.
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.
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
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.
