App SDK and Tools Release Candidate 3 + Basic MIDI 1.0 Loopbacks

UPDATE: 2026-03-01: Replaced the SDK & Tools package with a newer one with an updated MIDI Settings App installer to help those who were running into the XamlParseException on Settings app Startup.

---

Instructions

This is for customers who have Windows MIDI Services enabled on their PC. If you are unsure, use the midicheckservice tool below.

Be sure to download the correct version for your CPU. Arm64 versions are for Qualcomm Snapdragon and other Arm64 processors. x64 versions are for Intel/AMD processors.

If you want MIDI 1.0-style loopback endpoints, first install the Loopback Endpoints Plugin Preview below. This requires that you first turn on Developer mode in Windows because this preview package is not yet signed. For the same reason, your browser and/or OS may warn you multiple times when you install it.

The service plugins below have these names

• Windows.MIDI.Services.Basic.MIDI.1.0.Loopback.Preview.1.0.0-preview.1.2-arm64.exe
• Windows.MIDI.Services.Basic.MIDI.1.0.Loopback.Preview.1.0.0-preview.1.2-x64.exe

IMPORTANT: If you have the previous preview from Discord, uninstall it first, as it will conflict with this preview. If you accidentally install this without removing the other one, uninstall both, and then install this version.

After installing the service plugin, install the App SDK Runtime and Tools. This will provide the settings app and more.

The SDK Runtime and Tools installers below have these names

• Windows.MIDI.Services.SDK.Runtime.and.Tools.1.0.16-rc.3.3-arm64.exe
• Windows.MIDI.Services.SDK.Runtime.and.Tools.1.0.16-rc.3.3-x64.exe

If after installing both packages, you open the MIDI Settings app and find that you do not see the MIDI 1.0 loopback endpoints on the left, it likely means that the installer for the plugin was unable to restart the service. The easiest way to handle this is for you to reboot your PC. Those who are familiar with the Services app in Windows can restart the MIDI service from there, after closing all MIDI-using apps including the MIDI Settings app.

Changes

New MIDI 1.0 Loopback Service Plugin

This is a preview of a feature we'll work into Windows in a few months. This can be used like the third-party loopback endpoints you are familiar with today. The important difference compared to the MIDI 2.0 loopbacks is that you can have a single name, and the result is a single MIDI Source/Input and a single MIDI Destination/Out, vs a pair of each.

We're working on the fixes to make loopMIDI and similar virtual devices work again. In the meantime, if all you need is a loopback endpoint, or dozens of loopback endpoints, this will work for you. There is no practical limit to the number of endpoints you can create.

App SDK

• MidiEndpointDeviceInformation has an IsMuted property. Right now, this only applies to basic loopback endpoints, but we're considering supporting this for all types of endpoints in the future.
• Microsoft.Windows.Devices.Midi2.Endpoints.BasicLoopback is the namespace with the new MIDI 1.0 loopback features

MIDI Settings App

The MIDI Settings app checks for Windows MIDI Services feature enablement upon startup.

Support for MIDI 1.0-style loopback endpoints. These work like the third-party loopback endpoints do today, in that you only need to supply a single name. These loopbacks also support muting, which enables you to stop message transmission through the endpoint without removing it. Muted endpoints have a little glyph at the top left of the loopback item on the MIDI 1.0 loopbacks page.

The first time you use the MIDI Settings app, you will be prompted to create a configuration file and the MIDI 2.0 loopbacks, as in the past. However, a default MIDI 1.0 loopback will now be created in addition to the MIDI 2.0 loopbacks.

MIDI Console App

You can now create and remove transient MIDI 1.0 loopbacks.

Known issues and workarounds

We're seeing some customers (so far, only in non-English countries) having issues where the settings app is not loading up, and there's a XamlParseException being thrown. We haven't been able to reproduce this ourselves. If this is happening to you, please let us know on our Discord server https://aka.ms/mididiscord in the #midi-user-questions or #bugs-and-suggestions areas . Please be specific about your Windows version and installed language. Thanks!

This release does not change any of the issues in the build-in Windows components like the MIDI Service, transports, and driver. Those updates come through Windows Update. The second set of those updates is currently rolling out.

This is the blog post with known issues and workarounds:
https://devblogs.microsoft.com/windows-music-dev/windows-midi-services-rollout-known-issues-and-workarounds/

App SDK and Tools Release Candidate 2

This is an interim release primarily to help customers using the recently rolled-out Windows MIDI Services updates in retail Windows 11, so they can easily create loopback endpoints.

As in the previous release candidate (rc1), the Windows MIDI Services app SDK is itself of release candidate quality. The tools (specifically MIDI Settings app) are preview quality.

This release is not signed, so it is not a "go-live" release for app developers. Additionally, customers downloading this release will receive warning dialogs in their browser that must be clicked-through to keep the download.

As a result of not being code signed, you will likely need to:

• Confirm more than once in your browser that you want to actually keep the file
• Turn off smart app control (temporarily) so the installer can install the files.

Changes

App SDK

• Added AreGroupTerminalBlocksUpdated to the MidiEndpointDeviceInformationUpdatedEventArgs type. To avoid breaking compatibility, this is on a new interface IMidiEndpointDeviceInformationUpdatedEventArgs2. Normally, Group Terminal Blocks are immutable. However, this was added in support of the dynamic endpoint updating for drivers/apps like loopMIDI, where virtual group terminal blocks can come and go. From this, you can also infer that the MIDI 1.0 ports associated with this endpoint have changed.

MIDI Settings app

• The MIDI Settings app now checks for feature enablement when starting up
• You can directly specify the names for each side of a loopback endpoint pair. This makes them a more viable alternative to loopMIDI, loopBE, and similar.
• SysEx sender is hidden unless you select the option to "Enable Preview Tools", in the settings page

MIDI Console app

• The MIDI Console app now checks for feature enablement when starting up
• You can now create temporary loopback endpoint pairs using the MIDI console
  midi loopback create

Reminder. This is the blog post with known issues and workarounds:
https://devblogs.microsoft.com/windows-music-dev/windows-midi-services-rollout-known-issues-and-workarounds/

Edit: the previous upload picked up an older version of MIDI Settings. 1.0.15-rc.2.18 is the corrected version.

MIDI Feature Enablement Checker for Retail 24h2 and 25h2

Windows MIDI Services in-box components are rolling out to supported retail versions of Windows (not Insider builds) throughout the end of January and into February, via Windows Update. It takes approximately 30 days for the rollout to complete and the feature to be enabled on all PCs.

Please let the process complete normally, and do not install any Service builds on your PC, or else you will need to reset/reinstall your PC to have a functional MIDI system. There is no way to force the feature to be enabled on your PC ahead of time.

We'll have a new version of the SDK and Tools available after or near completion of the rollout. The previously available rc1 version will continue to work with the in-box components only if the feature is enabled on your install, but we recommend that non-developer customers wait for the February release of the SDK and tools.

MIDI Enablement Checker

This tool (midicheckservice) will tell you if Windows MIDI Services in-box components are installed and enabled per our controlled feature rollout process. Note that if you've used a tool like the vive tool to enable Windows MIDI Services, you may get a false positive on an otherwise not-completely-functional system. Do not use third-party tools to try to force the enablement of Windows MIDI Services.

Additionally, if you have run a Korg driver installer/uninstaller or similar utility that changes the midi...midi9 entries in Drivers32 in the registry, this tool may report that Windows MIDI Services is not enabled, even though it may have been before the use of that tool.

This article explains that situation and which entries are required for Windows MIDI Services.

NOTE: This tool is unsigned and so will be blocked by default on most browsers. and Windows installs You may need to click through the "details/keep this file" process in your browser's downloader and in your OS. This tool is completely optional, so if you do not wish to use it, simply wait until the official SDK release.

Update 2026-02-10: The app now has a pause built-in so you can simply double-click to run it.

Korg Driver Install/Uninstall Repair Tool

Update 2026-02-15: Added midifixreg. If you know Windows MIDI Services has been enabled on the PC, but the Korg driver installer/uninstaller or a third-party tool that claims to fix the driver order, has resulted in a non-function MIDI setup, use this tool to restore that Drivers32 registry location to what is required for Windows MIDI Services. Run the tool from an Administrator Terminal window.

WARNING: If Windows MIDI Services was not enabled on your PC, this will mess up your MIDI setup. It is only for PCs which have had Windows MIDI Services enabled.

App SDK RC 1

Windows MIDI Services App SDK Release Candidate 1

Announced on the Windows Insider Blog today. Please see the blog post for information on the update toggle.

IMPORTANT NOTE 1: Installing this on a Windows release build will not make Windows MIDI Services available to you. If you are on non-Insider Windows, please wait for the official release in Q1 2026. Unless you are a developer, please do not install this version of the SDK and tools because it can make it appear as though MIDI is enabled on your PC, even when it is not. If you are not a developer, please wait for the next SDK release.

IMPORTANT NOTE 2: The 24h2/25h2 release is part of a Controlled Feature Rollout and test validation. That means that not everyone will get the new MIDI stack enabled on their PC at the same time. It takes approximately 30 days. If you are on Insider Dev/Beta, only 50% of people on the Insider build will receive the feature update. There is no way to change that.

If you are a MIDI customer reading this after our official 2026 release, then you do not need to install anything except for the SDK and Tools runtime package. The service is already installed on your PC. Installing this service version on retail Windows 11 will change your Windows installation, and require you to repair the Windows install and/or reinstall Windows to get back to the normal release.

Windows Version	Instructions
Windows Retail 24h2/25h2	Do not install anything from this release. Coinciding with the 1.0 in-box Service and components release, we'll release an updated SDK and Tools package in Q1 2026 with the 1.0 SDK release.
Windows Insider Dev and Beta	Install today's Windows Insider release, and then install just the SDK Runtime. Do not intsall the service package.
Windows Insider Canary	Install the service and SDK packages. Note that some bugs have not yet been fixed in Canary, and will remain buggy until into Q1 2026. Notes below.
Windows Retail older than 24h2	Windows MIDI Services will not be available for your version of Windows. Upgrade to a more recent version of Windows 11.

Status

SDK Production use by application developers is not yet allowed. However, preview/beta-level use for applications shipping preview releases to customers familiar with working with previews is encouraged. One reason for this is that the Windows MIDI Services detection code supplied to developers falsely indicates a working install on machines which have Windows MIDI Services installed, but not yet enabled as part of our feature rollout process.

Status of included components in this release

Component	Status	Notes
App SDK NuGet Package	Release Candidate	No further changes planned for 1.0 release *
App SDK Runtime Package	Release Candidate	No breaking changes planned for 1.0 release *
Various console utilities like mididiag.exe	Release Candidate	No further changes planned
MIDI Console App midi.exe	Preview	Mostly complete
MIDI / Musician Settings App	Preview	Actively in development
PowerShell Utilities	Preview	Not yet a full implementation
USB MIDI 2.0 Driver	Release 1.0	This code is in process of going in-box in Windows
MIDI Service	Release 1.0	This code is in process of going in-box in Windows. DO NOT INSTALL unless you are on a Windows Insider Canary release. This is not needed for Insider Dev or Insider Beta releases, and will not work on non-Insider Windows.
KS / USB Transport	Release 1.0	Same status and notes as MIDI Service
Virtual Device Transport	Release 1.0	Same status and notes as MIDI Service
Loopback Device Transport	Release 1.0	Same status and notes as MIDI Service
Service Test Transport	Release 1.0	Same status and notes as MIDI Service
Network MIDI 2.0 Transport	Early Preview	Not yet a full implementation. Requires you have Developer Mode enabled to install.
WinMM MIDI 1.0 API Compat	Release 1.0	Requires the feature via Windows Update for latest fixes.
WinRT MIDI 1.0 API Compat	Release 1.0	Requires the feature via Windows Update for latest fixes.

* The SDK includes types marked as preview or experimental: for example, the Network MIDI 2.0 support. Those types will continue to change and may possibly break. The remaining components not marked as experimental will not have breaking changes and are safe to compile against using SemVer rules for version compatibility.

Required Windows Builds

Because we are in the process of releasing the in-box components, the Windows Insider Canary release will not have the latest bug fixes for WinMM until after we've already deployed into production. The Windows Insider Dev and Beta releases from today have the service bits you need, and are therefore the recommended Windows versions to use. For this release, we will not accept bug reports from any releases except from the latest Insider Dev / Beta.

IMPORTANT: Do NOT install the service components on retail Windows 11, or on Windows Insider Dev / Beta channel builds. Doing so may result in you having to reset your PC. The MIDI Service is only for use on Windows Insider Canary releases. We provide no support for installs on other releases of Windows.

Customer Deployment

These bits are not yet for customer deployment for production applications. We recommend waiting for the in-box component deployment in Q1 2026 to deploy applications using these components. See additional information in Status section above.

Changes and Fixes

MIDI Settings App

The MIDI / Musician Settings app is still in preview and will continue to change as we add features and fix bugs. This release includes bug fixes, primarily around data refreshes. Please see the Issues area for known issues.

Supports light-mode as well, of course. We're still tweaking colors, so Dark mode tends to look a bit better and have more robust contrast in this release.

MIDI Console App

The MIDI Console app is still in preview and will continue to change as we add, remove, or update features. This release includes bug fixes, and also some UI reformatting, as well as cleaning up of the MIDI monitor output.

MIDI Monitor shows more useful data by default

The original output of the MIDI monitor was largely focused on developer output. As this is the primary MIDI monitor for Windows MIDI Services, it's been updated to produce more musician-friendly output by default. New switches have been added to help control the output

By default, the timestamp information is hidden, but the messages are decoded. If the device is a MIDI 2.0 device, the data field will be large enough for 4 MIDI words. If the device is a MIDI 1.0 device, it will be sized for two words.

PowerShell Projection

Thanks to a PR from first-time contributor @bjompen, the PowerShell projection now includes the New-MidiLoopbackEndpointPair cmdlet. Thanks!

Other Tools

The SDK and Tools package includes the following command-line tools, installed to your Program Files\Windows MIDI Services\Tools folder, and then added to the path so they can be run from any new Terminal instance.

Tool	Notes
midi1enum.exe	Debugging tool which lists all MIDI endpoints as seen by the WinMM MIDI 1.0 API
midi1monitor.exe	A simple incoming MIDI message monitor which uses the WinMM MIDI 1.0 API. Use midi.exe for a more feature-rich MIDI monitor which uses the new SDK
mididiag.exe	Use this when talking with technical support at a company. It creates a text dump of your MIDI setup
midifixreg.exe	A useful tool in case you ran a driver installer or "top 10 drivers" rearranger which has messed up the two required entries for Windows MIDI Services
midiksinfo.exe	A debugging tool that provides insight into connected KS (typically USB) MIDI devices
midimdnsinfo.exe	Lists advertised Network MIDI 2.0 endpoints on your subnet

Developer Changes

App SDK for Developers

Visual Studio and .NET version

The app SDK project has been updated to Visual Studio 2026. The .NET projection for the App SDK now uses .NET 10 and so requires the .NET 10 runtime.

The .NET-based tools have also been rebuilt to use .NET 10 and Visual Studio 2026. .NET 10 is the latest release, and is also a long-term-support release of .NET, bringing with it many fixes and performance improvements.

The generated projection targets files for .NET no longer add the .winmd file as a reference, and so no longer require C#/WinRT, making them more compatible with other .NET languages like Visual Basic. See issue #801.

Virtual Devices

Added helper function to MidiVirtualDeviceManager to get the client-side endpoint id, if it's available

Multi-message sending

The only really new SDK feature in this update is the addition of proper multi-message sending. This can provide a significant performance boost when sending large chunks of data inte...

Preview 13

Announcing Windows MIDI Services Preview 13!

(This will be updated on the main download page at aka.ms/midi and in the existing settings app after this has settled a little.)

To avoid installing wdmaud2.drv and the in-box service, you will need to use Windows Insider Canary release 27920 or later. Recommended release: Windows Insider Canary 27950+ (br_release)

IMPORTANT: If you install this on a retail Windows build before the feature has been rolled out to everyone in late 2025/early 2026, WinMM and WinRT MIDI 1.0 calls will not be routed through the service, and so there will be no multi-client operation. You also will not see loopback or network MIDI endpoints in MIDI 1.0-API-using apps. For those reasons, I recommend you install on a Windows Insider Canary release of Windows

If you receive a "file in use" error during the install, please let me know. I've only been able to reproduce this issue on one test VM. It's with the Windows App SDK Runtime installer part of the SDK and tools install. I've brought this to the product team but today is a holiday so any changes will need to come later. Note: There's no workaround right now.

This release has two major areas of updates:

• Device surprise removal detection and recovery
• Settings app and SDK updates

There are some other changes and bug fixes, but this release is primarily about getting the Settings app closer to a 1.0 release, especially around endpoint customization, and for getting the surprise remove service / app lock-up issues addressed.

Surprise Removal

Most or all of the Surprise Removal issues should now be fixed. You can plug/unplug devices whether they are in use or not. You should no longer experience any MIDI Service hangs as a result. You can also plug in USB devices without restarting the service.

SDK-using apps can auto-reconnect to the endpoint when it comes back. WinMM apps cannot. We're validating that the behavior is consistent with WinMM in the past and will update if needed.

SDK Updates

Cleaned up the loopback endpoint code. Instead of crashing the service, it will now reject entries where the unique ID has already been used. (Issue #721).

The loopback endpoint creation result now includes an error message that apps can display if the creation did not succeed.

As part of that work, the default loopback endpoint ids were simplified and the default names changed to include "App" so they are not confused with the diagnostics endpoints (change driven by app developer feedback).

A new type, MidiImageAssetHelper has been added to help with resolving paths and default image file names for apps to use when displaying images for endpoints. This takes into account the customer's customizations as well as the fallback images.

vcpkg

On Monday September 22, the vcpkg microsoft-windows-devices-midi2 will go live. This is the Preview 13 SDK for developers and has been created to simplify consumption of the NuGet package from cmake. It does not include the SDK runtime, just the metadata required for compilation. Please see the new cmake sample in the samples area for information on how to use the vcpkg.

The Last of the Breaking SDK and Service Changes

We're still in preview, so although we try to avoid breaking changes, they are still allowed when they will make the final product better. Once we're out of Preview, which is expected to be the next release, e'll follow SemVer rules and not have breaking changes until a major version update, at which time the major versions will be available side-by-side so as not to break existing applications.

To cleanly support customization, the endpoint properties have been changed to remove references to large/small image (it's just the image now), and the device property for large image has been removed. The property number for the small image has been retained but is now just the image. The device enumeration SDK type for user-provided info has been updated accordingly.

Additionally, the MidiEndpointDeviceInformation type now has a Midi1PortNamingApproach enum property to indicate how MIDI 1 port names are generated for that endpoint. This information is needed as part of the customization workflow for endpoints.

Added the static GetAssociationId method for the MidiLoopbackEndpointManager to facilitate endpoint removal from the Settings UI.

Simplified the Midi1PortNameTableEntry structure to represent the new simplified name table structure

Change IMidiServiceTransportPluginConfig.GetConfigJson() to return a JsonObject instead of a string. This was done to align with earlier code review. Most applications will not be using this object directly. This improves error handling and also helps improve performance and memory usage by avoiding all the conversions between JsonObject and winrt::hstring.

To use the runtime from this release, these breaking changes will require you to recompile your apps against the latest NuGet package, included in this release.

Note that any types marked "Experimental" may continue to change. For example, the Network MIDI SDK types

Settings App Updates

There has been significant work done in the MIDI Settings app, now named "Musician Settings" . It's not yet complete, and there are a number of bugs. However, it does much more than previous versions.

Note: One of the main issues in the Settings app right now is around data refresh. There are several places where data is not refreshed until you either switch the page you are on, or restart the app. The other main issue is the lack of feedback when you make changes: there are no confirmation or error dialogs displayed in some places, including the Network MIDI 2.0 setup page.

First Run

The first time you run it, or if you have removed the configuration file, you'll be prompted to go through the first-run setup.

When you click "Finish MIDI Setup" you have several options. By default, it will create the configuration file needed for endpoint customization, loopback endpoints, Network MIDI 2.0, and more. It will also create a set of default loopback endpoints that apps can use. This was a request from web developers who want to count on a specific loopback in Windows.

(scroll down)

You also have the option to choose the new-style MIDI 1.0 names, and also to set the service to auto-start with Windows. By default, this option it set to On, as we assume anyone using this settings app is a frequent MIDI user.

New Endpoints Page

The combined endpoints page now shows all endpoints. You can filter by transport if you want.

It has both a card view and list view display option.

Clicking "Monitor" for an endpoint opens the MIDI Console monitor with the endpoint pre-selected.

Updated Endpoint Detail Page

The Endpoint Detail page has been simplified and now includes the Monitor and Panic buttons at the top. If you want to customize the endpoint (next section) click the "Customize" link under the name.

Details for the Waldorf Iridum, running MIDI 2.0 firmware

Details for the ESI M8U eX, a MIDI 1.0 device with many ports

Endpoint Customization

You can now customize the names and other details for USB (KS and KSA, more correctly) endpoints. Customization for other types of endpoints is not planned for our first release.

Note: Customization relies on a persistent Id for the endpoint. In the case of USB devices, we try to be a little clever about matching that up, but if you change you device to a different USB port, or add a USB hub into the mix, and the device does not have a unique serial number, the personalization may be orphaned.

Customization requires the version of the MIDI Service that is included in this release. This version is not yet out in the Insider builds

When setting the generated port names, you can choose to use auto-generated "Classic Compatible" WinMM names, use the new style names (which take the name from the iJack, and device, which some devices enable for customization themselves via their own apps) or use the system-wide default.

If a custom port name is specified "Mini 347 In" and "Mini 347 Out" in the above, it always overrides the choice for that port.

Here's a partially-customized Moog One

And here's an interface with many ports. Only the image has been customized.

There a...

Preview 12

Update 2025-07-31 : WinMM/wdmaud2.drv replacement PowerShell scripts have been updated to support non-English systems. The wdmaud2.drv files themselves are unchanged.

Release Notes

Please see the Preview 11 release notes for all the features and details..

Preview 11 only worked on PCs with the Debug VC Runtime installed, which generally means developer PCs.

This install has been tested in a fresh Windows 11 VM. It no longer includes the debug version of the service and plugins for developers and troubleshooters. Debug versions have a dependency on a debug version of the Visual C++ runtime which is not redistributable, but is installed with developer tools. I'll look into a better approach for that in the future.

Instructions

Please uninstall the Preview 11 installed packages, and install the new Preview 12 packages. wdmaud2.drv has not changed from Preview 11 and so does not need to be removed/reinstalled if you have a working Preview 11 installation.

Preview 11

Preview 11 Quick start

Due to including debug versions of the service and plugins, this release will only work if you are on a PC with developer tools like Visual Studio installed. Please see Preview 12 for important updates which will work on all PCs.

Preview 12

Edits:

I've added a 32-bit wdmaud2.drv package to this release. If you install this (in addition to the 64 bit version) you'll be able to use your 32-bit apps like MIDI-OX and MidiClock, editors, etc.

There was a problem with the wdmaud2.drv included in the release. I've updated the binaries below. I've kept the old ones around for curiosity, but renamed the zips.

---

Recommended Windows Build: Windows Insider Canary 27902 or later. You must run these bits on a Windows Insider Canary build. They will not work on other builds of Windows.

IMPORTANT NOTE
The service and SDK have a breaking change to support optionally waiting for messages to fully transfer before returning from a SendMidiMessage call. This is enabled by default in WinMM and disabled by default in the SDK. This breaking change requires updated versions of

• The Windows MIDI Services SDK (install via installer)
• MIDI Service (install via installer)
• wdmaud2.drv (if using or testing any MIDI 1.0 / WinMM apps). If you want to install this, you must use the scripts included in the wdmaud2.drv zip files with the release. This will require a reboot after the file has been copied.

The minimum Windows Insider Canary build required to use this with the in-box service and wdmaud2.drv will be posted here when available ____________________________ , if there's not a newer GitHub release before then. Until then, this version of the SDK and wdmaud2.drv will not work with current Insider builds, only with the service build from the GitHub source as part of this release.

IMPORTANT NOTE 2

Because WinRT MIDI 1.0 (Windows.Devices.Midi) is delivered only in Windows, it will not be updated to use the new service API, and so you will not be able to send and receive messages using WinRT MIDI 1.0 (sometimes called UWP MIDI) until the Windows builds catch up and get the new service. If you rely on WinRT MIDI 1.0, do not install this release. For a similar reason, 32-bit apps like MIDI-OX will not work with this build. They require the SysWOW64 version of the wdmaud2.drv which ships with Windows.

Installation Instructions

1. Enable developer mode in Windows if you will be installing the service or plugins.
2. Uninstall any previous SDK version or service plugins
3. Only if you have previously had Network MIDI 2.0 configured, go to %allusersprofile%\Microsoft\MIDI in the file system and delete the *.midiconfig.json file(s). Then open regedit, navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows MIDI Services and delete the CurrentConfig entry completely. You can also just hand-edit the json to remove the Network MIDI 2.0 settings, but you must ensure your JSON file is valid or else it will not be loaded by the service. If you have not used Network MIDI 2.0 in the past, this step is not needed.
4. If you want to enable the latest service updates before they make it into Canary (required until the updated service is in Canary), turn on Developer Mode in Windows Settings, and then install the in-box Debug Service package before installing the SDK package. Normally this would be only for developers.
5. Optionally install the Preview Service Plugins package for Network MIDI 2.0
6. If you want to use WinMM (MIDI 1.0 apps) you must install the new wdmaud2.drv from the zip file. More information on that is included in the readme file in the wdmaud2 zip files. You will need to reboot after installing this (or after the next step).
7. Everyone should then install the SDK Runtime and Tools package. This is normally the only package an individual would install. The last step of that offers the ability to run the MIDI Settings app. I recommend doing that so you can set up your configuration file to allow for loopback endpoints, naming options, Network MIDI 2.0 configuration, and more.

When you click on "Finish MIDI Setup", you'll be able to create the required configuration file, create default loopbacks, set the service to auto-start, and also pick the default MIDI 1.0 port naming approach.

Installation Changes

Installing full preview builds, including the service, from GitHub is now much easier. No scripts to run, no settings buttons to push. The service installer now handles all permission setting and file ownership changes itself. This is still an advanced or developer feature, and so the service installer also now checks for Developer Mode to be enabled before it will execute. Developer Mode is enabled in Settings > System > For Developers. The scripts are still there in case something gets broken and you have to use them.

To reduce download size, the SDK Runtime and Tools installer now downloads the .NET runtime installer on-demand only if not already present. It has been removed from the actual install package.

SDK Changes

There has been a lot of work done on the SDK since the last public preview. Some of the changes are breaking changes requiring recompilation of apps built against older preview SDK versions.

Breaking Change: Updates to initialization COM object and HPP file ⚠️

Please ensure you pull in the latest initialization HPP Microsoft.Windows.Devices.Midi2.Initialization.hpp from the NuGet package. There have been some minor but breaking changes to align with SemVer versioning of the SDK while also aligning with Windows file versioning.

Breaking Change: Contracts and interface Ids for future versioning ⚠️

The SDK in this release includes contracts for all the different non-experimental SDK features. This enables versioning and an application safety net after we go live with the first release

Additionally, all the runtime types now have UUIDs specified in the IDL. These are different from the auto-generated ones, and make it easier for us to manage additions in the future without breaking backwards compatibility

** This means this preview will not work with apps compiled against the old metadata from NuGet **. However, these are now set for good and will not change.

IDs are consolidated into the midi_sdk_idl_defs.h file.

Breaking Change: Support for waiting for message sends ⚠️

The MidiSession::CreateEndpointConnection signature has changed. AutoReconnect was moved to the settings interface and a new type MidiEndpointConnectionBasicSettings was added as a concrete implementation of that interface. In addition to AutoReconnect, this type also includes a property to indicate if the SendMidiMessage functions should return only after the message has been confirmed sent to the driver / endpoint. Otherwise, the function returns as soon as the message has been dropped into the service incoming message queue.

This change, which was required for WinMM compatibility, necessitated a change in the service interface. For that reason, the MIDI Service, wdmaud2.drv, and the SDK must all be updated at the same time. It will take several weeks before updated wdmaud2.drv and updated MidiSrv make it into the Canary builds.

Outgoing Message Scheduler

To help avoid errors, there's now a maximum future time allowed for scheduling messages. That's currently set to 5 minutes into the future. You can inspect this time by using MidiClock::TimestampConstantMessageQueueMaximumFutureTicks().

The limit is enforced inside the MIDI Service.

Preview Support for Network MIDI 2.0

This release of the SDK includes preview support for Network MIDI 2.0, when the Network MIDI 2.0 preview service plugin is installed. This code is not yet considered stable, and is tagged as experimental. The types do not yet have final interface UUIDs.

Support for SDK updates

The SDK also includes functions to check for updated SDK runtimes. This is primarily for use by the MIDI Settings app, but it's public and so can be used by your own apps if you wish to check for updated SDK runtime versions for a PC which already has the runtime installed.

Other general SDK changes

Eliminated redundant LoadLibrary calls when activating SDK types

Removed GetInstalledMessageProcessingPlugins from Microsoft.Windows.Devices.Midi2.Reporting.MidiReporting. That will be added back to the interface under a new contract version when it is implemented.

Added MidiUniversalSystemExclusiveMessageBuilder for some Universal SysEx, like Identity request. This is marked experimental while it is fleshed out.

Added MidiUniversalSystemExclusiveChannel to support the 0-127 values for Universal System Exclusive channels

ToString() on Channel, Group, and MidiUniversalSystemExclusiveChannel all use the long label now ("Group" instead of "Gr", etc.)

For endpoint processing plugins, the source parameter of the MidiMessageReceived event has been changed from the parent endpoint connection, to the plugin itself. Without this change, centralized message handling lacks the context required to know the filters in use.

In addition, we moved the ConnectionId, ConnectedEndpointDeviceId, Tag, IsAutoReconnectEnabled, and IsOpen connection properties to IMidiEndpointConnectionSource interface and then added `...

Customer Preview 2 - Feb 28, 2025 Windows Insider Canary

Thank you for checking out Customer Preview 2! This release is the next step on the journey to having full in-box support for Windows MIDI Services in Windows later this year. This preview requires Insider Canary release 27802+ and will not work with the previous releases, including 27788. Additionally, SDKs from those releases will not work with this one, because there has been a service ABI change.

Please read these notes in their entirety before installing anything.

If you want to install this on retail (non-Canary Windows) like Windows 11 24h2, you can install the entire Service/Plugins and the SDK/Tools. However, there will be no MIDI 2.0 class driver, and no support for existing MIDI 1.0 applications using WinMM or WinRT MIDI 1.0. Installing this way is really only useful if you are a developer working directly with the Windows MIDI Services SDK, and with MIDI 1.0 devices through it, or with virtual MIDI 2.0 devices created in software.

Install Options

Because of the WinMM fixes are critical to so many, and because it will be another week or two before the first of the WinMM fixes make their way into the Insider Canary builds, there are two options for installation for this preview.

Do nothing

If you install only the Windows Insider Canary build, but no SDK or other installers from here, you will have WinRT MIDI 1.0, but not much else.

Install just the SDK and Tools

Install just the SDK & Tools, and use the in-box pre-installed Service, Driver, and Plugins from this Canary 27802 release. This is a good option if you do not use any apps which require WinMM (MIDI 1.0) messaging, and you want to focus only on MIDI 1.0/2.0 development using the new SDK, or want to test out WinRT MIDI 1.0 compatibility.

In this case, WinMM (MIDI 1.0 used by most apps today) will still be broken, but the in-box MIDI 2.0 class driver will function, as will anything using the Windows MIDI Services SDK directly, or using WinRT MIDI 1.0.

Install the full service replacement, with WinMM fixes, in Developer Mode

This is the best option if you are relying on WinMM MIDI 1.0 compatibility, or want to test out all of the latest fixes before they make it into the next Canary release. This approach will still use the in-box MIDI 2.0 class driver, but everything else will be installed from GitHub.

Install the SDK & Tools, as well as the Service & Plugins and wdmaud2.drv. This is more involved, and is primarily for technical users and developers with local Administrator access, but includes all the fixes for WinMM compatibility, service changes, and more, including some which may not be in Canary for several weeks.

Note: This will not provide compatibility with 32 bit MIDI apps like MIDI-OX. That will need to wait for the WinMM fixes to make their way into an upcoming Insider Canary release

Instructions on how to install everything in developer mode are included here. The dev prep process no longer requires running scripts, but can instead be handled primarily through the MIDI settings app.

Major Fixes in Canary 27802 if you do NOT install the Developer preview Service and API components, and only install the SDK and Tools

• Fixed #49. WinRT MIDI 1.0 now works with the service like WinMM MIDI 1.0 does.
• Fixed #558 with SDK initializer lifetime issues
• Fixed #538 (feature request) The first run experience in the MIDI Settings app now makes it easy to create a default loopback
• Fixed #510 with sending note on/off messages in midi2 using midi console play-notes
• Fixed #502 Where the loopback MIDI transport was not properly installed in Canary 27788

Major Fixes if you install the developer preview Service and API, and wdmaud2 packages on 27802 in addition to SDK and Tools

• Fixed the major WinMM crashes and compatibility issues #524, #518, #517, #516, #448, #445, #436, #433. This is the primary reason to install the Service, API, and wdmaud2.drv from this release.
• Fixed #503 Where function blocks were not being captured in Canary 27788 (Customer Preview 1)
• Loopback endpoints now expose Group 1 to WinMM endpoints, so there's a functional MIDI 1.0 loopback
• Updated WinMM names to no longer include trailing O/I and group number, when the original device is a MIDI 1.0 device

Important notes:

• WinMM port naming is still not compatible with what it was before Windows MIDI Services. Per issue 522, we are working on this. #522

• The installers are not signed, so you will get big warning dialogs when you go to install the tools & sdk installer. This is expected for now.

• In this release, SDK binary compatibility with the Loopback Endpoint Manager has changed. If you are creating loopback endpoints from code, via the SDK, you need to use the latest matched nuget package and runtime from this SDK. These are also marked "experimental" now to indicate they may still change. When we reach our official release, we'll lock binary compatibility so this does not happen when apps are shipped with dependencies on the SDK.

• The Arm64 build of the SDK and Tools still requires that both Arm64 and x64 versions of the .NET 8 runtime be installed.. The Arm64 version is installed as part of the setup. The included x64 version of the .NET 8 runtime must be manually run at any point before using the Settings app.

Other SDK Changes and Additions

• Updated SDK MidiGroupTerminalBlock::AsEquivalentFunctionBlock to remove orphaned separator characters like - and _ which would end up at the start of the generated function block name (especially with Korg devices)

MIDI KS Info app

• The midiksinfo.exe app has been updated to show MIDI 1 and MIDI 2 devices only, and with cleaner output.
• Use this app to see what our Kernel Streaming stack provides the service as far as naming and port information go. This is the information, (in addition to Group Terminal Blocks and Discovery info in MIDI 2.0) that we have available for naming ports and endpoints.

Settings app

• This is still a work-in-progress, but there have been a number of changes in this release.
• Added a first-run experience, making it easy to create a default configuration, set the service to auto-start, and create default loopback endpoints
• Added basic SysEx transfer (outgoing to devices only) to Settings app (experimental, please try). It currently works with binary .syx files.
• Updated loopback endpoint creation process to be easier to understand, as they are a little different from what folks are used to with MIDI 1.0

• Removed some unused developer settings. If developer mode is set to on in Windows, the For Developers page appears in the settings app with some additional settings specific to developer debugging hardware and software devices and apps.
• Updated the Home page

Console app

• midi.exe now has the midi service set-auto-start which, when run from an administrator console, will change Midisrv from demand-start to auto-start, eliminating the delay when apps first use the service.
• The message sending code now waits for you to hit enter before it closes the connection. This can be necessary with some devices. Use --no-wait if this behavior is undesirable

Simple WinMM MIDI Input Monitor

• midi1monitor.exe now decodes incoming messages and provides more useful output. It also hides active sense and clock messages.

New! PowerShell cmdlets

• The SDK installer now includes some work-in-progress PowerShell cmdlets for PowerShell 7.4 (.NET 8) and above. Using these, you can enumerate endpoints, send messages, see sessions, get information about a message, and more. One feature not yet fully implemented is event handling for incoming messages. That will come in a future release. But if you've been looking for a way to script with MIDI on Windows, here you go. :)
• The samples, located here https://github.com/microsoft/MIDI/tree/main/samples/powershell , show how to use the features
• Like the other SDK bits, the cmdlets are not yet signed.

Import-Module WindowsMidiServices
Start-Midi

$session = Start-MidiSession "My Session Name"

$endpointDeviceId = "\\?\swd#midisrv#midiu..."
$connection = Open-MidiEndpointConnection $session $endpointDeviceId

Send-MidiMessage $connection @(0x40905252, 0x02001112)

Stop-MidiSession $session

Stop-Midi

Output from the current version of the PowerShell sample

Files

All required files are in the x64-full and arm64-full zip files. Be sure to uninstall any existing Windows MIDI Services previews before installing these.

The .nupkg is needed only for developers. For the rest, see installation notes above. Please do not skip reading those. :)

Customer Preview 1 - Feb 5, 2025 Windows Insider Canary

Milestone!

We're in and fully enabled in the Windows Insider Canary channel! We've had versions in the Windows Insider Canary builds since the past fall, but they were not enabled for everyone. This time, they are.

Learn more in the blog post at https://aka.ms/CanaryLatest and https://aka.ms/midifebcanary

Please read the entire release notes, especially the key known issues like having to restart the service to see MIDI 1 devices, before installing the SDK or filing any issues.

Bumping this up to the top so more folks see it. The SDK runtime and tools is not yet signed because it's being built from source here on GitHub and not from our internal system. You'll get the usual browser warnings and SmartScreen filter dialogs as a result. That's also why the NuGet package is here, and not on the official site. This is likely to be the case for the next couple preview releases. Entirely up to you if you want to install it anyway, but I encourage you to try it out. :)

Required OS Release

If you rely on your music applications on this PC for any production work, do not use this release. Windows Insider Canary releases are for enthusiasts and developers who wish to try out new functionality, provide feedback, and get a peek into where we're going.

At a minimum, this release requires the Windows Insider Canary Channel release from February 5, 2025: Windows 11 27788.

We'll have a future SDK update for an upcoming Canary release which will need to be locked with that release due to one change in the contract between the SDK and the service. We'll announce that when it comes, lately near the end of February.

Installation

Developers: no need to install any bits other than the SDK runtime and tools. The driver and everything is included in the Windows Insider build so there is no service or driver install in the GitHub release. If you have any previous Windows MIDI Services SDK installed, uninstall it before this installation. Ideally, uninstall any Windows MIDI Services developer preview packages before you upgrade to latest Windows Insider Canary Channel release.

First, ensure you have the required minimum Windows Insider Canary build installed. This will not work with earlier releases.

If you are a end-user, the only thing to install is the SDK Runtime and Tools package for your CPU architecture. For developers, I've also included the NuGet package so the version numbers align with the samples.

IMPORTANT NOTE FOR ARM64 USERS: I had to use the x64 version of the Settings app to work around an SDK activation issue with WinUI apps #508. This requires the x64 runtime for .NET 8, which is not included in the install. The Console app still uses the Arm64 version of .NET 8. To install, get the 8.0.12 (or later) x64 Desktop Runtime from here. The SDK and other tools are all Arm64 native.

What to Expect

The Windows Insider Canary release includes:

• The new MIDI 2.0 and MIDI 1.0 UMP Class driver, enabled as a class driver
• The MIDI Service and all production transport plugins
• WinMM Support for 64 and 32 bit applications on Intel/AMD processors.
• WinMM Support for 64 bit applications on Arm64

The WinMM support is important to call out. The WinMM API now routes messages through wdmaud2.drv which calls into the new service. The service is also responsible for creating the port names. So now, all WinMM ports are multi-client, and have (we hope!) better names for the devices you use.

The SDK and Tools release includes:

• All console tools as before (midi.exe, midiksinfo.exe, mididiag.exe, midimdnsinfo.exe)
• Preview of the MIDI Settings application. In this, you can see the different types of endpoints available in your installation, create loopback endpoints (see note below), monitor inputs (via launching the console) and more. This is a very early preview so is far from complete. We'd love your feedback and ideas for what you want in a MIDI Settings app.

Issues

There are a number of known issues with this release. Please check the Issues list before reporting new issues. In-particular, the loopback endpoint activation entry is missing from the registry in this one. See #502 for information and workaround. Additionally, function blocks are not being captured from MIDI 2.0 devices. See #503 .

Most MIDI 1.0 devices are not correctly detected if plugged in while the service is running. Issue #483. Restarting the Windows MIDI Services through the Services app will then show the devices for you. (Start > Services, find the Windows MIDI Service, right-click and select "restart". If you have the SDK runtime installed, you can also open an admin command prompt and type midi service restart)

WinRT MIDI 1.0 will not work with this release. You'll see ports but cannot use them. We have that functioning internally and will include it in an upcoming Insider release.

32-bit apps like MIDI-OX on Arm64 are not currently working. We're looking into it. See #504

The Runtime tools and SDK installer is not signed, so you will get the usual warnings when you download and install it.

Other issues are in the issues area of this repo.

Documentation

Documentation: https://aka.ms/midi

DP9 NAMM Preview 4 - Arm64 fix

This build is really only needed if you are using Arm64 and have run into the problem with not being able to open connections -- a pretty essential function :)

Please see instructions from Preview 3.