








The "parameters" may also be usurped by a manufacturer for mode control, 
since their purposes are undefined.

Another HUGE problem with the "daisy-chain" mental set of MIDI is that most 
devices ALWAYS shovel whatever they play to their MIDI outs, whether they got 
it from the keyboard or MIDI in. This means that you have to cope with the 
instrument echoing input back at you if you're trying to do an interactive 
session with the synthesizer.  There is DRASTIC need for some MIDI flag which 
specifically means that only locally generated data is to go to MIDI out.  
From device to device there are ways of coping with this, none of them good.

<<



SYSTEM MESSAGES

The status bytes 0x80 - 0x8f do not have channel numbers in the lower nibble.  
These bytes are used as follows:

byte    purpose              data bytes

0xf0    system exclusive     variable length
0xf1    undefined
0xf2    song position        2 - 14 bit value, least significant byte
                                 first
0xf3    song select          1 - song number
0xf4    undefined
0xf5    undefined
0xf6    tune request         0
0xf7    EOX (terminator)     0

The status bytes 0xf8 - 0xff are the so-called "real-time" messages. I will 
discuss these after the accumulated notes concerning the first bunch.

Song position / song select are for control of sequencers.  The song position 
is in beats, which are to be interpreted as every 6 MIDI clock pulses.  These 
messages determine what is to be played upon receipt of a "start" real-time 
message (see below).
The "tune request" is a command to analog synthesizers to tune their 
oscillators.

The system exclusive message is intended for manufacturers to use to insert 
any specific messages they want to which apply to their own product.  The 
following data bytes are all to be "data" bytes, that is they are all to be 
in the range 0 - 127.  The system exclusive is to be terminated by the 0xf7 
terminator byte.  The first data byte is also supposed to be a 
"manufacturer's id", assigned by a MIDI standards committee.  THE TERMINATOR 
BYTE IS OPTIONAL - a system exclusive may also be "terminated" by the status 
byte of the next message.

>>

Yamaha, in particular, caused problems by not sending terminator bytes.  As I 
understand it, the DX-7 sends a system exclusive at something like 80 msec. 
intervals when it has nothing better to do, just so you know it's still 
there, I guess.  The messages aren't explicitly terminated, so if you want to 
handle the protocol (esp. in hardware), you should be aware that a DX-7 will 
leave you in "waiting for EOX" state a lot, and be sending data even when it 
isn't doing anything.  This is all word of mouth, since I've never personally 
played with a DX-7.

<<







some MIDI ID's:

        Sequential Circuits   1      Bon Tempi     0x20     Kawai     0x40
        Big Briar             2      S.I.E.L.      0x21     Roland    0x41
        Octave / Plateau      3                             Korg      0x42
        Moog                  4      SyntheAxe     0x23     Yamaha    0x43
        Passport Designs      5
        Lexicon               6

    PAIA                  0x11
    Simmons               0x12
    Gentle Electric       0x13
    Fairlight             0x14






>>

Note the USA / Europe / Japan grouping of codes.  Also note that Sequential 
Circuits snarfed id number 1 - Sequential Circuits was one of the earliest 
participators in MIDI, some people claim its originator.

Two large makers missing from the original lineup were Casio and Oberheim.  I 
know Oberheim is on the bandwagon now, and Casio also, I believe.  Oberheim 
had their own protocol previous to MIDI, and when MIDI first came out they 
were reluctant to go along with it.  I wonder what we'd be looking at if 
Oberheim had pushed their ideas and made them the standard.  From what I 
understand they thought THEIRS was better, and kind of sulked for a while 
until the market forced them to go MIDI.

Nobody seems to care much about these ID numbers.  I can only imagine them 
becoming useful if additions to the standard message set are placed into 
system exclusives, with the ID byte to let you know what added protocol is 
being used.  Are any groups of manufacturers considering consolidating their 
efforts in a standard extension set via system exclusives?

<<

REAL TIME MESSAGES.

This is the final group of status bytes, 0xf8 - 0xff.  These bytes are 
reserved for messages which are called "real-time" messages because they are 
allowed to be sent ANYPLACE.  This includes in between data bytes of other 
messages.  A receiver is supposed to be able to receive and process (or 
ignore) these messages and resume collection of the remaining data bytes for 
the message which was in progress.  Realtime messages do not affect the 
"running status byte" which might be in effect.

Do any devices REALLY insert these things in the middle of other messages?

All of these messages have no data bytes following (or they could get 
interrupted themselves, obviously).  The messages:

0xf8   timing clock
0xf9   undefined
0xfa   start
0xfb   continue
0xfc   stop
0xfd   undefined
0xfe   active sensing
0xff   system reset

The timing clock message is to be sent at the rate of 24 clocks per quarter 
note, and is used to sync. devices, especially drum machines.

Start / continue / stop are for control of sequencers and drum machines.  The 
continue message causes a device to pick up at the next clock mark.

>>

These things are also designed for performance, allowing control of 
sequencers and drum machines from a "master" unit which sends the messages 
down the line when its buttons are pushed.

I can't tell you much about the trials and tribulations of drum machines.  
Other folks can, I am sure.

<<

The active sensing byte is to be sent every 300 ms. or more often, if it is 
used.  Its purpose is to implement a timeout mechanism for a receiver to 
revert to a default state.  A receiver is to operate normally if it never 
gets one of these, activating the timeout mechanism from the receipt of the 
first one.

>>

My impression is that active sensing is largely unused. <<

The system reset initializes to power up conditions.  The spec. says that it 
should be used "sparingly" and in particular not sent automatically on power 
up.




                      AND NOW, CLIMBING TO THE PULPIT ....



>> - from here on out.

There are many deficiencies with MIDI, but it IS a standard.  As such, it 
will have to be grappled with.

The electrical specification leaves me with only one question - WHY? What was 
wanted was a serial interface, and a perfectly good RS232 specification was 
to be had.  WHY wasn't it used?  The baud rate is too fast to simply convert 
into something you can feed directly to

your serial port via fairly dumb hardware, also.  The "standard" baud rate 
step you would have to use would be 38.4 Kbaud which very few hardware 
interfaces accept.  The other alternative is to buffer messages and send them 
out a slower baud rate - in fact buffering of characters by some kind of I/O 
processor is very helpful.  Hence units like the MPU-401, which does a lot of 
other stuff, too of course.

The fast baud rate with MIDI was set for two reasons I believe:

        1) to allow daisy-chaining of a few devices with no noticeable
                end to end lag.

        2) to allow chords to be played by just sending all the notes down
                the pipe, the baud rate being fast enough that they will
                sound simultaneous.

It doesn't exactly work - I've heard gripes concerning end to end lag on 
three instrument chains.  And consider chords - at two bytes (running status 
byte being used) per note, there will be a ten character lag between the 
trailing edges of the first and last notes of a six note chord.  That's 3.2 
ms., assuming no "dead air" between characters.  It's still pretty fast, but 
on large chords with voices possessing distinctive attack characteristics, 
you may hear separate note beginnings.




I think MIDI could have used some means of packetizing chords, or having 
transaction markers.  If a "chord" message were specified, you could easily 
break even on byte count with a few notes, given that we assume all notes of 
a chord at the same velocity.  Transaction markers might be useful in any 
case, although I don't know if it would be worth taking over the remaining 
system message space for them.  I would say yes.  I would see having "start" 
and "end" transaction bytes.  On receipt of a "start" a receiver buffers up 
but does not act on messages until receipt of the "end" byte.  You could then 
do chords by sending the notes ahead of time, and precisely timing the "end" 
marker.  Of course, the job of the hardware in the receiver has been 
complicated considerably.

The protocol is VERY keyboard oriented - take a look at the use of TWO of the 
opcodes in the limited opcode space for "pressure" messages, and the 
inability to specify semitones or glissando effects except through the pitch 
wheel (which took up yet ANOTHER of the opcodes). All keyboards I know of 
modify ALL playing notes when they receive pitch wheel data.  Also, you have 
to use a continuous stream of pitch wheel messages to effect a slide, the 
pitch wheel step isn't standardized, and on a slide of a large number of 
tones you will overrun the range of the wheel.

Some of these problems would be addressed by a device which allowed its pitch 
wheel to have selective control - say modifying only the notes playing on the 
channel the pitch wheel message is received in, for instance.  The thing for 
a guitar synthesizer to do, then, would be to use mode 4, one channel per 
string, and bends would only affect the one note.  You could play a chord on 
a voice with a lot of release, then bend a note and not have the entire still 
sounding chord bend.  Any such devices?

I think some of the deficiencies in MIDI might be addressed by different 
communities of interest developing a standard set of system exclusives which 
answer the problem.  One perfect area for this, I think, is a standard set 
for representation of "non- keyboard / drum machine" instruments which have 
continuous pitch capabilities.  Like a pedal steel, for instance.  Or 
non-western intervals.  Like a sitar.

There is a crying need to do SOMETHING about the "loopback" problem. I would 
even vote for usurping a few more bytes in the mode messages to allow you to 
TURN OFF input echo by the receiver.  With the local control message, you 
could then at least deal with something that would act precisely like a half 
or full duplex terminal. .More..Several patchwork solutions exist to this 
problem, but there OUGHT to be a standard way of doing it within the 
protocol.  Another thought is to allow data bytes of other than 0 or 127 to 
control echo on the existing local control message.

The lack of acknowledgement is a problem.  Another candidate for a standard 
system exclusive set would be a series of messages for mode setting with 
acknowledgement.  This set could then also take care of the loopback problem.

The complete lack of ability to specify standardized waveforms is probably 
another source of intense disappointment to many readers. Trouble is, the 
standard lingo used by the synthesizer industry and most working musicians is 
something which hails back to the first days of synthesizer design, deals 
with envelope generators and filters and VCO / LFO hardware parameters, and 
is very damn difficult to relate to Fourier series expressing the harmonic 
content or any other abstractions some people interested in doing computer 
composition would like.  The parameter set used by the average synthesizer 
manufacturer isn't anyplace close to orthogonal in any sense, and is bound to 
vary wildly n comparison to anybody elses.  Ther are essentially no 
abstractions made by most of the industry from underlyin hardwre prameers.  
hat tandarizaton exits refects only the similarity in hardware.  This is one 
quagmire that we have a long way to go to get out of, I think.  It might be 
possible, eventually, to come up with translation tables describing the best 
way to approximate a desired sound on a given device in terms of its 
parameter set, but the difficulties are enormous.  MIDI has chosen to punt on 
this one, foks.

Well that's abot it.  Good luck with talking to your synthesizer.














                               Written by Bob McQueer       <MCQUEER>
