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 27934.1 (br_release)

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.

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 are no product images included with the install. Images shown here are for illustrative purposes only. No rights to those images are implied by their use here.

These are the freely-usable default images for endpoints, installed with the SDK. The image is based on the transport used.

There are some known issues around customization, especially for devices using the new MIDI 2.0 driver / KS transport. For example:
#748
and the fact that you cannot yet remove images from the Settings app
#745

Global Settings Page

Speaking of the OS-wide default for naming, you can set that in the Global ...

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

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. :)

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

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.

(Note: If you are on Arm64, please use Preview 4 with the same instructions here. Preview 3 has a problem connecting to endpoints on Arm64)

Important Pre-Installation Steps

If you are on a Canary Insider build of Windows, you MUST follow these steps BEFORE installing the packages below. This is required each time you get a new version of a Windows Insider Canary build.

https://microsoft.github.io/MIDI/developer-how-to/how-to-install-development-builds.html

If you see failures registering components during the install, it may be because of the above steps not being followed.

WinMM Compatibility

If you are testing WinMM port generation, you must also use the enable tool to switch from AudioEndpointBuilder to MidiSrv and also the copy tool to replace wdmaud2.drv in your System32 directory. Directions have been provided to you in Teams if you are a partner helping with this internal testing before the feature is enabled in Windows Canary builds by default.

Remaining Installation

Install the Packages

Run the three installers as you would with any other release. Do make sure you uninstall any other version you may have installed.

Firewall

If you are testing Network MIDI 2.0, let MidiSrv through the firewall as explained in DP9 NAMM 1 here https://github.com/microsoft/MIDI/releases/tag/dev-preview-9-namm-1

Copy the Default.midiconfig.json

If you are testing Network MIDI 2.0, you will need to modify the configuration file with your own entries. I have included example versions with the release.

To replace the Default.midiconfig.json file, you will need to take ownership of the %allusersprofile%\Microsoft\MIDI folder as per the same DP9 NAMM-1 instructions above. In some cases, you may also need to right-click the MIDI folder and grant rights to all users. I haven't nailed down the differences yet, but this will be changed after our first post-NAMM preview.

Some have found they could not edit the existing Default.midiconfig.json, but they could overwrite it with the version from the release.

Changes and Fixes

Service

• Service startup time improved by optimizing the WinMM port creation code

Aggregate (MIDI 1.0 Devices) Transport

• Now properly detects newly plugged-in devices and other changes (driver assignment etc.) and re-enumerates the device.

Network MIDI 2.0

This is still a work-in-progress, but is more functional than the previous release. This is not ready for production use, but may be used for demos, development, etc.

• Changed endpoint creation so it no longer directly uses the Product Instance Id. This eliminated several issues
• MIDI Service now sends outbound pings
• MIDI Service now disconnects from remotes if 5 consecutive pings are not returned

One way you can test Network MIDI 2.0 is by using MusiKraken available in the iOS app store. That has preview Network MIDI 2.0 functionality in place.

Note that the Network MIDI 2.0 implementation does still require that the remote host be advertised using mDNS. Direct connection is not yet supported. Also, authenticated connection is not yet supported.

Known issue: If you disconnect from a remote network MIDI host (Windows is the client), Windows MIDI Services will not reconnect to it without restarting the service.

SDK Compatibility

This SDK version is binary compatible with apps built for DP8 or DP9.

USB MIDI 2.0 Driver

There's no new driver for this release, but an updated version is coming in the post-NAMM release in the Windows Insider Canary build. This will work with the 10.0.1.7 driver from DP7. https://github.com/microsoft/MIDI/releases/tag/dev-preview-7

Documentation

While not complete, I've made significant updates to the documentation at https://aka.ms/midi .

Well, that was quick :)

I found a sequence number bug in the Preview 1 release which was preventing communication with some devices. As a result, figured I'd better put out another update here so folks don't waste their time.

The only thing that has actually changed here is the Service transport plugin. So if you already have the NAMM Preview 1 installed, just uninstall the preview service plugins and replace with this.

Instructions are in NAMM Preview 1: https://github.com/microsoft/MIDI/releases/tag/dev-preview-9-namm-1

Unless I find something really blocking folks, It'll be a couple more days before I put out another preview of this.

Important Note

Even more Important Note: Please use the bits from NAMM Preview 2. I've removed the installers from this release so no one wastes their time.
https://github.com/microsoft/MIDI/releases/tag/dev-preview-9-namm-2

This is a rough DAILY build with minimal testing. I recommend using this only if you plan to test or demonstrate Network MIDI 2.0 functionality. Do feel free to log any bugs you find, and note the release used as DP9 NAMM Preview 1 if you are using the entire preview.

The DP9 SDK is compatible with DP8 and DP9 services.

Installation Instructions

There are a few key fixes in the DP9 service code, but it is otherwise nearly identical to DP8. Please uninstall DP8 completely before installing this.

Please follow the DP8 install instructions with the DP9 preview bits included in this release. DP8 install instructions are here:
https://github.com/microsoft/MIDI/releases/tag/dev-preview-8

1. Make sure you have run the scripts to give yourself permissions (covered in the DP8 instructions). If you have done this previously for DP8 and have not installed a new Insider build since then, there's no need to do that a second time.
2. Install the In-box Service
3. Install the Preview service components (currently Network MIDI 2.0)
4. Install the SDK Tools and Runtime
5. Replace the configuration file as per below
6. Manually add midisrv.exe to your firewall exclusion list (see below)
7. Restart the service from the Services control panel (right-click "restart")

Minimal Install for DP8 users

I recommend installing everything, especially if you intend to file any bugs, but if you want to use the existing DP8 service, that is possible.

1. Uninstall the DP8 SDK Runtime and Tools
2. Install the DP9 SDK Runtime and Tools
3. Install the DP9 Service Plugin Preview installer (this includes Network MIDI 2.0)
4. Follow other instructions re: config files etc.

If you run into bugs and plan to file them, please first upgrade to the full DP9 preview.

Minimal Install for In-Box users

This has not been tested with the recent in-box Canary bits, but is not expected to work with in-box bits until the at-or-after-NAMM Canary release. Please use the full installer instructions above until we release a version that has been tested with that upcoming Canary build.

Firewall

Currently, midisrv.exe does not have permissions to poke through the firewall. As a result, Network MIDI 2.0 will not work without a Firewall exception. It is also not in the list of apps in Windows Defender Firewall, so you need to manually add it.

If you are using a third-party firewall product, you will need to use their instructions for allowing an app through.

1. Search->"Allow an app through Windows Firewall"
2. Click "Change settings"
3. Click "Allow another app..."
4. Click "Browse" to locate the exe
5. Navigate to the location of midisrv.exe. In preview builds, this is under Program Files\Windows MIDI Services\Service . In in-box builds, this is under \Windows\System32
6. Click "Network types..." to select the appropriate network types (for those demonstrating at NAMM or using someone else's network, you may need both Private and Public to be checked)

10. Then click "Add". You will either see "midisrv.exe" or "Windows Midi Service" depending upon when you look at the list. Either is fine.

11. After you have completed this step, you will be able to restart the service and connect to the network.

For those who prefer, you can also add the exclusion through the basic command-line or PowerShell:

netsh advfirewall firewall add rule name="Allow midisrv in" dir=in action=allow program="C:\Program Files\Windows MIDI Services\Service\Midisrv.exe" enable=yes

netsh advfirewall firewall add rule name="Allow midisrv out" dir=out action=allow program="C:\Program Files\Windows MIDI Services\Service\Midisrv.exe" enable=yes

Support for the command-line option is beyond the scope of this project. Information on how to use netsh may be found here: https://learn.microsoft.com/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior

Configuration File

For this preview, there is no user interface for creating Network MIDI 2.0 connections, and they cannot be created at runtime. Instead, they can be created in the configuration file located in %allusersprofile%\Microsoft\MIDI

In Insider Canary builds with Windows MIDI Services pre-installed, you may run into an issue where the configuration file cannot be edited. To fix this, open an Administrator console and issue the following:

echo %allusersprofile%
c:

cd %allusersprofile%\Microsoft\

takeown /F MIDI /R

The echo and c: are just to ensure you are on the correct drive, and may be omitted if you have only a single drive, or know you are already on the correct drive. The Microsoft\MIDI folder is added by the preview installer and also by the recent Canary Insider builds.

That will give you ownership of the MIDI folder and the files it contains. We will fix this in later in-box releases. Note also that currently Canary Insider builds will overwrite the default.midiconfig.json file, so if you make changes, please keep a backup.

Included in this release is a replacement configuration file which includes a Network MIDI host, as well as examples of a few clients definitions. There are also some loopbacks defined which you may remove if you want as long as you make sure the file is still a valid JSON file (no stray or missing commas etc.)

In this preview, these match only on the Id, which means the devices must advertise their hosts on mDNS. The ids come from running the midimdnsinfo.exe tool which is included in the SDK runtime. That tool will, after a minute, list all advertised Network MIDI 2.0 endpoints visible on this subnet. It also lists

Example Host

You may define any number of hosts as long as you give each one a unique identifier (the GUID at the top here). I use GUID by convention, as will the tools, but you may use any unique string.

For those who used earlier Network MIDI 2.0 configuration files, the format has changed, and the old configuration file will no longer work. Note that this is still in preview and the configuration file formats are likely to change again before release.

                    "{090ad480-3cf8-4228-b58f-469f773e4b61}":
                    {
                        "enabled": true,
                        "networkProtocol": "udp",
                        "advertise": true,
                        "port": "auto",
                        "serviceInstanceName": "windowspreview",
                        "name": "Windows Network MIDI Host",
                        "productInstanceId": "3263827-5150Net2Preview",
                        "authentication": "none",
                        "connectionPolicyIpv4": "allowAny",
                        "createMidi1Ports": false
                    }

When in doubt, please refer to the Network MIDI Protocol specifications at https://midi.org

Example Clients

There are a number of clients defined in the configuration file. These are connections to remote advertised hosts. Currently, the hosts must be mDNS advertised to work. Direct IP/Port connection is not yet supported.

                    "{4353df3f-2ab3-47ff-bc51-dd9511047c29}":
                    {
                        "enabled": true,
                        "networkProtocol": "udp",
                        "name": "Kissbox Endpoint 21",
                        "match":
                        {
                            "id": "DnsSd#kb7C5D0A_1._midi2._udp.local#0"
                        },
                        "createMidi1Ports": false
                    },
                    "{893cd814-70f9-42a3-bffa-7e716c107756}":
                    {
                        "enabled": true,
                        "networkProtocol": "udp",
                        "name":"BomeBox DIN",
                        "match":
                        {
                            "id": "DnsSd#bomeboxdin-8q6d2z-1._midi2._udp.local#0"
                        },
                        "createMidi1Ports": false
                    }

Welcome to DP8!

The purpose of this preview release is to enable developers to code against the new centralized SDK. We'll be demonstrating some of these apps at the NAMM Show in January, as well as a preview of Network MIDI 2.0.

This is not an end-user-ready release.

Installation Notes

Always completely uninstall any previous Developer Preview releases before upgrading to a new release, and also before upgrading Windows to a new Canary Insider build.

Windows MIDI Services Dev Previews require Windows 11 Insider Developer channel or Windows 11 Insider Canary channel releases. Canary releases will be the first to receive the in-box builds. You can learn more about Windows Insider releases here

https://www.microsoft.com/windowsinsider/

You can enable Windows Insider releases on your non-production PC via Settings > Windows Update > Windows Insider Program

If you are running a recent Windows Insider Canary build, that build already ships with an older version of Windows MIDI Services pre-installed. Because it is an in-box release, the registry keys which it uses are protected and so our install this time around is a little more complex.

⚠️ IMPORTANT PRE-INSTALLATION STEPS ⚠️

To install a developer preview, we must unprotect those registry keys. If you do not do this, registering the service components will either fail with errors in the installation (most common outcome), or will fail silently.

• There's a new script which helps developers install the DP in a system which has Windows MIDI Services in-box installed. Run this before running the installer. The zip file below has the ones from the time of this build. You can always get the latest from:
  https://github.com/microsoft/MIDI/tree/main/src/dev-tools/reg-helpers

Run list-reg.cmd to see the current state of the system. If it returns back components with locations in your System32 folder, then you will need to run the dev-prep.cmd to take ownership of those registry entries before installing DP8. For example, this shows System32 (pre-installed) Insider components.

This shows the successful output from the dev-prep cmd file, which means you can then run the installers.

After running the installers, this output of list-reg shows the DP8 components installed and registered. Note that the file locations have changed from System32 to Program Files. Also note that the lack of entry for Network MIDI 2.0 is normal at the moment.

Notes:

• The scripts require Windows PowerShell 7.0 or higher, available here: https://learn.microsoft.com/powershell/scripting/install/installing-powershell-on-windows
• You must run the scripts from an Administrator (elevated) command prompt
• You must have script execution enabled (Settings > System > For Developers > PowerShell). Optionally, this can be done from an elevated PowerShell console using the Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine command as described here https://learn.microsoft.com/powershell/module/microsoft.powershell.security/set-executionpolicy .

When using dev builds with the Windows Insider Canary builds at this stage, there are several things to be aware of:

1. You may see duplicate entries due to both MidiSrv and AudioEndpointBuilder enumerating endpoints
2. It's a bit of a lottery as to which WinMM ports go through MidiSrv vs the older stack. This can result in problems with WinMM multi-client and more.
3. The existing bug with the older MIDI 1.0 class driver and power management is still there. When you assign a device to use the new MIDI 2 UMP class driver, and the device was previously assigned the generic MIDI 1.0 class driver, you need to unplug and replug the device quickly to avoid a potential green screen (BSOD) due to a power management bug in the old driver.

Those issues are all fixed, and we've provided a small number of partners with internal tools to enable the fixes, but we cannot distribute those broadly at this time. Instead, we're working to accelerate getting to a point where we can turn Windows MIDI Services on by default, along with these fixes and the new class driver, in Canary builds around the time of the NAMM show so that everyone may benefit and so customers can test as well.

Installer Versions

During installation, you may notice different versions between the two installers. That is fine. It's just a mismatch between file name and internal metadata when a file doesn't need to be rebuilt.

App SDK

Centralized Installation

In previous releases, apps had to ship the SDK implementation in the application's folder, and also had to include a manifest file which listed all the WinRT SDK types.

DP8 is the first version with the new centralized SDK. Desktop applications should no longer ship the Microsoft.Windows.Devices.Midi2.dll, the initialization DLL, or any MIDI activation manifest entries. Please verify that your own applications are following this new approach.

• The NuGet package no longer includes the WinRT implementation DLLs
• Under the Build folder of the NuGet package, the .hpp file for C++ apps replaces the previous Initialization binary. The C++ samples have been updated to use this. This is how you initialize the SDK.
• The aka.ms for downloading the latest installer is not yet active
• The installers are not yet signed

The SDK now includes a MidiEndpointDevicePropertyHelper class which is a convenience for identifying Windows MIDI Services properties. This is used in the console as described below.

Endpoint Connection Creation Hardening

In previous versions, you could pass any string to the session function to create a new connection, and it would happily return a connection object for you to later (fail to) open. This was brought up in issue #429.

The SDK code to create a new endpoint connection now pre-validates the supplied endpoint id by:

1. Ensuring it represents a Windows MIDI Services MIDI device
2. Checking to see if the MIDI streaming interface on the device has been activated.

If either check fails, the function returns nullptr. Of course, in between the time the connection is created and opened, the endpoint could go away. In that case, the call to Open will return false.

Additionally, the code to create a MidiEndpointDeviceInformation object by Id now does the same type of validation.

URLs

• Changed SDK Method InitializeSdkRuntime to InitializeDesktopAppSdkRuntime to avoid any confusion when using the SDK from packaged apps in the future, where it does not use the initializer
• Removed GetLatestSettingsAppReleaseInstallerUri and GetLatestConsoleAppReleaseInstallerUri. Instead, everything that is not in-box will be provided through a single installer at GetLatestDesktopAppSdkRuntimeReleaseInstallerUri
• Application developers are permitted to include the latest supported release version of the installer with their application. However, apps must not uninstall newer versions already installed on the PC. By default, the installer will not overwrite newer versions. When uninstalling your app, do not uninstall the SDK Runtime - mark it as permanent.
• To download the SDK runtime, please use the URLs returned by the Initialization methods, when they are activated (before 1.0 release)

Type Changes

• Fixed some static SDK types which had [default_interface] incorrectly specified, and some which didn't have the static keyword applied to the runtimeclass in the IDL. This changed the clsid property for a handful of classes
• Function blocks and most other locations which previously used a uint8_t Group Index now use the MidiGroup type.

Known Limitations

• The activation code doesn't prevent calling it twice within the same process (for example, the host app and a plugin). This is being worked on.
• For this release, packaged / MSIX / Sandboxed applications are not supported. Only desktop apps are supported.
  • To fully support packaged apps, we need to get the runtime installed as a shared library/framework package in the store. Packaged apps will also continue to require the manifest.

Experimental SDK features

• SDK components for preview service plugins, like Network MIDI, are marked with the "experimental" attribute and may change in future releases. If you use them, you'll see warning CS8305 with MSBuild.
  - Network MIDI 2.0 is under development, and not yet available in this release
• Experimental features are not guaranteed to be backwards compatible from release to release

DLL Versions

• SDK DLL properties now include proper product version resources

C# Projection

• .NET support has been moved to version 8 and above, as the SDK is using some COM features supported only in .NET 8 and higher. .NET 8 is the long-term-servicing version of .NET so this would have been required soon anyway.

WinMM Compatibility

Although we still have some bugs to sort out, the WinMM compatibility code is in place and is feature complete. However, do see the notes below about usage.

• For MIDI 2.0 devices, we use Function Block information, if available, and Group Terminal Block info if not, to decide which groups are active and should be exposed as MIDI 1.0 ports.
• For MIDI 1.0 devices, we try to name the ports in a way that makes sense g...