Multiple identical USB-MIDI inputs

[sandeep-ma]

Hi Tiago

It seems it will not allow two identical USB-MIDI keyboards to be used as inputs. at the same time. Soon as I drop one on the designer surface, both are greyed out.

This works in MIDI-OX and the primary reason I am using it (apart from for channel filtering)

Thanks

[tiagolr]

Ahhh very strange indeed, probably the program identifies the control surfaces by their name.....

May be difficult to solve, I'll see what I can do.

[sandeep-ma]

FYI, if it helps in figuring out a solution, this is how they are enumerated individually when running a powershell script that I was provided by an AI chatbot. Note that Windows created 3 for each instance ID:

2. InstanceId: SWD\MMDEVAPI\MIDII_66DE91EA.P_0000 FriendlyName: 3 - Keystation Pro 88 [0]
3. InstanceId: SWD\MMDEVAPI\MIDII_66DE91EA.P_0001 FriendlyName: 3 - Keystation Pro 88 [1]
4. InstanceId: SWD\MMDEVAPI\MIDII_66DE91EA.P_0002 FriendlyName: 3 - Keystation Pro 88 [2]
5. InstanceId: SWD\MMDEVAPI\MIDII_EA527A4C.P_0000 FriendlyName: 5 - Keystation Pro 88 [0]
6. InstanceId: SWD\MMDEVAPI\MIDII_EA527A4C.P_0001 FriendlyName: 5 - Keystation Pro 88 [1]
7. InstanceId: SWD\MMDEVAPI\MIDII_EA527A4C.P_0002 FriendlyName: 5 - Keystation Pro 88 [2]

[tiagolr]

Thanks, I'll get back to ask you if you can try out something soon, maybe a script like the one you used but using the library I run instead.

The main difficulty for me is that I don't have two identical controllers, but its a common use-case so really would like to fix this.

[tiagolr]

Hey, let me ask you a few things:

Do you have time to help debug this? I would only need you to run a couple of scripts to check if the problem is on the frontend or backend, if its on the frontend good news, I should be able to debug it from there, if its on the backend can be more complicated.

Are you on windows?

Are you techie? Can I send you a program to run or are you familiar with rust and can run cargo t yourself?

The program I'd ask you to test is this:

testtt.zip

It runs the backend tests against the Mididash core, with some luck the tests pass on your machine (please connect both MIDI devices before running).

Alternatively I can send you the source-code and you only need to run cargo -t to perform the same thing, in case you are concerned with viruses and whatnot.

Let me know if you have patience / time.

Thanks.

[tiagolr]

I am crossing fingers its Frontend only problem, it seems to be (both devices show correctly), let me know if you can help otherwise I'll try to improvise something that may or may not work.

[sandeep-ma]

Hi Tiago

Sure, I am willing to help. It would be nice if I could swap MIDI-OX with MidiDash since it looks so cool and modern. I am a techie but from the yester era. Never worked with Rust (in fact had never even heard of it). But yesterday I took it upon myself to install the compiler and with help from the AI chatbot, I built and ran an executable with this simple code in it:

main.rs.txt

That gave me these results:

I did not want to install builder components on my mixer PC, so I went for the executable builder. So I can run any source file you give... I will build it.

I am pretty sure the issue is in how windows enumerates MIDI devices and how midir is written. It is not really designed for Windows platform. To resolve it would probably require building a fork of midir that accesses the WinMM api's directly or additionally other uPnP APIs or the registry (like how the powershell script did).

I ran your exe and all tests passed.

Regards

[sandeep-ma]

Also, if you like... and see it worthwhile, I could attempt to put together a solution that provides overloads with some additional traits to the MidiInputPort and MidiOutputPort structs so that they will fetch the additional metadata from the underlying APIs that is required in windows to uniquely identify a midi device... something like that... but it would mean that the fork would only be for windows, I guess.

[tiagolr]

Brilliant, thanks!

I am digging into the problem I'll let you know if I have something that you can run that should help.

See the main issue is that the MIDI devices use the same exact name identifier, this may be tricky to solve as I use the midi devices names to make the connections and all.

From what you describe things kinda work, but with multiple devices with the same name, its likely that even if I don't disable them on the frontend when you add an instance, chances are that the connections will always be made to the first device with the name.

I'll keep looking into it, hopefully there should be something that separates unique devices.

Also, if you like... and see it worthwhile, I could attempt to put together a solution that provides overloads with some additional traits to the MidiInputPort and MidiOutputPort structs so that they will fetch the additional metadata from the underlying APIs that is required in windows to uniquely identify a midi device... something like that... but it would mean that the fork would only be for windows, I guess.

That may be useful, its not a clear easy solution, maybe there is something simpler, if you can manage that would be great but still requires some wiring on the App, and would only work on windows (fine by me but not ideal). I'll keep digging and let you know if I find something that can be used, what you propose may be the real solution though.

Thanks a lot.

[tiagolr]

So, in midir examples, there is also an id() to each port: https://github.com/Boddlnagg/midir/blob/master/examples/test_list_ports.rs

Maybe I should have used this instead of port name as identifier....
I'll still have to dig a bit more but seems likely, in which case I'll take a big refactor to make it work properly using IDs instead of port names.
I'll keep you updated, may take a few weeks...

[tiagolr]

To avoid refactor the whole app adding IDs + names, I may just concatenate the ID to the port_name as a suffix, and hide it on the frontend. This would make it much simpler to implement, think I'll go for something like this.

[tiagolr]

On closer inspection those IDs are not unique to the device itself:

\\?\usb#vid_0763&pid_3111&mi_00#7&1992d9d7&0&0000#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\global

Part	Meaning
\\?\	Windows “extended-length” device path prefix
usb#	USB device
vid_0763	Vendor ID (M-Audio)
pid_3111	Product ID (Keystation Mini 32 MK3)
mi_00	USB interface number
#7&1992d9d7&0&0000	System-assigned instance path
{6994ad04-93ef-11d0-a3cc-00a0c9223196}	MIDI device class GUID
\global	Global namespace

ChatGPT says DAWs use these IDs hashes + fallback logic, I'll still need to be clever about it.

[AtmanActive]

To avoid refactor the whole app adding IDs + names, I may just concatenate the ID to the port_name as a suffix, and hide it on the frontend. This would make it much simpler to implement, think I'll go for something like this.

Warning, this can lead to unexpected behaviour on windows. Even when there are no duplicate port names, windows STILL re-enumerates MIDI ports out of the blue for no apparent reason. One day, a port FOO is at index 1, next day at index 5, a week after at index 14, and so on. The only correct way seems to be to match exclusively per port name, but then, what to do with genuine duplicates like here, that's the question.

[sandeep-ma]

To avoid refactor the whole app adding IDs + names, I may just concatenate the ID to the port_name as a suffix, and hide it on the frontend. This would make it much simpler to implement, think I'll go for something like this.

Warning, this can lead to unexpected behaviour on windows. Even when there are no duplicate port names, windows STILL re-enumerates MIDI ports out of the blue for no apparent reason. One day, a port FOO is at index 1, next day at index 5, a week after at index 14, and so on. The only correct way seems to be to match exclusively per port name, but then, what to do with genuine duplicates like here, that's the question.

I hear you... but to be honest, this is not to do with windows really, the index is just a running serial number generated by rust, it is not coming from windows... and based on the bit of research I conducted, the 40 year old API was never updated by Microsoft and the index will change every time you reboot or turn devices on and off etc.

It is certainly a potential workaround to the duplicates issue, but not a solution... it will need to be updated every time you reboot or restart the devices.

On the other hand, finally, after some forty odd years, Microsoft has developed a new midi software stack and guess what, they are rolling it out as we speak. They plan to roll it out to all Windows 11 PCs this month (February). And the expectation is that it will fix the issue with that 40 year old Windows 3.1 API that is currently used by Rust and was never updated. by Microsoft for decades So, hopefully, the Rust project is going to adopt it in the coming months and it will fix things automatically.

I too am tinkering with it in my spare time but was set back by a few days as it requires the latest version of Windows 11 to work.

Will provide an update once I have a working POC on Rust with the release candidate, hopefully in about a week or so.

https://github.com/microsoft/MIDI/releases/tag/rc-1

[sandeep-ma]

You see... they have this new "midi" console app now, that I am using from the release candidate SDK, and it looks promising

This is something you would never get with winmm (what rust is using)

Below are the strings returned for the two identical keyboards (legacy m-audio keystation pro 88's)

\?\swd#mmdevapi#midiu_ksa_16311208013591461351_0_0#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}
\?\swd#mmdevapi#midiu_ksa_12880132197781944884_0_0#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}

This seems to be what Tiago was hoping for, I think, but it is not yet available in rust, until they upgrade to the new version.

And my impression is that these IDs are guaranteed to be consistent and unique even across reboots etc., as one would have expected in the first place.

[tiagolr]

Yes, I am struggling with that exact issue, the IDs used in the rust lib do not persist for example if the USB port changes.
I think in macOS it uses proper ids but not sure about linux as well.

I wonder how MIDIOX works, or any DAWs that recall the correct MIDI devices.