Conflictuous devices name.
Closed this issue · 9 comments
Hello :)
After an upgrade of portmidi v236 (from mixxx/portmidi repository), to v2.0.2 from this repository (used in the mixxx software), I'm not able to distinguish both of my Denon SC3900 decks plugged in via USB and connected via MIDI to my laptop.
The devices are reported via the same name (SC3900 MIDI 1), but since the upgrade, only one device is reported. I opened a bug on mixxx's launchpad containing some investigations, which lead me to the conclusion that the bug is related to portmidi.
I suspect this part of the lib to be the cause (compared to the code of the former repository).
Do you have some more explanations about how virtual devices are supposed to be handled ? Am I wrong about my hypothesis ?
Thank you for your help.
I didn't know it was possible to have two devices with the same name. The code that changed is supposed to prevent opening a virtual device with the same name as an existing virtual device. This might be just a PortMidi restriction, but it seems reasonable to require applications to give devices different names. I will change the code so that you can add external devices even when they have the same name as an already added device. The ugly case will be that if you create a virtual SC3900 MIDI 1 device, and then plug in a physical SC3900 MIDI 1 device, the new device will be admitted, so you can still end up with a virtual name conflicting with a hardware name. Or for that matter, if another app creates another virtual SC3900 MIDI 1 device, that device will be recognized too, so you'll end up with a virtual name created in PortMidi conflicting with a virtual name created elsewhere. Thanks for identifying the responsible code.
Thank you for your quick answer :)
Just wanted to confirm that commenting the return statement about virt devices names conflict "solves" my issue (i.e. I'm able to see both devices reported by portmidi when this line is commented).
This confirms that the issue is related to this part of the code.
Maybe it could be worth to consider the device hardware card in PmDeviceInfo struct ? In order to help differentiate devices with similar names.
I guess virtual devices would have no hw card (or at least the is_virtual flag would be set to TRUE on their PmDeviceInfo).
ALSA reports the hw card number :
$ amidi -l
Dir Device Name
IO hw:2,0,0 SC3900 MIDI 1
IO hw:3,0,0 SC3900 MIDI 1but I don't know about other sound libraries on other platforms ^^.
Can you let me know if the latest changes solve your problem? I don't have 2 identical devices, so testing is difficult. The main objective was to prevent the creation of a virtual port that could "fake" or "shadow" an existing hardware device or even some other application's virtual port, and that feature is preserved (although it may be possible for two applications to create same-named virtual devices if they both complete Pm_Initialize first, and THEN create virtual devices. Oh well.) Another issue is should PortMidi try to distinguish devices with matching names, e.g. by appending "hw:2,0,0" or something. I think the names are the intended representation for end users, so they'll just have to deal with it.
If this all seems to work, I think I should make a 2.0.3 release.
Hello,
Yes, with your latest changes, I'm able to see both of my devices reported by portmidi, thank you !
Another issue is should PortMidi try to distinguish devices with matching names, e.g. by appending "hw:2,0,0" or something. I think the names are the intended representation for end users, so they'll just have to deal with it.
Better let the names as is IMHO, and not try to concat anything else to it. It would be nice to add the hardware card to the PmDeviceInfo struct, and then it would be the responsibility of the app using portmidi to apply its own logic IMHO, in case of multiple devices with similar names.
In the meantime, I'm OK with a 2.0.3 release with this fix, if you don't have any objections ^^
Great, and thanks. I'm trying to find time to make a release and expect to do it soon.
Thank you for the release !
I'm closing the issue as my problem has now been fixed by using the new release in flathub/org.mixxx.Mixxx#42 :)