It it possible to name separate USB MIDI interfaces?

[HLammers]

It is fairly easy to implement multiple midi interfaces over one USB connection, but how do I give each one a unique name?

To demonstrate what I’m talking about, let‘s modify midi_example.py, by changing lines 45 to 47:

m = MIDIExample()
# Remove builtin_driver=True if you don't want the MicroPython serial REPL available.
usb.device.get().init(m, builtin_driver=True)

into:

m = MIDIExample()
n = MIDIExample()
o = MIDIExample()
# Remove builtin_driver=True if you don't want the MicroPython serial REPL available.
usb_device_core.get().init(m, n, o, builtin_driver=True, product_str="Test")

After this change three MIDI connections show up in my DAW (FL Studio 2024): ‘Test’, ‘Test #2’ and ‘Test #3’. I assume they acually are all three called ‘Test’ (i.e. the product string value) and ‘#2’ and ‘#3’ are added by the DAW itself. Is there any way to give each Interface instance a unique name, via product string or otherwise?

Edit
Perhaps multiple virutal cables is a better approach to achieve this, but that hasn’t been implemented in usb.device.midi. Does anyone know how to implement that?

[projectgus]

Is there any way to give each Interface instance a unique name, via product string or otherwise?

Not from the USB side, I don't think. There's no string field in any of the MIDI descriptors, just the device product string. You might be able to change the names in the host computer OS, or in Windows maybe even via a custom .inf driver file, but I'm guessing that won't solve the problem for you.

Perhaps multiple virutal cables is a better approach to achieve this, but that hasn’t been implemented in usb.device.midi. Does anyone know how to implement that?

This is probably the way, although I think these also won't provide you with different names just different numbered "Jack IDs".

As per the comment here, the driver has all of the structure to add multiple "jacks" in one descriptor but I didn't have a lot of luck getting something useful out of it.

[projectgus]

Not from the USB side, I don't think. There's no string field in any of the MIDI descriptors

Oh actually I am wrong, there is an interface string descriptor index (iInteface) that's currently not passed through by the driver in this call:
https://github.com/micropython/micropython-lib/blob/master/micropython/usb/usb-device-midi/usb/device/midi.py#L174

You could try patching the desc_cfg() function in midi.py to something like:

    def desc_cfg(self, desc, itf_num, ep_num, strs):
        # Start by registering a USB Audio Control interface, that is required to point to the
        # actual MIDI interface
        desc.interface(itf_num, 0, _INTERFACE_CLASS_AUDIO, _INTERFACE_SUBCLASS_AUDIO_CONTROL, iInterface=len(strs))
        strs.append("interface string")

If this works then we could add an optional interface_name argument to the MIDIInterface class, that passes through here.

[dhalbert]

A couple of caveats here that have been confusing to CircuitPython users, where we have a MIDI renaming capability:

1. The device and jack names on macOS are very sticky. They get cached the first time the device is seen, and subsequent changes are ignored. You have to delete the device to get new names to show up. This caching may also be true on Windows.
2. On Windows, either the interface name or the jack names are not very visible (I forget which), and don't show up in Device Manager.

[projectgus]

Thanks for the heads up, @dhalbert. If there is a jack name capability in USB MIDI then my first reply is wrong on two counts! Apologies, @HLammers. I'll try and dig into this more when I have some time.

[dhalbert]

See https://docs.circuitpython.org/en/latest/shared-bindings/usb_midi/index.html#usb_midi.set_names. Also, we recently found this gotcha on Windows, that jack names longer than 31 chars break something, even though that's not inherently a USB length restriction that we know of: adafruit#9871

[HLammers]

Thanks @projectgus and @dhalbert!

I tried patching the desc_cfg() function in midi.py to:

        # Start by registering a USB Audio Control interface, that is required to point to the
        # actual MIDI interface
        global interface_count
        interface_count += 1
        desc.interface(itf_num, 0, _INTERFACE_CLASS_AUDIO, _INTERFACE_SUBCLASS_AUDIO_CONTROL, iInterface=len(strs))
        strs.append(f'interface {interface_count}')

But now it creates three MIDI ports, each called ‘Interface 6’, while it should be ‘Interface 4’, ‘Interface 5’ and ‘Interface 6’ (numbers 1 to 3 are taken by the dummy calls to desc_cfg).

I do not have time now to do more testing to try to figure out why it refers each time to the last string. I guess the clue to that must be in core.pi. The annoying thing is that I’m using VS Code (on Windows 11), with the MicroPico extension, which doesn’t reconnect to the REPL after self.active(True) is called in _Device.init - which makes debugging very hard (I guess that’s an issue to raise in the MicroPico repository).

[HLammers]

@projectgus, do you know if there’s a way to make vREPL work in VSCode (using MicroPico) while running USB enabled code? builtin_driver=True doesn’t seem to make any difference and debugging is very hard without REPL.

I finally want to start working on getting this to work again to integrate it into my Cybo-Drummer project. I found some hints here and there that the solution might be to have multiple MIDI Streaming Interfaces, each with its own Interface Descriptor and MS Interface Descriptor blocks, and use the iInterface parameter to point to unique names.

[projectgus]

@HLammers I haven't tried the VSCode plugin, but unfortunately I'm guessing "no" - the USB serial device will appear to disconnect and reconnect whenever the board soft resets and the host program has to manage this.

(We are in the process of getting support for automatic reconnections in mpremote via #17322 - once this lands it might be a convenient example for other programs to emulate, but they'll need to implement support themselves.)

[HLammers]

I'm doing thourogh testing of four possible ways to achieve a multiport USB MIDI setup:

1. A single MIDI Streaming interface with a single set of endpoints and multiple virtual cables (no luck so far to get this to work with WIndows or Linux, but I have one more adjustment to test before completely writing it off)
2. A single MIDI Streaming interface with multiple endpoints (so far I got this to work with Linux, but not with Windows, but more testing to be done)
3. Multiple MIDI Streaming interfaces, each with a single set of endpoints (this one works with Linux and with Windows as long as builtin_driver == False and with some issues when naming interfaces, which I'm still further investigating)
4. A USB MIDI 2.0 implementation (I only did some very intitial testing and I will further focus on this after finishing testing the other ones, I can also only test this with Linux, because Windows support for USB MIDI 2.0 is only expected to be part of the next feature update, probably released in autumn 2025)

I have no macOS device available to test, for that I will later on rely on others to confirm it works.

While debugging issues with the multiple MIDI Streaming interface approach I found a potential error in core.py. @projectgus could you please have a look and confirm whether this is indeed a bug or not? According to the docs str_max equals to "One more than the highest string descriptor index value used by any built-in descriptor", but line 169 of core.py (while len(strs) < builtin_driver.str_max:) seems to interpret it as 'equal to the highest string descriptor index value used by any built-in descriptor', so I guess this line needs to be changed into while len(strs) < builtin_driver.str_max - 1:. I'm also wondering if lines 169 and 170 are necessary in the first place, because the docs also mention that "Apart from index 0, all the string values should be plain ASCII", which I interpret that they should not be None.

Once I round up my testing of at least the three USB MIDI 1.0 approaches I will make the Github repository publc and let you all know you can try it yourself.

[HLammers]

I managed to get it to work and published my progress is a discussions post: https://github.com/orgs/micropython/discussions/17640