You can find the code that JUCE uses to determine the port name here:
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:
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.