October 21st, 2024

Windows MIDI Services October 2024 Update

Pete Brown
Principal Software Engineer

It’s been a little while since I last posted an update about Windows MIDI Services outside of our Discord Server, but we’ve been busy! With all the announcements today at Qualcomm’s Snapdragon Summit, I thought I’d dive in a bit on where we are with our new MIDI 1.0 and MIDI 2.0 stack on Windows.

For more information on what we announced for musicians at Snapdragon Summit this week, check out this blog post Make Great Music with Windows on Arm.

What’s MIDI?

Not everyone reading this is familiar with MIDI as it applies to musicians. So a brief explanation is in order.

MIDI: The original standard

MIDI (Musical Instrument Digital Interface) has long powered stage shows, lighting, lasers, and even quadcopters. It’s what enables one synthesizer or sequencer to control another. And, of course, it’s what you can use to connect your controller or synthesizer or drum machine as an input or output device to your PC running sequencing software. MIDI is about control messages, not audio, so it is half of what’s needed to make music with a digitally connected set of instruments, with audio as the other half.

MIDI, now referred to as MIDI 1.0, uses a simple serial communication byte-format stream (or in 1999, on USB, 32-bit packets) using values that are typically in the range of 0-127 (except multi-byte values), at speeds generally constrained by the original standard of 31,250 bits per second (often even on USB, where the device on the receiving end may not have the ability to receive messages any faster than that). That means each Note On message took almost 1ms to transmit, and a chord of 5 notes could take 5ms. These speeds and capabilities were revolutionary in 1983, but they can be a bit of a hindrance in today’s market where every millisecond counts, and drum tracks especially are more complex and layered.

People outside of the musician community often think “MIDI” means just the music file format that was made popular in the late 80s and beyond. But the SMF (Standard MIDI File) format is just one small part of MIDI. Its real power is in connecting devices, computers, instruments, video equipment, and more to synchronize behavior to record or perform. It is simply one of the most powerful and influential standards in music creation, and it has lasted, with its core unchanged, for over 40 years.

MIDI 2.0

MIDI 2.0 is the latest evolution in musical instrument connectivity and control. It provides better discovery and self-declaration of capabilities. It has much higher resolution controller values. And it supports new features like per-note articulation for powerful expressivity, and absolute pitch, which makes custom scales and tuning available all the way from the recorded information the DAW through to the instrument.

MIDI 2.0 is not speed constrained, so messages can be transferred as quickly as the underlying transport will allow.

You can learn more about MIDI at the MIDI Association.

Windows MIDI Services: The New Windows MIDI Stack

Windows MIDI Services supports MIDI 1.0 as well as the MIDI 2.0 Universal MIDI Packet (UMP) standard. Together this provides compatibility with existing MIDI devices as well as the new MIDI 2.0 devices already in-market or coming soon (I have several MIDI 2.0 devices here in my studio).

MIDI CI, which bridges the gap between MIDI 1.0 and MIDI 2.0 UMP, is supported through normal SysEx support, and we recommend the use of open source cross-platform libraries which help with creating and parsing those messages. We’re evaluating what we will do in the future to make some features, like profiles and property exchange, simple to use on Windows.

Why the new API/SDK?

The older WinMM API served its purpose, but has a lot of shortcomings for developers: It’s difficult to identify when devices are added or removed, any new transports require writing, signing, and deploying a driver, and it could not be reasonably extended to support the new MIDI 2.0 UMP format, timestamps and scheduled messages, across-the-board-multiclient, and more. We’ve taken a stab at other API models in the past, but they all had similar constraints and limitations.

Windows MIDI Services is a complete rewrite from the ground up, so it does not inherit those limitations. It’s designed to fully support MIDI 2.0 UMP, and to make it much easier to plug in new features and transports.

Windows MIDI Services Architecture Diagram
]3 Windows MIDI Services Architecture Diagram

This is the SDK application developers should be working with going forward, to get the most out of MIDI on Windows.

Backwards compatibility with the WinMM MIDI 1.0 API

But we know that almost every app today that uses MIDI 1.0, does so through the WinMM API. So we have some clever approaches to repoint that API to the new service, and provide some of the benefits that adopters of the new SDK get (multi-client, for example). It does not provide access to all transports, or to new features like creating loopback endpoints and virtual devices.

If you are interested in seeing the older WinMM API compatibility in action, including adding in multi-client support, check out this video I put together:

That video shows a mix of MIDI 1.0 and MIDI 2.0 in action, sharing the same endpoints, with multi-client capabilities and auto-translation between protocols and formats. You can also see the Windows MIDI Services Console, and the new properties that are associated with each endpoint, and the console’s ability to monitor a MIDI input device (it can also stream the monitor output to a file).

Back in January, before we had the WinMM compatibility in place, I demonstrated Windows MIDI Services at NAMM, showing previews of Steinberg Cubase and Bremmers MultitrackStudio both using the new API, and able to communicate with MIDI 2.0 apps and devices.

Windows MIDI Services Launch Features

Windows MIDI Services is available in developer-only preview today, and will ship in Windows Insider builds next month for developer and technical customers, and then gradually roll out from there. The developer previews and in-box releases fully support AMD/Intel x64 and also Arm64 devices. At launch, Windows MIDI Services will include the following:

Device Compatibility

  • Support for MIDI 1.0 devices through our older in-box MIDI 1.0 class driver
  • Support for MIDI 1.0 devices through most existing MIDI 1.0 drivers
  • Support for MIDI 1.0 devices through the new combined (faster!) MIDI 1.0 and MIDI 2.0 USB Class driver. Most MIDI 1.0 devices will need to be manually assigned to this driver to use it.
  • Support for MIDI 2.0 UMP devices through the new combined class driver

API Compatibility

  • New UMP-centric MIDI 1.0 and MIDI 2.0 SDK with full MIDI 2.0 message and feature support
  • Backwards compatibility support for MIDI 1.0 and MIDI 2.0 devices through the WinMM API (WinMM apps can talk to USB MIDI 1.0 and MIDI 2.0 devices at a MIDI 1.0 compatibility level). This provides basic compatibility features, but no MIDI 2.0-specific features
  • Possible backwards compatibility support for the WinRT MIDI 1.0 API introduced in Windows 10 (if not in the first release, it will be available very shortly after)

Transports

  • USB MIDI 1.0 and 2.0 devices
  • Virtual MIDI 2.0 devices (app to app MIDI with Discovery and MIDI 2.0 features)
  • Simple Loopback Endpoints (can be created by user or apps)
  • Diagnostics loopback for development and testing
  • Diagnostics ping for support testing

Other Key Features

  • The new UMP-based driver is faster and more efficient than MIDI 1.0 drivers
  • All endpoints are multi-client by default, regardless of driver used
  • Outgoing messages can be scheduled using a high-resolution timestamp
  • All incoming messages are timestamped by the service
  • Full MIDI 2.0 UMP support, as well as Endpoint Discovery and Protocol Negotiation
  • When using older MIDI 1.0 APIs or MIDI 1.0 devices, we handle all translation between data formats (byte format, UMP) and protocols (MIDI 1.0 and MIDI 2.0)
  • New SDK has support for detailed device properties, including user-specified endpoint names and descriptions
  • When using the new SDK, apps can register for notifications for when device properties are updated, new devices are added, or existing devices are disconnected

Bundled Apps

  • With the SDK install, we provide diagnostics apps that customers or partners can use when diagnosing problems. The mididiag.exe tool provides key information in a machine-friendly text format so that apps may launch it and include the output with any customer bug reports.
  • The Windows MIDI Services Console midi.exe is a command-line way to interact with and automate MIDI. You can send and receive messages, sysex files, and much more. In the upcoming Insider build, the backwards compatibility with MIDI 1.0 WinMM API is only partially in-place, which is why it is an opt-in preview for technical users and developers. Join our Discord server to learn how to opt-in https://aka.ms/mididiscord

Future Work

Any undertaking of this size is going to have a backlog of things which don’t make it into the first release, but are super important.

  • The MIDI Settings app, which is a GUI app for managing the MIDI System will remain in preview, available via Github, for the initial Windows MIDI Services release. We have a bunch of work to do there for it to fit the vision we’ve set for it.
  • At the NAMM Show in January, we’ll have a preview demonstration of the upcoming Network MIDI 2.0 transport standard using Windows MIDI Services. Network MIDI 2.0 is really promising because it enables a different type of connectivity, unencumbered by USB cable length limitations. The Network MIDI 2.0 standard is nearing final review and approval. There are already a number of devices in development which support the upcoming standard, and you’ll be able to use them with Windows.
  • After that, we’ll also pick back up the work on Bluetooth MIDI, flexible patch bay-like routing, and the pluggable “MIDI Mapper-like” transforms in the service, with user configuration. This is an on-going project, and you can watch the progress or participate in the development on our GitHub repo, accessible via the main MIDI landing page.

Launch Date

Windows MIDI Services will be rolling out through Insider Builds over the next months, starting in November, to both Intel/AMD x64 and Arm64 PCs, with increasingly more consumer-ready releases. We’ll start with the more technical customers and development partners on our Discord Server and will expand as we find and fix issues. Then, once we and our customers and partners are satisfied with the compatibility and quality, we’ll switch it on by default, and roll it out broadly to retail Windows customers.

I can’t wait!

For Developers

Get started today

If you are a developer of an app that uses MIDI, you can get started developing today. See the documentation at the main MIDI landing page and join us on the Discord server linked there. The repo also includes examples for C++ and C# applications using the new features.

If you are a hardware of software developer looking to implement MIDI 2.0 on Windows, you may contact me on the Discord Server, or email me directly at pete dot brown at microsoft dot com. Note that our email spam filter is aggressive, so please make sure the title is super obvious.

.NET Conf talk for C# Developers

If you are a C# developer, you may be interested in my upcoming .NET Conf talk which explains Windows MIDI Services features, and then shows how to write a C# app which uses the SDK.

The video will play at 1:30pm Eastern time on Day 4 of .NET Conf 2024. Information here: https://www.dotnetconf.net/agenda

Author

Pete Brown
Principal Software Engineer

Pete is a Principal Software Engineer in the Windows Developer Platform team Windows at Microsoft. He focuses on client-side dev on Windows, apps and technology for musicians, music app developers, and music hardware developers, and the Windows developer community. Pete is also the current chair of the Executive Board of the MIDI Association. He first got into programming and electronic music by working with sprites and the SID chip using BASIC on the Commodore 64 in 6th and 7th grade, and ...

More about author

0 comments