In-box Preview 10

This is now open to all customers who would like to try out the features and functionality.

Highlights and instructions

Key items

• MIDI 1.0 Loopbacks, RTP-MIDI 1.0, Network MIDI 2.0, Bluetooth LE MIDI 1.0 transports
• Apps including keyboard, Windows MIDI Glass, Windows MIDI Patchbay, and much more. Details here
• General MIDI Synth is a MIDI 2.0 synthesizer now

Packages and Installation Instructions

If you are running any of the older rc4 or similar SDK Runtime and Tools, or any of the older preview transports, fully uninstall them from Settings > Apps > Installed Apps before installing anything here.

Install the Tools package to have access to all the in-box tools required to configure endpoints, customize, route MIDI endpoints, create controller surfaces, and much more. Everyone will want this package. The tools are documented on the tools page.

Install the Transports package to have access to preview versions of

• General MIDI Synth
• Basic MIDI 1.0 Loopback Transport
• RTP-MIDI Transport
• Network MIDI 2.0 Transport
• Bluetooth LE MIDI Transport

You can turn the individual transports on or off on the Transports page of MIDI Troubleshooting and Repair, which is in the Tools package.

If you installed the separate Preview 9 transport installers, you don't need to remove them first. The Transports package removes them when it installs. Uninstalling them first won't cause any harm. The uninstall instructions above are to cover everyone, regardless of what they have installed. When in doubt, uninstall the old stuff.

MIDI Glass App (Using the Acrylic backdrop on my PC)

MIDI Patchbay App (Using the Mica backdrop with a custom blue tint on my PC)

All the apps let you set the background style (Solid Color, Acrylic, Mica) and your desired color.

Details for Developers and Technical Customers

Developer permitted use

We want to ensure customers have the best experience going forward. Because of this, we want to ensure that these app-local binaries are not normally present on customer systems which have the binaries in System32.

Distributing these API binaries is a choice you make. Although we will try to keep compatibility, Microsoft makes no guarantee that the in-box API binaries or service transports will be compatible with this Preview release. If that is not acceptable, please wait to distribute your app until the transports and API ship in Windows.

Developer Go-live agreement

This is the first Windows MIDI Services API release with a "go live" license for Windows.Devices.Midi2.dll, .winmd, and .pri.

This is still a preview, and we want to ensure that customers have a great experience going forward, so if you do go live with this, you need to agree to the following terms. These replace in whole the previous preview distribution terms.

By distributing the API binaries with my app, I (the developer of the app) agree:

Agreement updated 2026-10-05 due to tests run

Why this change: In all language projections we tested, unlike most DLLs, a local WinRT DLL is the fallback not the first pick by Windows. So once the API goes into Windows, your locally distributed copy will no longer be called.

That means that you as a developer need to stay up to date with any breaking changes up through when we indicate that the API surface area and metadata is locked.

Once Windows includes Windows.Devices.Midi2, your app uses the Windows copy, even if you still ship your own. Your copy is only used on PCs where Windows doesn't have it.

Given that, and the impact it will have on your customers, the new agreement is as follows:

1. I understand that the API is not yet locked, and breaking changes in metadata may cause my app not to work when the API is in-box in Windows. I will be prepared to compile against the latest .winmd file from Microsoft available before the rollout.
2. I have a mechanism to update the app to remove the API binaries once they are in-box in Windows, and to keep up to date with any additional previews.
3. I will make all possible efforts to keep up with any additional preview releases, and update my app to include those, ensuring customers have the latest fixes and features at least up through the point where we announce that the API surface area / metadata is locked
4. I will let my customers know that I am using preview Windows MIDI Services APIs, until the point when the preview API is removed from my product.
5. I will not ship the Windows.Devices.Midi2 API to versions of Windows below Windows 11 25h2 (Windows 11 24h2 is unsupported, and will not get the required fixes, so we recommend customers move to a supported version of Windows 11, or switch to Legacy API Mode)
6. I will file bugs on GitHub for any issues I encounter, and make an effort to assist in the debugging of the reported problems.
7. When the 1.0 version of the Windows MIDI Services WinRT API is in Windows, and I have a new release of the app built against it, I will make an effort to contact my customers to inform them of the new version and encourage them to update to it, if that process is not automatic.

Failed WinRT component activation is typically projected as an exception in your applications, so keeping up to date with the latest updates is important. Microsoft will endeavor to lock the API well before the expected release date so this isn't a last-minute surprise, but there's always the possibility that the .winmd has to differ in some way in the in-box version.

Previous agreement:

1. I have a mechanism to update the app to remove the API binaries once they are in-box in Windows, and to keep up to date with any additional previews.
2. I will make a reasonable effort to keep up with any additional preview releases, and update my app to include those, ensuring customers have the latest fixes and features.
3. I will let my customers know that I am using preview Windows MIDI Services APIs.
4. I will update my app to remove the out-of-band API and release a version compiled against the actual in-box Windows.Devices.Midi2 API within 90 days of the API implementation shipping in Windows 11 25h2 and later. Earlier is better.
5. I will not ship the Windows.Devices.Midi2 API to versions of Windows below Windows 11 25h2 (Windows 11 24h2 is unsupported, and will not get the required fixes, so we recommend customers move to a supported version of Windows 11, or switch to Legacy API Mode)
6. I will file bugs on GitHub for any issues I encounter, and make an effort to assist in the debugging of the reported problems.
7. When the Windows MIDI Services API is in Windows, and I have a new release of the app built against it, I will make an effort to contact my customers to inform them of the new version and encourage them to update to it, if that process is not automatic.

Note: The .pri file contains resources and must be installed with the dll. In the distribution acquired here, the resources are en-US only. The version that ships in Windows will be translated.

What this doesn't cover

If you develop a reusable MIDI library for other apps, contact Pete Brown directly. In many cases, once another developer takes a dependency on your library, they don't come back for updates. Therefore, it's much harder to ensure that all customers are covered in that scenario, so the ability to go-live will be made on a case-by-case basis, with a strong lean towards not allowing redistribution in this scenario.

Do not redistribute any of the installers, tools, or transports. The only redistributable files covered here are Windows.Devices.Midi2.dll and Windows.Devices.Midi2.pri and the related .winmd and C# projection files, and only if you adhere to the above terms. We're not trying to hold you back here, but we want to prevent customer dissatisfaction with your apps and with Windows.

Remainder

This set of release notes only covers the delta from Preview 9. Please refer to Preview 9 and earlier for everything before that.

A few items below may already be on your PC if you installed the September 21 refresh of Preview 9. They weren't listed in its update notes, so they're included here. Items that were listed in that update aren't repeated.

Installers

Each platform now has two installers, Tools and Transports. In Preview 9, each transport had an installer of its own.

• Windows MIDI Services Tools (0.99.88-preview.10) has every app, the MIDI Console, the PowerShell module, the command line tools such as mididiag, and the Windows MIDI Services API files the apps use. Network MIDI Setup and Bluetooth MIDI Setup moved here from their transport installers, and MIDI Glass is new.
• Windows MIDI Services Transports (1.0.35-preview.8) has all five preview transports: Network MIDI 2.0, RTP-MIDI, Basic Loopback, the General MIDI Synth and Bluetooth MIDI. It replaces the separate Network MIDI 2.0, Bluetooth MIDI, Basic Loopback and General MIDI Synth installers from Preview 9. It removes them when it installs, so you don't have to, and they leave the Installed apps list too.
• Every app now installs into one folder, Program Files\Windows MIDI Services\Tools, instead of a folder each. The Start menu shortcuts are in the Windows MIDI (Preview) folder.
• Double-click a .midilayout file to open it in MIDI Glass, or a .midipatch file to a...

This release is for developers and technical customers with an interest to test, file bugs, and provide feedback. There are almost certainly bugs and missing/incomplete features. Do not install anything unless you have read these release notes and are comfortable with what is here.

Please refer to preview 8 for the full list of changes up until this release. https://github.com/microsoft/MIDI/releases/tag/inbox-dev-preview-8 . This set of release notes only covers the delta from Preview 8.

Plan is to have all of these transports and the API in Windows 11 25h2 and higher starting during the last week of November 2026. The cutoff for getting into that release is in September, so that is what we are working towards. Any issues found after the cutoff will be fixed in subsequent Windows updates.

Updated 2026-09-21. See notes at bottom

Permitted use

We want to ensure customers have the best experience going forward. Because of this, we want to ensure that these app-local binaries are not present on customer systems which have the binaries in System32. There is nothing in these binaries to enforce this, so it is entirely on you, the app or library developer, to ensure you do not distribute these files in situations where that happens.

"Binaries" here refers to the .dll, .pri and .pdb files included in the packages in this release, as well as any tool .exe files included. "Product" here refers to your application, library, service, or other code you are writing against these files.

Do not redistribute any of the installers or transports.

What to Test?

Technical Customers

If you are a technical end-user, I would love testing on your experience with Bluetooth MIDI 1.0 devices, with the Patchbay and other apps like the Troubleshooting app, and more. Provide your feedback on Discord https://aka.ms/mididiscord as a new thread in the midi user questions channel, or here as a bug. Whichever works best for you.

If installed before the November release, this doesn't replace any existing in-box delivered components (like KS/KSA transports), so you are welcome to try it out and test.

Developers

For developers, please provide API feedback and log any bugs you run across.

Both

As mentioned below, keep in mind that not all features, especially in the MIDI 2 loopbacks, will be available until after the November release.

API Changes

NuGet package version for this release is 0.99.79-devpreview.9.

Three groups of changes landed in the API this time, and they came from three different places. The first group is small, targeted, and came from a developer working on a real application with preview 8. The second and third are new feature areas that were developed alongside the new in-box tools that use them.

Partner Feedback Changes

These changes were driven by some last-minute important partner feedback on the current API, based on use in a real-world application. Everything here is in the enumeration and watcher area, which is the first thing any host application touches and the part that is hardest to get right from the outside.

Update events now tell you what actually changed

MidiEndpointDeviceInformationUpdatedEventArgs gained six new properties:

• IsEndpointDiscoveryStateUpdated
• IsMidi1PortMappingUpdated
• IsDevicePresenceUpdated
• AreLatencyPropertiesUpdated
• AreTransportSuppliedPropertiesUpdated
• AreSystemDevicePropertiesUpdated

Previously, a number of the properties the watcher asks for were not covered by any flag at all. An application could receive an Updated event with every flag reporting false and have no way to know what to re-read, other than re-reading everything. Every property the watcher requests is now covered by at least one flag.

There is deliberately no "something else changed" catch-all flag. A catch-all becomes a compatibility problem the first time a new specific flag is added, because existing code cannot tell whether the catch-all means "a thing you know about" or "a thing you do not". Instead, the watcher now logs an error when it computes an update with no flags set at all, so that a property added in the future without a matching flag group is caught by us rather than by you.

MidiEndpointDeviceInformation.IsEndpointDiscoveryComplete

New property reporting whether in-protocol endpoint discovery has finished for the endpoint. This is a hint, not a barrier. Transports which do no in-protocol discovery (for example Bluetooth LE MIDI, and the aggregated MIDI 1.0 devices) set it when the endpoint is created. It is also set after a discovery timeout, not only after a successful completion. Use it to decide when function blocks and declared names are worth reading, not as a gate on opening a connection.

MidiFunctionBlock.RepresentsMidi10Connection default corrected

A default-constructed MidiFunctionBlock reported Reserved for this property rather than Not10. Code which read the value from a function block it had built itself, rather than one supplied by a device, saw a reserved value.

MIDI 1.0 port mapping

Feedback here was that the MIDI 1.0 port mapping for an endpoint is sometimes incomplete at the moment the endpoint's Added event arrives. That is structural and is not going to change: the MIDI 1.0 ports for an endpoint are separate Windows device nodes, created by the service after the endpoint itself, and they raise their own device notifications with no ordering relationship to the endpoint's. An application which needs the ports must watch for the ports.

The correct tool is MidiLegacyPortDeviceWatcher, and both watch-endpoints samples and a new knowledge base article now say so explicitly. See Endpoint arrival and update ordering.

Still open from this round

Being upfront about the items from that feedback which are not fixed in preview 9:

• Update events can be raised on more than one thread, and UpdatedDevice() hands back the live endpoint object rather than a snapshot taken when the flags were computed. The reasoning is settled — a lock is not the fix, because raising the event inside the mutation lock reintroduces a re-entrancy deadlock that was fixed earlier in September — and the likely answer is to hand back a snapshot. That change is deferred rather than rushed in before the cutoff. In the meantime, treat the properties you read in an Updated handler as possibly newer than the flags.
• Function block names can be momentarily blank during discovery on devices which send function block info before function block names. This is a service-side change and lands after the current code freeze.
• The app-to-app (virtual device) sample can leave the service in a bad state on repeated runs. That is a known service defect with a fix already scheduled for the November release. #1047

MIDI CI

(developed in concert with the MIDI Keyboard app and the new in-box General MIDI Synth)

This is a new, substantial namespace: Windows.Devices.Midi2.CapabilityInquiry. It is UMP only, never bytestream, and it covers both halves of MIDI Capability Inquiry — asking a device what it can do, and answering when you are the device.

Resources

Strongly typed, with JSON in and JSON out, so an application never has to hand-parse a Property Exchange body:

• MidiProgramList, MidiProgramListEntry — with paging, because workstations have thousands of patches
• MidiChannelList, MidiChannelListEntry
• MidiResourceList, MidiResourceListEntry, MidiResourceLink
• MidiDeviceInfo

Messages

• MidiCapabilityInquiryMessage — decode a complete CI message from the UMP packets that carried it, including reassembly, with typed accessors for the discovery, property exchange, profile and acknowledgment sections
• MidiCapabilityInquiryMessageBuilder — build any CI message, including chunking a large property reply across multiple messages
• MidiCapabilityInquiryMessageType, MidiCapabilityInquiryCategories, MidiProfileId
• Windows.Devices.Midi2.Utilities.Messages.MidiSystemExclusive7MessageBuilder — the missing half of the SysEx7 story. We could read SysEx7 out of UMP already; now you can build it.

Initiator side

• MidiCapabilityInquirySession — runs on a connection you already have open. Discovery, MUID management, request/response with timeouts, plus events for unsolicited traffic (ResponderFound, MessageReceived, ProfileStateChanged)
• MidiCapabilityInquiryResponder — one per remote MUID found, with async property exchange and profile calls
• MidiPropertyExchangeResponse, MidiProfileInquiryResponse, MidiCapabilityInquiryMessageReceivedEventArgs, MidiCapabilityInquiryStatus

...

In-Box Developer and Advanced/Technical Customer Preview 8

This release is for developers and technical customers with an interest to test, file bugs, and provide feedback. There are almost certainly bugs and missing/incomplete features. Do not install anything unless you have read these release notes and are comfortable with what is here.

This release note is cumulative. Previews 1 through 7 each documented only what changed since the one before it, which made it hard to see the whole picture. Everything from those releases has been folded in here, so a developer picking this up for the first time can read one document and understand every change since the rc4 App SDK. Preview-by-preview history is at the bottom, under
Change history, Preview 1 through Preview 7.

Plan is to have all of these transports and the API in Windows 11 25h2 and higher starting during the last week of November 2026. The cutoff for getting into that release is in September, so that is what we are working towards. Any issues found after the cutoff will be fixed in subsequent Windows updates.

Important notes:

• You cannot edit the MIDI 2 loopbacks using the tools here. Required features are not present until the November CFR. For customers who need to use the MIDI 2 loopbacks, continue to use the older SDK and Tools release from https://aka.ms/midi
• Those same older tools will not work with the Basic Loopback, Network MIDI 2.0, or Bluetooth MIDI transports included in this release.
• All service-related changes will ship as Controlled Feature Rollout (CFR) starting at the end of November for 25h2 and up. It takes up to 45 days for features to be enabled on all PCs that are up to date with updates. Until those features are enabled, anything in this release which depends on feature enablement will not yet function at the levels covered here.
• Windows 11 24h2 will not receive the new API or any of the November features or fixes. 24h2 customers are advised to either update to 25h2 or turn on Legacy API Mode

Contents

• Permitted use
• What is new in Preview 8
  • Breaking API changes
  • New API surface
  • MidiClock fixes
  • MIDI 1.0 port naming rework
  • Message scheduler rework
  • Network MIDI 2.0
  • Bluetooth MIDI
  • Apps and tools
  • Samples
  • Documentation
• Corrections to earlier release notes
• Install instructions
• Change history, Preview 1 through Preview 7

Permitted use

We want to ensure customers have the best experience going forward. Because of this, we want to ensure that these app-local binaries are not present on customer systems which have the binaries in System32. There is nothing in these binaries to enforce this, so it is entirely on you, the app or library developer, to ensure you do not distribute these files in situations where that happens.

"Binaries" here refers to the .dll, .pri and .pdb files included in the packages below, as well as any tool .exe files included. "Product" here refers to your application, library, service, or other code you are writing against these files.

Do not redistribute any of the installers or transports.

What is new in Preview 8

Breaking API changes

There are very few here, and they are targeted. All of them require a recompile against the NuGet package in this release.

MidiEndpointConnection.AddMessageProcessingPlugin now returns a result.

// before
[noexcept] void AddMessageProcessingPlugin(IMidiEndpointMessageProcessingPlugin plugin);

// after
[noexcept] MidiMessageProcessingPluginAddResult AddMessageProcessingPlugin(IMidiEndpointMessageProcessingPlugin plugin);

There were several ways to add a plugin that would silently never be called, and no way for an app or a library to find out. The new Windows.Devices.Midi2.MidiMessageProcessingPluginAddResult enum reports which one happened:

This matters most to library authors. If your library adds a listener on a connection the app also uses, the app can now be told why the listener did nothing, instead of debugging silence.

MidiEndpointDeviceInformation.IsMidi1PortCreationEnabled has been removed. It was never populated by anything, so it was always true regardless of the endpoint. Removing it before production is better than shipping a property that cannot be trusted. Fixes
#1192.

Midi1PortNamingApproach gains UseAutomatic = 3. See MIDI 1.0 port naming rework below. This is an additive enum change, but it is also the new default behavior, so read that section before assuming port names are stable
from Preview 7.

COM Extensions: SetMessagesReceivedCallback now has a defined contract. It previously accepted calls it could not honor. It must be called before Open() on the connection, and only on a connection which has no message processing plugins attached. It now returns:

If you were relying on the previous silent behavior, you were relying on a bug.

New API surface

Network MIDI 2.0 typed configuration for entry updates and saved client decisions. Until now, changing settings on an existing host or client entry meant tearing it down and creating it again. These new types change an entry in place.

New methods on MidiNetworkTransportManager:

[noexcept] static Windows.Foundation.IAsyncOperation<MidiNetworkHostUpdateResponse> UpdateNetworkHostAsync(
    MidiNetworkHostUpdateConfig updateConfig);

[noexcept] static Windows.Foundation.IAsyncOperation<MidiNetworkClientUpdateResponse> UpdateNetworkClientAsync(
    MidiNetworkClientUpdateConfig updateConfig);

[noexcept] static Windows.Foundation.IAsyncOperation<MidiNetworkRemoteClientForgetResponse> ForgetRemoteClientAsync(
    MidiNetworkRemoteClientForgetConfig forgetConfig);

Note the split in how the two kinds of setting behave. Whether an endpoint has MIDI 1.0 ports at all is decided when the endpoint is created, so CreateMidi1Ports is recorded for the next connection rather than applied to one already up. FallbackMidi1PortCount applies to an endpoint which is already up.

MidiNetworkHostKnownClientsConfig is save-only. There is nothing to send: the service is told about a single decision through ApproveOrDenyRemoteClientConnectRequestAsync, and this type is the configuration file record of every decision made so far. Both saved lists are replaced by what it holds, so it must be the complete set for the host and not only what changed.

Withdrawing a decision takes both halves. Leaving a client out of `MidiNetworkH...

In-Box Developer and Advanced/Technical Customer Preview 7

2026-09-09 Updated BLE transport and app for better compat.
2026-09-07 Update to Just the NuGet package. See important developer notes at the bottom.

This release is for developers and technical customers with an interest to test, file bugs, and provide feedback. There are almost certainly bugs and missing/incomplete features. Do not install anything unless you have read this entire release notes and are comfortable with what is here.

We're quickly coming up on the deadline to get fixes and features into the November release. While we continue testing and debugging here, I wanted to get this out to you now for your own development and testing. Plan is to have all of these transports and the API in Windows 11 25h2 and higher starting during the last week of November 2026.

The cutoff for getting into that release is in September, so that's what we're working towards. Any issues found after the cutoff will be fixed in subsequent Windows updates.

This release is primarily about three things:

• Bluetooth MIDI
• The new MIDI Console app (ported to C++)
• The new touch-enabled MIDI Keyboard app

Permitted Use

We want to ensure customers have the best experience going forward. Because of this, we want to ensure that these app-local binaries are not present on customer systems which have the binaries in System32. There is nothing in these binaries to enforce this, so it is entirely on you, the app or library developer, to ensure you do not distribute these files in situations where that happens.

"Binaries" here refers to the .dll, .pri and .pdb files included in the packages below, as well as any tool .exe files included.
"Product" here refers to your application, library, service, or other code you are writing against these files

Do not redistribute any of the installers or transports.

Breaking API Changes

There are very few here, and they are targeted.

• MidiServiceTransportPluginConfigManager.EnsureConfigurationFile() added to support tools needing to save to the config file.
• MidiBasicLoopbackEntry now contains a message count (this change requires a recompile if you use basic loopback entries).
• Added MidiBluetoothTimestampSource enum and MidiBluetoothDeviceInformation.TimestampSource property for reporting back to the client apps.
• Endpoint Connection COM Extensions now have const correctness. This is a small breaking compile-time change for apps which compile against this again in the future. This should avoid needing to use const_cast

Transport and App Updates

• More BLE work in the app and transport to help ensure we handle more types of devices and BLE advertising
• BLE bug fixes around timestamps. Previously this was preventing WinMM from seeing data in some cases.
• BLE, Network, and Loopback apps updated so they will create a default configuration file if none exists
• The loopback setup app now has a button to import other third-party loopbacks and create basic loopbacks from them.

MIDI Console C++ Rewrite

The MIDI Console has been completely ported from C#/.NET to C++. As a result, it uses approximately 1/4 the memory, 1/4 the CPU, and is much better at keeping up with blasted streams of midi messages during monitoring. It also doesn't require a .NET Runtime install.

Fixed Console issues:

#1171 MIDI console lags behind incoming messages when monitoring, and is slower to startup than desired
#1023 Consider allowing some basic keyboard input during console monitor for common commands

New App: Virtual Keyboard

IMPORTANT NOTE: The current virtual device bug #1047 impacts this app if you use virtual device mode, and results in a service lock up. Do not use in virtual device mode. Instead, connect it to another MIDI port. For that reason, the virtual device functionality for this app has been temporarily disabled.

Removed Apps: midifixreg and midiapimode

These functions are now in the MIDI Troubleshooting and Repair app

Registry check and fixup:

API mode:

Removed App: midimdnsinfo

This is now midi network browse in the MIDI console app

There's also a --verbose switch for additional information

Network MIDI

No changes to Network MIDI as compared to last preview (Dev Preview 6).

If you used Network MIDI prior to the Dev Preview 6, you will want to fix up your config file as the older entries are not compatible. The Network Config repair in the assets downloads will do that for you.

Basic Loopback

Basic loopback now reports message count

Bluetooth MIDI

Connection / disconnection is more robust now. It also properly handles devices which do not correctly report BLE message timestamps (like the M-VAVE devices). The app also provides more information so you usually know when a device requires pairing or has failed to connection. This is functionally complete, but if you run into any compatibility issues with devices, do let me know. There are lots of edge cases with devices which implement the specifications in .. creative ways :)

• If you are using the KORG BLE MIDI 1.0 driver, fully and completely uninstall it before trying to use BLE MIDI 1.0 devices.
• If you are using a third-party Bluetooth Bridge-type app, or an app which provides Bluetooth MIDI functionality by directly connecting to the devices, do not use it while using the in-box Bluetooth components.

Current tested device list here: #1173

Install Instructions

As in the past, these previews are not signed and require you to turn on Developer Mode in Windows Settings > System > Advanced. They also require you to accept a few SmartScreen prompts and choose "keep" so the downloads are not automatically deleted. If you use third-party anti-virus / anti-malware software, it may also delete the installs after they happen. You'll need to refer to your own software's settings.

Minimum OS version: Windows 11 25h2.

1. Make sure you have read all of the information above. **Do not install anything without reading and understanding what is in this release. **
2. Before installing anything, completely uninstall all previous Loopback previews, network previews, bluetooth previews, and SDK Runtime and Tools packages. Uninstall the previous developer in-box previews as well as the older release candidates. Ensure that your Program Files\Windows MIDI Services directory is empty or missing, and delete the contents it if not.
3. Install the Basic Loopback, Network, and Bluetooth transport packages. The order is not important.
4. Install the Tools package. Again, the order is not important.

A common question is "Will I need to uninstall these bits before the November release?". In general, yes, but other than possibly with the PowerShell cmdlets, I don't anticipate issues if you do not. Just some confusion when you have multiple versions of the same app installed. Our in-box release is expected to go out the last week of November for 25h2 and higher.

Firewall

If you are using Network MIDI 2.0, you may need to let the MIDI Service through the firewall. Additionally, you will need to let the Network MIDI 2.0 Setup app through the firewall (it will prompt on first use).

https://microsoft.github.io/MIDI/kb/network-midi-firewall/

If you are using a third-party firewall product, please refer to their instructions. Both the app and the service need access.

Packages

Windows MIDI Services itself is already installed on your PC. These packages are add-ons which preview functionality coming to Windows

These are logically broken up so you do not need to install something you don't need.

• Network install: The Network Setup app and the Network MIDI 2.0 transport
• Bluetooth install: The Bluetooth MIDI 1.0 setup app and the Bluetooth MIDI transport
• Basic Loopback: The basic loopback transport. The app, which also supports MIDI 2.0 loopbacks, is in the tools install.
• Tools install: all the other console and GUI tools including the MIDI Console, MIDI Settings, MIDI Monitor, Troubleshooting, and also the PowerShell cmdlets for MIDI. Everyone will want this. Again, please ensure you uninstall any previous SDK runtimes/tools before installing.
• NuGet package: for developers to build against in preparation for the November release.
• Samples zips: fo...

In-Box Developer and Advanced/Technical Customer Preview 6

UPDATE 2026-09-03: New tools package. See below.
UPDATE 2026-09-02: Updated Network MIDI 2.0 and Bluetooth MIDI apps. Uninstall previous versions and install the new versions in the assets below.

This release is for developers and technical customers with an interest to test, file bugs, and provide feedback. There are almost certainly bugs and missing/incomplete features. Do not install anything unless you have read this entire release notes and are comfortable with what is here.

We're quickly coming up on the deadline to get fixes and features into the November release. While we continue testing and debugging here, I wanted to get this out to you now for your own development and testing. Plan is to have all of these transports and the API in Windows 11 25h2 and higher starting during the last week of November 2026.

Permitted Use

We want to ensure customers have the best experience going forward. Because of this, we want to ensure that these app-local binaries are not present on customer systems which have the binaries in System32. There is nothing in these binaries to enforce this, so it is entirely on you, the app or library developer, to ensure you do not distribute these files in situations where that happens.

"Binaries" here refers to the .dll, .pri and .pdb files included in the packages below, as well as any tool .exe files included.
"Product" here refers to your application, library, service, or other code you are writing against these files

Do not redistribute any of the installers or transports.

Breaking API Changes

Fixed a few broken UUIDs

MidiLegacyPortDeviceInformation had an auto-generated static interface id
IMidiServiceConfigResponse had an incorrect interface id

Network MIDI 2.0

As with the previous release, delete all Network MIDI 2.0 entries from your midiconfig json file, or simply delete the configuration file and re-create it. There are a few breaking changes in there now.

Update 2026-08-31: There's a PowerShell script in the assets that can do this work for you now, repairing or removing the entries.

mDNS Watcher

The mDNS / DNS-SD device watcher needed rebuilding from the ground up using base Win32 APIs. As a result, it is no longer backed by a WinRT Device Watcher, but still retains the same shape. Threading may be slightly different.

Why? The DNS-SD implementation in the base WinRT Device Watcher does not actually fire Updated or Removed events. It also returns null for the TTL property, and has no other presence indicator. To the best of my knowledge, this limitation is not documented.

Included Transports

This includes three transports which, assuming they meet the quality gates, will ship in the November release. This also includes the WinRT API expected to ship at the same time.

The main application is the new MIDI Settings app. However, it looks completely different from the one you are used to. This is a new C++ app that starts faster and includes fewer features directly in the app. Here are all the GUI apps included

Important Bluetooth Consideration

The Bluetooth MIDI 1.0 transport is new. Please be sure to report any bugs. Do note that if you have paired a BLE MIDI device, it will likely be picked up by our old BLE MIDI 1.0 support in WinRT MIDI 1.0, resulting in the device not coming up on the new transport. You can usually get around this by unpairing the device, or if that is not possible, by deleting the paired BLE device from the Sound, video and game controllers section of Device Manager. Once this transport is in production on Windows, this will not be an issue.

If you are using the KORG BLE MIDI 1.0 driver, fully and completely uninstall it before trying to use BLE MIDI 1.0 devices.

Devices successfully tested so far: See #1173

Network MIDI 2.0 Note

The Network MIDI 2.0 implementation is feature complete for our first in-box release. Note that it does not yet support any sort of authentication, and will not in our first in-box release.

MIDI 2.0 Loopback Note

The currently in-box Loopback transport does not support all the features used by the app (muting, listing, etc.). For that reason, you will not be able to properly configure MIDI 2.0 loopbacks with these tools until those features ship in Windows. Existing MIDI 2.0 loopbacks in your config file will continue to work as before.

MIDI 1.0 Loopback Note

Please be sure to follow the instructions below to ensure you using the MIDI 1.0 Basic Loopbacks from this release so all features are enabled.

Included Apps

The existing MIDI Settings app has been broken apart, rewritten in C++, and made easier to use. There are dedicated apps for specific setup steps for individual transports, and the main MIDI Settings app focuses on the management of endpoints and global settings. Most debugging and troubleshooting steps have been moved to the troubleshooting app. The apps no longer rely on the console tools.

Most extra endpoint detail has been moved out of the MIDI Settings app, but retained in the technical-focused MIDI Console. That is a deliberate choice to simplify the user experience.

All of the apps have settings for background color and style, and can be customized to your preferences.

There's continued fit & finish work going on in these apps, so please only report functional / stability bugs.

MIDI Settings

This is the primary app for MIDI. From here, you can access all of the other apps. It is deliberately simplified from the previous version.

IMPORTANT NOTE: Individual MIDI 1.0 port renaming is not in this app currently. It will be in the production release. Otherwise, this app has all the intended features.

MIDI Settings App Overview

MIDI Loopback Setup

Use this app for setting up MIDI 1.0 and MIDI 2.0 Loopbacks

MIDI Loopback Setup Overview

MIDI Network Setup

Use this app to set up Network MIDI 2.0

MIDI Network Setup Overview

MIDI Bluetooth Setup

Use this app to set up Bluetooth LE MIDI 1.0. Unlike the old BLE MIDI 1.0 support, most devices do not need to be paired to function. Additionally, other BLE MIDI 1.0 devices which simply didn't work with Windows (like some ROLI products) now work.

MIDI Bluetooth Setup Overview

MIDI Monitor

MIDI Monitor shows you the MIDI messages arriving from a keyboard, controller, synth, or any other MIDI device on your PC. It’s the tool to reach for when you want to answer questions like “is this knob actually sending anything?”, “which channel is my keyboard on?”, or “what exactly does my synth send when I press that button?”.

MIDI Monitor Overview

MIDI SysEx Utility

The MIDI SysEx Utility sends System Exclusive files to an instrument and captures System Exclusive data coming back from one. Although not intended to be a fully-featured librarian, it covers most of what people mean by “patch librarian” jobs: loading a bank of sounds you downloaded, backing up the sounds you’ve made, applying a firmware update, or capturing a dump to send to a manufacturer’s support desk.

MIDI SysEx Utility Overview

MIDI Scratch Pad

MIDI Scratch Pad lets you type MIDI messages yourself and send them to a MIDI device. It’s the tool to reach for when you want to answer questions like “does this synth actually respond to that controller?”, “what does this SysEx message from the manual do?...

In-Box Dev Preview 5

This version of the WinRT API has the same limitations on use as all previous releases. This is not for end-user use, nor is it to be deployed with an app, outside of limited testing, for any sort of production use. Doing so will compromise the user experience once these go in-box.

The in-boxing date is currently targeted for the last week of November (11D).

The apps included with this release all ship with a local duplicated copy of the WinRT API. Although this works, it is not permissible for your own apps unless you have explicit permission from Microsoft via email. Shipping this runtime now, without cleaning it up after the November release for every single customer may result in problems for your apps that are challenging for you to diagnose and result in a poor experience for customers.

That is also why this release is not for end-user customers who rely on their PC for making music, but is intended only for developers (and their testers) and highly technical users who know to uninstall this before the November in-box release.

Breaking Changes

• IMPORTANT. If you have ever used Network MIDI 2 previews before, you will need to manually remove your host entry from the config file. The new format requires a GUID for the host id / entry identifier, not a random string and any host where the id is not a valid GUID will fail. The current MIDI Settings app is not compatible with this Network MIDI 2.0 implementation for that reason. You must use the new app to handle Network MIDI 2.0

In addition, the connectionPolicyIpv4 key is no longer used. It will be ignored if specified.

If you prefer, you can just delete your current config file and then regenerate it using the MIDI Settings app. It's stored in %allusersprofile%\Microsoft\MIDI

Symptoms:

• The new Network MIDI Setup application doesn't open

• Your Network MIDI host isn't advertised on the network

• The MidiEndpointDeviceWatcher now passes the entire MidiEndpointDeviceInformation object in all events, just like the Legacy Device Watcher does. This was a needed breaking change because without it, there was no way to get the other information, like TransportId (thanks for finding this hole, Thomas!) because the object was already removed from the watcher's collection. Plus, this brings the two watchers in-line so they work the same way. So for each of those event args, the Id was replaced by the full object

Example:

Before:

runtimeclass MidiEndpointDeviceInformationUpdatedEventArgs
{
    [noexcept] String EndpointDeviceId {get; };
        
    [noexcept] Windows.Devices.Enumeration.DeviceInformationUpdate DeviceInformationUpdate{ get; };

    [noexcept] Boolean IsNameUpdated{ get; };
    ...

}

After:

runtimeclass MidiEndpointDeviceInformationUpdatedEventArgs
{
    [noexcept] MidiEndpointDeviceInformation RemovedDevice{ get; };

    [noexcept] Windows.Devices.Enumeration.DeviceInformationUpdate DeviceInformationUpdate{ get; };

    [noexcept] Boolean IsNameUpdated{ get; };
    ...

}

• MidiEndpointDeviceInformation and MidiLegacyPortDeviceInformation CreateFromId methods now actually validate that the correct type of Id was passed in. If you interchange them, you will get a nullptr back when you try to create the device information object. Previously, due to all the exception handling, you would receive a seemingly valid object but only filled with the properties that are in common with both.
• MidiServiceSessionConnectionInfo changed EndpointDeviceId to EndpointOrPortDeviceId because it can contain either.
• MidiReporting functions added for getting active sessions that include specific port or endpoint ids.
• MidiReporting function return types changed from IVector to IVectorView to be consistent with other read-only collections returned by other functions
• MidiEndpointDeviceIdHelper changed to MidiEndpointDeviceHelper and now includes additional validation functions for ump endpoint name, product instance id, etc.
• Basic Loopback Association Id and Loopback Association Id are now read-only on the creation config. It gets generated inside the class. This is consistent with the new network
• By default, loopback and basic loopback generate their unique identifer from the Association Id if empty
• MidiLoopbackEndpointDefinition constructors have changed due to the above. NOTE THE CHANGE IN PARAMETER ORDER.
• Same change in constructors made to MidiBasicLoopbackEndpointDefinition to keep them parallel

Other Changes

• Added IsMutedStateChanged to the MidiEndpointDeviceInformationUpdatedEventArgs type
• Added QueryAllCapabilities to the MidiServiceTransportPluginConfigManager type
• Added FindAllSessionsWithOpenEndpoint to MidiReporting so you can quickly find sessions with a UMP endpoint, or one of its associated MIDI 1.0 ports, open
• Endpoint name and Function Block name utf-8 length validation and utf-8-aware truncation in Virtual Device, Loopback, Basic Loopback, and Network MIDI API/SDK functions. In general, just better utf-8-aware string handling everywhere that pops up in the MIDI 2.0 protocol.
• The Virtual Device now has a new event and a new property so you know if there are any client apps connected to the device.

What's New

Bug fixes and test coverage

There are a number of bugs fixed as part of this work. You won't see those in the service until it releases in Windows at the end of November. However, the tests cases are all in the repo, and similar bug fixes, when appropriate, were applied to the WinRT API. Until the service components are available, you may still see some discrepancies, especially with utf-8 handling.

Significantly updated Network MIDI 2.0

Aside from there being no support for Network MIDI 2.0 Authentication modes yet (a post-1.0 release update), this is a code-complete version of Network MIDI 2.0. It passes all the protocol spec tests.

Note: there were a number of other race conditions, deadlocks, and related in the service which were discovered when completing the Network MIDI 2.0 and testing under load. Those all resulted in various types of service hangs or lockups which required killing the midisrv process to recover from. For that reason, I do not recommend this plugin be used by the general public. Like the other components here, this is a developer release for people developing products, apps, libraries, etc. There's no end-user support for this plugin.

The current MIDI Settings app is not fully compatible with the Network MIDI 2.0 implementation. Specifically, it creates entries with non-GUID identifiers.

Apps

I'm in the process of breaking the MIDI Settings up app into multiple separate apps, so that when we create an in-box Settings UI for MIDI, it can still call out to useful apps without them having to be built into the Windows Settings app. Third-party apps can also launch these apps if that is convenient to the user.

Each GUI app has the same UI customization options (Dark/Light theme, Acrylic/Mica/Solid backdrop, and an optional background color)

The equivalent functionality has been removed from the monolithic MIDI Settings app.

These are preview apps. Final names and icons TBD.

Windows MIDI Monitor

Until now, the only MIDI Monitor available with Windows MIDI Services was the console monitor. We now have a GUI monitor with a few additional features including saving the data to a file, selecting all the SysEx etc.

Full documentation and screenshots here

Windows MIDI Scratchpad

An earlier version of this was built into the last MIDI Settings release. This now provides support for both MIDI 1.0 byte format and UMP format messages.

Full documentation and screenshots here

Windows SysEx Utility

Send and receive SysEx. This is similar to the tool I have in the Store that uses the old WinRT MIDI 1.0 API, but this handles both sending and receiving, and can save your incoming files to a SysEx Library folder.

Full documentation and screenshots here

Windows Network MIDI Setup

Do not use the MIDI Settings app for Network MIDI 2.0. This new stand-alone app is compatible with the version of Network MIDI 2.0 that will be in Windows in November, and is available in preview with this release.

When you have a pending invite which needs a decision, it will show at the top of the page with the appropriate options.

Full documentation and screenshots here

Windows MIDI Loopback Setup

Like Network MIDI, loopback setup is now its own app. The app handles both styles of loopbacks if you have the transports installed and active.

Do not use the older MIDI Settings app for loopback device management. This new stand-alone app is compatible with the version of the Basic Loopback that ...

Usage

Previous Preview 1 and Preview 2 information, notes, and usage all apply to this preview. This is not for end-users, or for production use. There is no "go live" license for this preview.

In-Box Dev Preview 1 (with most release notes)
In-Box Dev Preview 2 (a few additions)

Known Issues

Discovered after release:

• #1070 (Basic Loopback not working correctly from WinMM) (Update: now fixed, with new transport installers attached)

Changes

Updated Basic Loopback Transport

This transport works with this release of the API. The old version of this basic loopback does not work with this version of the release. This version of the basic loopback does not work with the rc4 SDK, rc4 MIDI settings app, rc4 MIDI Console, etc. Do not attempt to use it with apps compiled against the older SDKs, including the MIDI Settings and MIDI Console apps.

This is for developers using the Developer Preview 3 SDK only. This is not for general customers.

You will need to turn on (and leave on) Developer Mode in Windows to use this unsigned preview package with your MIDI Service.

Support chunked SysEx in MidiMessageConverter

Updated MidiMessageConverter to be able to handle chunked SysEx messages in any one call, which requires retaining state across calls.

In addition to this existing method:

[noexcept] static IVector<UInt32> ConvertMidi1CompleteMessageBytesToUmpWords(
    Windows.Devices.Midi2.MidiGroup group,
    IIterable<UInt8> midi1Bytes,
    Boolean allowRunningStatus
);

Added the following method overload:

[noexcept] static IVector<UInt32> ConvertMidi1CompleteMessageBytesToUmpWords(
    Windows.Devices.Midi2.MidiGroup group,
    IIterable<UInt8> midi1Bytes,
    Boolean allowRunningStatus,
    Windows.Devices.Midi2.Utilities.Messages.MidiBytestreamToUmpMessageConverterState converterState
);

and this new type for retaining state:

namespace Windows.Devices.Midi2.Utilities.Messages
{
    [contract(MidiMessageUtilityApiContract, 1)]

    [interface_name("Windows.Devices.Midi2.Utilities.Messages.IMidiBytestreamToUmpMessageConverterState", UUID_IMidiBytestreamToUmpMessageConverterState)]
    [constructor_name("Windows.Devices.Midi2.Utilities.Messages.IMidiBytestreamToUmpMessageConverterStateFactory", UUID_IMidiBytestreamToUmpMessageConverterStateFactory)]
    runtimeclass MidiBytestreamToUmpMessageConverterState
    {
        MidiBytestreamToUmpMessageConverterState();

        String Tag{ get; set; };
    }
}

The behavior is this:

• If no state object is passed in, the static conversion function will dump SysEx state once it reaches the end of data in any one call. Additionally, there's no way to continue SysEx in a subsequent call without adding an opening 0xF0.
• If a state object is passed in, you can keep message state across calls. SysEx will be continued. SysEx state will not be dumped until an 0xF7 is received. If no 0xF7 is received at the end, there may be unconverted bytes left in the state.
• If you need to convert malformed SysEx (no opening/closing 0xF0/0xF7 pairs), you will need to instead handle that manually. These functions have to assume some basic level of data integrity.

Here are the two tests which show the behavior

// This verifies that Sysex state is dumped when the end of the input data is reached
void MidiMessageConverterTests::TestIncompleteSysEx7Conversion()
{
    std::vector<uint8_t> bytes = { 0xF0, 0x7E, 0x7F, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 };

    // assumes group index 5 in the output
    MidiGroup group(5);
    std::vector<uint32_t> expectedResults = { 0x35167E7F, 0x00010203, 0x35230405, 0x06000000 };

    // sysex state will be dumped when the input data runs out
    auto actualResults = MidiMessageConverter::ConvertMidi1CompleteMessageBytesToUmpWords(group, bytes, false);

    VERIFY_IS_NOT_NULL(actualResults);
    VERIFY_ARE_EQUAL(expectedResults.size(), actualResults.Size());

    for (uint32_t i = 0; i < expectedResults.size(); i++)
    {
        VERIFY_ARE_EQUAL(expectedResults[i], actualResults.GetAt(i));
    }
}

// This verifies that Sysex state works properly across calls
void MidiMessageConverterTests::TestStatefulSysEx7Conversion()
{
    // this is what is used to retain state across calls. You'll want to have
    // one of these per endpoint/group that you're converting data for. When
    // it goes out of scope, the state is lost. You can also allocate this using
    // winrt::make and then explicitly destroy the object, like you would with
    // any other WinRT type
    MidiBytestreamToUmpMessageConverterState state;

    std::vector<uint8_t> bytes1 = { 0xF0, 0x7E, 0x7F, 0x00 };
    std::vector<uint8_t> bytes2 = { 0x01, 0x02 };
    std::vector<uint8_t> bytes3 = { 0x03, 0x04, 0x05, 0x06, 0xF7 };

    // assumes group index 5 in the output
    MidiGroup group(5);
    std::vector<uint32_t> expectedResults = { 0x35167E7F, 0x00010203, 0x35330405, 0x06000000 };

    // three separate calls, each with parts of the sysex payload
    auto actualResults1 = MidiMessageConverter::ConvertMidi1CompleteMessageBytesToUmpWords(group, bytes1, false, state);
    auto actualResults2 = MidiMessageConverter::ConvertMidi1CompleteMessageBytesToUmpWords(group, bytes2, false, state);
    auto actualResults3 = MidiMessageConverter::ConvertMidi1CompleteMessageBytesToUmpWords(group, bytes3, false, state);

    // combine the actual results received, reassembling the full package
    // of converted data, so we can compare against the expected
    // resulting message words
    std::vector<uint32_t> actualResults{};
    actualResults.insert(actualResults.end(), actualResults1.begin(), actualResults1.end());
    actualResults.insert(actualResults.end(), actualResults2.begin(), actualResults2.end());
    actualResults.insert(actualResults.end(), actualResults3.begin(), actualResults3.end());

    // ensure we received the correct number of words
    VERIFY_ARE_EQUAL(expectedResults.size(), actualResults.size());

    // compare the actual content of the words
    for (uint32_t i = 0; i < expectedResults.size(); i++)
    {
        VERIFY_ARE_EQUAL(expectedResults[i], actualResults[i]);
    }
}

UUID Change

Corrected UUID for UUID_IMidiSystemExclusive7MessageHelperStatics

Be sure to compile against the NuGet package below so you have the correct ABI.

Docs

Cleaned up a number of docs in the KB section, including removing several which are no longer needed. Also added a new developer doc on moving from WinMM to Windows MIDI Services

• Moving from WinMM to Windows MIDI Services
• Full set of articles

Please refer to https://github.com/microsoft/MIDI/releases/tag/inbox-dev-preview-1 for usage information, and the larger changes introduced with the in-box version.

This release is a minor update which builds upon that information and has the same restrictions. There are no new distribution rights conveyed with this preview release.

Changes

Legacy API Port Enumeration

• Fixed MIDI 1 Port off-by-one problem, issue #1046
• Added MidiLegacyPortDeviceWatcher::GetEnumeratedPortsForAssociatedEndpointAndGroup to be compatible with the rc4 SDK features
• Added Arm64X binaries to Arm64EC binaries section in NuGet package
• Tons of copilot-assisted hardening of input parameters and exception handling

Docs

There's still documentation work to do, but the SDK reference documentation has been significantly updated to reflect these changes.

https://microsoft.github.io/MIDI/sdk-reference/

In-Development SDK Types

As before, the in-development SDK bits like Network MIDI 2 are not included in this release.

2026-10-01 old release artifacts removed to avoid customer / developer confusion

Quality

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.

2026-10-01 old release artifacts removed to avoid customer / developer confusion

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