Midi chain: Do I have to expect latency?

[SounDuke]

Hi everyone, I've got six midiboxes and I'd like to chain them and use the integrated merger to connect the whole equipment to a single midi In port on my laptop. Do you think that by connecting the midi out of the first midibox to the in of the second midibox, then the midi out of the second midibox to the midi in of the third midibox ecc. would cause latency problem? Thanks for the advice.

[lylehaze]

That depends on how much delay is acceptable.

The bare minimum delay should be around 1ms per board that you are passing through, so that would be 5 ms for an event from the last board to reach the front of the chain. Mind you, that is the minimum, assuming that there is no timing overhead for other processing.

Another possible problem is bandwidth by the time all six streams are connected. You'll have to collect complete messages before forwarding them, as most messages can't be "mixed together", each will have to travel as a complete packet. So this can double or triple the earlier estimate of delay, and impose greater delays as the traffic gets "thicker". All of this depends on the details of what you are combining.

But if you want to shove six midi streams into a single MIDI IN port, it will have to be combined anyway.

I'm not an expert, and I invite ANYONE to call me wrong or offer a new way of looking at this.

Good Luck,

LyleHaze

[QBAS]

hi

I noticed differences in latency with only one keyboard ! connected to second keyboard midi in and from midi thru to computer midi in.

I worked with virtual sampler and hardware sequencer. The latency can change all groove and feeling of rythm. Of course it can be acceptable if you work with pattern style seq, but when you play by hands samples then latency is problem.

If you want connect for egzample 3 keyboards check this alone and tell us your feelings :) We all interesting in this.

I recommended to minimalize stuff but if you need use more keyboards please connect it in serial and play for egzample 3 mounths. After this please change configuration: the last one is now first, If you will notice dramatically differences then you will fell latency problem.

[lylehaze]

Woah.. I may have missed something here.

There is a big difference between using "MIDI Thru" to chain things together, and merging incoming messages in software.

the "MIDI THRU" method should be very fast, as it's just

copying the incoming signal back out, without even decoding it. That could offer a "thru-delay" that is as small as the optocoupler response time.(pretty darn fast)

The idea of receiving messages at MIDI IN, then re-sending them on MIDI OUT is what I was discussing above, and that's why there will be more delay involved. Of course that would be necessary if you want to merge your outputs with those already in the stream.. I hope this is making sense.

Anyway.. I'll go back to my corner now.

LyleHaze

[SounDuke]

I own a midex 8 so I have all the in's I want, but I wanted to try merging so I need to bring with me less hardware on the stage. Consider that I'm not the sequencer type ^_^,  I'll use these midiboxes only to send note on/off and pitch bend messages to the Vst's, so maybe one midi thru for each device could result in an acceptable delay. So maybe I should build an LTC module for each device

[QBAS]

how about four IIC Midi module in big MB_midi_merger for take only one step of proccesing?

[SounDuke]

Qbas, do you mean the midi router project? I didn't read it carefully yet, but it seems that I can use up to 4 iic modules and I have 6 midiboxes to mix, and I think that makes no real sense as I'll have always an external box, so it makes sense to use my midex with separate ports.

[QBAS]

probubly yes, but you can also include 4 iic midi modules in one from 6 your midiboxes - then you no need external box, only extend your one box by modules and midi socets (plus change code).

[dj3nk]

or jst build one more core and build a standalone router.

dj3nk