My reasoning is something like this:

	GrainWave deals with a MIDI note-on as an independent trigger event. 
It is independent because there is no relation implied by GrainWave
between different MIDI note numbers.  64/Channel 1 might be 1 half-step
higher than 63/Channel 1 or it might control a completely different
instrument.  The only purpose to the note numbers is to differentially
trigger different parts of an instrument.  The instrument designer
builds a map which associates particular note-ons with the triggering of
particular notes.  This means that GrainWave has 2048 (128 * 16)
different trigger messages, which can handle an extremely complex
instrument (remember, the note number doesn't have anything to do with,
for instance, frequency, so you don't have to waste 128 triggers to
provide a complete scale).
	Once a note has been triggered, GrainWave makes available the
associated note information (number, velocity) to the instrument, if it
wants to use it.  This is where the limitations of MIDI come in.  A
GrainWave designer may want 6 floating point parameters to be passed
along with the note-on, but this can't happen inside MIDI.  Thus the new
protocol.  The MIDI event is passed to the normal MIDI handler, where it
is treated like a standard MIDI event.  The rest of the data is passed
along and made available once the event happens.  One major reason is
due to the UI.  GrainWave already has an MIDI assignment UI, which would
still need to be in place for those using standard MIDI.  It would be
far more complex to add a second mapping UI for a second complete
triggering system.  Instead, I can use the same UI, but extend the functionality.
	I think that any protocol should separate the event identifier (note
number) from any associated parameters (like frequency).  It makes sense
to have a limited number of identifiers, so an integer value works well.
 Also, the receiver can have a single value which it recognizes as a
event it responds to, instead of a range.  However, an integer parameter
is a real pain for continuous values like frequency, since you have to
make a map at the receiver, not the controller where the map should be.
Michael Gogins wrote:
> 
> This is interesting, but I don't understand the motivation for using
> additional fields for note number and velocity, instead of simply increasing
> the precision of the existing MIDI fields as in SKINI.
> 
> -----Original Message-----
> From: Mike Berry 
> To: csound csound 
> Date: Monday, July 26, 1999 11:21 AM
> Subject: Re: sequencer
> 
> > The solution that I am working on implementing in my own software uses
> >MIDI as a base identifier with further long and floating point tags in
> >the message.  So a note on might look like:
> >
> >long NumberOfMidiBytes  = 3
> > unsigned char  = 0x90  (Note On)
> > unsigned char  = 0x20  (Note number)
> > unsigned char  = 0x80  (Velocity)
> > unsigned char pad
> >long Number OfLongParameters = 2
> > long LongParam1
> > long LongParam2
> >long Number OfFloatParameters = 3
> > float FloatParam1
> > float FloatParam2
> > float FloatParam3
> >
> > So, for instance, LongParam1 might be the duration of the note.
> >FloatParam1 might be the pitch of the note in Hz.  And these could be
> >defined by the receiver however they wished, and with as many p fields
> >as necessary.  I pass these messages using UDP.  When the UDP is
> >received, the receiver determines if only MIDI is supported or if the
> >extended format is supported, and parses out the message accordingly.
> > Obviously the gap is in hardware - I don't have a slider box which
> >supports anything besides MIDI.  But when the communication is between
> >two pieces of software, this is easy to use.
> > I preserve the MIDI data also because it is a useful format for
> >defining triggering information, particularly if your app already has a
> >MIDI triggering system built in (as GrainWave does).  So these messages
> >can enter into that triggering system but still carry further data.
> >--
> >Mike Berry
> >mikeb@nmol.com
> >http://www.nmol.com/users/mikeb


-- 
Mike Berry
mikeb@nmol.com