I have been working on a small synthesizer for tesla coils, and have some issues with the USB Midi implementation.
I need to support multiple devices connected to the same PC, with each one having a nickname, that can be given to it with a configuration software.
I can successfully change the port names from the firmware, but as soon as I connect more than one, windows decides that they should all have the same names.
For example:
stick 1 is called "hello"
stick 2 is called "world"
-> when plugging in only stick 1 or stick 2 the midi ports have the correct names, but when connecting both, they are both shown as "hello" or "world".
The devices all have an individual USB serial number, and USBDevview, and the windows device manager shows them as having the correct names, but in any midi software the ports have the naming issue described above.
Is this a problem with my implementation, or because of windows foo?
I need to support multiple devices connected to the same PC, with each one having a nickname, that can be given to it with a configuration software.
I can successfully change the port names from the firmware, but as soon as I connect more than one, windows decides that they should all have the same names.
For example:
stick 1 is called "hello"
stick 2 is called "world"
-> when plugging in only stick 1 or stick 2 the midi ports have the correct names, but when connecting both, they are both shown as "hello" or "world".
The devices all have an individual USB serial number, and USBDevview, and the windows device manager shows them as having the correct names, but in any midi software the ports have the naming issue described above.
Is this a problem with my implementation, or because of windows foo?
Accepted Answer
0
Undo
Votes
VMPK never managed to open the second port at all, and always kept sending data to which ever one came first in the list. I assume because it opens midi devices by name.
DrumstickRT (Windows VMPK backends) enumerates the devices, and keeps in memory the number and name of each one as an associative array. The names are presented in VMPK as items in the MIDI Connections combo boxes, and the selected name is stored also in the configuration registry. When a device name is selected, the table of the enumerated devices is searched for a matching string, and if one is found the corresponding stored number is used to open the device.
The same problem has been detected in Linux ALSA backends when two devices are given exactly the same names. There is a ticket registered for this bug.
0
Undo
Votes
WinRT MIDI does have a problem enumerating MIDI devices correctly, but you might not be running afoul of it.
If you changed the name of one of the devices after it had already been attached to your computer, this might simply be a caching issue.
Plug both devices in, go to the Device Manager, right-click on each device and choose "Uninstall device".
Then click on the "Action" menu and "Scan for hardware changes" or remove the device and plug it in again.
If this doesn't help then it's possible you are bumping into the enumeration bug.
If you changed the name of one of the devices after it had already been attached to your computer, this might simply be a caching issue.
Plug both devices in, go to the Device Manager, right-click on each device and choose "Uninstall device".
Then click on the "Action" menu and "Scan for hardware changes" or remove the device and plug it in again.
If this doesn't help then it's possible you are bumping into the enumeration bug.
I have tried that before but it didn't work as expected either. The weird thing is though, that when I have the midi software open with only one device attached, and the plug in the other one while it is still open, they have the correct names (as reported by the individual synthesizers), but after restarting the software they don't anymore.
I also don't think it is a caching issue, as the names are displayed properly everywhere else.
I have also tried this with a number of programs (Anvil studio, FL studio, synthfont, vmpk and midi-ox) and they all have the same naming issues, so I do believe that the issue lies somewhere in the windows subsystem. Though VMPK never managed to open the second port at all, and always kept sending data to which ever one came first in the list. I assume because it opens midi devices by name.
I also don't think it is a caching issue, as the names are displayed properly everywhere else.
I have also tried this with a number of programs (Anvil studio, FL studio, synthfont, vmpk and midi-ox) and they all have the same naming issues, so I do believe that the issue lies somewhere in the windows subsystem. Though VMPK never managed to open the second port at all, and always kept sending data to which ever one came first in the list. I assume because it opens midi devices by name.
Accepted Answer
0
Undo
Votes
VMPK never managed to open the second port at all, and always kept sending data to which ever one came first in the list. I assume because it opens midi devices by name.
DrumstickRT (Windows VMPK backends) enumerates the devices, and keeps in memory the number and name of each one as an associative array. The names are presented in VMPK as items in the MIDI Connections combo boxes, and the selected name is stored also in the configuration registry. When a device name is selected, the table of the enumerated devices is searched for a matching string, and if one is found the corresponding stored number is used to open the device.
The same problem has been detected in Linux ALSA backends when two devices are given exactly the same names. There is a ticket registered for this bug.
- Page :
- 1
There are no replies made for this post yet.
