Mid session, nothing was working, usual culprit MR, catastrophic fail, happens regularly but not usually to all six MR’s. Please fix. 
Hi,
Could you be more specific, please?
Windows 11 latest
Custom MR scripts with hundreds of mapped buttons and CC faders.
For no particular reason the MIDI Remote(s) will stop working mid session. It happens on a regular basis. I need to quit Cubase to get them up and running again. Reloading/importing the script into the current session does not work.
Hi,
How is the hardware connected? What kind of MIDI Port do you use?
Doesn’t the hardware (or the (USB?) bus) go to any kind of sleep mode?
I’ve got 2 iPads running Metagrid Pro connected to my PC. Metagrid doesn’t disconnect, so I doubt it is a sleeping USB thing. The MIDI ports are to/from Bome MIDI Translator Pro. I’m 99% sure it’s Cubase because if I relaunch Cubase everything is back up and running, albeit temporarily.
Here is my MR’s 2 hours later. Notice the ‘VSL -VEP’ is greyed out now and the others are okay. It seems somewhat random.
Hi,
How is the iPad connected to the computer? Is it via USB port, or via BT/WiFi? Doesn’t this connection become lost by any chance?
I believe there is also some kind of virtual MIDI Port involved. This might also be risky.
The iPad’s are connected via USB.
Metagrid, Loop MIDI and Bome all continue to work as expected. It is only the MIDI Remotes in Cubase that become greyed out/unresponsive.
So switching my Roland FP10 off and on again while Cubase is up and running kills all my MIDI Remotes. Completely re-producible.
You didn’t specify, but it sounds like you’re on Windows.
If so, I wonder if this is related to port renumbering after a device is removed. This would cause any ports with an index higher than the Roland to be renumbered.
If that’s the case, it could possibly be fixed by using “WinRT MIDI” instead of “Windows MIDI” in studio setup. But that does complicate a number of other things (device naming being one), so I wouldn’t try it on a real project.
Pete
Microsoft
2 Likes
Hello Pete,
why are the port numbers being changed?
I always thought the ports were permanently assigned?
I always thought the ports were permanently assigned?
Nope. Port numbers are assigned based on the order the devices are enumerated. If you leave them plugged in, they will usually remain in the same order across restarts. But it’s not guaranteed.
Apps using WinMM don’t handle gaps in numbering. They make a call to get the number of devices “n”, and then iterate through those from 0 to n-1. Example of numbering for output ports on my system:
If you unplug a device, the gap needs to be closed, or else the next time an app (could be the same app) gets the number of devices, they will fail to open one of them.
So if, in the pic above, I were to unplug the LinnStrument, then everthing after it would move up by one slot. If I then plug the LinnStrument back in, it’s likely going to end up at the end of the list.
In the new stack, we actually tried to preserve port numbers, thinking that might be a better experience for existing MIDI 1.0 apps. However, as soon as we tested it with real apps like Ableton Live, Studio One, and Cubase, we found we broke every one of them, sometimes in very interesting ways. 
With WinRT MIDI 1.0, it’s different. The identifier of the port is the long software device id. It looks something like \\?\swd#mmdevapi#midiu_ksa_6030123581617843594_1_9#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}
The new Windows MIDI Services SDK also uses full device ids, similar to the older WinMM MIDI 1.0 IDs.
Most musicians don’t need to see the Ids very often, so we don’t show them everywhere.
But you can add the --show-endpoint-id switch to show them:
(MIDI 2.0 doesn’t use ports, so you see fewer devices listed. What used to be a port is now a group in the message. But that’s a detail primarily for developers.)
And just to close this out with way more detail than asked for, here you can see a MIDI 2.0 device and its auto-translated mapped MIDI 1.0 API ports (we do all the conversion in the service so that everything just works), complete with their current WinMM port numbers.
Pete
Microsoft
1 Like