Posting this so we can point people to this post vs cluttering up the forums with discussion about Microsoft bugs.
The Windows MIDI Services rollout started at the end of January. Since that time, we’ve found a few issues. Some of which have already been fixed and have those fixes going out to customers starting the end of last month.
None of those issues appeared during a year of testing with partners. We had many hardware and software partners, as well as customers involved. However, not every company was equally engaged, and we also just didn’t have some of the right equipment to test their products (a big hole in the testing was DJ and producer-focused equipment).
If the issue appears to be Windows MIDI Services, the best place to discuss, find workarounds, try preview bits to unblock you, and more is our Discord server Windows MIDI / Audio
I know it can be difficult to tell if the issue is related to MIDI or not, but here’s some information to help.
There are two main issues that are causing traffic, plus one that just most folks generally expected
Cubase Crash on Initializing MIDI or hang on Close
It’s not always the case that this is MIDI, but if it just started in the past few weeks, it’s possible it is. If you have a crash dump and it hangs on a call from midisrv, then it likely is.
Drivers from inmusic brands (m-audio, AKAI, RANE, and a few others) are crashing in the Windows MIDI Service midisrv. We’re working on figuring out why. We haven’t seen problems with other third-party drivers. These drivers presumably all have a common origin and a common issue we’re hitting.
However, in cases where you can, we advise you to just uninstall the third-party driver and use our in-box drivers. Ultimately, that’s where we’d like to get with any device that is class-compliant as third-party drivers are no longer needed for MIDI-only devices. Everything in Windows is now multi-client, so third-party drivers aren’t needed just for that. If the MIDI device would work on macOS without a driver, it will work on Windows using our in-box driver.
Dynamically added ports
loopMIDI, loopBE, Avid Eucon, rtpMIDI (which uses loopMIDI tech under the hood) and other virtual ports are not enumerating unless they were created before the service has started up.
We have two workarounds/fixes available on our Discord server at Windows MIDI / Audio.
The first is to use our first-party loopbacks in the case of loopMIDI/loopBE. We have the MIDI 2.0-capable loopbacks as shipped, and a preview of the loopMIDI-style MIDI 1.0 loopbacks here. Please follow the instructions on that page before installing.
The second is a preview fixed version of the transport involved in that. This removes the requirement to start up loopMIDI etc. in advance. See the #early-preview-releases channel in Discord.
Korg .drv-style USB drivers
Old-style Korg USB drivers. Not many questions here on this, but the solution is to completely uninstall the Korg USB drivers and use our in-box stuff.
We don’t expect this behavior to change, and we don’t want folks using those old-style drivers because they don’t get any of the new benefits. Full Korg Uninstall instructions are available on the Discord server in the Workarounds section.
Korg Bluetooth drivers still work. However, they will not appear to apps using the new MIDI SDK (like MIDI Settings), and they don’t become multi-client or gain any new capabilities.
But it’s important that you don’t use tools to rearrange that part of the registry. The Korg driver uninstallers can also mess up the registry. The SDK and Tools linked in the RC3 link above includes a midifixreg utility you can use to fix the registry entries in case that happens.
When in doubt, please ask on our Discord server. I’m doing my best to help customers there.
Pete
Microsoft