FW: [sdiy] Processing Midi - Dropping Notes

[phillip m gallo]

-----Original Message-----
From: phillip m gallo [mailto:philgallo at attglobal.net]
Sent: Friday, July 16, 2004 5:53 PM
To: Theo
Subject: RE: [sdiy] Processing Midi - Dropping Notes


Theo,

Your point is well made and those who have implemented MIDI interfaces no
doubt appreciate it's implication.

Given the number of inquiries i see across various lists regarding MIDI
input processing, i would wager a web page devoted to MIDI input processing
would be very popular and save many a great deal of frustration.

regards,
p

-----Original Message-----
From: Theo [mailto:t.hogers at home.nl]
Sent: Friday, July 16, 2004 5:30 PM
To: philgallo at attglobal.net
Cc: synth diy
Subject: Re: [sdiy] Processing Midi - Dropping Notes


Ok I mis-understood you.
My point was that there is a easy fast and simple to implement solution for
the message sequencing and stuff.
Only about three jumps/evaluations for every byte and the difficult cases
fall in place on their own.
It works both on the fly and when using FIFO.
Think i will cookup a webpage about midi reception as the question comes up
every now and then.
Not that I am a expert but it will add content to my now empty SDIY web page
:)

Cheers,
Theo



----- Original Message -----
From: phillip m gallo
To: 'Theo'
Cc: synth diy
Sent: Saturday, July 17, 2004 1: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 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
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.715 / Virus Database: 471 - Release Date: 7/4/04

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.715 / Virus Database: 471 - Release Date: 7/4/04