Windows MIDI Services is the new MIDI API, Service, and SDK in Microsoft Windows. It’s delivered in two parts:
In the past, the Windows APIs for MIDI would connect a single application directly with the driver for the MIDI device being used. Although this made a lot of sense when first developed around the turn of the century, it introduced a lot of limitations, including the inability for more than one application to use a device without special drivers.
The new approach uses a Windows Service (midisrv.exe – the “MIDI Service”) as the mediator between the devices and the applications. Any number of applications can talk to any number of devices, and devices may be connected to by more than one application without any changes to their drivers. This is because each device still has only one client: the MIDI Service.
This gives us the flexibility to have more processing inside the service so that we can support protocol data capture, translation, message scheduling, and more in the service today, and custom routing and message manipulation in the future. It also enables us to seamlessly integrate MIDI 1.0 and MIDI 2.0 because we handle all translation in the service.
The service supports the concept of a Transport plugin. This enables us to support new transports, like Network MIDI 2.0, without having to create kernel device drivers.
At the time of this writing, we ship the following transports in the box:
In the future, we have plans for BLE MIDI 1.0, Network MIDI 2.0 (demonstrated at NAMM Show 2025), a virtual patch bay / router, and others.
If Developer Mode is not turned on in Windows Settings, all service plugins must be signed with a valid certificate by an authority that is recognized on the PC.
Another type of service plugin is the Message Transform. These plugins take in a message, do something with it, and optionally pass it along to the next step.
One of the biggest ways we use this in the service is for message translation. We translate between MIDI 1.0 byte format and MIDI Universal MIDI Packet (UMP) – inside the service, all messages are UMP. We also use this to scale up/down values between the high resolution MIDI 2.0 protocol and MIDI 1.0.
Another way we use this is for message scheduling. The outgoing MIDI Message scheduler is implemented as a Transform. It takes incoming messages, looks at the timestamp, and either sends them along immediately, or adds them to an outgoing message queue.
We have plans for making these plugins open and configurable in the future, like we have for Transports. That way we can add more plugins that can do interesting things with messages, much like the old MIDI Mapper. That is not yet enabled.
For the new MIDI 2.0 UMP driver we took a page (ha!) from WaveRT and use a cross-process buffer approach to communicate with the service. This makes data transfer faster than the approach used with MIDI 1.0 drivers.
The new driver supports both MIDI 2.0 devices as well as MIDI 1.0 devices. By default, we do not currently move existing MIDI 1.0 devices to the new driver because we need to be sure of compatibility first. However, a customer is free to do this manually today, or through tools we provide in the future.
Some devices, due to how their USB descriptors are set up, will automatically move to the new UMP driver. This is not a large percentage of devices, but includes ones like the Korg nanoKey and family, and the Conductive Labs MRCC.
Thank You!
The open source USB MIDI 2.0 driver has been generously donated by AMEI, the Association of Musical Electronics Industry, and developed by AmeNote :tm: in partnership with Microsoft. Please see the file headers for any additional copyright notices. A huge thank you to AMEI and its member companies for making this happen: AlphaTheta Corporation, INTERNET Co., Ltd., Kawai Musical Instruments Manufacturing Co., Ltd., CRYPTON FUTURE MEDIA, INC., CRIMSON TECHNOLOGY, Inc., KORG INC., Educational Corporation Shobi Gakuen, SyncPower Corporation, ZOOM CORPORATION, SUZUKI MUSICAL INST.MFG.CO.,LTD., TEAC CORPORATION, Yamaha Corporation, Yamaha Music Entertainment Holdings, Inc., Roland Corporation, Analog Devices, K.K.
If your USB MIDI device is class-compliant (that is, it will work with devices like the iPad with no driver required) then you probably do not need to install a driver on Windows. We encourage you to use the in-box drivers whenever possible to reduce the complexity of your setup.
Devices which are not class-compliant will still need their own drivers. We support those just as we do the in-box MIDI 1.0 class driver.
In short, to ensure that everything plays together nicely, we have replumbed the existing WinMM MIDI 1.0 and WinRT MIDI 1.0 APIs to talk to the new MIDI Service instead of talking directly to device drivers. This ensures apps using those APIs do not lock ports and instead participate in multi-client use, and also that they can use ports created from new MIDI 2.0 endpoints.
Please see the knowledge base for more information about backwards compatibility.
Windows MIDI Services also comes with a number of tools, like MIDI Settings and the MIDI Console to enable you to customize and manage your MIDI devices. More information can be found in the tools pages.
As mentioned at the top, we ship Windows MIDI Services in two parts. The part that ships in-box supports MIDI 1.0 in-box APIs. The service, transports, and plumbing are all there for MIDI 2.0, however apps will need to use the Windows MIDI Services App SDK to interface with it. The existing WinMM and WinRT MIDI 1.0 APIs cannot support the newer constructs, message scheduling, creating virtual device apps, etc. All of those features are in the new SDK.
Windows MIDI Services is an open source project with all source available on GitHub. We have a great community on Discord as well. Between GitHub and Discord, you should find the information you are looking for.
Contact us and we’ll get back to you as soon as possible.
Submit a Request