All hubs using the VIA VL812 chipsets are single-TT, FYI. That includes most, if not all, currently shipping Anker hubs and a majority of 4, 7, and 10 port hubs on the market (BTW nearly every hub with more than 4 ports is a series of chained hubs internally since most USB hub chipsets have 4 downstream-facing ports, this is why they usually come in series of 4, 7 (4 + 3) and 10 (4 + 3 + 3) because each internal chip consumes one downstream port from the 4 port chip upstream of it.
The Overbridge hub isn’t special in any way, though. It’s a twinned pair of Genesys GL3520 chips in the 4+3 config. Apparently many bargain-basement USB hubs of no-name sort also use this chipset - so it’s clear the chipset is quite cheap, but it’s hard to get a definitive list of currently available hubs which do use it.
The VL811+ chipset (although I’m not certain about all versions of the 811 series) in the Plugable 7-port hub is also reported to be Multi-TT as indicated here (and by my own research as well).
My biggest gripe with the Overbridge hub is that the upstream port is NOT the Standard-B robust connector but a Micro-B connector which is surface mounted to the board. These connectors can be prone to peeling off the board and are not as durable or resistant to wear, corrosion, etc. over time as the Standard size USB series. Also they disconnect more easily and are more physically fragile.
A crap ton of boring implementation details
Anyways, my own tests have shown that Multi-TT is not necessary for the modern crop of Elektron products since those are USB 2.0 compliant interfaces (Digitone, AR MkII for sure, I can’t speak for the others since I don’t own them). Multi vs. Single -TT only applies for USB 1.0 and 1.1-spec devices which need a translator to connect to the USB 2.0 bus. So if you only run USB 2.0 gear from Elektron over overbridge, you’re not likely to run into problems with a Single-TT hub. If you run more than one USB-1.0 or 1.1 device (dark trinity, etc) on the hub, though, you’ll want a multi-TT hub for the high bandwidth that Overbridge requires to those devices. For basic MIDI, it doesn’t make a huge difference since the internal latency handling the various transfers to each device has roughly 1ms timing (and can be faster or slower depending on a wide variety of factors - USB is a bit complex) and that’s within the time frame it takes to spit out a new MIDI message at standard MIDI speed so Single-TT is certainly no slower than a DIN connection under normal conditions. People pushing lots of USB-1.1 devices with very busy MIDI routing (clock + polyphony + CC sequencing, etc. or a 1.1 device generating clock and the computer repeating it back to other 1.1 devices on the same hub, etc) might run into some timing issues - but in that case even Multi-TT is not guaranteed to solve your problem since some of that often comes from DAW MIDI sloppiness or the USB stack internal to the computer.
More useless rambling: most MIDI devices don’t use the guaranteed-bandwith “isochronous” mode of USB, because the spec supports “bulk mode” or polling-based USB bus usage. This means that timing of MIDI over USB is always the dead last priority for the USB bus with a resolution of 1ms or so per polling interval per bulk device. Since the total bandwidth is not really a concern, but MIDI is highly timing sensitive, this “slop” can multiply by the number of MIDI devices on the bus and in some cases result in multi-ms deviations between the intended note-on and the actual received note-on by the destination device. It also means if you’re streaming audio or using the USB hub for a hard drive which is also in “bulk” mode that the hard disk transfers and the isochronous nature of the audio stream can take priority away from the MIDI data. So, MIDI over USB is not quite the panacea it was thought to be.
