Midi Merge Technique?

[Batz Goodfortune]

Y-ellow Y'all.
	Just jumping in because I'm writing -or rather, re-writing- a MIDI routine
right at the moment.

At 10:43 PM 01/19/00 -0500, Byron G. Jacquot wrote:

[snip]

>Assuming that you're doing the abovementioned data thinning, you might want
>to parse the incoming MIDI data.  When you detect the space between messages
>(say, between a note on's velocity byte and whatever follows), you could
>shoot out some controller data...maybe run round-robin- send an incoming
>message, send some knob data(if there is any), repeat.  IE: you create your
>own pauses when you need them.

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.

As I understand it, there are 2 ways to merge MIDI. the easy slack way, or
the hard and proper way.

The slack way assumes that there'll be no sysex what so ever and that one
side is going to be only transmitting occasional data. So you give one side
priority and delay the other side in the event of a message on the priority
side. If you're passing a message from the lower priority side and a high
priority message comes through, you wait till the third byte goes through
and then switch back to the priority side. Something like that. You'll get
a few garbled messages from time to time.

But! to MERGE MIDI properly you have to parse both sides and take proper
account of sysex and running status. You have to have a large-ish buffer
and still give priority to system timing messages. Otherwise you just end
up with garbled messages.

As far as I can tell, there would be no such thing as a perfect merger.
There would always be problems. Especially if a large sysex message was
passed on one side. Anything on the other side would have to be buffered
for the duration. And in MIDI terms, that would make those messages pass
their use-by date.

Probably a half way solution could be employed here. In that if you defined
the priority and purpose of each MIDI input, you could then allow your
merge box to discriminate certain messages. And if all you wanted to do was
allow a pass through on a knob box, then it's really a relatively simple
matter of not sending knob data if the input side is active. Yor buffer
would need to be relatively small to cope.

As I've mentioned before. The simplest MIDI merger I ever made consisted of
a couple of resistors and a switch. The resistors weren't even a proper
wire OR. It was to merge a computer which handled sysex data to a synth
only, and a mother keyboard. As long as you didn't do any playing on the
keyboard while the computer was doing sysex, and you didn't request any
dumps while twinkling the plastics, it worked just peachy keen. And did so
for many years. 

A similar, though less flakey approach could be used in this case. -If I
read the problem right- In that you could simply detect the input and not
send knob data. Buffering the input for one or two messages if you got into
the situation where you were already sending knob data and some other
message appeared at the input. In which case you'd buffer the incoming till
your last knob message was sent out and then throw priority back to the input.

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    |_____|