[sdiy] MIDI merging info requested

ASSI Stromeko at compuserve.de
Thu May 12 23:16:25 CEST 2005


On Donnerstag, 12. Mai 2005 20:01, Ingo Debus wrote:
> 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.

I wasn't suggesting that they would be nilly-willy handed through from 
all inputs. However there are useful and practical scenarios where one 
device sends Clock and another device sends Start/Stop/Continue.

> 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.
[...]

Active Sensing doesn't really work anyway, much less if you merge. I 
filter it out on all interfaces. To make sure that Clock is sent by a 
single source only should not be the concern of the merging device 
IMHO.

> I don't quite see the benefit of timestamping/prioritizing.
[...]

This would be useful for situations where one input had timing critical 
data while the other is used for editing. Prioritization makes sure 
that the timing critical data survives the merging while none of the 
editing gets lost (provided the buffer is large enough and the edit 
data doesn't consist of long reams of sysex). The store-and-forward 
allows to make better use of running status for the de-prioritized 
channels (this is also a workable strategy for optimizing MIDI from a 
single device).

If you want to merge a pedal board with two keyboards this strategy 
doesn't make sense of course and cut-through forwarding becomes the 
weapon of choice. Running status optimizations (don't forward status 
that is already sent) is still possible, but less likely to succeed as 
normally you'd get the data on different channels.

I think it should be possible to adaptively switch between the two 
strategies if you can't know in advance which of the scenarios is more 
likely.


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46 Neuron microQkb Andromeda XTk sonic heaven]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Stromeko.Synth.net/#WaldorfSDada




More information about the Synth-diy mailing list