Experimental support for the Windows Runtime MIDI API


I’d certainly consider it, but there was a motivation for choosing 256 that I’ve since forgotten.

Does everything work as expected for you if you change it?


Sorry, edited message instead of replying. 64k works well, also every other 2^N size below that, run a lot of tests.


OK, I’ll revisit this tomorrow and see if I can work out why I picked 256.






We have been testing the new API using a connected Bluetooth LE device. We have noticed that when we send MIDI Sysex messages to a Bluetooth LE device only part of the message arrives at the receiver, e.g. if we send a short four byte message only the first two bytes are received.

Have you guys discovered any work arounds for this problem? The only work around that we have come up with is to use the Windows Bluetooth SDKs directly…


We’ve not found anything better than that.

However, there is some related good news on the horizon - Microsoft appear to have fixed this issue in their latest developer preview, which means it’s likely this will be fixed in the next major release. Once that’s verified we’ll investigate enabling the new MIDI API by default for new Windows versions.


Hi, what’s the current status on this? Am I correct in thinking that this will also provide multi-client access to a MIDI port? thx


Microsoft were told about the SysEx hanging problem in 2015. They are also aware of the device enumeration problem. In their forums, they say they’re working on it. I have to wonder what takes three years to fix two crippling problems.


Their attitude to MIDI is perplexing to say the least. I can’t believe that we still need things like loopmidi to create virtual MIDI ports also.


There has been some progress on the BLE issues here.

As of the latest Windows update, short sysex messages can now be transmitted!

Device enumeration is still a problem - at the moment devices are always listed as available once they’ve been paired. However, there is hope; the next round of Windows Insider builds should contain a fix for this and some more general stability improvements.

If all goes well the next big Windows update, coming “in the fall”, could be the one where we can switch over.


thx for the update. do you know if this will include multi-client access to MIDI ports (ala OSX?)


Yes. This should include multi-client access.


Great stuff. I wonder if there’s any way to get MS to consider adding virtual MIDI drivers at some point? Don’t suppose you happen to know if this is on the road map at all?



Unfortunately it turns out that when Microsoft addressed the BLE issues they also removed the multi-client abilities from the new API.

Their reasoning was that their early adopters of the new functionality were interested in transmitting lots of MIDI data as fast as possible and doing this in a multi-client way slowed things down a little, so they removed that capability. It’ll be at least a release or two before before this can be readdressed.

At ROLI we’ve multiplexed heavy MIDI streams on $2 microcontrollers without any trouble, so this is pretty surprising.


Wow, that is surprising. If I worked for Microsoft MIDI I’d be pretty embarrassed about this.


I realize that the rollout of Windows 10 version 1809 has been put on hold for now, but I successfully upgraded the moment the rollout started. I was not affected by the “known folder redirection” issue.
I am pleased to announce that the SysEx hanging problem appears to have been fixed. My UWP apps that rely on sending SysEx requests to get SysEx responses is now working for all SysEx message sizes.
I am anxious to see if anyone can verify this on their systems. Hopefully 1809 will be available again soon.


Hi All.

Sorry about the long delay with getting the BLE issues fixed. BLE MIDI was introduced with the Anniversary update in summer 2016. We fixed most of the bugs last year and then the SysEx one in the spring release. The sysex one was just a dumb bug and is fixed. But yes, the connected status one took a bit because it involved a fair bit of work with the (non-MIDI) BLE team. Low Energy devices aren’t really persistently “connected” like other types of Bluetooth, so some funkiness had to be done in the 1809 release. I’ve talked with T0m (who has been really good with feedback on these issues, thanks!) so everyone should be in sync now.

Multi-client was lost in a patch before we added BLE because a few partners (DJ apps, mostly) were unhappy with performance when sending large amounts of MIDI data (they used the pitch bend messages for things like scratching). The runtime broker we use for sharing between UWP apps was easy to implement, but does have a performance hit for anything that is especially spammy. It sends messages across process boundaries. FWIW, the black MIDI enthusiasts were sending me mail about the perf hit as well.

I was super disappointed to see that go, and want it back. The best way to show a desire to get that back is to add an item to the Feedback Hub App asking for multi-client MIDI to come back (but with better performance), and get your fellow developers and users to vote it up. I don’t currently see a multiclient MIDI feedback item in the hub. It may seem silly, but the feedback hub items go into our database, and have the right visibility for the leadership making decisions.

In any case, I’ll continue to champion for that, but as it is a fair bit of work to implement (we’d have to use a very different approach vs what we had before), having user/developer requests for it in the system really helps when making the case.

Hopefully I’ll see some of you at the ADC. I’ll be there to learn, answer questions, take notes, etc.



As of the very latest version of Windows 10 (1809, October 2018 Update), which contains the BLE fixes, JUCE support for the WinRT MIDI API is no longer “experimental”:


Just a heads-up for Windows MIDI devs. The october 2018 update is available again.