WinRT MIDI stack name handling flaw. WinRT MIDI stack is presently unusable.

[Noemata]

The WinRT MIDI stack appears to have a serious name handling flaw that manifests a number of issues.

Here are a few examples of enumerated device names:

Oxygen 25 [0]
Oxygen 25 [1]
A-01 [0]
A-01 [1]
Launchpad S [0]
Launchpad S [1]
QUAD-CAPTURE (1)
Boutique (1)

The device names that end in [0] are for output, and the device names that end in [1] are for input.

The device names above that end in (1) are for input and output, yes, that little detail is also problematic.

But it gets worse.  Any device that has a consolidated name for input and output, that is, it does not have a [0]/[1] ending to its name, those ending in (1) above, hang the MIDI stack when any given SysEx message is sent to its output port.  The GUI of the associated App also becomes frozen.

I'm speculating; the lock up is probably due to the fact that the MIDI stack has confused itself as to where to send the output due to this naming inconsistency.  So devices that have a consolidated name for input and output hang the MIDI stack when a SysEx message is sent, and the only method of recovery is to sign out or restart.  Closing the UWP apps process does not clear the problem.  Closing an app should always clear up any such problems and not result in a hung IO stack.

Device names should either always be consolidated, that is, there should never be a [0]/[1] ending to the name, or they should always have the separation.

So at present, the WinRT MIDI stack is unusable because of the lock up when sending SysEx messages to devices that have a consolidated name.

Looks like Microsoft needs to have a better testing regiment here.  If Microsoft chooses not to fix the naming issue, that's fine, we can work around the inconsistency.  But the MIDI driver layer has to work with the naming variations correctly.

This problem needs to be resolved ASAP!!!

[Noemata]

And we wait, and wait and wait (really pathetic Pete) ...

[Noemata]

Still waiting … over 1 year after this problem was raised with the man that supposedly handles such things! Message is clear, stick to the Win32 API or move to another platform.

[Noemata]

Oh, and the silence is deafening, which is more than a little weird from a company the size of Microsoft.

[tommai78101]

You might want to try this instead.

https://devblogs.microsoft.com/pax-media/how-to-report-ble-midi-connection-or-communication-issues-in-windows-10/

And send your feedback straight to the Feedback Hub, under the Bluetooth MIDI category.

There is a period of time in between 2018 and 2019 where there's a transitional shift to consolidate everyone's feedback in general into one place.

[Noemata]

I've given up on trying to address Windows issues in general, and UWP problems in particular. Although there are a few very decent folks at Microsoft that strive to improve company products and provide good service to customers, there seem to be an equal number of folks that are the opposite. Often the sum is 0. Not something you want to hang your hat on. I got burned by Silverlight, and now round 2 with UWP. I've gotten the hint.