Developer Preview 5

Hi Everyone. We're continuing our march to production with Developer Preview 5!

(Updated Windows.Devices.Midi2 zip below with missing header files)
Updated driver because the initial release went out with an old driver version.

In preparation for our next API review and for moving into production, we've looked at every aspect of the API and evaluated it for completeness, usability, and necessity and also rolled in a lot of the feedback we've had over the past 6 months.

As a result, there are a number of changes in this release. In our testing, all applications built against previous versions of the API will need to be recompiled against the new metadata, and may require some minor code changes. Note that changes in class signatures does result in changes to the generated interface Ids.

Please do file bugs! But please also check the current outstanding issues before doing so. Feel free to add more data or comments to existing issues if you find you've run across the same problem.

Documentation

In prep for production and for our internal API review, I've started fleshing out the documentation. Work-in-progress docs are currently using GitHub pages and are now published at https://aka.ms/midi . When we have an official MS Learn section for Windows.Devices.Midi2, we'll repoint the aka.ms to that.

NOTE: Some of the docs, especially those about the configuration file format, need to be updated and are no longer valid. We're catching up with these as soon as possible.

Important Method Signature Changes

Our internal API validation required that any out or in/out parameters be the last items in a parameter list in any function. For that reason, all the MidiMessageReceivedEventArgs methods which would fill an array, buffer, or struct, had to be modified so the array/buffer/struct was the last item in the parameter list. To keep things consistent, all the Send message methods were changed to operate the same way.

Additionally, any method which took an IVector or IVectorView as a parameter has been changed to take an IIterable to be consistent with our API guidelines and automated validation.

Finally, for the same reasons, several of the "Flags" enums were renamed to be plural and remove the word "Flags" from the enum.

API and Service Highlights

App-to-app and Loopback MIDI

• App to app MIDI devices can now be created 100% through the API, from an application. See the app-to-app MIDI C# example for details. This version of app-to-app MIDI enables your application to appear as a full MIDI device, with endpoint information, function blocks, and more.
  • https://microsoft.github.io/MIDI/endpoints/virtual-device-app.html
• Simple loopback MIDI now available through the configuration file and through the API
  • https://microsoft.github.io/MIDI/endpoints/virtual-loopback.html

Active Sessions

• The service now tracks active sessions and displays the name your apps are providing when creating a new session. The console midi enum sessions command has been added to report on that information.

Installed Transports

• The service now reports on installed transport plugins. The console midi enum transports (with optional --verbose) lists all the transports currently enabled in the service.

Example with --verbose

This information is also reported by the mididmp utility.

MIDI Service Control

• The console midi service command has been updated to now have sub-commands to start/stop/restart the service. These must be run from a command prompt running as administrator midi service start, midi service stop, and midi service restart are the new commands.

MUID

• The MidiUniqueId class now has methods for generating a new random MUID, parsing the MUID from bytes or a single 32 bit integer, and more. This class is useful when you are working with MIDI CI.

Connection Updates including Multi-message sending

• Refactored the endpoint connection settings, resulting in different signatures to the MidiSession methods to create a new connection.
• MidiEndpointConnection no longer implements IClosable / IDisposable and no longer has a Close or Dispose method. Always close the connection through the related session. This avoids having dead connections in the session collection. The MidiSession class still implements these interfaces.
• Added to MidiEndpointConnection the SendMultipleMessagesWordList and SendMultipleMessagesWordArray to send a vector/collection/list/array of words. Currently, the code behind this will pick this apart into multiple discrete messages, and send all with the same specified timestamp. This is the only method which will accept multiple UMPs and send them all. We're including it for ease of use and for potential future optimization for sending more than one message at a time.
• At the same time, the methods which send only a single message have been renamed to new names in the form SendSingleXXXX.

Here are some informal speed tests. The code that generated this output is in the samples section. This is going to vary a bit from time to time as we adjust timings and optimize code.

Full thread: https://discord.com/channels/980245825202552942/1208186499993178192

Message Scheduling

Now that we have other message sending bugs resolved, I've re-enabled message scheduling.

Message Scheduling is still due for an update to ensure that there's only one instance per device, so you may run into scheduling strangeness like before if you have multiple connections open to the same device, each sending scheduled messages.

Please file bugs here if you see problems.

Message updates

• The MidiStreamMessageBuilder API functions now take and return IMidiUniversalPacket instead of MidiMessage128. This makes them more usable from other functions
• The IMidiUniversalPacket type now has functions to return all the words either as a new vector, or insert them into an existing vector
• Removed the MidiMessageTranslator which was not yet implemented. Other libraries already do a good job of upscaling/downscaling MIDI 1 <> MIDI 2 messages.

MIDI Clock Update

• The MidiClock class now includes a TimestampConstantSendImmediately property. You can still just use 0 in place of the timestamp when sending messages if you want to bypass the scheduler, but this property makes that value more obvious. It's a property because WinRT doesn't support shipping defines or constants any other way.
• MidiClock also has a few more conversion methods to make it easier to handle the time calculations from any language

Enumeration Updates

• Added additional sort order options to MidiEndpointDeviceInformationSortOrder so if you want to sort by the transport (for example, all network MIDI devices followed by all virtual devices) you can do that.
• Added various "LastUpdateTime" properties to the device information object for the in-protocol discovered properties like function blocks, endpoint information, etc.
• Renamed some of the enumerated device properties so they better represent their source
• The MidiEndpointDeviceWatcher events have all been normalized to send XXXXEventArgs types as the second parameter. This was the result of automated API review.
• There's a bug in the driver right now so we don't yet pull the iSerialNumber property. Next release for that.

Apps and Tools

Console

• The console has generally kept pace with the API changes and so surfaces new features like session reporting, transport enumeration, and more. There's quite a bit of new functionality in there.

MIDI Dump Utility

• The install now includes the mididmp.exe utility. This will be ship in Windows with the API. It's a lightweight bare-bones command-line program which outputs the devices, the midi clock information, and the results of a service ping test. Intention here is for this to be available for use by technical support personnel and for desktop applications as per original AMEI request. Output is plain text with machine-readable tokens because most apps will redirect output to a file or otherwise capture the output. Here's a screen shot from an early revision of the app:

This is a C++/WinRT console app which uses the API. Source here:
mididmp.exe source

The utility is in the app path, so to use it from your own applications, just ShellExecute or your other favorite way to launch other processes, and capture the output.

Work-in-Progress MIDI Settings App

A very early build of the MIDI Settings app is also included with this release. There's a lot in here which is not yet wired up, but you can view endpoint devices, sessions, transports, etc. Expect random errors and more.

The settings app was built using .NET 8, WinUI 3, and the Windows App SDK. The installer package installs all of those components on the target PC. Note that .NET 8 is also used for the MIDI Console app.

Installed Transports

Enumerated Endpoints

Endp...

Developer Preview 4 (Official NAMM Readiness Preview)

Hi All

Here's the official Developer Preview 4, just in time for NAMM! This is the release I'll be using when presenting on stage.

This includes everything from the previous dailies:

• https://github.com/microsoft/MIDI/releases/tag/dev-preview-4-daily3
• https://github.com/microsoft/MIDI/releases/tag/dev-preview-4-daily2
• https://github.com/microsoft/MIDI/releases/tag/dev-preview-4-daily1

In addition to what was listed in the DP4 daily releases, we have the following:

Changes

This includes support for app-to-app MIDI, as long as the device is configured in the midiconfig file in advance. Later, we'll add in the plumbing to enable this at runtime. This is an unstable feature, however, so use at your own risk at the moment. The related PR shows the syntax of the config file entry. #232

• When the service starts, the config file is read and the device-side endpoint is created. This is the endpoint the app acting as a device should open. This endpoint is not visible in a normal enumeration call as it has a purpose of MidiEndpointDevicePurpose::VirtualDeviceResponder which is normally excluded from enumeration.
• Once the app opens that endpoint connection, the service will enumerate a client-visible endpoint that is routed to the device endpoint. This is the normal multi-client endpoint that all apps should use.
• When the device app closes, the client-visible endpoint is torn down

This has basic support for reporting function blocks and endpoint metadata. Protocol negotiation is buggy for it, so that has been turned off for this release just for this type of endpoint. For now, you can use midi endpoint request endpoint-metadata --all to request endpoint info and then midi endpoint request function-blocks --all to get the function blocks.

In addition, there's a new sample app. It's a C# WinUI app that is a 4x4 pad controller demonstrating app-to-app MIDI and how to configure function blocks and endpoint metadata.

Fixes and Workarounds

#224 Fix: Console send-message should allow hitting escape. This is fixed in this preview.

#233 Work around: Slow send-message-file command has been worked around. For now, only failed messages are displayed on the console. There's a summary at the end telling you how many messages have been sent. This will later be changed to a better display, but I wanted to deal with the performance issue. If there are MANY failed messages (thousands), it'll be slow again.

Screen shot from the test vm. The messages sent in just a few seconds.

USB Driver

We don't yet have a new version of the USB driver, so please continue to use the one from December. Download and install instructions here: https://github.com/microsoft/MIDI/releases/tag/dev-preview-2

A reminder that the MIDI Association Developer Day is this Friday. I'm kicking it off at 10:30am with a presentation on Windows MIDI Services.

Thanks again to everyone for testing. See you at NAMM this week!

Developer preview 4 (NAMM Readiness - Daily 3)

Important items for this release:

• Something in the changes here triggered generation of a new .winmd file. My apologies there, as we were trying to keep that stable/static. As a result, the projections had to be regenerated including the NuGet package. That is all included in this release but you'll likely need to update your references.
• Made the midi clock command more informative.
• Added more information to the monitor output summary, especially if running with debug settings
• Issue #227 worked around (but needs more diverse testing from folks). I've been testing with both the loopback and the protozoa. Where I was getting lost messages before, I am now receiving 100% of them. There's a bit more jitter (around 10 microseconds) as a result. We'll continue to monitor and Gary has an idea for how to better fix this long-term.
• Added a pair of test/debug flags to send-message and monitor on the midi console app. These are designed to work together over the loopback, or using the ProtoZOA firmware which sends messages with an increasing value in word 2.

Examples:

midi endpoint monitor --debug-warn-skipped-increment

midi endpoint send-message 0x41234567 0x00000000 --count 100000 --debug-auto-increment --pause 0

Please test on your systems and let us know if you run into any issues

Scheduled messaging is still turned off until we are sure on issue #227 above, so we can keep any problems isolated

We won't have a new revision of the USB driver before NAMM, so please continue to use the one from December.

If you are seeing green screens with that driver, one possible cause is power management. If you turn off USB suspend and related power management on Windows, it will stop those specific errors from happening.

Developer preview 4 (NAMM Readiness - Daily 2)

Ok, this time the console monitor speed improvements really ARE significant :) The console will now keep up monitoring within a few messages when it's getting spammed by a device sending messages in tens to hundreds of microsecond intervals. Previously, it would lag quite far behind.

Addresses issue #182
Addresses issue #222
Addresses issue #218

Still work to do on sending messages from the console. The current code doesn't allow for anything more rapid than around 700us.

Same NuGet package and winmd file as the previous preview. Please uninstall the previous exe installer from Settings -> Apps -> Installed Apps before installing this.

Tested on VM and dev workstation, but this is a daily, not a full preview.

Developer preview 4 (NAMM Readiness - Daily 1)

NOTE: The previous installer Windows.MIDI.Services.Developer.Preview.4.x64.1.0.24015.2013.exe had a bad config file with it which caused the install to fail. That has been fixed and replaced

Why the convoluted name? This is a quick release, and hasn't been through the usual level of testing for a developer release.

This preview is for anyone in active development, especially those who

• Are working on a Demo for NAMM (the winmd here represents the API as I will use it at the NAMM show)
• Are debugging a performance or lost message issue in the console
• Can provide immediate feedback for any problems

Main changes

• Significant performance improvement when monitoring in the console. I've also pared down the console output when you monitor in a non-verbose mode. Lower CPU usage and faster display is the main result
• Console gracefully handles a device disconnect during monitoring
• Group Terminal Blocks are projected as roughly equivalent function blocks if you call the .AsEquivalentFunctionBlock() method on the GTB.
• Endpoint discovery and protocol negotiation (UMP) happen when you plug in a USB MIDI 2.0 device
• In-protocol discovered metadata is now cleared when a device is enumerated (plugged in, or the service is restarted)
• USB device endpoint renaming works through the configuration file.

The API surface area won't change between this and the NAMM show, so metadata will remain valid.

• There is no Electron projection for this interim release.
• There is no updated USB driver for this interim release. Please use the one from December.

Please be sure to uninstall the previous version before installing this.

Developer Preview 3

This is a relatively small but important update over Developer Preview 2.x. For those who were blocked in the previous release due to bugs caused by the scheduler, this release will unblock you and allow you to continue development.

If you have a previous preview installed, please uninstall it.

Key notes

• Outbound message scheduling is temporarily disabled. It was causing a number of issues in the previous preview. Once it is solid, we'll release another preview with it enabled. The API is still the same, it's just that the timestamps are ignored and all messages are sent immediately.
• Still plenty of debug code (primarily OutputDebugString and similar) in the builds. If you run dbgview64, or attach to the service process (or app process) from Visual Studio, you can see the output.
• No updates to the USB driver due to the holidays. Please use the version from Developer Preview 2.
• Defender sometimes flags the setup package, or part of it, as a threat. This is a false positive. We'll look into code signing Github releases for the future. See screen shot below for VirusTotal and Kaspersky submission results

Please see the issues list for other known issues

Bug Fixes

This preview fixes or works around a few bugs:

• Fixed: #188 Incoming KS device timestamps are 0
• Worked Around #183 as this is related to outbound message scheduling crashing in the service
• Worked Around #182 also related to message scheduling

The last two are not yet marked as fixed because they are simply worked around in this preview release. However, it's key to work around those right now for you all to be able to test the release.

New features

Service metadata parsing

• The service now parses in-protocol endpoint data and function blocks as long as there is at least one client listening to an endpoint. Right now, this information persists across service restarts. In the future, we'll be clearing this information from the cache when the device goes away. There must be an active client connection at the time of message arrival for the data to be cached. This is by design.

MIDI Console

• The MIDI console can easily request endpoint metadata and function blocks through the new midi endpoint request command. If you don't have a long-running connection open in another application, the recommended way to use this is to open one console monitoring the UMP device, and another for sending the request. Note that the console doesn't keep an active connection after sending messages, unless you schedule messages out into the future. Otherwise, only when you are monitoring an endpoint is the connection maintained.
• Function blocks are displayed in the endpoint properties
• Endpoint Device Watcher updated to display more information about what has changed

Enumeration API

• The Enumeration API has been updated to provide more information about which properties have changed in the Watcher Updated event.
• There have been additional properties added to the MidiEndpointDeviceInformation class, as well as an update to the Function Blocks vector to change it to a map, indexed by block #

Installation

Uninstall any older version of Windows MIDI Services from your apps -> installed apps in settings. You do not need to uninstall the USB driver.

Unzip the Windows.MIDI.Services... zip file somewhere and run the contained exe installer. This will install the API, Windows Service, and MIDI console. Keep the installer around so you know which version you last installed. This is needed for bug reports.

If you want to communicate with USB devices, install the attestation-signed USB driver from Developer Preview 2. Requirements for the driver are documented there. Primarily, you need to be running an Insider Canary build of Windows 11.

As always, discussions on Discord are welcome, as are bug reports here.

Developer Preview 2.1

This release fixes two issues, one major and one mine.

1. The high CPU usage issue is fixed in this release. In some cases, this could lead to 100% CPU usage and an unusable system until you restart the MIDI service.
2. The MIDI Console app no longer truncates the word "Escape" when you press the escape key.

This update includes only the service/API/tools installer. All of the other components remain the same and do not need to be updated.

To update, uninstall Windows MIDI Services from the Apps -> Installed Apps section of Windows Settings, and then install this version.

For all other notes, please refer to Developer Preview 2:

https://github.com/microsoft/MIDI/releases/tag/dev-preview-2

Developer Preview 2

NOTE: There's an update to this release which may be found here. You'll still need the driver, projections, etc. from this release, but there's a new installer.

https://github.com/microsoft/MIDI/releases/tag/dev-preview-2.1

===

We're excited to release the latest snapshot of Windows MIDI Services, including the new Windows Service, the API and projections, the console app, and the USB MIDI 2.0 driver.

This is a developer preview intended for application and device developers. This is not a customer / end-user / musician-ready release. It is not intended to be used on a production workstation or a PC you rely on. There is no end-user support for this release. Any bugs must be filed in Github for us to track.

Please do not host or distribute these files to others. Always refer them to this release page to read the instructions and download the files

We want to know about your experiences with this release. Please report (or add detail to) bugs on Github, and ask questions or have discussions on our Discord server.

Developer Preview Release Highlights

• A mostly complete UMP-based MIDI 2.0 API with features based on your feedback and discussions on Discord, at MIDI meetings, and at readiness events
  • Multi-client by default
  • Supports outbound message scheduling by default
  • Provides much more information about connected devices
• A Windows Service with support for pluggable transports and pluggable message processing plugins*
  • Much faster than the older MIDI infrastructure in Windows, using circular buffers in shared memory for communication between the service and API, and the service and the Windows Kernel-mode drivers.
  • Provides a centralized location for translation, enumeration, message processing and more
  • Doesn't require drivers for each type of transport. Most can be implemented as user-mode service plugins.
• A console app useful for testing, debugging, and general inspection of the system

* the message processing dynamic loading is not yet in place, but it is in place for transports. The plugins are loaded from entries in the registry.

Key Notes

Please report any bugs, no matter how small. There are many we know about, but they are not all documented just yet. We're moving to a phase of more formal bug reporting now.

Installer

If you are running any earlier previews, please uninstall them from Settings->Apps->Installed Apps. Patch/upgrade installs are not supported.

If you are running any OS dism patches from the on-campus plug-fest and readiness event, please also remove those. The latest Windows Insider Canary build contains the OS components required.

The Windows MIDI Services Installer is not a full-featured installer. It's used only during these developer previews. Before installing a new version, you must always uninstall any previous versions through the Windows Settings app.

In addition, the installer temporarily takes over ownership of the registry location for WinRT activation entries, which is normally owned by Trusted Installer. This is not a supported scenario, but is needed for external releases from Github vs requiring your app keep the API local and include a large manifest file with activation entries. If this installer fails for some reason, it could leave you with a broken WinRT system requiring a repair or reinstall of Windows (we have not yet run into that in our testing, but it could happen). In addition, these entries get wiped out each time you upgrade from one Windows Insider Canary build to the next. We do not recommend you adopt this approach in any products you ship.

USB MIDI 2.0 Driver pre-release

The USB MIDI 2.0 driver needs to go through a lot more internal testing before we can qualify and production sign it. But we know we need solid USB device support for this API to succeed. In support of this, we also want to see it tested with as many different devices as possible. We'll do quite a bit of this ourselves and with partners, but this is where you can help. If you are a developer of a device and want to ensure your device works with the new MIDI stack and driver, please test and report any bugs here, or start discussions on Discord.

If you do not need to test USB devices under the new API, do not install this driver. There is no end-user support for this driver and it's quite likely you will have a crash or two.

We're providing the driver primarily to those actively implementing the API in their apps, or testing their own devices. If you do not need to work directly with USB MIDI devices, you can use the built-in loopback devices with the API.

• We have an attestation-signed pre-release USB MIDI 2.0 driver developed by AmeNote. This is a build of what will be the new MIDI class driver shipped in Windows. Because it has been attestation signed, you do not need to turn on test signing, disable secure boot, or any of the other things which make self-built versions more of a challenge.
• To use the driver, you must manually assign it to the device using "have disk". Unzip the driver files to a known location, right-click the hardware device (not the software device) in Device Manager and choose a driver from those on your PC.
• If you unplug the device and replug it, you may need to manually pick the driver again.
• The driver will green screen your system if you pick an incompatible device, such as the audio device from a combined audio/midi device, or a serial management endpoint of same.
• The driver requires the latest Insider Canary build of Windows 11 for our USB stack updates which have not yet been serviced to mainstream supported Windows 11 and Windows 10 releases. Only the Canary releases will work here. For more information on the Windows Insider program, check the documentation here.
• The driver currently supports only a single device at a time. #166
• The driver (and service plumbing) do not currently support the classic MIDI APIs on Windows.
• Please report any new bugs with as much detail as possible. If you are trying a MIDI device and found any failures or bugs, it would be helpful if you could also provide a copy of all the device header information using a tool like the Thesycon descriptor dumper or USB Device Tree Viewer. The latter has issues reporting all string properties, however, often saying the device is in a low power state.
• The password for the USB MIDI zip file is preview-2. The password is there to help ensure everyone installing it has read this section. :)

Upgrading your Windows Version

• If you upgrade to a new version of Windows (including to a new Canary build) you'll need to uninstall and then reinstall Windows MIDI Services and the USB driver.

Features and Other Notes

Service-based Message Scheduling

• Outgoing MIDI messages can now be scheduled through the service.
• Use a timestamp of 0 to bypass scheduling completely. You can also use a timestamp of MidiClock::Now() to effectively bypass scheduling. 0 is the better choice, however as it short-circuits the rest of the scheduler, and is also consistent with other operating systems.
• Fix: Originally, messages with the same timestamp > now had indeterminate send order. That has been fixed so the order is retained.
• Don't queue thousands of messages. Performance degrades based on outgoing scheduler queue size. This is unlikely to change.

Enumeration

• It can be a challenge to get all the custom properties using our standard enumeration objects
  • Also a lot of work just to find the parent device. We've handled that.
  • These classes wrap the standard enumeration types
• New support for the MidiEndpointDeviceInformation class and metadata. See sample.
• New support for the MidiEndpointDeviceWatcher class for add/update/remove notification. See sample. This is the preferred way for you to enumerate endpoints, because it will notify you when they are added or removed, and when properties (like function blocks) change.

Group Terminal Blocks

• The new USB driver now supplies Group Terminal Blocks from MIDI 2.0 devices. These are surfaced through the MidiEndpointDeviceInformation class and also through the console app as well using midi endpoint properties
• The new USB driver also creates group terminal blocks for USB MIDI 1.0 devices. The returned information should contain the correct names if you provide Pin names in your USB headers

A classic byte-stream MIDI 1.0 device. The names of the two virtual Group Terminal Blocks come from the iJack descriptors.

Listeners

Client API Endpoint Listeners now in place

• MidiChannelEndpointListener : Receive messages only for a group and channel
• MidiGroupEndpointListener : Receive messages only for a group
• MidiMessageTypeEndpointListener : Receive messages only for certain message types

Virtual D...

September Developer Preview (Dev Preview 1.1)

Windows MIDI Services September Developer Preview

This is the official Developer Preview 1 of Windows MIDI Services. (Updated to fix access violation in previous release)

Release Notes

As we get closer to a 1.0 release of Windows MIDI Services, we're working to have everything set up in a way that better represents how this will function when distributed with Windows. In all the interim previews to date, we've distributed everything through a NuGet package plus a small installer just for the Windows service.

Expect bugs. Please report them as issues on Github so we can track them

IMPORTANT NOTE: the installer requires that you are a local administrator on your PC. It does some hacky stuff to enable WinRT Type activation of an out-of-band library. This approach is neither supported by nor recommended by Microsoft, but we're doing it here to get you a dev preview, as open source, which behaves much like it will when in-box, without having to wait until the bits are in an Insider build. Specifically, the installer calls to a C# addin which takes ownership of the protected HKLM\SOFTWARE\Microsoft\WindowsRuntime\ActivatableClassIds, adds the new class Ids, and then returns ownership back to Trusted Installer. The implication here, if that gets interrupted or otherwise fails, is that the rights on that key could be compromised and either allow anything to be registered, or nothing. It has been tested on fresh VMs and developer PCs here. It uses registraton entries built as part of the cake build. You can see the source code in \src\oob-setup\RegistryCustomActions and specifically the CustomAction.cs file.

For this reason, this is a developer-only release and is not for installation on end-user or customer machines.

Do not distribute the installer to others. Please instead provide the link to this release.

Major near-term items not yet present

Transports

• USB MIDI 2.0 class driver (so no USB devices or group terminal blocks yet)
• Virtual MIDI (including virtual CI devices)

Other Features

• Function blocks and endpoint information, including automatic discovery. This is coming soon, after I have built good tests for it.
• System-wide caching of function block / endpoint, and other information. Cache implementation is local for this preview.
• User-configurable setups
• SDK. Most of the required SDK functionality has now been incorporated into the API, so for simplicity, we're leaving the SDK out until we start adding in virtual/network/etc. transport configuration objects (which will be SDK items). Because this is not an end-user release, and this feature may be unnecessary over time, we also do not include the SDK code for checking if Windows MIDI Services is installed.

Apps

• GUI Settings app
• Recording MIDI messages to a file in the console app (this is coming soon, but didn't make the cut here)
• Additional developer features in the console app (endpoint/function block simulation, etc.)

Type Registration / Activation

• COM clsids are not registered. For COM activation during development, you may need to copy the Windows.Devices.Midi2.dll local to your project and use it as in the previous releases.

Architecture

• No Arm64 support yet. The project is Intel x64. A reminder that there will not be any x86 builds or support for 32 bit processors.

Known errors

• Although far fewer than the past, there are still a number of functions that throw E_NOTIMPL HRESULT. Here are the ones we're expecting hresults from for this release. Please report any other hresults or problems you find
  • MidiMessageReceivedEventArgs::FillBuffer
  • MidiEndpointInformationConfigurator::*
  • MidiFunctionBlockEndpointListener::*
  • MidiStreamConfigurationEndpointListener::*
  • MidiTransportInformation::*
  • MidiVirtualDeviceManager::*
  • MidiMessageBuilder::BuildSysEx7MessageFromArray
  • MidiMessageBuilder::BuildSysEx7MessageFromBuffer
  • MidiMessageBuilder::BuildSysEx8MessageFromArray
  • MidiMessageBuilder::BuildSysEx8MessageFromBuffer
  • MidiMessageBuilder::BuildMixedDataSetChunkHeaderMessage
  • MidiMessageBuilder::BuildMixedDataSetChunkDataMessage
  • MidiMessageBuilder::BuildMixedDataSetChunkDataMessageFromArray
  • MidiMessageBuilder::BuildMixedDataSetChunkDataMessageFromBuffer
  • MidiVirtualDeviceResponder::*

Other Known Issues

• The service eventually becomes unresponsive after a few hundred messages. During the runup to that, message transmit/receive times start to go up. You can see this by using the midi console and typing midi service ping --verbose --count 50 and running that repeatedly. When the service becomes unresponsive, you can restart it in the Services snap-in or through SCM. We're looking into it.

Features

Now let's get to what is here, as there is quite a bit. In general, what you're seeing is much closer to the production version that will eventually ship in-box. There's a lot of service infrastructure in there, plenty of bug fixes and hardening, cleanup of type and parameter names and more. There's more to do, but if you're not already developing with the previews, this is a great one to start with.

API

• Quite a bit in the API and service, including all the infrastructure to send and receive messages For more information, see the API documentation

Service

• Diagnostics transport which includes cross-wired BiDirectional UMP endpoints, an input and output endpoint, and a ping endpoint. These are all for developer and testing/support use as described in the API docs.
• Bug fixes for the initial issues around flooding messages without consuming any of them. Hammer this as hard as you want and let us know what you find.

Documentation

• API overview documentation in \get-started\midi-developers\app-developers\docs

NuGet Package

• C# projection is fully functional
• NuGet package with the WinMD and C# projections and works for both C# and C++.
• Package no longer contains the API implementation DLL
• Package no longer contains any SDK components

Installer

• Installs the MidiSrv Windows service, the console app, and the API
• Installs the .NET 8 Release Candidate desktop runtime (required by the apps)
• Installs the retail Visual C++ Runtime (required by the API and service)
• Registers the WinRT types for activation (this is a hack for developer purposes only. See note above)
• Tested on Windows 10 22H2 bare VMs, and on developer machines

Service

• UMP Bidirectional loopback endpoints. Sending to A->out comes back on B->in. Sending on A->in comes back on B->out
• Unidirectional loopback endpoints. Sending on the out loopback comes back on the in loopback
• Ping transport. For internal use. The console application uses this, and the MidiService API type has a static method to perform the ping in case you need to do any sort of diagnostics from within your apps.

Console app

• Combined with the loopback UMP Endpoints, useful for testing MIDI 2.0 implementations. See this thread in Discord
• Service status and ping to check that the service is installed and running
• Message sending from the command line
• Send a file of messages for automated testing
• Monitor incoming messages on a UMP endpoint
• Enumerate all UMP Endpoints
• Enumerate all bytestream (MIDI 1.0 endpoints as they appear to WinMM and older WinRT APIs.

Build process

The entire package is built using the build.cake build script in the repo.

Verifying the install

A successful install looks like this:

• Root folder %programfiles%\Windows MIDI Services
• API subfolder with Windows.Devices.Midi.dll and Windows.Devices.Midi.pri
• Service subfolder with MidiSrv.exe and the different abstraction DLLs. The abstraction DLLs are COM self-registered on install
• Tools subfolder with Console and Settings folders.
• Console folder with midi.exe and all dependencies
• Settings folder is empty but will contain the Settings GUI app in a future release.
• %PATH% updated to include the location of the MIDI Console app midi.exe
• Microsoft MIDI Service installed in Services and running (it will make a device connection sound when it starts up on Windows 11. - Investigating to see if there's anything we can do about that)
• Opening up a new console and typing midi service ping --verbose returns a positive result

Testing without any MIDI 2.0 devices

The console app provides easy ways to send and receive UMP messages. You can load up a file with valid (or valid enough) UMPs and use that to test receive functions in your app.

Here's one of the files I used for testing the feature:

# This is a test file for sending UMPs through Windows MIDI Services
# It uses auto for the field delimiter so we can have different 
# delimiters on each line

# The line above was empty. The next data line is a UMP32

0x22345678

# The messages aren't valid beyond their message type matching the number of words

0xF1345678 0x12345678 0x03263827 0x86753099
0xF2345678,0x12345678,0x86754321, 0x86753099
0xF3345678|0x12345678|       0x86754321|0x86753099

0x21345678
0x42345678 0x12341234
0x43345677 0x12341235
0x44345676 0x12341236
0x45345675 0x12341237
0x26989898

# The next two lines have different hex formatting

41345678h 12341234h
22989898h
F3345678h 12345678h 86754321h 86753099h


# The next lines have no hex formatting

41345678 12341234
22989898

# The next lines...

September Developer Preview (Dev Preview 1)

This has been replaced by Dev Preview 1.1 due to a console app access violation due to a mismatched NuGet package.

Please uninstall the previous release through Settings->Apps and install the new version from here

https://github.com/microsoft/MIDI/releases/tag/dev-preview-1.1