WinRT output devices from loopMIDI wrong output names

[benkuper]

The issue has already been discussed here : https://forum.juce.com/t/winrt-midi-output-wrong-device-names/43301 but I figured there may be better activity here...

Yes, we know that Microsoft won't do anything for that, so I guess it's a matter of fixing this ourselves. Many softwares are successfully using WinRT and displaying good names. I've tried contacting and asking them how, but no answers yet. Resolume is using JUCE and has good display names, though I don't know if they use WinRT.

It may be an issue specific to loopMidi, but loopMidi is widely used and a lot of users see this issue as a bug from the software itself, they don't really care or even have a way to know where it comes from.

I think there is some possible workaround to do by detecting a wrong name / deviceInfo in juce_Win32_Midi addDevice function; Especially since loopMidi has a specific, unique path, and only the output is badly named, there is a way to grab the name from the input I think. I could try and do it but I'm sure it won't fit JUCE's practices. So if anyone has info or will to get on that, it would help a lot of developers AND users.

Thank you very much

[benkuper]

Following the research, the non-WinRT version seems to detect BLE devices, but can't open them... Is there maybe something to do by just handling opening BLE devices with the WINRT part, and keep the rest with the WinMM stack ?

[afestini]

Since the issue is still open years later, I guess I'll post it here too.

The name isn't wrong. The port name is exactly what is returned. You want the device name. If you examine the device in your device manager, you can see the hierarchy of "device container" including one or more "devices", which contain one or more "ports".

You have to get the container id from port properties, create the info for that and you got the top level name. Assuming that port is the DeviceInformation of the port (from a watcher or enumerating)

const auto container_id = port.Properties().Lookup(L"System.Devices.ContainerId").as<winrt::guid>();
const auto device = DeviceInformation::CreateFromIdAsync(to_hstring(container_id), {}, DeviceInformationKind::DeviceContainer).get();
const auto device_name = to_string(device.Name());

[tpoole]

Ultimately this is a limitation of the API itself.

We're currently working on a new, MIDI 2.0, implementation, where the problem should be addressed.

[tazzit24]

Hi,

The original post was complaining about the virtual Loopback MIDI ports.

The above suggestion is working quite fine for physical MIDI devices and also for other virtual MIDI drivers (as Divisimate BOME Network).

So :

Divisimate Loopback => BomeMIDI: Divisimate Loopback (1) WIDI Master (Bluetooth MIDI OUT) => WIDI Master

But when you try to do the same for all your LoopMIDI ports (say I have two of them) or even the MS Synth, the device returned back by the "CreateFromIdAsync" method will be the name of your computer. So:

MIDI => MY-PC MIDI => MY-PC Microsoft GS Synth => MY-PC

=> even the Microsoft GS Synth will display its name by default. => but the two LoopMIDI ports (for instance named "LoopMIDI Synthesia" and "LoopMIDI Musescore") will display "MIDI" but nothing more.

This is because the container_id will return incomplete data for those virtual devices, such as :

Data1 = 0 Data2 = 0 Data3 = 0 Data4 = 0x000000b0c20...

For the other devices, Data1, Data2 and Data3 will return other values than 0.

I didn't use the JUCE framework for these tests; instead, I'm accessing the native Windows API directly (either in a standalone C++ project and in a UWP C# project) and the limitations are the same.

I agree this is not exclusively a Microsoft's issue (I'm unsure if LoopMIDI can provide better Windows integration), but since either the MidiInPort class and the old winmm.dll will display the configured name of the LoopMIDI out ports, the MidiOutPort class seems faulty too.

The Microsoft MIDI 2.0 project on Github and Discord sounds promising...

Regards.