[sdiy] MIDI merging info requested

[ASSI]

On Mittwoch, 11. Mai 2005 07:33, Byron G. Jacquot wrote:
> Sysex data is limited to 7-bits.  Values of 0-127 only.
>
> Receiving a byte with the MSB set (128 and above) indicates a new
> command, thus the end of the sysex transfer.

Close, but no cigar. Real-time events don't terminate the sysex, but 
have the MSB set. You can however try this and see how many software 
and synths are thrown off by interspersed real-time events...


On Mittwoch, 11. Mai 2005 09:08, Bob Weigel wrote:
> That's...not the standard.

It is. The standard says explicitly that sysex may be terminated by the 
next status byte (except real-time).

> Softward that follows the MIDI standard 
> looks for F7 (eox ie. end of sysex message transmission).

There is probably a lot of software that does that, but it is still just 
braindead.

> Intelligently written software/firmware
> actually could splice other messages in there but I've never
> experimented to find if any machines actually do it.

That is simply not allowed per MIDI spec. You cannot hold up a sysex 
transmission, send other messages and then resume the sysex. What you 
can do OTOH is send part of the message, wait some time and then send 
the rest of it - and the merger would be well advised to keep the 
timing intact. Sysex is an escape mechanism to do things the MIDI 
standard didn't care to define. Start of sysex turns the wire over to a 
non-standardized communication. End of sysex by whatever means, be it 
EOX or just resuming with standardized messages, returns it to normal. 
Then again, you really shouldn't try to terminate a sysex message with 
another status byte when the synth is not expecting you to do that...

>  For instance, if it noted a high first bit (Status byte) , it would
> generally either
>
> 0) Assume it's the eox...don't bother checking if it's F7 or not...

Again, you must remember to check for real-time. Although it's probably 
easier to siphon off all real-time events before they complicate the 
rest of the event decoding mechanism. If you also handle active sense, 
it is quite unclear whether you should abort a long sysex transmission 
that hasn't been terminated and no active sense is received.

> 1) assume it's a one byte message like clock or active sensing... or

These two are real-time events and can theoretically occur anywhere, 
even inside other messages including sysex. They don't terminate the 
message and they also don't break running status. In effect these are 
on their own logical (side-)channel.

> 2) go all out and check to see what the byte actually is, and from a
> look up table or whatever decide how many bytes to ignore until the
> next status byte comes through.

Except that wouldn't work if you got another sysex event because then 
you wouldn't know the length of the message.

The MIDI spec was IMHO developed without considering the merging of two 
different MIDI streams. The hidden assumption is "one master and a 
chain of slaves". Any multi-master situation leads to ambiguities and 
quirky definitions.


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

Q series MIDI Implementation & additional documentation:
http://Stromeko.Synth.net/#WaldorfQDocs