This release is for DEVELOPERS ONLY. This is not a non-developer customer release. If you are not a developer, do not download or install anything from this release. There is no support for non-developer customers using these packages.

Update 2026-07-14: Fixed and re-uploaded C++/WinRT Samples zip file

Update 2026-07-19: Latest release is here: https://github.com/microsoft/MIDI/releases/tag/inbox-dev-preview-2

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

Use	Notes
Development	Your developers may use the binaries here for development and testing of future releases of a product
Testing	Your testing team(s) may use these binaries with your product
Customer Preview	You may distribute these with an alpha/beta/preview version of your app as long as that app has an enforced (through code or obvious and explicit agreement) expiration date of no later than December 1, 2026, and you clearly indicate that this is using pre-release code which may not work in production. You are responsible for all support
Production / Release app	These binaries are not permitted for this use. Do not distribute these binaries with a production application.

This release changes the structure and activation of the WinRT API in order to support bringing it into Windows as a normal WinRT API in the next couple months.

Why is this being released?

As previously discussed on the MIDI Discord server https://aka.ms/mididiscord , we've decided to put the WinRT API/SDK into Windows, to simplify everything about using it.

There are a number of breaking changes going from the preview/rc SDKs to this version, as described below. To get a start on changes required for the in-box version, you will need these new metadata and binaries for development and testing.

Additionally, the Windows SDK may lag some time behind the implementation binaries going into Windows, so you may need the metadata in the NuGet package to develop against the in-box implementation libraries even after our in-box release.

This has the correct ABI to match what will be released in-box in Windows, and enables developers to build against this metadata and test against this implementation.

Special Instructions

During development, you will need to have the implementation DLLs side-by-side with the process executable that uses the MIDI API. If you do not, you'll get the REGDB_E_CLASSNOTREG exception / hresult when trying to activate a type.

In addition, the .pri files associated with them must be in that same folder

Once the binaries are in-box, you will no longer want to have these side-by-side with the app. There are dependencies between some of the .DLL files, so I recommend you just copy them all over rather than trying to sort out which needs which. When in-box, they will all always be available together.

The .props and .targets files in the NuGet package will normally take care of copying the files for you. If you are not using NuGet directly, you will need to add this to your build steps.

C++ Specifics

I've used C++/WinRT 3.0.x when creating the binaries. Although not necessary, you may prefer to do the same, as 3.0 introduces module support. C++/WinRT 2.x will still work.

The COM Extensions header and c file for sending/receiving raw message data are included in the NuGet package. Distribution mechanism for these once we're in-box is still TBD.

Service Specifics

If you use the Basic Loopback part of the API, this requires the latest Basic Loopback transport, which is not yet available. Without that, you will not receive back useful error codes from the service.

C# Specifics

There's no projection for .NET distributed with the binaries here. You must use CSWinRT 2.2.x to generate the projections from the .winmd. I did not have any luck using CSWinRT 3.0 preview.

There is also no projection of the raw message COM extensions. Distribution method for this is still TBD but may end up being a NuGet package in the future, even when in production.

Delphi and Other Manual projections

The clsids/uuids have changed for the types to help everything live side-by-side, and to normalize those ids.

Once we're in-box, most companies and projects which produce projections for our official SDKs will kick in and produce their projections as normal. Until then, if you need the clsids for COM activation, or you are otherwise manually building the projections, please refer to midi\src\api\Client\WinRT\shared\midi_sdk_idl_defs.h file

Instructions

You do not need to uninstall the rc4 SDK and Tools. This can exist side-by-side with that install, and you may want access to the tools included in that release.

There is no CMAKE/vcpkg package for this release. The NuGet Package has everything you need to build against. Remember, the winmd files will be in Windows itself, so having a separate cmake package for that will not help you once this is part of the Windows SDK.

If you just need the files from within the NuGet package, simply change the file extension to .zip and pull out the files.

As with the preview NuGet, you will need to download the .nupkg to a known location on your PC, and set that up as a NuGet package repository. Then you will add a NuGet package reference to your project.

Again, because this is a preview and not registered in-box, you must have the implementation .dll and .pri files in the same folder as your running executable. That includes during development time in your IDE or build system.

At development time, C++/WinRT cppwinrt.exe needs to be able to find the .winmd file from the NuGet package. When it is run against that metadata, it will generate the required headers. If you use the NuGet package in Visual Studio, the props and targets files take care of this for you.

Updates and Changes

Namespaces

Area	Old Namespace	New Namespace
All	`Microsoft::Windows::Devices::Midi2::*`	`Windows::Devices::Midi2::*`
Client Plugins	`Microsoft::...::Midi2::ClientPlugins`	`Windows::Devices::Midi2::ClientPlugins`
Diagnostics	`Microsoft::...::Midi2::Diagnostics`	`Windows::Devices::Midi2::Diagnostics`
Enumeration	`Microsoft::...::Midi2`	`Windows::Devices::Midi2::Enumeration`
MIDI 1 Enumeration	`Microsoft::...::Midi2`	`Windows::Devices::Midi2::Enumeration::Legacy` *
Reporting	`Microsoft::...::Midi2::Endpoints::Reporting`	`Windows::Devices::Midi2::Reporting`
Service Config	`Microsoft::...::Midi2::ServiceConfig`	`Windows::Devices::Midi2::ServiceConfig`
Basic Loopback	`Microsoft::...::Midi2::Endpoints::BasicLoopback`	`Windows::Devices::Midi2::Transports::BasicLoopback`
Loopback	`Microsoft::...::Midi2::Endpoints::Loopback`	`Windows::Devices::Midi2::Transports::Loopback`
Virtual Device	`Microsoft::...::Midi2::Endpoints::Virtual`	`Windows::Devices::Midi2::Transports::Virtual`
Message Utilities	`Microsoft::...::Midi2::Messages`	`Windows::Devices::Midi2::Utilities::Messages`

Note the change from Endpoints to Transports in the namespaces.
The SysEx sender, clock generator, and the MUID type, are not currently in the release. If you have a dependency on these, please let me know. Same with preview transports including Network MIDI 2.0, BLE MIDI 1.0/2.0, and the patch bay.

* The "Legacy" name here refers to the older MIDI 1 APIs, not to MIDI 1 itself. MIDI 1.0 is a first-class citizen of the new API, which we would prefer developers use vs WinMM, WinRT MIDI 1.0 and the deprecated DirectMusic API. The new API fully supports both MIDI 1.0 and MIDI 2.0, supports incoming and outgoing timestamps, and is fully multi-client for all connections.

Connection

The IMidiEndpointConnectionSettings interface has been removed. MidiEndpointConnectionBasicSettings has been renamed to MidiEndpointConnectionSettings. The json field and customization was not used. Thanks to Thomas for helping to find that on Discord.

There's also a C++ sample now for using the COM Extensions for send/receive.

rc4 SDK	Changes
`MidiEndpointConnectionBasicSettings`	`MidiEndpointConnectionSettings`
`IMidiEndpointConnectionSettings` separate interface	removed

Basic Loopback

In addition to adding error codes and changing structs to runtime classes, some of the type names have changed names in the Basic Loopback transport SDK, and there have been other structural changes. Please refer to the loopback-basic-endpoints-cpp sample.

Primarily removed "Endpoint" and promoted "Loopback" to be a noun vs an adjective. Added response types for all calls. Existing response types renamed and made runtimeclass types vs structs.

rc4 SDK	Changes
`MidiBasicLoopbackEndpointManager`	`MidiBasicLoopbackManager`
`MidiBasicLoopback*Result`	`MidiBasicLoopback*Response` for example `MidiBasicLoopbackCreationResponse`
`MidiBasicLoopback*Result`	`MidiBasicLoopback*Response` for example `MidiBasicLoopbackCreationResponse`
`MidiBasicLoopbackEndpoint*Config`	`MidiBasicLoopback*Config` for example `MidiBasicLoopbackCreationConfig`

Loopback

In addition to adding error codes and changing structs to runtime classes, some of the type names have changed names in the Loopback transport SDK, and there have been other structural changes. Please refer to the loopback-endpoints-cpp sample.

Note that error codes from the service are not yet available. This requires a change to the loopback transport which will happen in the future via CFR.

Primarily removed "Endpoint" and promoted "Loopback" to be a noun vs an adjective. Added response types for all calls. Existing response types renamed and made runtimeclass types vs structs.

rc4 SDK	Changes
`MidiLoopbackEndpointManager`	`MidiLoopbackManager`
`MidiLoopback*Result`	`MidiLoopback*Response` for example `MidiLoopbackCreationResponse`
`MidiLoopbackEndpoint*Config`	`MidiLoopback*Config` for example `MidiLoopbackCreationConfig`

Initialization

There is no more COM initializer because no special logic is required to load the SDK runtime. Similarly, there's no SDK Update functionality, or versioning. Everything instead follows normal in-box WinRT SDK rules.

The EnsureServiceAvailable() function has been moved to be a static member of the Windows::Devices::Midi2::MidiApi type.

MidiApi::EnsureServiceAvailable()

There is no SDK initialization or shutdown code required. However, if you use a COM interface (IBufferByteAccess, the raw connection interface, etc.) you must release those references before calling winrt::uninit_apartment()

API detection

Use standard WinRT API detection approaches, such as handling the hresult REGDB_E_CLASSNOTREG exception.

// air code
#include <winrt/Windows.Devices.Midi2.h>
using namespace Windows::Devices::Midi2;

bool IsWindowsMidiServicesApiAvailable() 
{
    try 
    {
        return MidiApi::EnsureServiceAvailable();
    } 
    catch (winrt::hresult_exception) 
    {
        return false;
    }
}

This next bit of code may work, but I cannot test it until we're in-box (I am GitHub-first on the development here, so don't have a separate branch of Windows set up just for testing this).

if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Devices.Midi2.MidiApi")) {
    // Safe to use the API
}

Enumeration

Most of the APIs received only minor updates (like adding error codes to return structures when creating loopback endpoints, or changing structures to runtimeclass types). However, the enumeration API includes a larger number of changes primarily to better integrate with existing legacy MIDI 1.0 APIs like WinMM.

First, all Enumeration types were put in the Enumeration namespace, or a child of that namespace instead of the root Midi2 namespace.

Windows.Devices.Midi2.Enumeration is where you will find the MidiEndpointDeviceInformation, Watchers, and other types, including MIDI 2.0 metadata

Windows.Devices.Midi2.Enumeration.Legacy includes equivalent types for working with legacy MIDI 1.0 API ports. It also includes functions to help find the MIDI 1.0 ports for a given endpoint, and more. This is primarily for facilitating the transition from the older APIs to the new.

The functions to enumerate MIDI 1 ports were removed from the MidiEndpointDeviceInformation types. Instead, I recommend using the MIDI 1 device watcher, because MIDI 1 ports are created asynchronously after the creation of the main endpoint, which itself is after the parent device comes online. Additionally, the MIDI 1 device watcher is better at caching and synchronizing the data centrally, resulting in less memory usage and more efficient lookups.

These enumeration changes will make it easier for your apps and libraries to identify and keep track of both MIDI 1.0 ports and MIDI 2.0 endpoints. In addition, even existing WinMM apps which don't otherwise use the functionality in this API can use the functions in the Legacy namespace to get more information about ports, watch for port add/remove, etc.

The MidiDeclaredDeviceIdentity type has arrays instead of discrete properties for SysExId and SoftwareRevisionLevel. Any fields with more than just MSB/LSB were broken out this way. Remember, these are WinRT properties, which means you still need to use function syntax. Example: declaredDeviceIdentity.SystemExclusiveId()[0]

Additionally, because of the change from struct to runtimeclass types, the GetXYZ() methods on the MidiEndpointDeviceInformation type can return nullptr if the information is not provided. This is more useful than returning an initialized type with placeholder values, but does need to be handled in your code.

rc4 SDK	Changes
`MidiEndpointDeviceInformation` `FindAllAssociatedMidi1PortsForThisEndpoint`	Use new methods in the `MidiLegacyPortDeviceWatcher`. It caches values, keeps up to date with add/remove once started, and provides fast lookup.
All other functions which integrate MIDI 1.0 API mapping and port discovery	`MidiLegacyPortDeviceInformation` / `MidiLegacyPortDeviceWatcher`

ServiceConfig

Most of these functions were only used internally in transport-specific namespaces.

rc4 SDK	Changes
`MidiServiceConfig`	`MidiServiceTransportPluginConfig` . When we add in transform customization, we'll add a new parallel class.

Utilities

A number of utilities were removed from the in-box API either because they were not yet complete, or they are no longer needed. Useful features may be added in, or made available as a companion download.

rc4 SDK	Changes
`MidiUniversalSystemExclusiveMessageBuilder`	Removed as all functions were no-ops in rc4. Will re-evaluate in the future
`MidiClockGenerator`	Removed for this release. Will re-evaluate in the future
`MidiClockDestination`	Removed for this release. Will re-evaluate in the future
`MidiRuntimeRelease`	Removed because no more need for versioning info.
`MidiRuntimeUpdateUtility`	Removed because no more need for versioning info.
`Microsoft.Windows.Devices.Midi2.Utilities.RuntimeInformation *`	Removed because no more need for versioning or download info

Samples

Status of samples for this release

Language	Notes
C++/WinRT	Samples are up to date
C++/WinRT cmake	Samples have not yet been updated
C++	Removed as the COM SDK initializer has gone away
C#	The basics and app-to-app MIDI samples have been updated
electron-js	Not updated
powershell	Not updated
rust-winrt	Not updated. When the SDK is official, we'll get Rust projections out of that

Fixes / Updates

Fixed potential deadlock caused by using certain MIDI Enumeration APIs within a coroutine (or an event handler) in an STA thread like the WinUI UI thread.
Lots more exception handling in the APIs

Troubleshooting / Likely FAQ for this release

I get REGDB_E_CLASSNOTREG when creating types

Ensure the .dll and .pri files are co-located with the executable for the process which uses these APIs. They must be side-by-side in the same folder.

Error C3867 in VS / MSBUILD

If you get something along these lines:

'winrt::impl::consume_Windows_Devices_Midi2_IFooBarBaz<winrt::Windows::Devices::Midi2::IFooBarBaz>::SomeField: non-standard syntax; use '&' to create a pointer to member

It likely means you have existing code that referenced a field in a struct, and that struct is now a runtimeclass, so the fields became properties, requiring you to use function syntax. In this case, you have SomeField and you need SomeField().

Error E0300 in VS / MSBuild

a pointer to a bound function may only be used to call the function. You'll get thse for the same reason as C3867, but when assigning instead of reading a value. Change SomeField = somevalue to SomeField(somevalue)

Errors about missing packages

Make sure you've added a NuGet reference to this release.
Unload and look at your project file.
For C++ MSBUILD/VS projects, you'll see package references at the top in Import Project=" items. Ensure the old MIDI SDK is no longer included there.
Then scroll down to the bottom in the ImportGroup Label="ExtensionTargets", and remove it from there if present.
Finally, scroll down to the Target Name="EnsureNuGetPackageBuildImports" section, and remove any Error Conditions that refer to props or targets from the old MIDI SDK.

The same can apply to cppwinrt and other NuGet packages.

I've done everything I need to do, but VS still shows errors all throughout my code

Intellisense doesn't like NuGet package changes like this. Close and then reopen Visual Studio to clear it up. (You can also just unload and reload the project(s) )

I get a crash when calling winrt::uninit_apartment()

This will happen if you have dangling COM references. Be sure to set any explicit COM objects to null, and ensure they aren't doing anything weird in their destructors which might cause another reference to be created. For regular WinRT types, this should not happen.

What tools will be in Windows?

This is subject to change, but the following tools are expected to ship in Windows, so that support staff at companies can rely on them being present.

mididiag.exe
midi1enum.exe
midi1monitor.exe
Possibly midiksinfo

Again, the exact list is TBD until we actually ship. Tools that aren't included in-box will be made available, if they are still useful, in other ways.

Will the MIDI Settings app or MIDI Console app ship in Windows?

There will eventually be some in-Windows functionality for end users to set up the different transports (loopbacks, network, etc.), see MIDI devices, etc. but it will look different from the current MIDI Settings app. The current MIDI Settings app will be updated and maintained until the time we have the required features in Windows. The MIDI Console will also be made available separately.

Known SDK Issues and items to be completed

MidiBasicLoopbackManager::GetActiveLoopbackEntries() is a no-op. This will be fixed.
The Mute/Unmute for the bidirectional loopback is a no-op. This will be fixed, but also requires a service component update.
I need to update the strings in mididiag.exe and similar in-box executables to put them in resource files for automatic localization.
There's additional exception handling to add in a few places (there always is).
Documentation has not yet been updated. Please don't file bugs against docs for the SDK :)
The above GetActiveLoopbackEntries()
PowerShell projection has not yet been updated
No MIDI Settings or MIDI Console for this release. However, you can use the existing ones from the SDK side-by-side with this
MidiEndpointConnectionRaw doesn't have appropriate projections and code for C# yet
Midi1 Legacy port numbers returned by this SDK are off by one for message source/input ports. This has been fixed for next rev.

Developer Calls to Action

Please code against this API and report back any problems as soon as possible, so we have a chance to change/fix before these go into Windows and get locked-down
Refer to the C++/WinRT samples for how to accomplish tasks. Another is the set of tests in the src\api\Test\WinRT Client\ folder
Ask questions!
Please report as a new issue here, discuss on Discord, or use the existing channels you have with us.

Navigation Menu

Uh oh!

In-box SDK/API Developer Preview 1

Choose a tag to compare

Sorry, something went wrong.

Sorry, something went wrong.

Uh oh!

No results found

Permitted Use

Why is this being released?

Special Instructions

C++ Specifics

Service Specifics

C# Specifics

Delphi and Other Manual projections

Instructions

Updates and Changes

Namespaces

Connection

Basic Loopback

Loopback

Initialization

API detection

Enumeration

ServiceConfig

Utilities

Samples

Fixes / Updates

Troubleshooting / Likely FAQ for this release

I get REGDB_E_CLASSNOTREG when creating types

Error C3867 in VS / MSBUILD

Error E0300 in VS / MSBuild

Errors about missing packages

I've done everything I need to do, but VS still shows errors all throughout my code

I get a crash when calling winrt::uninit_apartment()

What tools will be in Windows?

Will the MIDI Settings app or MIDI Console app ship in Windows?

Known SDK Issues and items to be completed

Developer Calls to Action

Uh oh!