Mixing audio signals is easy; MIDI datastreams are another matter altogether - but MIDI merging can make the difference between a good setup and a bad one.

THERE'S AN ENGLISH proverb which warns "you can't get a quart into a pint pot". Some believe it to have originated in Olde English hostelries but it actually has its origins in the magick art of merging MIDI information.

Coming up to date, the purpose of a MIDI merger is straightforward: it's a "black box" which combines two MIDI signals, allowing control of, say, an expander, simultaneously from a keyboard and sequencer. A simple merger has two [Content missing due to misprint]

So in Figure 1, if a key is pressed on the synthesiser or the sequencer is run, a note will play on the expander. There are other common applications for mergers. In the above example, the keyboard player may play along while the sequencer is running. If the expander is multitimbral, the sequencer and keyboard can use different voices.

If the two controlling devices are both instruments, say a MIDI wind controller and a keyboard, two players can share one [Content missing due to misprint]

In theory, both MIDI channels could be carrying MIDI information all the time. Unlikely, but in MIDI terms strictly legal. Try to combine both signals into one MIDI data stream, and information will inevitably be lost or delayed due to the bottleneck caused. Two MIDI leads can carry twice as much information as one, and there, as they say, is the rub.

More practically, as most MIDI information arrives "on the beat" during a piece of music, a merger must combine the messages so they do not mess each other up. Figure 2 illustrates this problem. In this example, two different three-byte messages, such as Note Ons, arrive at the two inputs at the same time. If the merger simply alternates between the bytes of the two incoming messages, the two messages become confused; the expander would see Status byte X without Data bytes, then Status byte Y followed by four Data bytes. Figure 3 shows what should happen.

Upon seeing a status byte at Input 1, the merger starts sending the message (after a short internal delay due to processing). The message arriving at Input 2 has to be stored inside the merger until transmission of the first message is complete, and then it too is sent. In other words, when two MIDI messages clash, one has to be delayed by the merger.

Herein lies another problem. How long can a MIDI message last? The answer is, surprisingly, forever. There's nothing in the MIDI spec that prevents sending, for example, a Status byte, and then waiting 100 years before sending the remaining two data bytes. The receiving expander should wait patiently for a century and then act upon the complete message.

In reality a three-byte MIDI message may well last longer than the theoretical minimum of 990 microseconds. For example, MIDI real-time bytes may have been filtered out of the incoming data stream, leaving a gap, or the transmitting device may simply be slow. Worse still, one input channel may be receiving a 4000-byte System Exclusive message, lasting over a second in duration. Thus MIDI messages can last quite a long time in reality.

In the meantime, the merger has to store the information from the other input in a buffer until it has decided that the message on the first input is complete. Then it can send the stored message(s), at the same time buffering anything that then arrives at the first input. But how large should this buffer be?

If, for example, the merger has to wait a whole second before transmitting a buffered Note On, the keyboard player is going to get a few funny looks from the lead singer and drummer, and no more gigs. So one particular rule is that the input data buffers of a merger need not be all that large, a few dozen bytes at the very most. If a lot of data needs to be buffered, it's delayed for so long it becomes musically useless, and is better thrown away. Imagine a gig during which the synthesiser stops playing notes for four seconds, and then plays 40 notes at once... Is that the stage lighting, or has the keyboard player's face gone red?

The exception to this rule is when both inputs are used for SysEx messages, in a situation other than live performance. If two long messages clash, and are corrupted because the merger buffer is too small, then the merger has failed to perform. The sensible solution is to arrange things so that these clashes don't occur in the first place - don't make two voice dumps at once, for example.

Clearly, then, there are times when a MIDI merger simply has to discard incoming information. How elegantly a particular merger copes depends upon the quality of the unit. The merger, ideally, has to become an intelligent MIDI filter, only discarding something when it has no other choice.

If a sequencer allows real-time MIDI input whilst it is playing (as most do), then the sequencer itself is performing the merging function. The rules of merging still apply, be it by a dedicated merge box or computer software. As perfect merging is in principle unachievable, a few ground rules are needed to make practical merging as painless as possible. If the following MIDI features are particularly important to your MIDI application, these guidelines should help you evaluate a merger for its suitability.

SYSTEM REAL TIME

HIGHEST PRIORITY SHOULD be given to System Real Time messages, as their name implies. A System Real Time message arriving at one merger input can be neatly inserted into the middle of any message arriving at the other input, with no problems. The MIDI spec is designed that way. Fortunately, System Real Time messages are always only one byte long.

Some System Real Time messages are best not merged from two inputs; MIDI Clocks for example. If two synchronised sequencer outputs are being merged, and both send Timing Clocks, then the merger would output two lots of clocks, effectively doubling the clock rate. Ideally, MIDI Clocks should only be sent by one source. An intelligent merger might automatically look for clocks at one input and ignore subsequent clocks at the other to avoid this problem.

Active Sensing is a curious message. It's an optional facility, and exists only to reassure a receiving MIDI device that it's still connected in the absence of any other MIDI signal. In other words, it only need be sent when both merger inputs are inactive, otherwise it can be discarded. For that reason, Active Sensing has the lowest priority of all when MIDI merging. Other System Real Time messages such as Start, Continue, and Stop will occur so rarely in a live MIDI data stream that they do not present a problem in practice.

SYSTEM EXCLUSIVE

SYSEX MESSAGES LONGER than a few bytes should be interrupted by the merger if a higher priority message arrives at its other input. A Note On is (usually) more urgent than a voice dump, for example, and should be given priority. This will, however, corrupt the SysEx message, making it useless. This is one of the prices you pay for merging. Figure 4 illustrates the point.

If a System Exclusive message is interrupted in this way, the receiving device will automatically ignore it, as the interrupting Status byte will have the effect of cancelling the SysEx message. An intelligent merger must filter out the rest of the incoming System Exclusive message once it has been aborted, otherwise the orphaned SysEx data might end up tagged onto the end of a Note On, with embarrassing results.

If a SysEx message has to be buffered in the merger, then it may be lost due to buffer overflow. As a rule, avoid using long SysEx messages through a merger - you're asking for trouble, especially in a live performance. Program the voices before the start of a song, and instead use Program Change to select the chosen patches.

If SysEx messages must be sent in a performance, for example for synthesiser parameter control, try to send them in passages of the music where there is little MIDI activity, and it has a greater chance of getting through. This is very hit-or-miss though, and is difficult to achieve live. One exception is when only one input of the merger is actually in use, and the other input is inactive. This might occur when you keep your voice library on one device, and sequences on another, using a merger simply as a junction box to avoid unplugging leads. Another scenario is where MIDI outputs from two MIDI controllers in a home studio are merged, and only one controller is played at a time.

If only one input is active at a time, a good-quality merger should pass everything, even long SysEx messages.

SYSTEM COMMON

TUNE REQUEST IS no real problem to a MIDI merger, as it is a single-byte message that does not occur with great frequency.

End of Exclusive (EOX) is normally attached to the end of a SysEx message, and is thus treated the same as the rest of the message. If it appears by itself, It is an error and the merger can discard it anyway.

Song Select will normally only occur at or before the beginning of a song, and is thus unlikely to clash with other MIDI information.

Song Position Pointer is rather like Timing Clock, in that if such messages arrive at both inputs, they are probably the same and information from one input could be discarded. If they are not the same, then the two MIDI sources are out of sync, which is a problem that is nothing to do with the merger. The merger would have to cope with sequences stopping and starting, however, so the best solution is to prevent two lots of Song Position Pointer information reaching the merger by filtering one out. Alternatively, the filtering may be performed within an intelligent merger.

The same argument applies to MIDI time code Quarter Frame messages, where excess messages would confuse the receiving device anyway.

CHANNEL INFORMATION

NOTE ONS WILL be filtered out or delayed by the merger, if too many arrive in a short space of time. Note Offs (or Note Ons with zero velocity) should be given priority over Note Ons, because stuck notes are worse than missed ones. This may occur on a beat, especially if you have been quantising a sequence, and all Note Ons want to occur at once. If this is a problem, it serves you right for writing boring mechanical music. Try pushing or retarding the beat on a few channels - or the merger might do it for you.

Note Ons should only be lost in the most exceptional of circumstances. They shouldn't be delayed after their corresponding Note Offs, but if they arrive at different inputs a merger will have difficulty coping.

One well-known eater of MIDI channel bandwidth is the notorious Pitch Wheel. On some synthesisers, pitchbends seem to be sent by the thousand if you so much as look at the pitch wheel. When the going gets tough, a good merger might discard or delay some information in preference to delaying Note Ons at the other input.

If you try to merge two pitch wheels on the same MIDI channel, you're unlikely to get musical results. Exactly the same arguments apply to Channel Pressure.

Continuous Controllers similarly may have to be thinned out. The problem here is that an all-important value such as centring or zeroing a controller may be missed. A merger has no way of spotting these particular values, as they are not defined in the MIDI spec.

A particular breed of Channel message is the Channel Mode message, which affects the Omni On/Off, Mono/Poly Modes, Local Control, and of course All Notes Off. Incidentally, all Channel Mode messages also function as All Notes Off messages. They have an important effect on the operation of the receiving device, and therefore should have high priority through a merger.

That said, the MIDI specification does say that if Note Ons are being received on one merger input, then any conflicting All Notes Off messages received at the other input should be filtered out by the merger.

If a Channel Mode message is received whilst other messages for that channel are still buffered inside the merger, it's generally a good idea for the merger to discard such data in the buffer. However, there are arguments against doing this, as important messages like a Patch Change could thus be lost.

Just when it seems that things are difficult enough, the MIDI specification throws up a really nasty problem - Running Status. When a particular Channel message is used repeatedly in succession, such as Pitch Bends, MIDI allows the sending device to avoid repeating the Channel Status byte until it changes. Figure 3 illustrates this. In this example, repeated Poly Pressure Status Bytes on Channel 2 are legitimately left out.

This feature was included in the MIDI specification to reduce the number of bytes transmitted. The problem is that it has the effect of making MIDI Channel messages of indeterminate length. If a three-byte message arrives at the input of a merger, it cannot be sure that it is the complete message. The merger has to assume that this is not so, and keep a tag on the Running Status of both inputs. If the merger is mixing two Running Status messages, it will have to jump from one input to another, adding extra Status bytes each time it swops (see Figure 6). In other words, merging can actually increase the amount of MIDI data. This is a harsh test for a merger.

In summary, a good merger is not simply a box that crudely mixes two data streams, but a device that intelligently arbitrates between messages, sorting out the priorities of individual messages, and, as a last resort, filters out information in a way that causes least musical damage. A good merger should cope without ever generating MIDI errors, but this is no mean feat.

Messages should be given priority by the merger, according to their importance. If the merger's buffer is nearly full, low-priority messages should be aborted or discarded in favour of higher-priority messages. Data will be lost, but MIDI errors will be avoided.

The message priorities can be listed in approximate order as shown in the table below:

Priority	Message
Highest	System Real Time
	All Notes Off & Mode
Messages
	Note Off
	Note On
	Controllers, Pressure, Pitch Wheel, Program Change
	System Exclusive
Lowest	Active Sensing

As an alternative to intelligent filtering, a merger may be "programmable". This allows you to select for yourself the messages you want filtered out, improving flexibility at the expense of making the merger more difficult to use.

MERGE A TROIS

YOU MAY WELL be wondering how mergers manage to work at all. In the strictest sense they can't, but in practice, there are enough gaps in normal MIDI data streams to allow merging without the joins being too obvious. It is this fact that allows even badly-designed mergers to work - usually.

It should now be apparent to you that while it's unlikely any available MIDI merger obeys all the above "rules", a good merger should come pretty close. Of course, you can make things even more interesting by trying to merge three MIDI signals. It's not impossible, but your success will again depend on how busy each input is. A practical problem is that mergers with three inputs are not readily available; two inputs are complex enough. So how can three signals be merged?

Figure 7 illustrates one solution. Two two-input mergers are used. Two MIDI signals are combined in one merger. The resulting merged stream is then fed into a second merger, where it is combined with the third MIDI signal. In fact, there's no reason why yet more mergers cannot be cascaded, as long as the inputs are not so busy as to overload the output. A slight delay will occur in each merger as it processes its inputs, however.

If a merger tries to save time by filtering out Undefined Messages, it's cheating. Undefined Messages are incorporated in the MIDI spec to allow future development of MIDI, and are not MIDI errors. Already, a new message has been added to the original specification, Reset All Controllers, and others will surely follow. The merger must cope and be "future proof".

Before buying a merger, try to experiment to see what it does with things like pitchbend, SysEx messages and ordinary Note On/Off messages. Ideally, try it with your own equipment. Above all else, a good merger should not leave you with notes stuck on.

In reality, a handy companion to a merger is a device with a "panic" button - one that sends Note Off and All Notes Off messages on all channels when disaster strikes. Such a device should also have a MIDI In, otherwise you'll need yet another merger to mix it into the MIDI datastream. When selecting a merger, pay attention also to its construction: whether it has a power supply or needs batteries, the quality of connectors, and the number of outputs providing the merged signal. Better mergers may also have MIDI Thru outputs from their inputs. A really versatile merger will perform filtering of the inputs before merging, (controlled by switches) or even be programmable, via its own SysEx messages, from a computer.

As long as you use it sensibly, a well-designed merger can be installed in your setup and forgotten about. If you do get problems, this article should help you trace them, and hopefully find a cure. On the other hand, if you must send Sample Dumps at the same time as playing 32-note polyphonic chords, don't blame your merger for whatever your audience throws at you.