in the past, Ive seen quite a lot of issues getting particular midi controllers working with SoC (in particularly when working on Axoloti).
it can be a real pain, during initial development, as its never possible to test every possible controller… and usb is not as ‘standard’ as it pretends
it does get better, over time, as you fix each of the ‘special cases’
power
for debugging, the first thing I found useful is to remove power from the equation…as this can lead to all sorts of oddities with controllers.
unfortunately, MM doesn’t support USB hubs at this time…
(as, Id usually, Id just stick a powered hub in-between)
I guess it might work to use something like blokas MidiHub.
also I think there are some adapters that add power… but Im not sure if they present themselves as the native usb device or a hub
usb end points
USB supports multiple endpoints, ive seen many hosts not handle these correctly , often they will just connect to the first one.
there are two particularly situations:
- multiple usb midi ports (e.g. Push/Osmose have 2 usb ports),
- hidden end point (or non midi)
many usb devices will have secondary endpoint for ‘other purposes’ , sometimes they are hidden as they are proprietary (e.g. for firmware update), or for other purposes (e.g.) audio/ mass storage
you can try to diagnose this plugging into a computer, and this can reveal hidden endpoints or additional usb midi ports
midi messages
sometimes there are ‘extra messages’ sent with can confuse host if not coded.
a common one is sysex being sent as a kind of ‘initialisation’.
the issue here, is it ‘corrupts’ the midi stream (as far as the host is concerned)
this is less common on usb (compared to din) , as it uses a 4 byte structure, but still happens.
this can be diagnosed by looking at the raw midi stream on a computer, and looking for something that might be a bit ‘unusual’
I think those are the main ones Ive had issues with…
(apart from device enumeration, though thats usually an issue with end points too)