MidiOutput::getAvailableDevices() gives inconveniently ordered and named lists

[Kraku]

The following happens at least on Windows 10 & 11 JUCE builds:

juce::MidiOutput::getAvailableDevices() (and juce::MidiInput version also) gives MIDI I/O device lists in fully sorted order, which by default gives jumbled up results.

Here’s a screenshot from AudioPluginHost:

Notice especially “MIDIOUTxx (iConnectMIDI4+)” output devices how they’re in very inconvenient order. They should be in ascending order like in other DAW software instead of starting from number 10. Now the user needs to spend lots of time desciphering and hunting for the correct MIDI device from the list.

Is there a way to get that list in more convenient order? Here is for comparison what Ableton Live shows for the same MIDI output devices. The names stay consistent, instead of changing from “iConnectMIDI4+” to “MIDIOUT10 (iConnectMIDI4+)” and they’re shown in logical order.

[jrlanglois]

You could approach the issue by sorting the array of MidiDeviceInfo yourself using a comparator, specifically where you compare name instances using juce::String::compareNatural.

See juce::Array::sort.

[Kraku]

The only available data MidiDeviceInfo has is “name” and “identifier”. And the name is the one that’s shown in the list which you can see in the screenshot I provided. So it’s already unrepairable.

[asimilon]

Could you not repair the names returned first and then sort?

Loop over the names, if you find brackets then rename it to what’s in the brackets and use the number from MIDIOUT<x> to write (Port <x>) after it.

Something like (untested):

auto devices = juce::MidiOutput::getAvailableDevices();
for(auto& device : devices)
{
    if(device.name.contains("(")
    {
        auto deviceName = device.name.fromFirstOccurrenceOf("(", false, false).upToLastOccurrenceOf(")", false, false);
        auto portNumber = device.name.fromFirstOccurrenceOf("MIDIOUT", false, false).upToFirstOccurrenceOf(" ", false, false);
        device.name = deviceName + " (Port " + portNumber + ")";
    }
}
// now sort the devices on .name, exercise for the reader...

[reuk]

You can find the code that JUCE uses to determine the port name here:

modules/juce_audio_devices/native/juce_Midi_windows.cpp

If you trace it through, you’ll see that we’re just calling midiOutGetDevCaps(), and then using the szPname of the device that’s reported by the OS, so JUCE is surfacing the information provided by the OS with minimal changes.

I’m not sure what Live is doing. Maybe it’s using the old Win32 API and then reformatting the names manually, or maybe it’s using the newer WinRT API. You can enable this newer API by setting the preprocessor definition JUCE_USE_WINRT_MIDI=1 in your project, to see whether it makes a difference. With the devices I have available for testing, I see slightly more reasonable naming after enabling the WinRT MIDI backend.

I think that, at this point, we’re unlikely to make changes to port names when using the Win32 API. User code may be using names instead of identifiers to differentiate between devices, so this change could be somewhat disruptive for existing projects.

It’s worth keeping in mind that Microsoft is currently in the process of rolling out an entirely new MIDI implementation that provides improved device metadata, native MIDI 2.0, virtual app-to-app connections, and lots of other new features. This new API provides device information in a way that’s easier to group/sort. JUCE already supports the new API - take a look at this thread for details:

MIDI 2.0 Preview Branch

Sorry, I missed your comment previously! MidiMessage isn’t going to see any changes, it’s always going to represent a MIDI 1.0 bytestream message. If you want to send/receive bytestream messages through ump::Input or ump::Output, you’re responsible for converting between UMP and bytestream representations on either side. JUCE includes some mechanisms to assist: there’s GenericUMPConverter for conversion from bytestream to UMP-formatted MIDI 1.0 or MIDI 2.0; to go in the other direction, you ca…

You can use the functions in ump::Endpoints to enumerate the connected MIDI devices and determine their capabilities, ports etc. If the new Windows MIDI Services are available, then you’ll get detailed results that include MIDI 2.0 devices. Otherwise, this API will present individual MIDI 1.0 ports represented as separate UMP endpoints.

[Kraku]

@asimilon

auto devices = juce::MidiOutput::getAvailableDevices();
for(auto& device : devices)
{
    if(device.name.contains("(")
    {
        auto deviceName = device.name.fromFirstOccurrenceOf("(", false, false).upToLastOccurrenceOf(")", false, false);
        auto portNumber = device.name.fromFirstOccurrenceOf("MIDIOUT", false, false).upToFirstOccurrenceOf(" ", false, false);
        device.name = deviceName + " (Port " + portNumber + ")";
    }
}
// now sort the devices on .name, exercise for the reader...

I think I’ll take this route and when the MIDI 2.0 support is available in JUCE I’ll switch to that.