With the recent activity and interest in the state of the art
regarding USB and MIDI, here is some of my experience to share.

USB has two modes of operation, Host Mode and Device Mode.  Until
recently it has been difficult to implement Host mode onto a small
processor, and my work has been with the Device Mode space.  I am still
wading through the MIDI USB specs and some technical documentation to
understand the host side of the issue.

A few months ago Future Technology Devices International (FTDI)
released a Host Mode bridge chip.  FTDI is the main supplier of USB
bridge chips.  This is the same chip manufacturer I have used in the
USB scanner that was demonstrated to San Francisco Bay Area AMICA on
the 11th of February.  It is, in effect, a USB-to-parallel converter.
Vinculum is the next generation that goes both ways.

In the last seven or eight years that I have been working with MIDI for
mechanical music instruments, I have found some obfuscation with terms
used to describe MIDI hardware.  This mostly relates to the generic use
of the word "controller."  Some of this obfuscation comes from the
audio world.

Specifically, I want to call the device I have done the most work on a
"stand-alone MIDI file player," when in practice it should be called a
"sequencer."  To audio engineers a sequencer is something like the
Cakewalk computer program (that takes tracks and sequences them) so
they call the box on the solenoid piano a controller.  The obfuscation
happens as the note driver board is also called a controller.

MIDI is further obfuscated in that there are many parts to the standard.
The two best known are the MIDI wireline protocol and the SMF (Standard
MIDI File) file exchange format.  There is a lot of confusion here that
the two things are one and the same -- they are not!  SMF was optimized
to sequence data to be sent over the MIDI wireline.  SMF can also
sequence and capture data over any other wire or network protocol like
USB.  SMF is a file storage system.

I like to present the argument that SMF files do not contain the
"note on" and "note off" events inasmuch as the files, like sheet
music, represent the phase relationships of these note on and off
events, and that to change the volume _is_ to change the velocity
[event] of the represented note.

Conversely, MIDI wireline protocol is an optically isolated current
loop running at 31 kilobits per second.  This is not to be confused
with baud rate, which is a measurement of data transmission rate.  With
MIDI wireline, typically events (which are called packets) are sent
once per millisecond.  This is how a one megahertz Apple computer could
generate MIDI.  It also works out that a typical note event takes three
instructions to send, which is close to one MIDI wireline clock.

The MIDI wireline is also balanced, so that the transmission and
reception of the packets on the wire can use the same hardware
interface components.  This means that the individual devices can be
connected together as a common whole.   Typically there are events sent
on the wireline which cause the devices to shut down when the cable is
cut or unplugged.  The wireline itself is daisy-chained so that the
device can block messages from traveling to other parts of the network.

More confusion is over what is a MIDI device.  Usually a keyboard
contains some sort of synthetic sound source, so that the keyboard can
be used as a stand-alone instrument.  In reality the keyboard is two
MIDI devices: in one device the keys are send only, in the other the
synth is receive only.  These are connected inside the keyboard box to
make one unit.

With MIDI controlling a mechanical music device, the "synth" is
physical pipes and other percussion, like piano hammers against
strings, bar bells or dead animal skins.  With popular MIDI there are
all sorts of dials and foot controllers that can modify the note/phase
relationship throughout a whole show, even including the color of the
lighting.

Now let us take a look at USB.  USB (Universal Serial Bus) is a
master-slave protocol.  This means that there is a Host and a Slave.
The Host must request data from the Slave.  There can be only one Host
in the network (Big Brother).  This, up 'til recently, has required
a full-fledged CPU that can tell the difference between a printer, a
scanner, a mouse, data keyboard, hard disk drives and audio devices, all
which act like hungry children and demand to be fed at the same time.

MIDI under USB has been implemented as a subset of the Audio Device
class.  This is so that sequencers can send wave tracks to keyboard
synthesizers to play sampled sounds.  Most of us in the mechanical MIDI
world are more interested in sending MIDI note-on and -off events than
sending SYSEX control data and wave table samples to our Duo-Arts and
Wurlitzers.  (I still want to see someone implement the wire protocol
"tune" which is a request for the MIDI device to tune itself, rather
than a way to display the more obvious "tune" or track name.)

When the MIDI HID protocol was drafted it was designed to take much of
the feeding or nanny services from the computer and create a sort of
"Nanny Day Care" which will feed the hungry child -- the MIDI wire
protocol, a spoiled child that will throw its food to the floor when it
is not given attention every millisecond or so.  The HID protocol does
this by buffering several seconds of MIDI note/phase data into a USB
packet (or "playpen").  When the bell rings the MIDI data can now go
down the MIDI wireline in orderly single-file.  This also means that
the MIDI/USB bridge has to do the 31K clock and separate the boys
(transmitted data) from the girls (return data) and send them back to
the parent computer when soccer practice is over.  In other words it is
a complete computer.

The popularity of jump drives [a flash memory device carried in the
pocket] has created the demand for devices like cameras to be either
a Host or a Slave, so a new protocol was created called "USB on the Go".
This allows something like a jump drive to negotiate with a something
like a camera so that pictures can be exchanged.  This way one device
becomes the master and the other the slave.  This would probably make
the marquise proud, that there is a practical use for his life's work,
after all.

"USB on the Go" is really new.  I received Atmel's version in late
November 2006.  It seems to work with a special cable that has one
header if you are master, and a different dongle if you are using it
as a slave.  The documentation on these new chips is sketchy.  FTDI
began selling their "Vinculum" chip through Mouser only this week.

USB wireless has been out for some time.  The most popular versions use
Blue Tooth.  I have been using a wireless mouse for a few years.  This
is tested technology, and you recharge the batteries a lot.  All it
does is replace the wires that lead from the traditional CPU desktop or
laptop computer to the driver chips on the USB boards; the rest is the
same as for wired devices.

Here is where I see some obfuscation and confusion, that if the USB
wire can be replaced with wireless, then so can the MIDI wireline.
There is a problem here.  This is that MIDI is peer-to-peer (which the
RIAA does not like) and USB is Big Brother (where DRMs are coded into
the USB MIDI bridge.)  That means that to make MIDI wireless it is best
done between the computer/sequencer and the MIDI bridge.  This makes
the system work in only one direction wirelessly, the direction that is
controlled by the computer.  This works fine if, say, one is using a
Cakewalk or Van Bascoe sequencer program to connect to an M-Audio pod
and then to the piano.  There is still MIDI wireline between the piano
and the M-Audio pod.

If we make the MIDI wireless, without USB, we run into something like
Zeno's paradox where he sliced the runner on the track into smaller
and smaller units, and proved that the runner can not move.  If we put
a wireless transmitter/receiver on one side of the MIDI wire [send],
we must put the same on the other side of the MIDI wire [receive].  Now
we have to add clocking protocols and addressing as otherwise we could
introduce jitter in the conversion from electrical protocol to radio
frequency (RF) protocol.  MIDI wire protocol at 1/1000 second is slow
enough that this is probably not an issue.

This Zeno-like paradox gives question to the daisy chaining of MIDI
devices as how do you daisy chain RF?  The solution seems to be that
a microprocessor would need to be added to each MIDI plug.  So we start
replicating receivers all over the place like Zeno.

The solution then _is_ to keep the wireless on the USB side.  By using
"USB On the Go" protocol it will be possible to control instruments
from jump drives as these can become the master and send the data
through the USB->MIDI pod to the legacy wire device.  The question
remains, can this be done with off-the-shelf cables  or will dedicated
mechanical MIDI pods be needed to route and clock the data remotely?

In summary:

 - new chips have come on the market within the last year that will
allow for cross connection of MIDI and USB circuits,

 - the first generation of these devices are reaching the marketplace,

 - there is still a lot of confusion between the MIDI wire protocol and
MIDI file formats that save the music as note/phase data.

Julie Porter