It’s easy to confuse two concepts here: USB Hubs, and USB host devices, along with the third concept of USB MIDI class compliance. Hubs are not hosts, hosts are not hubs, and USB class compliant support for MIDI (and to further complicate it there is non-class-compliant USB MIDI too, although that’s very rare these days) is a separate concern which runs on top of these underlying USB principles.
USB is a physical (that is to say, connectors), electrical (that is to say, voltages, currents, and signal definitions), and protocol (that is to say, the semantics around the bits and bytes transmitted) specification for generic interchange of data on a shared bus. The USB itself has one and only one host, and one or more devices. One or more of those devices may be a hub which can then aggregate the traffic (actively - there’s a microprocessor in the hub handling this) for multiple downstream devices - which may also be hubs, and so forth up to a limit of total devices in the entire hierarchy (limited by the USB address space). Hubs in this sense do not provide any hosting functionality whatsoever and in fact behave according to a very strict and tight physical and wire protocol of signalling and data interchange solely intended to facilitate discovery and communication with downstream devices.
All USB traffic is initiated by the host - no devices ever send data spontaneously. The host will query each device for data in a particular sequence (depending on the “descriptors” the device registers with the host, among other complexities) and only when queried can a device send data in response, and only the sort of response that makes sense for that specific query. Device status and control queries are different from data queries, etc.
USB MIDI defines a particular set of USB descriptors that a device must provide to a host during the discovery phase, which imply that the device can support MIDI in a “class-compliant” manner. Once thusly registered, the host knows to load the generic MIDI driver and that this driver should be able to handle communication with the device - in this way no device specific drivers are necessary. This is what is meant by “class-compliant”. The MIDI specification then determines the format of the data going back and forth between the host and client, and how many ports, etc. are described by that data.
Keep in mind that the USB protocol mandates that devices cannot send any data voluntarily! The host coordinates (e.g. “requests” explicitly) the data when it is ready to receive it, and each device only responds when it is specifically queried for such data. As a result there is no way for one USB MIDI device to talk to another, period. It only talks to the host upon request (“speak when spoken to” sort of thing).
So any USB MIDI interchange must, by design, be coordinated explicitly by the (one, single) host - there’s no way for one device to send data to another device via the bus directly, and devices cannot share or pass on the host role dynamically - it’s an electrical / physical specification as much as a protocol requirement.
As a result, literally every single MIDI device which can act as a USB host for the purposes of MIDI requires a microcomputer to manage the USB native communications as well as host the (perhaps rudimentary) driver to handle the MIDI layer running on top of that bus which responds to and routes the MIDI traffic between the various devices (including those internal to the host in the case of a synth with a host port, for example) in a very active and explicit manner.
This means that no hubs have anything to do with USB MIDI per se, and so I suggest that any further discussion of USB MIDI itself be considered off-topic and moved to a separate thread.
===== Off-topic discussion of iConnectivity MIDI devices, click arrow to expand
I have an iConnectivity MIDI 4+ device and have interacted on multiple occasions in great detail with their support. The devices work fine when dealing with ordinary MIDI traffic such as note commands and ccs, etc. under normal usage. I have found some issues with edge cases, notably sysex (there are significant limitations and/or outright bugs in the handling of sysex, especially over RTP-MIDI but also with large sysex payloads such as the patch dumps of various synths which are dropped entirely by the iCM4+ even over DIN which should be byte-by-byte!), and not a lot of interest from their support to solve these issues or even take them seriously. In addition, some clients with slightly imperfect or unusual MIDI compliance which work fine on modern OSes do not work as USB devices (such as the NDLR). There is not a high priority placed on fixing these issues either. Since the MIO and their older line basically share an OS at this point (and thus share the bugs), I don’t have a high degree of confidence these issues will be fixed moving forward. Their Auracle software also crashes regularly for me. My advice there is to consider carefully what you want out of the device and if it is limited to normal MIDI traffic and has no sysex to bother with, it might do the trick, but if it doesn’t work right out of the box to not hold your breath for any fixes or improvements. Also there are limitations to the level of filtering and routing it can do (for instance it cannot conditionally remap a channel based on source and destination - it either globally remaps a channel for a given output, or a given input, so if you want channel 1 on input 1 to map to channel 2 on output 2 and channel 3 on output 3, you are forced to remap ALL channel 1 on output 2 to channel 2, and ALL channel 1 on output 1 to channel 3, regardless of source).
