Windows 10 UWP MIDI API to enable MIDI over Bluetooth?

[bharris222]

Hi. I am a music hobbyist with no programming experience. The developer of certain music software that I am interested in purchasing (XotoPad 2) advised me that he uses the rtmidi library. When I inquired of this developer whether I would be able to use XotoPad 2 with MIDI over Bluetooth on a Windows 10 tablet, he indicated that the rtmidi library would need to be updated to use the Windows 10 UWP MIDI API. Can you please let me know if there are any plans to update the rtmidi library to use the Windows 10 UWP MIDI API to permit MIDI over Bluetooth, rather than the Windows Multimedia API that I understand rtmidi currently uses?

Thank you!

[radarsat1]

Not aware of any plans as such.

[radarsat1]

(ps., leaving this open in case anyone wants to contribute an implementation..)

[sagamusix]

In case it's a motivation for anyone to work on this: The new MIDI API also brings other improvements such as being able to open a MIDI port from more than one application at the same time.
This may also be helpful, a "flat" C interface for the new UWP MIDI interface: https://github.com/stammen/winrtmidi

[jcelerier]

hello, I've been working on a fork of RtMidi which starts to have some support for UWP MIDI if anyone's interested : https://github.com/jcelerier/RtMidi17/blob/master/rtmidi17/detail/winuwp.hpp (feel free to port it back to RtMidi proper)

[sagamusix]

Nice work on that fork! Personally I'd try putting all the UWP stuff into a separate DLL to support older OSes but this is definitely a great start.

[pthorod]

@jcelerier What a timing! I just started fiddling with C++/WinRT MIDI myself with the aim of using it as the windows implementation in a cross platform CMake based midi library. Nice work 👍

[jcelerier]

I would just like to note, for anyone wanting to use it that the implementation has a LOT of problems (on the windows internal side of things - even in plain UWP apps written in C# as can be found in the windows store).

• Naming of detected MIDI devices is fairly inconsistent and even less useful than the old MME naming
• Some devices are flat out not recognized - had this problem for some Keith McMillen BopPad - out of ten, between two and four would not be recognized by the UWP stack depending on the reboot. The MME API saw them all.
• In some cases, sending sysexes can lock the entire MIDI stack and even require a windows reboot.

see for instance :

• https://techcommunity.microsoft.com/t5/Windows-Insider-Program/When-will-Microsoft-fix-the-MIDI-API-MIDISPORT-4x4-and-UWP/td-p/110431
• https://social.msdn.microsoft.com/Forums/en-US/8575360e-2ab0-4de0-be95-04cf327d2871/midi-uwp-api-still-broken-stuck-in-twilight-zone-since-2014?forum=wpdevelop
• UWP MIDI SysEx request hangs App and entire MIDI stack. microsoft/Windows-universal-samples#639
• http://forum.cakewalk.com/UWP-MIDI-issues-with-windows-creator-update-m3673627.aspx
• http://forum.cakewalk.com/A-bug-with-UWP-midi-m3605788.aspx
• http://forum.cakewalk.com/UWP-MIDI-driver-disappointment-m3582994.aspx
• https://social.msdn.microsoft.com/Forums/windowsapps/en-US/c86a29fb-29f1-42b9-8dc7-946ac42db956/uwp-midi-bugs-sending-sysex-device-enumeration-bluetooth-polyphony?forum=wpdevelop

so unless you have an absolute need for it, I'd say, stay with MME, it just works better.

[sagamusix]

Fantastic job, Microsoft.

[marksyzm]

Does anyone know if the new UWP MIDI format supports making virtual ports? As that's an issue I was about to make

[symdeb]

@marksyzm - The UWP WIn32 API does not support that. (At least not using the Win32 wrapper)

Steinberg has enabled "Bluetooth" MIDI in Cubase 12. which is actually just UWP MIDI, and you can see the several warning that things may not work, and it's got nothing to do with "older" devices. (unless Microsoft/Steinberg points out the details why this is )

https://helpcenter.steinberg.de/hc/en-us/articles/4501438703122-WinRT-MIDI-and-Windows-Bluetooth-MIDI-support-in-Cubase-12

Cubase is probably using that WIN32 wrapper or an alternative coded inhouse one. I used the wrapper from Microsoft in a client to enable UWP MIDI. and bumped into issues. No matter the Microsoft wrapper or custom one, the key problem is not in the WIN32 but in the core of UWP. For example, UWP cannot handle multiple same hardware devices and upon plug/in out weird things happen. I cannot recall all the details, but I have the nitty gritty details and evidence of debugging somewhere . After that nightmare, dumped the whole UWP MIDI part. The developer of the wrapper at Microsoft informed the port naming issues are due to Microsoft's implementation of UWP and it would be up to the Microsoft developers to fix this. Mainly issues arise when you unplug or plug a device , not only Bluetooth, and you can read this between the lines in the Cubase 12 warnings as well .Sysex is another problems. I have the Bobpad (great features, terrible quality) and it does a lot of sysex. UWP MIDI has been broken from the start since Windows 10 came out. No evidence win11 is better - still have to try it. I informed the person who is supposed to lead all the MIDI/audio Windows stuff (you can find him easily on twitter or other social networks), but nothing happened. It seem no one can push the UWP team at Microsoft and musical stuff just does not have priority. It is ultimately frustrating. You can find several posts on Microsoft Forums as well about this topic that jcelerier pointed out. Nobody at the dev team at Microsoft cares or perhaps there isn't even a real solution. Probably nobody at Microsoft likes to read this, but well , we need to keep raising this flag.

A few more posts:
MicrosoftDocs/windows-dev-docs#1424
https://answers.microsoft.com/en-us/insider/forum/all/windows-10-uwp-win32-wrapper-virtual-midi-port/804a0727-2171-4e89-8d85-75a25f5b7c67

https://www.midi.org/midi-articles/midi-enhancements-in-windows-10
https://blogs.windows.com/windowsdeveloper/2016/09/21/midi-enhancements-in-windows-10/#gAqpA2ecH0Uym9ut.97

With MIDI 2.0 UMP coming, the question is really if Microsoft will revamp the whole UWP API (and finally fix this as well). Likely they have to if DAW's need to use MIDI 2.0 since it is unlikely Microsoft will change the Win32 API, and that should then go along with a well supported and stable Win32 wrapper. But now comes the worry, if the new UWP MIDI API only support UMP, the legacy MIDI issues may stay forever. Hopefully Bitwig or other DAW providers can push, but Steinberg seems to have given up and "adopted" the bugs

What really would be nice is that after 6 years to see a formal statement and reaction from Microsoft.
Until a fix, MIDI UWP is a prototype and we need to keep looking ahead .... :-) ..black hole..

And BTW, on Ubuntu BLE MIDI it is now starting to work pretty well - even with the BobPad.

There is a new SDK, WinAppSDK a.k.a Project Reunion)
https://github.com/microsoft/WindowsAppSDK
But there is nothing on this API here
https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md
https://docs.microsoft.com/en-us/windows/apps/develop/audio-video-camera
It seems it's main target is to use UWP UI functionality on win32 code.

For those who wish to play around with UWP MIDI API:
https://docs.microsoft.com/en-us/windows/uwp/audio-video-camera/midi
https://docs.microsoft.com/en-us/samples/microsoft/windows-universal-samples/midi/

For those who wish to use the UWP Win32 wrapper (requires Visual Studio 2015)
https://github.com/stammen/winrtmidi

[trueroad]

I'm implementing Windows UWP MIDI API to enable BLE MIDI (Bluetooth MIDI) in #299.
Currently, you can enumerate and get the names of UWP MIDI devices.
The following are not yet implemented.

• MIDI port open/close
• MIDI message input/output

Building requires: Visual Studio Community 2019

[marksyzm]

Very cool! I'm reviving a project soon so your timing is perfect :)