OVERRIDING MIDI pt.II (long)

[JDMcEachin]

At 12:36 AM 2/4/97 -0800, Don Tillman wrote:

>For instance, I think the biggest problem with MIDI is that it treats
>everything as note-on note-off messages, and for most types of real
>musical expression, say for example a sax player wailing, that's a
>pathetic representation of a musical event.

Having been an enthusiatic user of CC messages, I'd say tbat that's not
necessarily accurate. You can do quite a bit with CCs on devices that
support them.  But, there is a definite bias towards notes in both
specification and implentation.  

The main advantage that NoteOn/Off messages have over CCs is that you get 2
1/2  parameters per message instead of one - Note#, Velocity, and
indirectly, Duration.  With CCs you're wasting a byte specifying the CC#,
which gives you a lousy 7 bits of CC data. If you've ever done a CC filter
sweep on a synth with 7 bit quantizing (Jupiter 6 springs to mind), you know
that this JUST DOESN'T CUT IT.  Of course, there's a 14 bit option, but it's
specified in such a braindead way no one EVER made a synth w/ 14 bit CC
resolution, to my knowledge.  Pitch Bend is the notable exception.

>So I'm all for replacing MIDI, but there haven't been much in the way
>of concrete proposals.

XMIDI sounds pretty well reasoned, and addressed many of the concerns
expressed so far, but alas, it lacks a champion with any clout in the
industry.  More on XMIDI below...

I don't know as much about ZIPI, but it seems that more money was put into
its development than XMIDI, and it was, I believe, implemented in at least
one Zeta product. For more info on ZIPI, see:

http://www.ipoint.com/ftp/pub/standards.html


At 05:03 PM 2/4/97 -0600, Jonathan Mayer wrote:
>
>>okay, i admit it! i'm a circuit-burning newbie... what's USB?

"Useless Serial Bus"

12Mb/s?  Kidstuff.  Firewire (IEEE 1394, yes, it's actually an IEEE
standard) has 100-200Mb/s, scaleable to 1.2Gb/s.  And yes, it's in shipping
products, mostly video right now, but look for it on a Mac real soon, and on
Wintel boxes when they figure out they're getting their asses kicked
technologically yet again.

>I predict in a year or so all new computers will have usb ports.

I predict in a year you'll be wishing you had gone with Firewire.  Don't
hitch your wagon to a technology that's obsolete before it's even released.

Only one problem with my argument - I don't know the implementation costs of
USB or Firewire.  I read a reference to Firewire being about $50 a box, and
you need a fast CPU to keep up with it.  Of course, the cost will come down
with popularity ( when I was in college they predicted that Ethernet would
eventually get down to $500 a box! ).


Oddly enough, a similar thread is currently on the Logic maillist.  Here's
what Michael Haydn, one of the main guys at Emagic, had to say:

> ------------------------------
> 
> Date: 07 Feb 1997 02:41:34 GMT
> From: mhaydn at emagic.hh.provi.de (Michael Haydn)
> Subject: MIDI spec 2.0 canvas
> To: logic-users at mcc.ac.uk
> 
> >>
> I'm canvassing for opinions on what features/improvements people would love to
> see in MIDI specification 2.0 and why. I'd be grateful for any suggestions,
> moans groans and comments. <<
> 
> * A high speed hardware interface like Ethernet or FireWire
> * A one-cable bus solution instead of unidirectional cables
> * More bits for MIDI channels and Device IDs.
> * Only one message for control changes (with 14 or more bit range) instead of
>   LSB and MSB messages -> Then you would have only one connector on your
>   computer, even if you have hundreds of MIDI 2.0 devices connected 
> * A protocol which allows 8-bit data bytes. This would make SysEx
transfers much 
>   easier. 
> * An idiot-proof definition of bank select messages. Maybe they are not
>   necessary at all by using more than 7 bits for Program Change messages.
> * A protocol that will make universal editor/librarians able to adapt to new
>   devices automatically. Right now, there is only the Universal Device
Inquiry,
>   which works like "Hello, someone new out there?" "Yes, I'm from manufacturer
>   XYZ, my Device ID is 1, my model ID is 123, and my software revision
number is
>   2.0". This message is not yet supported by all manufacturers, however there
>   are more and more. In future, it would continue with "I'm a DX-2080 pro-X. I
>   have the following data types ..., banks .... In a data type X, you will
find
>   the following parameters, with ranges, displayed values etc." There would be
>   some sort of standard for dumps, requests and parameter changes. GS and
XM are
>   only manufacturer-proprietary protocols.
> 
> >>
> I'd also be grateful if anyone could point me in any directions that will list
> any propsals that are currently in the works or any discussion groups that
> specialise in this. <<
> 
> Check out
> http://ourworld.compuserve.com/homepages/eric_lukac_kuruc/xmenu1.htm
> 
> That's the XMIDI home page. XMIDI is a proposal to use trinary logic in MIDI
> cables (i.e. positive, null and negative current). This expands the number of
> channels and possible value bytes extremely.
> 
> However XMIDI has been banned by almost all MIDI manufacturers. I talked to
> the creator of XMIDI at NAMM 96. He was very upset...
> 
> ------------------------------

XMIDI is very tempting, in that it offers backward compatibility, and does
just about everything I want, BUT, I have a feeling that in 5 years it won't
do everything I want, and its lack of industry support makes it a very slim
possibility.

I think the main problem with MIDI is that it deals with time critical
information, and yet there is no way to guarantee what time that data will
be acted upon.  As I see it, there are two types of data: that which must be
acted upon immediately (notes you're playing on a keyboard, gestural data
from your digital theremin, knob tweaks, etc.), and data which can be played
at a specific time (stored in your sequencer).  Since it looks like we're
stuck with a serial interface for cost reasons, then it would be
advantageous to be able to send some data before it needs to be acted upon,
to avoid bandwidth logjams during critical times (on the beat).  By
timestamping the data, it could be buffered until it is time to act upon it.
Of course, the requires more sophisticated synths and sequencers.  You may
argue that high bandwidth obviates the need for this, but bandwidth has a
way of being consumed by unexpected applications (who would have dreamt that
people would be doing 180-200bpm music with MIDI 14 years ago?).

Speculating on MIDI 2.0 is a fascinating intellectual exercise, but I don't
see it happening anytime soon.  Before attempting to extend it to get more
out of the synths you already own, ask yourself this: are you going to get
enough added functionality out of your synths to justify the huge investment
of time it will require?  My guess is no, based on my experience with
Europa.  Europa was started as a way to get more out of our Jupiter 6s, but
it has required so much time and energy that the only way it will ever
"payoff" is if we sell enough to quit our day jobs and work on
software/hardware design fulltime.  At this point, it looks like we'll just
get some pocket change and the satisfaction of enhancing other's creativity.

JDM
Synthcom Systems, Inc.
http://www.synthcom.com/

Synths as furniture?  Let's ask Kraftwerk: "America is very shy when it
comes to electronics.  People have all the latest state-of-the-art
technology, and yet they put wood panels on the front to help them feel
comfortable.  Or they develop new plastics and try to imitate the appearance
of wood.  They use modern technology to try to recreate the Middle Ages.
This is stupid."  Thanks Ralf - my sentiments exactly!
I'll be painting my MiniMoog black now...