If you are on Windows 11 (or Windows 10 for the UAD issue) and recently had either of these two issues, please read on:

1. You use a Universal Audio (UAD) device and found that all or most of your MIDI devices are no longer recognized in your DAW in Windows 11 or Windows 10
2. You have a new MIDI 2.0 (UMP Data Format – most any keyboard with a MIDI 2.0 setting) and it doesn’t work in Windows 11

Universal Audio Console problem

Recently, Universal Audio released a version of their Console app which broke MIDI on Windows. If you use a UAD audio interface and found your MIDI devices unavailable in your DAW, or saw an “out of memory” or similar error in MIDI utilities, this may be what you have run into.

Universal Audio quickly released an update to their Console which fixes this issue, so if you are up to date with your UAD Console updates, you should no longer see this issue.

• Forum thread: Universal Audio Forums
• Solution: Update to the latest UAD Console

MIDI 2.0 Device problem

On a Windows 11 PC with KB5066835 installed, this impacts MIDI 2.0 UMP (Universal MIDI Packet) Data format devices, including the following, when MIDI 2.0 Mode is enabled:

• Native Instruments Komplete Kontrol S mk2 family
• Roland A88 MKII
• Studiologic SL Mk2 family
• Waldorf Iridium and Quantum family with recent MIDI 2.0 firmware
• Yamaha MODX M
• Yamaha Montage M
• Various other MIDI 2.0 test and pre-production devices

It does not impact devices which are MIDI 2.0 for MIDI-CI but which do not use the Universal MIDI Packet / MIDI 2.0 Data Format (Korg Keystage, for example).

When you plug in the MIDI 2.0 device, you may not be able to receive MIDI from it. The solution is to leave the device connected and then reboot your PC. You may have to repeat this is you add a hub or change USB ports in a way that makes Windows think it is a new device.

• Solution: Leave the MIDI 2.0 device attached, and then reboot your PC.

Here’s why

Earlier this year, we started the process to roll out MIDI 2.0 / Windows MIDI Services to Windows PCs, with a target to enable them by the end of November. Those bits went out in Windows 11 KB Update KB5066835, in a disabled state in support of a controlled rollout / phased enablement with customers.

However, our partners found two issues which were blocking some apps from working properly so we did not continue the controlled rollout with those bits. They are still installed, but remain disabled.

Disabled unless you plug in a MIDI 2.0 UMP device, that is. In that case, the new USB MIDI 2.0 driver gets picked up by the device, and before Windows can move it back to the MIDI 1.0 driver, our new Windows MIDI Services starts up and holds on to the device for MIDI 2.0 discovery and protocol negotiation (part of the MIDI 2.0 handshake). As a result, Windows cannot move the device to the old driver, and so our old APIs do not see the device.

If you leave the MIDI 2.0 device attached and then reboot the PC, Windows will move it back to the MIDI 1.0 driver, the new MIDI Service will not be started, and the device will fall back to its MIDI 1.0 mode per USB MIDI 2.0 practices.

So what’s the status of MIDI 2.0 on Windows?

Windows MIDI Services, which is our new MIDI stack which updates MIDI 1.0 support and adds MIDI 2.0 support, has been in development and preview with our partners for some time now. It is currently supported only on Windows Insider Canary releases, and includes an SDK which cannot be used in production apps until the official release. There’s no supported way to enable MIDI 2.0 in public retail releases of Windows.

As I mentioned above, we were ready to release Windows MIDI Services as controlled feature rollout (where we roll out to a percentage of customers, verify we aren’t seeing a spike in errors, and then continue), but then those two bugs were found during additional partner testing. We’ve since fixed both issues (one is related to how DJ apps identify the DJ Controllers, and how some other hardware-tied apps identify the hardware they work with. The other is for SysEx transfer speed for higher-speed USB 2.0 and USB 3.0 MIDI devices). Thank you to Roland and Yamaha for finding those issues during their testing.

Those issues put a halt to enabling the November in-box release. We do not release updates in December, and January tends to be packed as a result of that, so we are targeting the end of February to begin the controlled rollout to customers. If all goes well, Windows customers who install the February update will have, by the end of March, the new WIndows MIDI Services stack. As part of that, everyone will get:

• Backwards compatibility with the existing WinMM and WinRT MIDI 1.0 APIs (this is what has taken us the most time during development)
• Better device names in WinRT MIDI 1.0, so they match those in WinMM
• Multi-client MIDI for all apps and devices (so multiple apps can use the same MIDI device)
• Support for MIDI 2.0 devices, even in MIDI 1.0 applications (we handle all the translation in the service)
• Built-in loopback endpoints for simple app-to-app MIDI
• A MIDI Console, MIDI Settings app, MIDI PowerShell scripting, virtual devices, custom device metadata, renaming of ports, some MIDI utilities, and more through an additional single download

This also sets you up to be able to get Network MIDI 2.0 (currently in preview), as well as Bluetooth MIDI 1.0 and the Virtual Patch Bay / routing plugin when these features are stable. You can follow the progress on GitHub and on our Discord server, all linked from our primary Windows MIDI Services landing page https://aka.ms/midi.

So it’s a bit later than our recent estimates, but given that we need to maintain backwards compatibility with the older WinMM MIDI 1.0 APIs above all else, we need to shift to the new date. We appreciate your understanding as we prioritize backwards compatibility and stability for our existing apps.