Exporting and reimporting the script may work also (Greg Ondo, Club Cubase):
Do Steinberg know about the concept of ‘Hot Fix’ or is every update months apart?.
I just lost days of work in that literally hundreds of faders I created to control various parameters in VEP came up ‘unmapped’ after a relaunch of Nuendo. 
The UI becomes unbearably laggy when there are many items. And the fact that we can only use a port once means some surfaces (MetaGrid Pro) needs hundreds of items. And being able to set a preference so faders default on ‘Jump’ and not ‘Scaled’ would be very helpful. And "Transmit’ doesn’t seem to be working as well as the GR. Blah, Blah, Blah,
Oh, and we have to do our own scripting if we want the stupid things to actually show up when we load our projects. 
Tried it, unfortunately this didn’t work for me.
They do hot fixes now and then. Not for this though. It was a problem on late cubase 13 and have been known since September. They have done hotfixes for 13 and regular releases for 14 without any fix for the problem. And about laggy. This is done with javascript, it is not designed for performance. I think Steinberg still have their SDK for remotes that uses C/C++ that still is under NDA. You will need that for best performance.
I appreciate the response. But I have absolutely no clue at all what any of that means. All I do know is that the MIDI Remote is a pig to set up, caused dozens of crashes, lost days of work, has useless documentation and requires musicians to learn JavaScript in order to make it work.
5 Likes
Hi,
I have read through it.
If you set up the MIDI Port names properly, then it works as expected?
Just to be clear. The MIDI port names does not belong to MIDI it is part of the driver naming and are to a proper key for assignment. So there is NO way to setup MIDI Port names properly.
Yes, this seems to work. But I have a small problem. (see also post above) :
I have an V1-M with two extenders. I am able to edit the script so that it sees the V1-M and the first V1-X. (iCon V1-X1 Poort 1) But what do I have to add / change to the script to see the second V1-X (iCon V1-X3 Poort 1) as well?
I tried copying and pasting the line for the extender detection and renaming it, but this doesn’t seem to work.
Hi,
we’ve been having this issue since Cubase 13.0.50 on Mac and Windows and the issue persists in Cubase 14.0.20.
Any MIDI remote surface that works with a script, would disappear upon Cubase restart, regardless of vendor or controller added.
Here is how we got it to work for a controller that uses a midi remote js script.
Thanks to @christos.andreou who came up with this!
-
Move the existing folder of the MIDI remote surface from the local folder C:\Users\USERNAME\Documents\Steinberg\Cubase\MIDI Remote\Driver Scripts\Local\VENDOR\CONTROLLER
to somewhere temporary. -
Open the js file in Notepad or other text editor. You will see a line:
const driver = api.makeDeviceDriver(“VENDOR_NAME”, “CONTROLLER_NAME”, “SCRIPT_CREATOR”); -
Open Cubase and create a new remote surface using Add Vendor and type in the vendor name, controller name and script creator exactly the same as in the js file.
Select the correct MIDI ports for your controller.
(You will not be able to change the midi ports after because they referenced by an ID in the json file)
-
Map at least one component (rotary encoder or fader etc) using the side panel so it will allow you to save the control surface.
-
Reopen Cubase and the control surface is automatically opened.
-
Copy the js file and folders inside the C:\Users\USERNAME\Documents\Steinberg\Cubase\MIDI Remote\Driver Scripts\Local\VENDOR\CONTROLLER
You will see a json file there. That is the json file created by the previous step.
So, you will have the json file and the js file and folders of the controller. -
Open Cubase and it will load the control surface using the js instead of json.
If you have problems ensure that the json file has the same values as the js file
Json file
“VendorName”: “VENDOR_NAME”,
“DeviceName”: “CONTROLLER_NAME”,
“CreatedBy”: “SCRIPT_CREATOR”,
Also these should match the folder structure inside Driver Scripts\Local\VENDOR\CONTROLLER
and the names of the files should be by default:
VENDOR_CONTROLLER.json
VENDOR_CONTROLLER.js
spaces or casing do not matter, as long as they match exactly the names as described above.
The folder structure should look something like this:
With this workaround or solution, it takes about 20 seconds to initialize the control surface upon opening Cubase 14.0.20.
We are not sure if this is because of the method or this is just how it is with the controller we are using.
Thanks!
3 Likes
I can testify that is indeed a current workaround on the existing bug in regards to MIDI Remote Controller disconnection. It puzzled @M_P and myself for quite some time so we are glad that there is indeed a temporary solution for this.
@Fabio_B and & @Christian_D this may be of interest.
Hi, I am trying (hard) and creating the json works as it gets loaded on start.
But copying the js files across does not load my Arturia remote.
One stupid thing I noticed is there are places where my device is called MiniLab 3 and other places called MiniLab_3 ..
I tried renaming every instance of one with the other within the js files but so far no success..
It is a headache and I wish Arturia and Cubase could get it together !
Anyone thinks this could be because of the _ ?
I’d love some help please 
@christos.andreou
[hi,
quote=“Antoine-B, post:52, topic:951248”]
One stupid thing I noticed is there are places where my device is called MiniLab 3 and other places called MiniLab_3 ..
[/quote]
Could you give us an example, please?
The most important is the folder name. The
const driver = api.makeDeviceDriver(“VENDOR_NAME”, “CONTROLLER_NAME”, “SCRIPT_CREATOR”);
has to follow the folder name.
Other variables could be named differently, but variable cannot be named with the space symbol. Only a string could have the space symbol.
Perhaps this might be the issue. If the ports have been created and there are multiple entries of them with (even) slightly different names, then the workaround won’t work possibly. That’s why @M_P mentions:
If you have problems ensure that the json file has the same values as the js file
Json file
“VendorName”: “VENDOR_NAME”,
“DeviceName”: “CONTROLLER_NAME”,
“CreatedBy”: “SCRIPT_CREATOR”,
Also these should match the folder structure inside Driver Scripts\Local\VENDOR\CONTROLLER
and the names of the files should be by default:
VENDOR_CONTROLLER,json
VENDOR_CONTROLLER,js
spaces or casing do not matter, as long as they match exactly the names as described above.
One thing that you might need to consider is to remove [backup before hand!] the MIDI Ports.xml file from \AppData\Roaming\Steinberg\Cubase 14_64 (if you are on a PC) and let Cubase re-instate the MIDI Ports afresh, so the device is getting assigned to a properly named MIDI port (as it should) rather than a duplicated one.
Again, this is something that you might try for your specific MIDI controller. The above workaround is based on the process we followed for the MP MIDI Controller. Either-way, please let us know your findings. Thanks!
@Martin.Jirsak I noticed there were instances using the space in the script and others with the underscore, I thought a developer mixed those two names and that created the bug.
After an hour tinkering I was fed up and just deleted the folder with the scripts. Went back to download Arturia’s script - I swear I believe it is the exact same file.
Put it in, opened Cubase, works just fine ! I cannot believe it
So my issue appears to be sorted .. weird, but good. I hope this post can be helpful to others with script issues !
Thanks guys, I can now have more fun with my keyboard ! 
1 Like
That’s great to hear @Antoine-B. These little things (like an underscore or a dot) can really mess things up in a script for sure. I’m positive that the matter will be solved and that a workaround won’t be necessary in the future. But in the meantime, glad to hear that you are finally able to use your keyboard with the setup! 
Hi,
If I understand it correctly and sum it, the workaround is to import the script from within Cubase instead just putting it to the folder manually.
Am I right?
Not really Martin, the workaround is to create a near empty shell script manually.
Then shut Cubase and put back the client-downloaded script files which if all named properly should replace the empty shell.
This entire stuff should be looked at by Steinberg engineers and perhaps talk to some manufacturers, see if there is something to fix or implement, eg naming conventions, for example no space in names to avoid stuff getting broken. Just an example.
1 Like
Can anybody help me with the above issue? (see my post above) I’ve almost fixed the script but I don’t know how to integrate the second extender in it correctly.
I wish I could help you ! What does Icon Audio say ?
Ideally Steinberg engineers and hardware & plugin manufacturers would have open channels of communication to solve all those issues !
My only suggestion is to try to @ the guys that were able to write custom scripts, mentioned above, see if they are available to come and help you.
As a matter of fact, I’ve been in contact with Steinberg about this issue today. They confirm that this is a bug, and that it should be solved in the next maintenance update, 14.0.30. Fingers crossed…
2 Likes