ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/MAGAZINE/MISC/MNFEB91.ZIP/MIDIEX2

Text File | 1991-01-26 | 12.6 KB | 303 lines

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>