MIDI Enhancements in Windows 10

As Windows 10 evolves, we are continuing to build in support for musician-focused technologies.

Let’s take a look at MIDI. Windows has had built-in MIDI support going back to the 16-bit days. Since then, most MIDI interfaces have moved to USB and our in-box support has kept pace, with a class driver and APIs that support those new interfaces.

Those unfamiliar with music technology may think of MIDI as just .mid music files. But that’s only a tiny part of what MIDI really is. Since its standardization in 1983, MIDI has remained the most used and arguably most important communications protocol in music production. It’s used for everything from controlling synthesizers and sequencers and changing patches for set lists, to synchronizing mixers and even switching cameras on podcasts using a MIDI control surface. Even the Arduino Firmata protocol is based on MIDI.

In this post, we’ll talk about several new things we’ve created to make MIDI even more useful in your apps:

UWP MIDI Basics – using MIDI in Windows Store apps

New Bluetooth LE MIDI support in Windows 10 Anniversary Update

The Win32 wrapper for UWP MIDI (making the API accessible to desktop apps)

MIDI Helper libraries for C# and PowerShell

In addition, we included a number of audio-focused enhancements when Windows 10 was released last summer. These enhancements included: low-latency improvements to WASAPI, additional driver work with partners to opt-in to smaller buffers for lower latency on modern Windows 10 devices like Surface and phones like the 950/950xl; tweaks to enable raw audio processing without any latency-adding DSP; a new low-latency UWP Audio and effects API named AudioGraph; and, of course, a new UWP MIDI API.

We’ve also recently added support for spatial audio for immersive experiences. This past fall, in the 1511 update, we enabled very forward-looking OS support for Thunderbolt 3 Audio devices, to ensure we’re there when manufacturers begin creating these devices and their high performance audio drivers. Cumulatively, this was a lot of great work by Windows engineering, all targeting musicians and music creation apps.

UWP MIDI Basics

In Windows 10 RTM last year we introduced a new MIDI API, accessible to UWP Apps on virtually all Windows 10 devices, which provides a modern way to access these MIDI interfaces. We created this API to provide a high performance and flexible base upon which we can build support for new MIDI interfaces.

We originally put this API out for comment as a NuGet package in Windows 8.1 and received a lot of feedback from app developers. What you see in Windows 10 is a direct result of that feedback and our testing.

The API plugs in nicely with the device enumeration and watcher APIs in UWP, making it easy to detect hot plug/unplug of devices while your app is running.

Here’s a simple way to get a list of MIDI devices and their IDs, using C#:

Using a watcher for listing devices and handling add/remove is a best practice to follow in your apps. No one wants to restart their app just because they forgot to plug in or turn on their MIDI controller. Using the watcher makes it easy for your app to appropriately handle those additions/removals at runtime.

The API is simple to use, with strongly typed classes for all standard messages, as well as support for SysEx and buffer-based operations. This C# example shows how to open input and output ports, and respond to specific MIDI messages.

In most cases, you would inspect the type of the message, and then cast the IMidiMessage to one of the strongly-typed messages defined in the Windows.Devices.Midi namespace, such as MidiNoteOnMessage or MidiPitchBendChangeMessage. You’re not required to do this, however; you can always work from the raw data bytes if you prefer.

Just like the older MIDI APIs, the Windows 10 UWP MIDI API works well with third-party add-ons such as Tobias Erichsen’s great rtpMIDI driver, providing support for MIDI over wired and Wi-Fi networking.

One great feature of the new API is that it is multi-client. As long as all apps with the port open are using the Windows 10 UWP MIDI API and not the older Win32 MME or DirectMusic APIs, they can share the same device. This is something the older APIs don’t handle without custom drivers and was a common request from our partners and customers.

Finally, it’s important to note that the Windows 10 UWP MIDI API works with all recognized MIDI devices, whether they use class drivers or their own custom drivers. This includes many software-based MIDI utilities implemented as drivers on Windows 10.

New Bluetooth LE MIDI support in UWP MIDI

In addition to multi-client support and the improvements we’ve made in performance and stability, a good reason to use the Windows 10 UWP MIDI API is because of its support for new standards and transports.

Microsoft actively participates in the MIDI standards process and has representatives in the working groups. There are several of us inside Microsoft who participate directly in the creation, vetting and voting of standards for MIDI, and for audio in general.

One exciting and relatively new MIDI standard which has been quickly gaining popularity is Bluetooth LE MIDI. Microsoft voted to ratify the standard based upon the pioneering work that Apple did in this space; as a result, Apple, Microsoft and others are compatible with a standard that is seeing real traction in the musician community, and already has a number of compatible peripherals.

In Windows 10 Anniversary Edition, we’ve included in-box support for Bluetooth LE MIDI for any app using the Windows 10 UWP MIDI API.

In Windows 10 Anniversary Edition, we’ve included in-box support for Bluetooth LE MIDI for any app using the Windows 10 UWP MIDI API. This is an addition which requires no changes to your code, as the interface itself is simply another transparent transport surfaced by the MIDI API.

This type of MIDI interface uses the Bluetooth radio already in your PC, Phone, IoT device or other Windows 10 device to talk to Bluetooth MIDI peripherals such as keyboards, pedals and controllers. Currently the PC itself can’t be a peripheral, but we’re looking at that for the future. Although there are some great DIN MIDI to Bluetooth LE MIDI and similar adapters out there, no additional hardware is required for Bluetooth LE MIDI in Windows 10 as long as your PC has a Bluetooth LE capable radio available.

We know latency is important to musicians, so we made sure our implementation is competitive with other platforms. Of course, Bluetooth has higher latency than a wired USB connection, but that tradeoff can be worth it to eliminate the cable clutter.

When paired, the Bluetooth LE MIDI peripheral will show up as a MIDI device in the device explorer, and will be automatically included in the UWP MIDI device enumeration. This is completely transparent to your application.

We added this capability in Windows 10 Anniversary Edition as a direct result of partner and customer feedback. I’m really excited about Bluetooth LE MIDI in Windows 10 and the devices which can now be used on Windows 10.

Desktop application support for the UWP MIDI API

We know that the majority of musicians use desktop Win32 DAWs and utilities when making music. The UWP MIDI API is accessible to desktop applications, but we know that accessing UWP APIs from different languages and build environments can be challenging.

To help desktop app developers with the new API and to reduce friction, my colleague Dale Stammen on our WDG/PAX Spark team put together a Win32 wrapper for the Windows 10 UWP MIDI API.

The work our team does, including this API wrapper, is mostly partner-driven. That means that as a result of requests and feedback, we create things to enable partners to be successful on Windows. One of the partners we worked with when creating this is Cakewalk, makers of the popular SONAR desktop DAW application.

This is what their developers had to say about the Win32 wrapper for the UWP MIDI API, and our support for Bluetooth LE MIDI:

“We’re happy to see Microsoft supporting the Bluetooth MIDI spec and exposing it to Windows developers through a simplified API. Using the new Win32 wrapper for the UWP MIDI API, we were able to prototype Bluetooth MIDI support very quickly.
At Cakewalk we’re looking ahead to support wireless peripherals, so this is a very welcome addition from Microsoft.”

— Noel Borthwick, CTO, Cakewalk

We love working with great partners like Cakewalk, knowing that the result will directly benefit our mutual customers.

This Win32 wrapper makes it simple to use the API just like any flat Win32 API. It surfaces all the capabilities of the Windows 10 UWP MIDI API, and removes the requirement for your Win32 application to be UWP-aware. Additionally, there’s no requirement to use C++/CX or otherwise change your build tools and processes. Here’s a C++ Win32 console app example:

This API is optimized for working with existing Win32 applications, so we forgo strongly typed MIDI messages and work instead with byte arrays, just like Win32 music app developers are used to.

We’re still getting feedback from partners and developers on the API wrapper, and would love yours. You can find the source code on GitHub. We may change the location later, so the aka.ms link ( http://aka.ms/win10midiwin32 ) is the one you want to keep handy.

We’re already working with desktop app partners to incorporate into their applications this API using this wrapper, as well as other audio and user experience enhancements in Windows 10. If you have a desktop app targeting pro musicians and have questions, please contact me at @pete_brown on Twitter, or pete dot brown at Microsoft dot com.

MIDI Helper libraries for Windows Store apps

In addition to the Win32 API wrapper, we also have some smaller helper libraries for store app developers and PowerShell users.

The first is my Windows 10 UWP MIDI API helper, for C#, VB, and C++ Windows Store apps. This is designed to make it easier to enumerate MIDI devices, bind to the results in XAML and respond to any hot plug/unplug changes. It’s available both as source and as a compiled NuGet package.

It includes a watcher class with XAML-friendly bindable / observable collections for the device information instances.

RPN and NRPN Messages

Additionally, the helper library contains code to assist with RPN (Registered Parameter Number) and NRPN (Non-Registered Parameter Number) messages. These can be more challenging for new developers to work with because they are logical messages comprised of several different messages aggregated together, sent in succession.

Because we exposed the Windows.Devices.Midi.IMidiMessage interface in UWP, and the underlying MIDI output code sends whatever is in the buffer, creating strongly typed aggregate message classes was quite easy. When sending messages, you use these classes just like any other strongly typed MIDI message.

I’m investigating incorporating support for the proposed MPE (Multidimensional Polyphonic Expression), as well as for parsing and aggregating incoming RPN and NRPN messages. If these features would be useful to you in your own apps, please contact me and let me know.

MIDI Clock Generator

One other piece the library includes is a MIDI clock generator. If you need a MIDI clock generator (not for a sequencer control loop, but just to produce outgoing clock messages), the library contains an implementation that you will find useful. Here’s how you use it from C#:

My GitHub repo includes the C++/CX source and a C#/XAML client app. As an aside: This was my first C++/CX project. Although I still find C# easier for most tasks, I found C++ CX here quite approachable. If you’re a C# developer who has thought about using C++ CX, give it a whirl. You may find it more familiar than you expect!

This library will help developers follow best practices for MIDI apps in the Windows Store. Just like with desktop apps, if you’re building a musician-focused app here and have questions, please contact me at @pete_brown on Twitter, or pete dot brown at Microsoft dot com.

The second helper library is a set of PowerShell commands for using the Windows 10 UWP MIDI API. I’ve talked with individuals who are using this to automate scripting of MIDI updates to synchronize various mixers in a large installation and others who are using it as “glue” for translating messages between different devices. There’s a lot you can do with PowerShell in Windows 10, and now MIDI is part of that. The repo includes usage examples, so I won’t repeat that here.

Conclusion

I’m really excited about the work we continue to do in the audio space to help musicians and music app developers on Windows.

Altogether, the UWP MIDI API, the Win32 wrapper for the UWP MIDI API, and the helper libraries for Windows Store apps and for PowerShell scripting make it possible for apps and scripts to take advantage of the latest MIDI tech in Windows 10, including Bluetooth MIDI.

I’m really looking forward to the upcoming desktop and Windows Store apps which will support this API, and technologies like Bluetooth LE MIDI. And, as I mentioned above, please contact me directly if you’re building a pro musician-targeted app and need guidance or otherwise have questions.

The Windows team would love to hear your feedback. Please keep the feedback coming using our Windows Developer UserVoice site. If you have a direct bug, please use the Windows Feedback tool built directly into Windows 10.

Join the conversation

Please bring back true sound hardware acceleration like during the DirectSound3D days. =/
Soundcards used to be more than just DACs and Amps. With VR on the rise, audio immersion is a must and needs to stop being treated like a second class citizen. We’re missing out on wonderful things that used to be part of soundscapes that stuff like EAX allowed.

AudioGraph also has some built-in effects like delay and reverb, and a mechanism to enable you to create your own. From what I can remember, what we have in software today surpasses what EAX did in hardware over a decade ago.

I know it’s not quite the same as DirectSound3d, but I’m also not sure we need the type of hardware acceleration today we did in 1997. We’re already able to service very small buffer sizes with demanding audio tasks on fairly modest current day processors and the vast majority of people use on-board sound cards for games. I remember back when the computer store had an entire aisle of nothing but sound cards — something you don’t see these days. Where we do see external processing today is external USB, Thunderbolt, PCIe, or other sound cards for music creation.

It’s the latter place where I’m excited to see some interesting innovation. For example Universal Audio has externalized DSP for their music creation/editing plugins, doing the types of things you want, but for musicians, not gamers. In those scenarios, the processing load can be extremely heavy and so external DSP really helps the creator scale up what they’re trying to accomplish.

so since i’m developing in straight c++ on win32 api, i can ignore all this, right?

it’s just for UWP apps.

I notice that WASAPI breaks on a LOT more devices now. For example, the Focusrite Scarlett 2i4 which is a HUGELY popular bit of hardware. When I query it, it says it’ll support a minimum latency of 3 msec. So, ok, I start using 3 msec and get terrible grinding audio due to the card not being able to actually DO 3 msec latency. On win7 and 8, it behaved just fine. It COULD DO 3 msec latency audio. I checked how often my callback gets woken up. I told it 3 msec and it only wakes me up every 10. Thanks windows 10. You guys might want to fix that before working on UWP that no developer I’ve ever talked to (outside microsoft) wants to even touch…

As I explained above, the Win32 wrapper was built specifically to make it easier for straight win32 desktop apps to use the Windows 10 UWP MIDI API. So if you’re building a Win32 app, and you want it to light up on Windows 10 with features like Bluetooth MIDI, you would check the OS version, and then dynamically load the wrapper DLL and code to it. (There are other ways, but that is likely to be the most common). So no, please don’t ignore it. 🙂

WASAPI: Most people don’t get 3msec on USB devices even with straight ASIO drivers. A friend in Australia has put together a large table of real-world latency values and has them posted in a thread on http://gearsz.com in the latency measurement thread (I don’t have the numbers handy). I can get under 2ms round trip on my MOTU PCIe device, at 48k, using ASIO.

That said, I’d like to understand more about why it reports 3msec and can’t do it. I have a 2i2 for travel but haven’t taken any measurements off of it. Feel free to email me at the address above and I’ll include a couple of the audio folks on the team to see if we can figure out what’s up.

We’ve also added a bunch to Windows 10 to control latency. If you are using identical code to what you had in 7/8, you may be missing out on the small buffer support.

I’m quite surprised you were getting 3msec using WASAPI on 7 and 8. To the best of my recollection, even our internal buffers were larger than that, even in exclusive mode., and I’m just about positive our callbacks were slower than that.

which win32 apps are supporting the wrapper so that they can ‘light up’ in windows 10? I sonar shipping with the wrapper dll installed? or did you guys just prototype the interface expecting a release date in the future….

Cakewalk is the company that came to us with the suggestion. They built a prototype and will be working to get the feature into SONAR. I would expect them to be the first to have it in place. They are not yet shipping with this feature; any date is for them to announce.

I’ve talked with a number of other companies, but it’s up to them to share any progress.

This is a feature request we’ve had on the backlog for some time, but it has not yet made it to a locked or promised feature. I’d encourage you to make sure it’s on the uservoice site and voted up to try to show enough interest in this feature. http://wpdev.uservoice.com

Hi Pete,
Thanks for your reply. Good to know that it is there in the backlog. As you said I have created a feature request in wpdev.uservoice.com. I am not sure people who are interested will read uservoice and vote. Lets hope to get some vote.
Thanks,
Rakesh

The audio improvements are great: I can now use 192 KHz / 24 bit quality as default in Windows with my QuadCapture audio interface. Before the update, I don’t think I could even use 96 KHz with the Windows Mixer.

One feature I would love to see integrated in the Windows core audio is support for VST plugins, specifically VST effects plugins.

One on the immediate use of such support would be system-wide room correction with a room correction VST plugin.

First off, can’t resist, even though “Pete Brown called to say I can make it okay,” I’m having a little issue. Pete, do I just need PeteBrown.PowerShellMidi.dll in order to do midi device discovery? It does detect for me Microsoft GS Wavetable Synth as an output device but it does not detect any other I/O. I have an older Presonus Firestudio 16/16 which shows up fine as digital I/O and the MIDI port seems to be okay as older SysEx programs find my various devices on the bus just fine. I saw your post here and was immediately encouraged accuse I have an older synth (Roland GR-33) that only has a really old-school editor/librarian. I don’t have a problem using that prog for managing patches, but I would *love* a way to list the patches in the device quickly for planning purposes (i.e., lay them out in excel for setlists then program them back in using the legacy tool). But I can’t even discover the MIDI port using your PS example though other progs see it fine. Any clue what I may be doing wrong?

Now enough of my problems. What you’re doing here is AWESOME. The automation possibilities are pretty nifty. I can think of *so* many things I could do with this and say any generic cheap control surface and some Arduino devices throughout the house. Forget audio, home automation! Keep up the great work, Windows! BTW the VST suggestion is a great one – why is nobody voting it up?

You don’t need my library at all unless you want something to make it a little easier. Any MIDI device which shows up in Device Manager as a MIDI port should show up automatically using the API. Some of the older Roland synthesizers and controllers need a proprietary Roland driver to be installed before you can see their devices.

If you see the Roland device using a DAW or something like MIDI-OX, but not through this API, please do let me know.

Hi, I don’t know if this is the correct place to post. I just purchased a Yamaha MD-BT01 and my Surface Book finds it and connects to it. I’m running windows 10 Anniversary edition. I have a Yamaha Disklavier piano with the MD-BT01 hooked up to the midi port. I’m trying to use a program called Playground Sessions and my keyboard won’t show up. This setup works in an app call Flowkey without issue. Is there a way to get it to work in Playground Sessions? Do the developers of Playground Sessions software need to change something or add the new windows 10 Bluetooth LE api? (not sure if I said that right as I’m not a software developer). I’d much rather use my Surface Book screen as it’s much larger than my iPad (which does connect). I appreciate any insight you could give.

Yes, the application partner needs to use the MIDI API we introduced last year with Windows 10. Once they have that implemented, they get Bluetooth MIDI automatically. We created the wrapper described in this post specifically to help make it really easy for partners like this to use the new API. What most companies are waiting for is their user base to ask them to do the work. So feel free to ask them and point them to this post and the wrapper we created.

I am having multiple Roland devices (GR-30, SH-201 and GS-10) – none of which connects either through usb audio or MIDI with windows 10 pcs due to the use of their proprietary drivers that they refuse to update for Windows 10. I have tried backward compatibility and all possible connection modes with no success. The only way I can use these as usb audio interfaces or as MIDI devices is by connecting them to either windows 7 or windows vista or windows xp (They don’t even work with windows 8.1). Can Microsoft do something about such situations that makes these hardware completely useless for recording? I have upgraded all my new devices to windows 10 except a very old Dell laptop that runs Windows XP. That is the only device that I can use to connect these instruments. I do upgrade my hardware and in fact have a newer Boss sy-300 (their latest guitar synth) which works with windows 10. But it does not give me the sounds and connectivity choices that I can get with a GR-30 or a SH-201. Even with heavy investments and upgrades, it is frustrating to find these instruments rendered useless with no mistakes from the side of the consumer.

Hi
Some manufacturers choose to have their own custom drivers rather than use class drivers. In some cases, that’s because they were wanted to support things like multi-client use of the driver. We’ve addressed those concerns in the new API, but that only matters if everyone uses it. Some other controllers and instruments have a way to flip between a class-compliant mode (which works on all modern operating systems) and the proprietary mode.

Although we do talk to manufacturers, we do not have any way to modify their drivers or code. If they provide custom drivers, it’s entirely up to them to keep them up to date with later operating systems versions. However, there are some unsupported workarounds on the web which may work for you. This is one:

Please note that that work around is neither supported nor endorsed by Microsoft or Roland, and could potentially result in instability or other problems. However, as a last resort, it may get you past the problem and back to using your hardware. (Note that the video comments also have some additional steps.)

This API is optimized for real-time MIDI input and output, and designed for flexibility to support new transports like Bluetooth.
It does not include built-in MIDI file playback. However, there are other third-party solutions and source code you may use for that if you want that in your app.

>> This API is optimized for real-time MIDI input and output…
But Windows isn’t a real-time OS. Please provide more detail. What would be necessary to make a sequencer from this framework with sub-2ms latency? DirectMusic provided functionality for that task, but I can’t see it in here from what you’ve written. Without sequencing ability, what good is this except for crude control?
Thanks!

Hi. Anyone know of a workaround for getting a BT device to work with MuseScore? I just got the Yamaha MD BT01, it seems to be active on my Yamaha piano (an older model so I was a little concerned about the plugs being powered), it pairs with my Windows 10 computer fine (and I verified it has been updated to Anniversary edition). But it then only appears as a Bluetooth device, not appearing as a connected device on that Settings page.

Additionally, my installation of MuseScore only has the following in an “API” dropdown list on the preferences page: MME
Windows DirectSound
ASIO
skeleton implementation

I’m not sure if anyone has already developed a work around or if I’m just out of luck until developers there add the newer Windows API.

Hi everybody,
I’m having timing problems controling my old external synths/samplers with midi via my Midi USB interfaces (esi m8u xl, steinberg midex8, midisport 2×2…) and Cubase. When I record the audio from my gears (while playing quantized midi tracks), its not perfect and totally tight. The best I can can have is between 0.1 and 0.5 ms differences on my audio tracks (which is okay for me), but when I restart cubase and record to audio the same midi track again (it might be 4ms later or before).

I’ve read a lot about it (usb interfaces..) and tried lots of things with DirectMusic, WindowsMidi, cubase timestamps options, disable internet and antivirus, plenty of settings on cubase… I made at least 100tests and still can’t get something that is always tight (less than 0.5ms). I recently purchased a steinberg Midex8 that has LTB system, supposed to work verry well with Cubase, it’s the best result I have but still not perfect.

I’m on Win7 64b, sorry if i’m off topic, but I don’t see no solutions anymore. I need help from developpers and I was also wondering if Win10 would get better results on midi tightness.

Anthony, the built-in General MIDI synth has fairly high latency. We made some changes in Windows 10 early on to cut down the latency a bit, but it’s still higher than what you might get from a professional synthesizer.

We currently have no plans to change performance of the built-in GM synth for real-time play. It’s really for playback as opposed to performance.

Yes. We fixed a number of BLE-related issues in 1803. I know there are a couple of other small things we want to continue to monitor, but the SysEx size issue was found and fixed. There’s always the potential that we missed a configuration, or specific test case. If you are running 1803 and still see issues, please do let me know.

Great that this is progressing. I was able to do some testing and SysEx are now indeed working with Bluetooh MIDI interfaces.
However, the sad news is that it seems to be very flaky. I am using different apps in the appstore that allow me to bridge MIDI BLE into a loopMIDI interface so I can use other applications that are not aware of this new API. I have also created my own implementation with the sample code from GItHub. In all cases, most of the time the first SysEx message passes correctly, all consequent ones do not. This is true even not using Bluetooth at all. In my implementation I am using the raw data bytes. Basically I read them from the input port and pass them directly to the output port. Some other times it works more than once but can suddenly stop without any indication.

Could you please assist? Please contact me for more details.

Christian

note: An App that does this bridging would be super useful if Microsoft releases an official one.

The Artiphon Instrument 1 makes heavy use of MPE – same with Roli’s Seaboard and BLOCKs.

I notice there’s still a MidiInOpenPort() call. On MacOS and iOS, it’s possible for multiple apps to register and talk to the same MIDI device at the same time. This allows, for example, a setup app and a synth app to co-control the device. This is how the Instrument 1 handles realtime adjustments to the instrument’s behavior. They do make a Windows control app but then warns users that on Windows:

“When using the Artiphon INSTRUMENT 1 Editor the INSTRUMENT 1’s MIDI port is used by the INSTRUMENT 1 Editor and cannot be used by a third-party sound generator or music-making app like Ableton Live, Bitwig Studio, Cubase, etc.

In order to change your presets and try them out in a third-party music app you currently need to open the INSTRUMENT 1 Editor, make your customizations, and then exit before opening the third-party app. When the third-party app is open and you want to continue to customize your presets, you’ll need to quit before opening the INSTRUMENT 1 Editor.”

As you can imagine, frustrating for Windows users. Maybe the Windows MIDI Team (or you, if that’s the team 🙂 ) could aim for feature parity with MacOS/iOS as a goal. I know I find it annoying how the assumption is always ‘if it’s music – you MUST be using Apple’…

When we first released the Windows 10 MIDI API, it was multi-client, as long as all apps with the port open were using the new API (Once an app opened the port with the old API, it would lock out any others). It stayed that way through a couple releases of Windows 10 until we had a partner point out that there was a performance hit to their app (which would send massive amounts of MIDI data). We decided to make it single-client to eliminate the performance hit.

We’re continuing to look at this over time. However, it will only make sense to do the engineering to make multi-client happen if the big applications that have the ports open are also using the new API.