Midi Merge Technique?

[Batz Goodfortune]

Y-ellow Byron 'n' y'all.
	
At 08:10 PM 01/20/00 -0500, Byron G. Jacquot wrote:
>>You can't actually do that. Otherwise bang goes your message. You can't
>>insert or nest one message inside another. The parser at the other end will
>>see it as a MIDI error at best, or at worst, will completely screw up.
>
>Just a quick clarification of terminology...I'm not as looped as it might
seem.
>
>By "message," I meant a complete "packet" of MIDI data, not just a single
>byte.  This could range from a 3-byte note on or off kinda message, all the
>way up to a file/sample dump via sysex.  (If we're only parsing bytes, we
>may as well just wire the 2 MIDI streams together with our favourite logic
>gate! ;> )

Yes. A good paraphrase of what I said. A MIDI "Message" is the actual
message contained within the 2 or 3 bytes. (or what ever) Depending on
running status, sysex etc. The actual message that says. Synth on channel n
play note with m velocity. Or whatever. 

And you are correct as I failed to mention. You have to re-generate the
Status when swapping backwards and forwards between the two. I guess in
practice you'd have one general buffer and a status buffer. Though then
you'd have to check to see if you already had a status message buffered up
because these days, MIDI devices often don't transmit using running status.
They just bugger the bandwidth and transmit everything. My O1V does that.

And you are also right in assuming that MIDI merging isn't really practical
in high volume traffic. It's pretty inefficient, adds delays and causes
bottlenecks. It works best in low traffic situations such as a Knob box
merged with a controller keyboard. But even then it has to be born in mind
that knob (controller) data can be pretty weighty at times.

Trying to merge sysex streams and do all that is necessary would be a
bugger of a thing. And to do it properly. As great as Yamaha's MEP4 was, we
use to be able to get it to fall over regularly by throwing too much stuff
at it. It's processor was only a 63B03 from memory. Running at about 4 meg.
Even these little atmel chips I'm using, running @ 24 meg would be pushing
it to do a proper merge and then have enough steam left to update the front
panel.

However, in this case, if the merger was actually built into the knob box
it self, then you have a different situation. Because you can suspend the
knob data quite easily.

And! you wouldn't necessary need to complete a message from the knobs. IE a
knob message could be interrupted any time by a message from the merge
input. So long as it sent a status byte. Or! As you say. Buffer the last
status byte and re-generate it should running status be involved.

You can do this because even if a message is in progress, another status
byte will by definition, terminate the previous status. You can interrupt
another message but you loose that message. But since that other message
would be knob data, you could probably get away with the fact that the knob
would be in transit and that message would be out of date by the time the
merge message is complete anyway. (assuming no sysex etc.)

The best way to do this would be to write down all the merging clauses.
Then you'd probably generate a flow chart which showed all the clauses and
where they lead.  It probably wouldn't look all that complicated at that
level but of course, banging the code together is another matter.

Hope this helps.

Be absolutely Icebox.

 _ __        _                              
| "_ \      | |         batzman at all-electric.com
| |_)/  __ _| |_ ____       ALL ELECTRIC KITCHEN               
|  _ \ / _` | __|___ |  Geek music by geeks for geeks
| |_) | (_| | |_  / /   
|_,__/ \__,_|\__|/ /    
                / ,__   http://all-electric.com
Goodfortune    |_____|