MIDI Remote Controller disappearing on launch

[nomisllewdor]

Yup yes please if you can say more about it. Where should we look for this code -within the remote api? Presumably also in any implementation script being used for any hardware. Trying to understand why the error occurs is half the battle particularly as @Martin.Jirsak says the bug occurs for some users but not others.
Many thanks.

[cubace]

In simpledevice example there is:

// define all possible namings the devices MIDI ports could have
// NOTE: Windows and MacOS handle port naming differently
deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('SimpleDevice IN')
    .expectOutputNameEquals('SimpleDevice OUT')
    
deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('SimpleDevice (MIDI IN)')
    .expectOutputNameEquals('SimpleDevice (MIDI OUT)'

I have my midi connected to a iconnectivity mio10.
So that was:

deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('mio10 HST 6 IN')
    .expectOutputNameEquals('mio10 HST 6 OUT')

Changed to:

deviceDriver.makeDetectionUnit().detectPortPair(midiInput, midiOutput)
    .expectInputNameEquals('mio10 HST 6')
    .expectOutputNameEquals('mio10 HST 6')

This does not make the manual configuration to work, but it load on start. This is working fine for USB-midi devices with uniq names, but it will not work for real midi devices nor network midi devices. (Without code customization like this) Manual configuration must have precedence over default values in code.

[nomisllewdor]

Thanks very much. I guess I would need to adjust it for the script that @bjoluc has very kindly provided for the Icon V1-M/X - but his script is superbly complex (and I also know he is busy completing his Masters degree currently so may not be able to help).

[alexis]

@cubace

Changed to: …

I’m not a programmer, but if I’m understanding you correctly you have figured out a fix for all USB MIDI controllers so they don’t disappear.

That is amazing and so exciting if so … congratulations!

1. For us non-programmers who simply build a virtual interface GUI in the new MIDI Remote Manager (sorry if I’m misremembering the actual name) - how do we access and edit the text you attached in our own controller?

Thank you!

[cubace]

@alexis

I’m not a programmer, but if I’m understanding you correctly you have figured out a fix for all USB MIDI controllers so they don’t disappear.

That is amazing and so exciting if so … congratulations!

1. For us non-programmers who simply build a virtual interface GUI in the new MIDI Remote Manager (sorry if I’m misremembering the actual name) - how do we access and edit the text you attached in our own controller?

Thank you!

I think it is mostly a non USB problem. But USB midi devices are not guaranteed to be unique.

[alexis]

Got it thanks!

Any help on the second part of my post? How do we mere non-programming/non- scripting mortals who only build virtual interfaces in the new MIDI Remote Manager make changes like you showed in your post?

[cubace]

Since I do not know how that works I can not answer. But I guess that you can find the java-script you can edit that source file. But I will probably have to be done every time it is changed. Assuming that it is a similar problem in the first place.

[nomisllewdor]

@Matthias_Quellmann
@Ed_Doll

Well what you have provided is of enormous help for end users trying to find a work around for the midi remote device setup failure to save state bug.

In the meantime let’s hope our senior Steinberg staff colleagues have read all our requests on this topic for a fix for a bug which should not really have appeared and can hopefully give us written reassurance here that it will be sorted by the next maintenance release for the #14 sequencer branch for both Cubase and Nuendo.

Many thanks all.

[Pablin_Drummer2]

I congratulate the user who has found a possible solution to a Cubase problem. It certainly wouldn’t be the first time. It’s also true that Steinberg should be at least a little ashamed if all this is true. As I’ve said before, I don’t have to stick to using software with so many bugs and have to pay to verify that problem X or Y has been solved.

We don’t have to settle for updates being released to us in dribs and drabs… as always, Steinberg will do what it wants. I’m sorry if my words offend anyone, but when I didn’t pay for my software, I complained much less because I understood that a bug meant it was cracked.

Over the years, I’ve increasingly realized that’s not the case. NOTE to moderators: Feel free to delete this comment. I’ll try not to complain anymore.

[Misja_van_Waterschoo]

Following.
I have the same problem with Nuendo 13 and 14, using the @bjoluc script for an Icon V1-m/x setup, and it’s been driving me crazy! If anybody (@cubace ) knows how to fix this without breaking anything, I’d love to know. Otherwise: Steinberg: PLEASE FIX THIS!

[Disharmoniker]

here’s a quick fix for @bjoluc’s superb script I posted a while ago.

SSL UC1 + UF1 or X-Touch One

Hi guys, desperately need your help, please ! I’m not new to MIDI controlling Cubase, atm I’m using a beautiful team of Console 1 Channel III, 2x BCR2000 via GR, Frontier Tranzport and a Faderport Classic - 100% reliable and tightly integrated, including track follow. Recently added an SSL UF1, as HQ replacement for my ancient Faderport which is ready for retirement. While the UF1 hardware is a stunning piece of engineering (and the reason I will keep it), the SSL software concept (MCU + 360…

it works 100% for my SSL UF1, and reportedly for the Icon Qcon lite as well (where the idea came from).

no guarantees for other models, but well worth two minutes of your time …

easy enough to try, backup your script before editing !

tl;dr :

change the MIDI port names in the script, so they are identical to how they appear in your MIDI Port Setup.

Done.

Coffee.

good luck, and post your results !

Mr.D

[cubace]

@Misja_van_Waterschoo

Following.
I have the same problem with Nuendo 13 and 14, using the @bjoluc script for an Icon V1-m/x setup, and it’s been driving me crazy! If anybody (@cubace ) knows how to fix this without breaking anything, I’d love to know.

I have checked the git source code. I think it is the same root cause for the Icon units. However the code it much more complex that tries to be smart regarding the connection. But I think it would be fairly easy to debug and fix for any programmer with access to a hardware unit.
Have you checked if the vendor can help?

[Antoine-B]

Well good news for me, after spending one hour looking deeply into js script files and various forums post ..
I was preparing a screenshot of my MIDI setup to ask for help about port names, when I realised my MIDI out was not connected to my Arturia controller !
And upon connected, you guess it, Cubase now sees the Remote script coming up fine !

Lesson always is, before you check complicated things, always check for easy things first !

[The_Elf]

This port name fix worked for me for my UF1 and X-Touch.

[Misja_van_Waterschoo]

Would you be so kind to explain the steps you performed? I am no programmer (so I could break something easily), but an explanation of what it is that you can do to fix this yourself would be highly appreciated.

[The_Elf]

You need to edit your remote’s .js file, as explained by cubace above. For me that meant editing the file:
C:\Program Files\Steinberg\Cubase 14\midiremote_factory_scripts\Public\ssl\uf1\ssl_uf1.js

In that file I found the line:
return detectionPortPair.expectInputNameEquals(“SSL V-MIDI Port 1 Source”).expectOutputNameEquals(“SSL V-MIDI Port 1 Destination”);

I changed this to:
return detectionPortPair.expectInputNameEquals(“SSL V-MIDI Port 1 [1]”).expectOutputNameEquals(“SSL V-MIDI Port 1 [1]”);

You need to give the script the port’s raw name that Cubase sees, and not the friendly name you may have given it in the MIDI Ports dialogue, hence the number in square brackets in my example above.

Do make sure you make a copy of any file you intend to edit BEFORE making any changes. If anything goes wrong you can then recover a fresh copy of the file and try again.

[Disharmoniker]

An example from my SSL.

[Misja_van_Waterschoo]

Thanks for your help, this almost fixed the issue!!! But I have a small problem. 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.

Thank you for your help!

[alexis]

@The_Elf

You need to edit your remote’s .js file, as explained by cubace above. For me that meant editing the file:
C:\Program Files\Steinberg\Cubase 14\midiremote_factory_scripts\Public\ssl\uf1\ssl_uf1.js

In that file I found the line:
return detectionPortPair.expectInputNameEquals(“SSL V-MIDI Port 1 Source”).expectOutputNameEquals(“SSL V-MIDI Port 1 Destination”);

I changed this to:
return detectionPortPair.expectInputNameEquals(“SSL V-MIDI Port 1 [1]”).expectOutputNameEquals(“SSL V-MIDI Port 1 [1]”);

You need to give the script the port’s raw name that Cubase sees, and not the friendly name you may have given it in the MIDI Ports dialogue, hence the number in square brackets in my example above.

Do make sure you make a copy of any file you intend to edit BEFORE making any changes. If anything goes wrong you can then recover a fresh copy of the file and try again.

Thank you, The Elf!

[Disharmoniker]

Sorry, I’m at the end of my wits.

Mr.D