[sdiy] Processing Midi - Dropping Notes

[Paul Maddox]

All,

FYI, what I do with anything over 0xF0 is put it in a seperate buffer
(realtime buffer I usually call it), set a flag
Carry on processing my note data (only that one note, not a whole stream),
then at the end of sorting my note data, check the flag,
if its set, then process the realtime buffer.
Given most micro controllers run at over 4MIPs, there shouldn't be any
noticeable delay in handling real time events such as clock in this way.

Paul


----- Original Message -----
From: "phillip m gallo" <philgallo at attglobal.net>
To: "'Theo'" <t.hogers at home.nl>
Cc: "synth diy" <synth-diy at dropmix.xs4all.nl>
Sent: Saturday, July 17, 2004 12:28 AM
Subject: RE: [sdiy] Processing Midi - Dropping Notes


> Theo,
>
> Think you mis-understand.  I didn't/don't advise coding for a few
> specific cases.
>
> Instead the entire MIDI Status set should be carefully considered, and
> planned for, even in cases where you intend to do no more than drop the
> message.
>
> When using either method (buffered or on the fly), message sequencing
> and traffic implications were where the real work in implementing,
> seemed to lie.
>
> Haven't seen the MMA flows will give them a look, thanks for the ref.
>
>
> regards,
> p
>
>
> -----Original Message-----
> From: Theo [mailto:t.hogers at home.nl]
> Sent: Friday, July 16, 2004 3:47 PM
> To: philgallo at attglobal.net
> Cc: synth diy
> Subject: Re: [sdiy] Processing Midi - Dropping Notes
>
>
> Agreed 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  <mailto:philgallo at attglobal.net> m gallo
> To: 'Theo' <mailto:t.hogers at home.nl>
> Cc: synth diy <mailto:synth-diy at dropmix.xs4all.nl>
> 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  <mailto:davebr at earthlink.net> 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
>
>