Midi Merge Technique?

[Byron G. Jacquot]

>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! ;> )

Since most messages are fairly small (between 1 and 3 bytes), running round-
robin between whole messages from the incoming stream and whole messages
generated internally.

It might be wise to increase priority for system real-time messages from the
input, as well.  When running status is used, you could break those messages
apart and re-transmit the status bytes, if needed.  It might be a good idea,
since running status doesnt guarantee that next message will be coming in
any specified amount of time...might as well use that time for other work.

If this were done using a state-machine based parser, it would be fairly
simple to parse whole messages, pass them to the output, and when a message
has been entirely sent, check to see if any new internal data must be
sent...another node in the parsing state-machine, really.

Conversely, only when a whole message has been recieved will it require
interrupting the stream of the internally generated data.

In one of the input sources (The MIDI in or the internal data) is quiet,
then the other will get priority for transmission.  If they're both somewhat
busy, then sharing the bandwidth is usually a reasonable solution...barring
lots of large sysex, etc.

If the data generated by the machine is itself small(say, in the form of
CC/NRPN values), then if theres a sysex transfer from the input, it would
have to wait for a 3 byte message to leave before it could begin, before the
state machine could begin copying input bytes (probably through a buffer) to
the output...the sysex would then have priority until it was finished.

Since this alternates between the 2 sources when the needed bandwidth is
low, it's reasonably "fair."  Each gets the bandwidth it needs to keep form
starving, as long as you assume that neither will hog the channel with long
transfers.  Recall that once a large sysex transfer starts, there's no
simple way to insert new stuff in the middle anyways.

It might not be unreasonable to spit out sysex altogether, depending on the
application.

However, merging MIDI is far from ideal when the desired bandwidth is high.
If you can guarantee that one side will be fairly sparse (which I'm assuming
from the initial post, some sort of knob/fader box, which would only need to
send data when values change), then it's easier to design a reasonable
algorithm...it's one of those cases where a general/universal solution would
be really tough.

Byron Jacquot