USB Hub support development

SmashedTransistors 2017-07-31 08:34:52 UTC #1

That would mean that we could connect multiple MIDI USB devices to an Axoloti ?

johannes 2017-07-31 10:02:25 UTC #2

If that works out, yes. The flood of NAK events has been addressed in the meantime, and the first test with a hub, one HID and one MIDI device seems to work, so it looks promising.

thetechnobear 2017-07-31 13:00:42 UTC #3

This mean we will need to consider exposing the USB device name , so that you can filter events by midi devices.
(The filtering needs to be midi device/midi port/midi channel)

Probably this could just be an extension of midi device id, (with axo din/USB device being fixed), and the host ports being dynamic.

wonder if you have to use the USB id, since when you store in the patch (for filtering) , it needs to be consistent regardless of order of USB devices being powered etc.

Hmm not trivial, when you also consider the 'name' needs to also be fed back to the user for selection purposes.

johannes 2017-07-31 14:49:31 UTC #4

In development, I have added "virtual midi input and output ports", those have only a index number (1-16). That would allow a patch to deal with index numbers only, making references to the USB device name would require changes to the patch when using a different usb-midi controller.
Multiple real midi input ports can be routed to several virtual input ports. Each virtual midi output port can also be mapped to several real midi output ports.

The use cases this cover would be:
* using virtual input port 1 for "just playing", merging all keyboards and direct controllers. Most patches would just use virtual input port 1.
* virtual input port 8 could be used for midi clock, perhaps also switching between external and firmware-generated clock without modifying the patch.
* midi controllers that are not intended as "just playing" controllers, like a Launchpad or a Mackie MCU, could use a different virtual input/output port than 1 or 8.
* virtual port 9-16 could be dedicated for midi thru routing

So that 'd move the midi device/port logic out of the patch.
The problem is then moved to firmware...
In many cases it is sufficient to merge all midi input ports to virtual port 1.
Clock can be a bit more tricky, merging midi clocks makes no sense. There are probably application scenarios where multiple midi clocks are useful, but 99% of the applications will be served with a single internal or external clock source. The first physical port where a clock is received could be selected as the clock source. The 1% of the applications that require multiple independent clock inputs could use specific virtual input ports rather than virtual input port 8.
Mapping midi devices to a specific port, I think this needs a configuration file on sdcard containing virtual port mapping for USB device names. That would not allow a different port mapping for, say, 2 Nanocontrols since they will both have the same name. But I don't see a reasonable way to deal with that scenario, no matter if it is selected by usb device serial number (if present), connection order, or usb port number, it will always remain a potential source of confusion.

Does that cover it? Hrmm also Sysex is problematic when merging several inputs to one virtual input, if they arrive simultaneously, they will get mangled. Assigning a separate virtual input channel would solve that again.

thetechnobear 2017-07-31 18:29:18 UTC #5

from my perspective (others may be different)

Id say, merging all midi input is rarely what I want (and of course, output = never)... Id usually want a patch/object to be able to determine where the midi data goes. In fact, the only scenario where I don't care, is when Im developing, say a synth patch, and I just need any controller to trigger the sound. ... but honestly I don't see that so much as merging data, as not filtering any device (e.g. Omni)

but other cases, I really do want separate streams, and I need them to be identifiable...
something like a Launchpad, you may be send/receiving specific data, to say control the pad colours.
or you might want you keyboard to be triggering a synth, but a 'pad controller' to be triggering drums.

(... and I don't like generally doing this via midi channels, its cumbersome at best, and if your controller is sending out on multi channels (sequencer/multitimbral synths/expressive controllers) , it may not even be viable.)

I'm not quite sure I understand the benefit of virtual mappings much.. over say simple filtering, with Omni options..... the only advantage I can think of, is if you had lots of controllers or similar types... and you want to treat them similarly.. then you could group into a virtual midi device - but that seems pretty 'corner case'

even with virtual midi ids, your still going to need to get the 'usb device name' back to UI, so the user can identify it.... are you proposing, that the first time a 'new' device connects it gets a virtual midi id, and then has it forever? ... that might work

also, how do you propose to do output? I cant see you ever want to merge output (ok, perhaps clock is useful, but not notes/cc etc), its going to get very confusing if a physical device has a different virtual midi input id, to its output id.

johannes 2017-08-02 18:30:36 UTC #6

The missing piece in my opinion the ability to filter "any device except the Launchpad and the Mackie MCU", preferably as a system setting, without a need to modify a "just playing" patch.

Checking how it is done in Max, in the MIDI setup dialog, every input/output port can be assigned to an abbreviation indicated with a single character (a..z), and a MIDI channel offset.
Those abbreviations seems very similar to my approach of virtual MIDI input/output ports.
The MIDI channel offset in Max, not quite sure how useful this is. Max does not limit the midi channel number to 0-15.
I'm not quite sure shifting MIDI channels is a good idea, could get confusing, and loses the relation between channel and port.
Max can also deal with MIDI port names in the patch, but I would expect this to make it hard to migrate patches from one setup to another, with a "Launchpad Mini" to a "Launchpad MK2" or a Mackie MCU connected to a MIDI DIN port.

If I recall correctly, Pd arranges all enabled MIDI input ports to successive MIDI channels, 1-16 for the 1st port, 17-32 for the 2nd port etc.

DAWs typically have a MIDI setup dialog where MIDI clock can be routed to destination ports, MIDI ports for "just playing" controllers/keyboards/synths can be enabled (or perhaps more relevant: excluded), and configure supported remote controllers that incidentally use MIDI.

To a midi-input and midi-output routing settings dialog UI, yes, but not to the patch.

No, any reference to such a virtual midi ID in a patch would be specific to each individual setup
the goal is to abstract specific setups.

thetechnobear 2017-08-02 18:56:47 UTC #7

in max you can assign specific controllers to specific midi input objects. (just right click on them), you can also specify the 'text' device name .eg "Ableton Push 2 User mode"

in PD, yes, for some platforms (e.g. OSS) its sequential midi channels (bad), but for others (e.g. alsa) , you can create virtual midi ports, which you can then use aconnect to route midi too.
max also supports virtual midi in/out, which you can use other software to then route too

the thing about virtual devices in these cases though, is they tend to then just be directly accessible from a daw etc... its not like you have to assign devices, its just like your treating them as virtual instruments... which you target from a daw.

I guess I don't mind, as long as I can say, in this patch , I want this controller (e.g. keyboard) to target this subpatch, and this other controller (e.g. drum pads) to target this subpatch.... and when I load that patch up (standalone) with those assigned controllers connected, it works the same as when I last used it

natcl 2018-12-29 23:12:12 UTC #8

In the iConnectivity soundcards you can "lock" a device to a specific virtual input which works nicely. You then have a matrix you can use to choose where the data goes.
Not sure about merging all devices to a single input, that should be optional for sure.