Port uniqueness

[mat1jaczyyy]

Stumbled upon this problem. I need to support a use case where two identical MIDI controllers are connected to my application. The port names are the exact same in RtMidi.Core, however I see other applications appending a number to the port name where necessary. This leaves me unable to differentiate between the two ports, and while they both show up because of that I can only talk to one of these at a time.

Trying to implement this number appending on my side, while debugging I noticed a port id hidden in the private vars of MidiDeviceInfo, I could well use it by adding it to the name and ensure the ports are unique. I was gonna submit a PR which adds a get property for the id, however I found this instead:

https://github.com/micdah/RtMidi.Core/blob/b076b5751dd3414cd6e470e28ebe5371e68ad7a0/RtMidi.Core/Unmanaged/Devices/Infos/RtMidiDeviceInfo.cs#L11-L14

It seems you're already stripping the number out when RtMidi provides it? You mention RtMidi may add it, I assume it does this only in cases when a port with the same name exists already? If so, I think this code could be simplified and you should simply use the name provided by RtMidi. If not, you could write some code that checks if a port with the same name already exists, and if it does keep the number or replace it with our own number.

Unsure how to proceed myself on implementing this, would love to hear what you think is the best course of action for resolving this issue. Thanks

[mat1jaczyyy]

Here are a few screenshots to help better describe the problem:

I can only differentiate by name, but the names are the same.

[mat1jaczyyy]

@micdah ?

[mat1jaczyyy]

RtMidi adds port number on Windows to "ensure uniqueness".

While it does succeed in ensuring it, disconnecting/reconnecting devices will change other devices' port numbers, so now it's impossible to tell who's who.

Additionally, on Windows, Microsoft GS Wavetable Synth is always assigned port number 0, so device in/out port names will always mismatch. On macOS they at least match, but the issue above remains unsolved.

It seems to go all the way to the OS' APIs, but Ableton Live somehow solved this... libusb?

https://github.com/micdah/rtmidi/blob/473ddc10aafd935d6d5d16e8876a566aa7c55a20/RtMidi.cpp#L2638-L2643

99% sure this is unsolvable but I'm leaving it here.

[micdah]

@mat1jaczyyy Would it help to expose the port number as provided by the underlying rtmidi library, in the IMidiDeviceInfo and implementing interfaces?

As you mention we do have this information available - it's just not exposed.

I would prefer leaving the names "clean" and adding the Port property to device infos - consumer applications could format a display name based on this, for better presentation if needed.

[mat1jaczyyy]

the Port isn't unique either, since it merely represents the "index" of a connected midi port. say there are 3 devices 0,1,2 and device 1 disconnects, device 2 will now become device 1 to rtmidi.

[micdah]

the Port isn't unique either, since it merely represents the "index" of a connected midi port. say there are 3 devices 0,1,2 and device 1 disconnects, device 2 will now become device 1 to rtmidi.

I see, well that of course makes it yes usefull.

Seeing with what we are given by rtmidi i don't see any good way to fix this issue.

We would need lower level support to present us with a more stable identifier, which is cross-platform applicable - or at least one that could be provided by all platforms, not necessarily the same between platforms.

But from a RtMidi.Core perspective, I don't see much more we can do.

[mat1jaczyyy]

@micdah haven't you already modified rtmidi to fit RtMidi.Core's needs? is there anything available in each platform's native API that we could expose to rtmidi, subsequently to RtMidi.Core?

[micdah]

I think the same issue has propped up here, but with a suggested solution tested on mac and Windows: https://github.com/micdah/RtMidi.Core/issues/30

Sounds like if we make the change suggested, it should work on both mac and Windows, sounds very much like the same thing we are seeing here