WinRT MIDI Output wrong device names

I’ve noticed a problem with MIDI output device naming, only on Windows and with WinRT enabled.

This is the detected input devices :

And this is the detected output devices :

“MIDI” and “MIDI-2” should show “Cool” and “loopMIDI Port”.

When disabling WinRT, this works just fine, output devics are shown the right way, without any change in the code.

This is a Microsoft problem. Unfortunately there is nothing that Juce can do about it.
This was brought to Microsoft’s attention years ago, but to date has not been fixed. They eventually fixed the SysEx problem, but not the device name problem. :frowning:

Thanks for the update, this is such a shame… Well I’ll just disable WinRT until this is in a better shape, this just feels like a shitty bug from the user perspective, and nothing I can do about it so…

Some update, I’m very curious because the software MIDIBerry is able to list the good names in the MIDI outputs… does someone know how they manage it ?

EDIT : From MIDIBerry description " Windows 10 does not report the port name correctly, so we analyzed it independently"
That may be the best outcome for now to implement in JUCE, since Windows will likely not move a finger on this one…

1 Like

Following up on this unresolved problem…
This is the WINRT_LOG from Juce using 2 loopMidi ports (“loopMIDI Port” and “DrumLoopback”) the 2 “MIDI” devices are the outputs detected by JUCE that correspond to the 2 loopMidi ports.

Detected MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A388.P_0000#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}
Adding MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A388.P_0000#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814} {00000000-0000-0000-FFFF-FFFFFFFFFFFF} MIDI
Detected MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A389.P_0004#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}
Adding MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A389.P_0004#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b} {00000000-0000-0000-FFFF-FFFFFFFFFFFF} loopMIDI Port [1]
Detected MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A388.P_0004#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}
Adding MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A388.P_0004#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b} {00000000-0000-0000-FFFF-FFFFFFFFFFFF} DrumLoopback [1]
Detected MIDI device: \\?\SWD#MMDEVAPI#MicrosoftGSWavetableSynth#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}
Adding MIDI device: \\?\SWD#MMDEVAPI#MicrosoftGSWavetableSynth#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814} {00000000-0000-0000-FFFF-FFFFFFFFFFFF} Microsoft GS Wavetable Synth
OSC Remote Control::Now receiving on port : 42000
Detected MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A389.P_0000#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}
Adding MIDI device: \\?\SWD#MMDEVAPI#MIDII_0AB1A389.P_0000#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814} {00000000-0000-0000-FFFF-FFFFFFFFFFFF} MIDI

We can see that there is a way to match input devices and output devices, they have the same path except for P_0000 for output and P_0004 for input. their id next to it (I don’t know what it is but it’s not the device info apparently) are different between input and output, but the same for all loopMIDI ports, even after restarting loopMidi.

Unfortunately the only info we get from Juce’s MidiDeviceInfo class is the deviceInfo property {00000000-0000-0000-FFFF-FFFFFFFFFFFF} and the name MIDI so there is no way to differentiate any of the loop midi devices if there are more than one.

There seems that the order of detection is not predictable, and everything happens multithread, which does not facilitate the task, but I guess if somehow we can first look for inputs and then outputs, and if the output is weird or with some recognizable pattern, then we can fetch the name from the input device ? That would at least make it readable for users, and definitely not waiting for Microsoft to deal with this sh*t…