App SDK Runtime and Tools Release Candidate 4

Quality

Component	Stage
App SDK Runtime	Release Candidate. NOTE ABI changes below.
MIDI Settings app	Preview. This is still beta-quality and is in active development
MIDI Console app	Preview. This is quite stable at this point
Other tools	Other tools like midi1monitor, mididiag etc. are all stable

Instructions

We recommend uninstalling the old version of the SDK Runtime and Tools from Settings > Apps > Installed Apps (Settings, not control panel) before installing this version. You do not need to uninstall any service plugins.

Download the version appropriate for your architecture (Arm64: Qualcomm and similar, x64: AMD, Intel) and double-click to install. You do not need to run the installer as Administrator -- Windows 11 UAC will prompt for admin rights during installation.

This installer is not signed, so you will receive warnings when downloading and installing it. Some third-party antivirus may actually delete the app after it has been installed, or may prevent the installer itself from working properly. Refer to your antivirus/antimalware software documentation for how to add a temporary or permanent exclusion.

If you want the MIDI 1.0 loopbacks

Until these are in the main Windows releases, please use the Service Plugin installers from the rc3 release. The MIDI Settings app will work with those builds.

• MIDI 1.0 Basic Loopback Intel / AMD x64
• MIDI 1.0 Basic Loopback Arm64

If you want the Network MIDI 2.0 Preview

• Please see the Network MIDI 2.0 preview release here.

Functional Changes

Endpoint Image Handling

• This is a breaking change for apps using the endpoint images. We now copy the image to an intermediate location and point everything to that. As a result, we no longer store the full path in the Endpoint properties, but simply the image file name. MidiImageAssetHelper has been updated with GetFullImageAssetPathForEndpointImage to return the full path of the image for the endpoint.

SDK

Important ABI Change

After some discussion on Discord, it was agreed that service transactions such as creating new loopback endpoints needs to have an app-accessible return code, at least in the case of errors. To support this, it required a few ABI changes which require recompiling applications that use any of these types.

This also means that apps which take a dependency on RC4 (and eventually 1.0) will not work with runtime installations earlier than RC4.

• Microsoft.Windows.Devices.Midi2.ServiceConfig.MidiServiceConfigResponse: Remains a struct, but now has a UInt32 ServiceCode field.
• Microsoft.Windows.Devices.Midi2.ServiceConfig.MidiServiceConfig (due to above change)
• Microsoft.Windows.Devices.Midi2.Endpoints.Loopback.MidiLoopbackEndpointCreationResult changed from a struct to a runtimeclass, and adds the ErrorCode field, and changes the clsid
• Microsoft.Windows.Devices.Midi2.Endpoints.BasicLoopback.MidiBasicLoopbackEndpointCreationResult changed from a struct to a runtimeclass, and adds the ErrorCode field, and changes the clsid
• Addition of the following enums
  • MidiLoopbackEndpointCreationResultErrorCode
  • MidiBasicLoopbackEndpointCreationResultErrorCode

Because runtime types have getter/setter semantics and not fields like structs, C++ clients will need to change calls to fields like Status into function calls like Status(); C# clients use the same syntax for both.

In all cases, the Success property is still required to know if the call worked. If the call failed, the ErrorCode property may contain an error code. Note that this is going to require synchronizing with new code in the service, which will take several months. Until that time, the code will be NoErrorInformationAvailable for anything which failed service-side.

Result error codes are not guaranteed to be interchangeable across transports.

Additional Changes

• Additional exception handling in MIDI SDK functions for adding/removing loopback endpoints
• Basic Loopback and MIDI 2.0 loopbacks now create default unique ids if not specified at creation time
• Basic and MIDI 2 loopback creation will now do some basic validation of the data before sending to service
• SDK will now show better error information in some cases when dynamic port creation (loopbacks, virtual device) fails in the service. Previously, when the service returned a failed HRESULT, it would not look for error information. That's technically the correct approach, but the service is already in production, so not going to change that behavior.
• Added functions to MidiMessageConverter class to support converting streams of data and text

Command-line tools

• midifixreg now fixes both the 64 bit and 32 bit registry locations which can get corrupted by KORG and other driver utilities and uninstallers.
• midifixreg will not remove some well-known third-party drivers like the KORG BLE driver, VirtualMIDISynth, and MIDIMapper. If you see other entries we should leave in place, please do let us know on Discord or as a new issue in this repo
• mididiag now outputs both the 64 and 32 bit registry locations

Settings app

• The MIDI Settings app no longer refuses to start if the feature is not enabled. This was done because nearly all consumer PCs now have Windows MIDI Services enabled. This has made it possible to incorporate the registry fixing and other troubleshooting tools into MIDI Settings

• Added feature to the Troubleshooting page to view and repair registry entries (midifixreg)
• Added feature to the Troubleshooting page to capture MIDI repro logs

• The transports page now shows the full path of the implementation dll for transport plugins. This makes it easy to see if you are running in-box components, or preview components.

• We now have a page for the service transform/processing plugins so those paths can also be verified.

• Customizing an endpoint by adding an image now copies the image rather than relying on the original image location being available in the future.

• When renaming MIDI 1.0 ports, you can now see a preview of the different naming choices

• The MIDI Settings app now has a MIDI scratchpad with helpers for some common messages.

Fixed/Cleared Issues

• #980 [Feature]: Consider adding error codes to loopback/virtual device creation
• #964 [TODO]: Put in a confirmation prompt when deleting loopback ports in MIDI Settings
• #963 [BUG]: Set Service to Auto-Start in global settings in MIDI Settings app does nothing
• #947 [BUG]: SDK MidiMessageConverter seems to lose group index
• #946 [BUG]: MIDI Settings app home screen option to create loopbacks doesn't specify the type
• #943 32-bit apps like MIDI-OX and VSThost and ROLI dashboard may not work after KORG or other registry driver removal/reordering (this still happens, but the MIDI Settings app makes this easier to repair now)
• #920 [BUG]: Personalize page in settings app can't scroll to view all ports
• #870 [BUG]: Settings app doesn't gracefully handle removed/moved personalization images

Troubleshooting The Install

We're seeing a few instances where the MIDI Settings app is throwing an error on startup. These appear to be dependency issues.

If the MIDI Settings app gives you a pop up with a XamlParseException in it, please install the current stable Windows App SDK Runtime from this location:

• For x64 (Intel/AMD) PCs (if unsure, this is almost certainly the one you want)
• For Arm64 (Qualcomm, etc.) PCs.

If that still doesn't sort the error in the MIDI Settings app, then please also install the latest Windows 11 SDK

If that still doesn't do it, please start a thread in #midi-user-questions on the MIDI Discord server. We're trying to track down what's in common with the few PCs that are running into this.

Network MIDI 2.0 Spring 2026

Network MIDI 2.0 Spring 2026 Preview

No functional changes. This is a recompile to work with current shipping MIDI Service.

This preview does not have the entire Network MIDI 2.0 protocol implemented yet. It is of early preview / alpha quality, but may be used for testing and demonstration. Feel free to log/report bugs you run across. Please do so directly on GitHub.

Disclaimer

There is little/no customer support for this implementation of Network MIDI 2.0. Network MIDI 2.0 may impact the stability of MIDI on your PC. There may be breaking changes, including configuration file incompatibilities, introduced in future releases of Network MIDI 2.0 Only run if you are comfortable using early preview technology.

Required Service Permissions

To use Network MIDI 2.0, you must set the Windows MIDI Service to use "Local System" rather than "Local Service". This will be reset with each monthly MIDI update.

When we ship this in-box, we will have the minimum required permissions already set up.

Required Firewall Rules

Secondly, if you are running Network MIDI 2.0 for the first time, you will need to let the Windows MIDI Service through the firewall on your public and/or private network as appropriate.
https://microsoft.github.io/MIDI/kb/network-midi-firewall/

Network MIDI 2.0 uses UDP ports on your PC.

MIDI Settings App

Please use the RC4 release of the MIDI Settings app.
https://github.com/microsoft/MIDI/releases/tag/rc-4

WinRT MIDI 1.0 Timestamp Fix

2026-03-18 An updated version with the correct port-relative timestamps is attached below. The previous one has been kept in case it is needed, but has been renamed zzold-...

---

If you are negatively impacted by the WinRT MIDI 1.0 bug with timestamps that are in the future, here's the fix. Known apps this impacts include Steinberg Cubase, Cakewalk Sonar, and Algoriddim djay Pro.

Related GitHub bug with details: #847

Steps

Please follow these instructions carefully.

Download the zip file from the files list below.

Right-click and extract the zip to a location of your choice.

Close all apps using WinRT MIDI 1.0.

Double-click the .cmd file. This will copy some files to Temp and then open up a PowerShell window set to run as Administrator. You may be prompted for credentials. Don't run the .ps1 PowerShell file directly. Always use the .cmd file.

Read the information on the screen and hit "y" to proceed or any other key to exit.

The script will then display the existing file information and the file that will be used to replace it. You can then use the version information display here to verify that replacement has worked.

After it has completed, load up your app using WinRT MIDI 1.0 and verify that the timestamps are now correct. (You receive MIDI messages again, for example)

The existing Windows.Devices.Midi.dll in System32 will be backed up, so you can copy it back in the future should you need to.

If you notice that a future Windows update or upgrade restores the original file, run this script again.

If you need to revert back, open your System32 folder, delete the existing Windows.Devices.Midi.dll from System32 and then rename the .bak version to just .dll so that it replaces what you just deleted. Make sure you are showing file extensions in explorer so that you see the .dll and .dll.bak names

The source zips below are just a GitHub artifact, and not directly related to this fix.

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.

IMPORTANT: If you want the MIDI 1.0-style basic loopback endpoints (they work like loopMIDI and similar), you must install the service plugin as well as the SDK Runtime and Tools. If you don't want those, you only need to install the SDK Runtime and Tools package.

---

Quality

Component	Stage
App SDK Runtime	Release Candidate. No breaking changes.
MIDI Settings app	Preview. This is still beta-quality and is in active development
MIDI Console app	Preview. This is quite stable at this point
Other tools	Other tools like midi1monitor, mididiag etc. are all stable

Note: because the runtime is not yet signed, we don't recommend that app developers take dependencies on the preview SDK if they are broadly releasing to customers unless you indicate that the functions you use from the SDK are currently in preview.

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

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 `...