[sdiy] Processing Midi - Dropping Notes

[Theo]

MessageAgreed it was just a example, however a valid example, its allowed and may occur.
For fail save midi reception you need to use a method similar to the one I described before using a running "status buffer" and "first data byte flag" + "first data byte buffer".
The method I described in the first mail automatically takes care of all possible midi input including sysex, running status and realtime messages.
BTW the MMA has flow diagrams for midi reception, all are variations of this same method.

To rely on just a few specific situations like you suggested is not the preferred design.

Theo



  ----- Original Message ----- 
  From: phillip m gallo 
  To: 'Theo' 
  Cc: synth diy 
  Sent: Friday, July 16, 2004 10:34 PM
  Subject: RE: [sdiy] Processing Midi - Dropping Notes


  Theo,

  The issuance of a Note On message should preclude the need for an Active Sense  message.   I have no doubt that folks violate the intent of Active Sensing by tying it to some blind timer based routine, but Active Sensing is intended to occur when there is no other traffic that would indicate the MIDI link is "in service".

  regards,
  p

  -----Original Message-----
  From: owner-synth-diy at dropmix.xs4all.nl [mailto:owner-synth-diy at dropmix.xs4all.nl] On Behalf Of Theo
  Sent: Friday, July 16, 2004 1:22 PM
  To: synth-diy at dropmix.xs4all.nl; David Brown
  Subject: Re: [sdiy] Processing Midi - Dropping Notes


  Hi David,

  Yes real-time messages can replace expected data just like the example you gave.
  Yes the real time message is guaranteed to be one byte only, but more than one real-time message is possible.

  Like:
  Note on
  Note value
  Real-time active sensing 
  Real-time timing clock
  Note velocity

  Or:
  Note on
  Real-time active sensing 
  Note value
  Real-time timing clock
  Note velocity

  The real time messages are:
  $F8 - Timing clock
  $F9 - undefined
  $FA - start
  $FB - continue
  $FC - stop
  $FD - undefined
  $FE - active sensing
  $FF - system reset

  The other one byte messages ($F1...$F7) are not real-time and not allowed to go in-between the data of other messages.
  However I like to pars them as if they where real-time messages, part for easy of coding.
  But also because of timing.
  "Midi time code quarter frame" ($F1) is one of them, you don't like that one waiting in a FIFO too long.
  And having "Song select"($F3) or "Song position pointer"($F2) waiting in the FIFO while $FA "start" is received and executed in is also a bit sloppy.

  Best use a method that takes care of these things automatically.
  Like the one I described in the other message.

  Cheers,
  Theo



    ----- Original Message ----- 
    From: David Brown 
    To: synth-diy at dropmix.xs4all.nl 
    Sent: Friday, July 16, 2004 6:14 PM
    Subject: Re: [sdiy] Processing Midi - Dropping Notes


    At 09:34 PM 7/13/2004, you wrote:

      For even more fun there is also "real time messages" that can come in-between the bytes of other messages.
       
      The real time messages are one byte only.
      So just check if a message is real time, then do something with it, like nothing at all.

    Can you clarify the real time messages?  I'm writing my own MIDI parser and I don't know if I have handled it correctly.  Specifically, can a real time message replace the expected data in a message?  For example ...

    Note on command
    Note value
    Real time message
    Note velocity

    In this case, is the real time message always guaranteed to be one byte?

    Thanks. - Dave 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://synth-diy.org/pipermail/synth-diy/attachments/20040717/a5a76e13/attachment.htm>