Decoding MIDI with discrete logic

[The Dark force of dance]

Y-ellow Michael 'n' y'all.
	Let me preamble this by saying this really is a job for super-chip. You
really do need a microprocessor to do this job. Why? Because you want to
decode a controller message. That simple.

There is really only one MIDI message you can decode reliably using a
discrete approach. That is MIDI timing. One of the system common messages.
This is because it is only a single byte and has the highest priority of
all MIDI messages. It is the only message that can interrupt a system
exclusive stream. A sysex stream it self having the second highest priority
and being able to interrupt any other message. Including controllers.

There is a system hierarchy with MIDI. To interpret it you have to do some
very complex things. I'm not saying it couldn't be done with discrete logic
and it would be an interesting exercise to do so. However you have to
decide if this is a practical thing you are trying to achieve or if it's
purely academic.

To decode the MIDI signal, as some have already suggested, you would need
to use something like a IM6404. Or AY5-blah blah blah. (Damn I can never
remember that number off the top of my head. The 6404 may in fact be too
slow for MIDI I'm not sure. from memory they come from the old days when
baud rates of 2400 were considered hell-fast.

That aside it would be the easiest solution because they are one of the few
UARTS which are pin programmable and do not require programming on a bus
oriented system. IE a microprocessor. Once they are hardwired, they will
simply spit out raw MIDI data. This is where the real fun begins.

Your system will need a timing sequencer. This is because you would have to
parse the MIDI messages in hardware and this required not the comparison of
the byte you're after, but all the ones you are not after. You have to know
for example that a running status has been flagged. This means you need
flag registers. You have to find the controller status on the required MIDI
channel and then flag that the status is valid. Should some other kind of
message come along you need to un-flag the status. This is because running
status says that you don't have to send a status byte again if one is
already in force. Unless that status changes. This means everything you
want to decode comes down to the second byte of a controller status
message. And this could be changing.

Blah blah blah. You get the idea. It's pretty complex. You cannot hardwire
the magnitude comparator because you need to compare for other things. So
you need to sequence some comparisons to find out what you're dealing with.
I would suggest here that it would be quicker for you to learn how to
program a simple micro such as a basic stamp or PIC. Or better still An
ATMEL AVR. Than it would be to nut-out the shrapnel required to decode it
discretely. Trust me on this, it would be more beneficial to you in the
long run.

A basic stamp would probably be a good place to star since they connect
directly to your PC for programming. They are programmed in tiny basic. And
they can be bought with a built in UART which is capable of handling MIDI
speeds. And! They're cheap. If you know enough about programming in basic
to save yourself in a crunch you should be able to handle programming a STAMP.

Having said that, and as many of you here know already, I personally prefer
the MCS51 core processors. I'm particularly fond of the ATMEL range of
FLASH based MCS51 derivatives. They program in seconds. They re-program in
seconds. They are entirely self contained and you can get them in a very
small 20 pin foot-print. But mainly, because they are based on the original
intel MCS51 processor,  once you know how to program them, you have access
to literally hundreds of variations on the original part. From the tiny
ATMEL parts through to the huge and blindingly fast Siemens parts. There
are even code compatible 16 bit versions now.

Comparisons of scale favor the small micro as well. Considering that it
will take you an entire board full of shrapnel costing perhaps US$100 by
the time you get it to work. Compared to a mere US$5.00 for an AT89C2051.
Which will replace all of it. Err except for the opto which should go
without saying. To make the system work it's simply a matter of hooking up
the chip and then sitting down at a leisurely pace and program it. Low flux
fume value.

The only other way you could get it off the ground simply is if you could
absolutely guarantee that it never sat in a MIDI stream where any other
message would pass. If you could guarantee that the only message that would
ever flow down your MIDI tube to your device was the one message you
required, then you would only have to account for running status. And that
would be because most, if not all devices sending MIDI would impose running
status as a matter of course if there were no other message type being
sent. If you could prevent the running status then you wouldn't have to
decode that. That then leaves you with just three byte values to decode.
Status, controller number and controller value.

Hope this helps.

Be absolutely Icebox.

 _ __        _                              
| "_ \      | |         batzman at all-electric.com / aek at all-electric.com
| |_)/  __ _| |_ ____           ALL ELECTRIC KITCHEN               
|  _ \ / _` | __|___ |  The Elementary Urban sanity CD
| |_) | (_| | |_  / /   out now on Transmission Communications
|_,__/ \__,_|\__|/ /    
                / ,__   http://www.all-electric.com
Goodfortune    |_____|