I can’t believe how difficult this is. I must’ve spent 8 hours at least just on this issue, and now my brain is a pile of mush.
The problem is really simple, and I have to believe it happens to people all the time.
I have several cheap MIDI controllers - pads, keys, knobs, etc. Pretty often, I find I need to change how the controllers are configured. The ONLY way to do this seems to be to completely close the session, fire up the controller’s editor software, make the change, then re-open the session. This is really stupid and time consuming. I should not have to close my entire session just to change Pad 1 from an Ab to an A natural.
After so many hours of Googling and playing with midiOX, from what I can tell, Cubase takes EXCLUSIVE control of ALL midi ports - active or not. Because of this, the controller editor software has nothing to connect to, and there is literally no way to stop this from happening. Please tell me I’m wrong. It would make my day.
I’m routinely opening Cubase first, then the NI Controller Editor and/or MIDI-OX. No problem at all as long as I open Cubase first.
So Cubase definitely doesn’t seem to be the problem.
p.s. Windows 10 covers a significant number of releases by now, so just saying Windows 10 doesn’t tell the whole story. I’m currently running Windows 10 Pro (20H2), but this was working fine for me on Win10 Pro (1909) and Cubase 10.5 as well.
I remember some years ago Win10 and older didn’t support multi-client midi, but it does for quite a while now. However not all midi software uses the newer improved Windows midi API, so they still grab exclusive control of midi ports. This is especially likely for older software and still possible for newer stuff (potentially including Chrome and/or Firefox browsers).
The more easily understandable and generally useful version name for Win 10 can be found in Windows > Settings > System > About where it says Version. OS build (the long number you showed) shows the exact smaller bug fix release in-between. While one can deduce the Version from the build, it’s an extra step for most people (including me) who don’t work at that level of detail on a daily basis. So you’ll end up getting more takers for your questions when you mention Version numbers.
However, I suspect that something else (not Cubase) is hogging that midi port. Just the other day another forum user discovered that the software for his audio interface was the culprit.
I’m quite certain it’s not the OS. At least, it’s not an issue with some OS update breaking the functionality. I’ve had this issue for at least 7 years through several versions of Cubase, Windows, and my several iterations of workstation hardware. In fact, I’ve never seen Cubase NOT take exclusive control of MIDI ports.
My little interface also doesn’t have that kind of functionality. Interesting idea, though.
Yeah - that article looks looks like the way it used to be before Windows 10.
And I think I’ve found that the new midi API arrived with Windows 10 in 2015 - as per the 2016 blog post by Microsoft’s own Pete Brown (very worthwhile following his Windows MIDI and Audio related posts, by the way) : MIDI Enhancements in Windows 10 - Windows Developer Blog
Relevant quote:
One great feature of the new API is that it is multi-client. As long as all apps with the port open are using the Windows 10 UWP MIDI API and not the older Win32 MME or DirectMusic APIs, they can share the same device. This is something the older APIs don’t handle without custom drivers and was a common request from our partners and customers.
I’m not sure, if it will make a difference to your situation, but I think some people have run some of their older midi controllers through LoopMidi to Cubase and/or MIDI-OX to make multi-client midi work.
