What is the internal latency of Midihub when routing an input directly to an input?
How much extra latency does simple processing (not involving adding delay obviously) like conditional mapping add in round figures?
@Blokas guys (@Giedrius or @Pranciskus) will be able to give you a proper test-bed answer.
Given that they may not pick up before Monday, here’s something to get you started:
what you see is two Midihubs talking to eachother:
- the lower window shows an LFO producing Ch1 CC3 in Midihub1
- it’s sent to MIDI A OUT (via Virtual A)
- Midihub2 (upper window) receives this, changes its channel to 7 and sends it back
- Midihub1 sends both the Virtual A and MIDI A IN to Virtual B so we can see both streams side by side
As you can see we’re getting a consistent 2ms difference but this obviously includes the cabling round trip.
My hunch on the answer to your real question is less than 1ms…
…I’m guessing that cos when I’ve done very complex parallel pipelines and added in monitoring virtuals to compare Before with After, I’ve come to expect them to be in the same millisecond. (but that’s a Virtual → Virtual test)
Happy to dig out an example of the above later if that’s of interest but you may prefer to await a more expert and scientific answer.
Welcome to Midihub forums, btw!
If you test sending a 3 byte message such as a Note On/Off or CC to Midihub and receiving it back over DIN-5 MIDI, the latency is around 1.92ms which is consistent with what you would expect such messages to take traveling back and forth over DIN-5 MIDI cables at the rate of 3125 bytes per second.
Sending and receiving 3 byte messages over USB MIDI it’s around 0.96ms.
The time taken by Midihub’s processing is insignificant compared to the time it takes for the messages to travel via their transports.
2 Likes
Thanks, it occured to me now that I might try using Midi Monitor which I belive produce timestamps too. It would be interesting to see how it performs with straight forward Midi Thru compared to a hardware Midi Thru.
It would be an unfair comparison - hardware THRUs don’t do any processing on MIDI data, that means they don’t have to wait for the entire message usually of 3 bytes in length before they can produce output. A hardware THRU simply reamplifies the incoming signal which means their latency comes only in terms of electronical signal rise and fall times introduced by a couple of electronics components, the standard THRU implementation is in the DIN-5 MIDI electrical spec:
For Midihub to do any sort of routing and processing with the incoming data, it needs to wait for the entire message to arrive before a new or same message can be sent out.
Anyway, the latency of Midihub is at the minimum limit of what is physically possible with DIN-5 MIDI and USB. 
Thanks, yes this is exactly what I was wondering. If also midi thru configurations goes via software in Midihub.
For me it’s not a matter of competition (“unfair” e.t.c.), just that it’s good to know how to set up my midi in the best way possible, considering the limitations of midi.
So, in my case I was planning to send a midi sequencer multiple output through Midihub and knowing the delay is in the milli second range that means I should send all messages this way, or add a slight delay to those messages travelling directly without passing Midihub. I have these options in the sequencer.
Oh ok, I thought you wanted to know what is the delay of the internal Midihub processing of the events, minus the time messages spend in travel.
In case you want to compensate messages sent directly to their destinations and not through Midihub, you should add about 0.96ms delay to to ports that don’t go through Midihub. But keep in mind the actual delay depends on the message length in bytes and bursts of data (like playing a 3 note chord would take at minimum 2.88ms for all Note On messages to arrive at their destination), so there’s going to be a lot of variability when playing.
Fortunately, it’s not noticeable, and in the end the best instrument to use for adjusting port delay offsets is your ears.
Thanks, yeah there’s no real solution to the slowness of midi. It is in fact noticable on extremely transient sounds already when there’s only a few milliseconds, when there’s two or more of them at the same click.