Today, we’re releasing the latest version of Windows MIDI Services to the Windows Insider Canary Channel, fully enabled for anyone to evaluate. We recommend this for technical users (as with any Canary release) and not for production use because we will have bugs. You can learn more about the Insider release here.

The Windows Insider blog post details what’s in this release and in the associated Windows MIDI Services App SDK. Here are some more details.

The Windows Insider Canary Channel is provided for testing and evaluation on non-production PCs. Please see the Windows Insider blog post for additional information about the Canary Channel.

What’s in the box?

This Windows Insider release includes our new MIDI 2.0 and MIDI 1.0 class driver (kindly funded by AMEI and developed by AmeNote in partnership with Microsoft), the WinMM (MME) redirection driver and code, and the new Windows Service and its transport and transform plugins. It includes everything you need to be able to try existing MIDI 1.0 apps and devices, and to verify that they work as expected. It’s representative of how we’ll ship in mainstream Windows later this year.

MIDI 1.0 benefits with this release:

• Every MIDI device is now multi-client, even for existing applications and devices. You do not need vendor drivers to enable more than one application to use a MIDI device.
• MIDI Port names are now better. We’ve surveyed many MIDI devices in market and come up with algorithms which provide better port and endpoint names for these devices. But there will always be exceptions. If you see those, please report them to us on GitHub (developers) or on our Discord Server (everyone else)
• Devices using the new USB MIDI 2.0 Class driver have faster data transfer. The USB MIDI 2.0 class driver uses faster data transfer mechanisms even for MIDI 1.0 devices. (If your MIDI 1.0 device is not picked up by the new driver, and is class-compliant, you can manually assign usbmidi2.sys to the device. We’ll post instructions for this in the future)
• The new features are backwards compatible with your existing apps and devices USB MIDI 2.0 devices and USB MIDI 1.0 devices are both usable from the WinMM (MME) APIs in a MIDI 1.0 capacity.

Everything here works on Intel/AMD x64 as well as Arm64 devices

Here’s the WinMM backwards-compatibility in practice. Most apps you have today using WinMM MIDI 1.0 will work with the new service. If you find apps which do not, please do let us know (see how to report bugs/info below)

Known Issues

The full list of known bugs and issues may be found here.

Although this is not a bug, this is important to know about. We’ve completely reworked the port names for devices, based on years of feedback from customers and developers. As a result, some applications which use the port name for reconnection in a project or to load up an appropriate template or script, may fail. Feel free to let us know about this so we can reach out to these companies to make sure they are aware and so we can validate that the naming works as expected for all devices (names are reported in multiple ways by devices).

The other larger issue (listed in the known bugs, but calling this out here) is that if you plug in a MIDI 1.0 device after the service has started, you will need to restart the service to see it (Start > Services, find “Windows MIDI Service”, right-click and choose “Restart”), or reboot, or type midi service restart from an elevated command prompt after you have the Windows MIDI Services App SDK installed. This is a regression that we need to fix from our last developer preview for the NAMM show, and will be an issue in this release and at least the next one.

Finally, this release does not have the required registry entry for the built-in MIDI Loopback transport. This will be fixed in a future release, but if you would like to enable this now and are comfortable working in the registry, please see issue #502 on GitHub.

Getting even more out of Windows MIDI Services

Similar in approach to the Windows App SDK, the Windows MIDI Services App SDK runtime and tools ship separately from the in-box components. This SDK includes everything apps need to be able to use MIDI 2.0 and MIDI 1.0 through the service, with support for timestamps, message scheduling, high-resolution messages, better device names, more device metadata, and connect/disconnect notifications, and more. It is the recommended SDK to use for all apps which need a modern MIDI experience on Windows. Shipping it separately gives us the flexibility to release SDK features and tool updates whenever our customers and partners need them, and not tie those releases to specific Windows updates.

In addition to the SDK code which communicates with the service, the runtime installer also includes several key applications as detailed in the Windows Insider blog post. Here are the two main ones:

Windows MIDI Services Settings app

This is a GUI application for working with Windows MIDI Services. This application is actively in development, and is a bit behind the console feature-wise, but does provide information about the various devices and endpoints available.

The MIDI Settings app is a .NET 8 app using WinUI 3

Windows MIDI Services Console app (midi.exe)

This is a command-line tool for working with Windows MIDI Services. You can automate message sending, get information about MIDI, and so much more. It has been around longer than the Settings app, and so has more features. Many of our hardware and software partners have used it for testing Windows MIDI Services, and I personally use it every day.

The MIDI Console app is a .NET 8 app using Spectre.Console for formatting and console IO.

Learn more about the Windows MIDI Services Console here.

Where to get the tools and SDK

You can download the SDK release for your architecture (Arm64, x64) from our release page on GitHub. Please check the Customer Preview 1 release notes for any additional details.

At the moment, for the preview, the tools and SDK Runtime releases are not signed, so you will get the usual browser and SmartScreen-type warnings when you download and run them. Once we start signing the builds for this and the NuGet package for developers, the warnings will go away.

When you run an app using the Windows MIDI Services App SDK, it will check for a compatible version, and if not available, will prompt you to download the latest version.

Developer documentation and samples

• Developer-focused documentation is available here.
• Developer code samples are available here

Learn more about MIDI 2.0

MIDI 2.0 is the first major update to MIDI in 40+ years. Retail devices like the Yamaha Montage M, Roland A88, Waldorf Iridium and Quantum (modules and keyboards), Studiologic SL mk2 range, Korg Keystage, Native Instruments Komplete Kontrol, and more support MIDI 2.0 features.

The best place to stay up with the developments in MIDI 2.0 is at the MIDI Association web site. If you create MIDI hardware or software, become a corporate member so that you may participate in upcoming standards and enhancements to the protocol. The MIDI Association working groups continue to work on new transports like Network MIDI 2.0, as well as new profiles like Piano and Orchestral Articulation profiles.

Learn about one of those newly-adopted additions to the MIDI 2.0 standards — Network MIDI 2.0:

As always, feel free to join our Discord community!

Reporting issues

If you run into any issues, please report them on our GitHub repo if you’re a developer, or start up a new thread on our Discord Server in the Bugs and Suggestions channel.

When will we go into retail (mainstream) Windows releases?

Once we are happy with the compatibility with existing apps and devices, we’ll move Windows MIDI Services into the latest supported releases of Windows 11 as well as the supported Windows 10 release. We hope this will be soon, but this is a quality-driven decision and we need your feedback. We’ve tested dozens of apps and MIDI devices here, and involved partners testing with their newest offerings, but there are thousands of MIDI devices released in the wild over the past 40+ years and we don’t have every one of them. We don’t want to break your MIDI workflow.