On Tue, 19 May 1998, Dan Walkowski wrote:

> >  This sound like realtime sysex MIDI messages and/or controller data
> >(aftertouch, for example) barreling on through.
> >
> >  Also, are you handling "running status" message modes correctly?
>
> Assuming they have the same structure as other MIDI messages, then yes.
> We read every byte, discarding all until we see either a note on or a note
> off.  When we do, we read the next 2 bytes, to get the velocity and note
> number.  We act on that message, and then go back to looking for note on or
> note off messages.

  This is where running status mode will cause you a problem.  To save
overhead, notes played after the intial "note on" for a given midi channel
do not have to have a note-on/mote-off message header byte.  They can have
those bytes, but they don't *have to*.  Instead, subsequent 2-byte note &
velocity (with 0=note off) messages are valid notes.

  Running status can happen for any note or controller event.  The
current running status mode is canceled upon the receipt of the next valid
message header, at which time a new running status mode may be done.

  Some MIDI sources don't use it, some do.

> We can send messages as fast as they can be generated from midi device #1,
> and nothing gets dropped.  With other midi devices, if we send messages
> close together, the second one gets dropped.  If they are sent slower, they
> work.  Note that 'too fast', in this case, is still nowhere near full MIDI
> throughput, even though we can handle that from the first device.

  Try adjusting your midi_in routine to do running status.  It sounds like
the midi source resends note-on headers if some amount of time has passed
between successive running state notes.

  --Scott

/**/