🚀 go-pugleaf

I apologise if your site received a MUCH longer version of this article.  I
had read in a large mail folder in order to avoid re-typing some of the text,
then forgot to delete the bulk of what remained, resulting in almost 700
extra lines.  8-(

In article <288200020@trsvax> pauls@trsvax.tandy.com writes:

>The best processor is an 8051 or 8031 with external eprom.

I'll agree that the 8051 is a good processor for the job, but without
specifications concerning things such as cost and availability, it's highly
subjective as to whether it is the best.

>                                                           The code is
>tricky, since you need to have 2 FIFOs and a ring buffer. THe FIFOs are
>need since each MIDI channel is asynch to the other.

I guess that anything is tricky to those who don't know how, but FIFOs
and ring buffers (which are the same thing) are fairly straightforward
data structures that any halfway competant programmer (especially one
with any substantial real time experience) should be able to implement
with ease.

Something more people will probably find tricky, if they wish to avoid a
UART external to the 8051 for the second MIDI input, is the software based
receiver that would be required.  One approach is to wire the second
receiver to an external interrupt input (INT0 or INT1).  The start bit is
detected by the interrupt generated by the 1 to 0 transition of the INT pin,
and the character is assembled by sampling and storing the state of that pin
at times determined by the expiration of a timer.  In the 8051, this turns
out to be fairly straightforward.

>                                                     Also, if both are
>going "full blast" something as to have priority, so you have to invent a
>protocol.

This is, in my opinion, just plain wrong.  Because MIDI is a temporally
sequential protocol, first-in, first-out is an especially valid approach.
Some feel that the real-time messages (such as TIMING CLOCK) should be
given priority, but I feel that, if the queues are being emptied in a
timely fashion (say, no more than two messages of backlog at any given
moment), the small amount of jitter introduced will be negligible.

There are, however, issues to be addressed if the inputs are 'going "full
blast".  If the sum of the inputs' character rates exceeds MIDI's max
character rate of 3125 characters per second, you're going to have trouble
keeping those queues from overflowing.  In this case, you may wish to
decide what gets discarded, but I think it's better to specify that the
device has a maximum throughput, and that if the user exceeds that throughput,
it's his problem.

A related problem is SYSEX messages, which are of indeterminate length, and
may not be interleaved with anything but real-time messages.  One can see
that, if one input is receiving an arbitrarily long SYSEX message, while the
other is receiving a typical mix of NOTE, CONTROLLER, and other messages, the
second input will eventually fill its queue.  This is especially easy to do
if one limits oneself to the memory available internal to the 8051, but is
still an issue unless one can guarantee queues larger than the longest
possible SYSEX message, which is indeterminate.  A common approach is to,
while passing SYSEX messages from one input, ignore messages being received
on the other input.

If you've read this far, you're probably interested in MIDI merging, and
might like to know about the 8051 based merger I am designing (I have
announced this project in rec.music.synth under the subject "The Urge To
Merge"), the software for which is being written in such a manner so as to
facilitate data filters and transforms, and other experimentation.  The
project is currently in the printed circuit design stage, and it is my
goal to be able to provide boards (along with a public doamin assembler,
the source code, and software and hardware documentation) to interested
parties at my cost.  With this package, one would be able to experiment
with these and other techniques, without having to start from scratch.  If
you are interested, please drop me a line and I'll send more info.

-- 
============================================================================
Michael Kesti  Grass Valley Group, Inc. | "And like, one and one don't make
    mrk@gvgspd.GVG.TEK.COM              |  two, one and one make one."
    !tektronix!gvgpsa!gvgspd!mrk        |         - The Who, Bargain