[sdiy] MIDI merging info requested

[Ingo Debus]

Am Dienstag, 10.05.05 um 19:24 Uhr schrieb ASSI:

> Yes, there is no such thing as a passive MIDI merge: you need to 
> extract
> complete messages without running status, merge them and perhaps
> reconstruct running status before sending out. Merging the messages
> requires an interlocked FIFO or keeping two timestamped queues (if you
> want to prioritize between the two input streams). Correct handling of
> realtime and sysex messages is a bit tricky. Realtime messages don't
> break running status and anyway are some sort of sidechannel data that
> can be transparently handed through if one of the interfaces never
> generates them.

Some thoughts...

IMHO it doesn't make sense if a merger passes Real Time messages from 
all inputs. If there are Start, Stop, Continue or Clock mssages present 
at more than one input and these are merged this will cause just a big 
mess.
If Active Sensing messages were merged, the protection against stuck 
notes wouldn't probably work anymore. Imagine two MIDI sources both 
sending Active Sensing, and one of them fails (switched off, plug 
pulled, whatever). The receiver cannot detect this because there are 
still the Active Sensing messages from the other source.

The easiest solution for the Clock etc. messages problem would be that 
the merger passes only those messages from one dedicated input and 
suppresses them for all other inputs. For Active Sensing, it would be 
best if the merger reacts on missing messages by itself (sending an All 
Note Off message for instance) instead of just passing the  0xFE bytes.

I don't quite see the benefit of timestamping/prioritizing. My merger 
starts with the output as soon as MIDI bytes arrive at any input. If 
prioritizing should make any sense at all, the MIDI data had to be 
delayed (in case data arrive at the input with higher priority), thus 
causing latency. Of course, the input with highest priority doesn't 
have to be delayed. Perhaps a good solution in some cases, for instance 
merging a keyboard with a unit that sends only program change messages.

Ingo