[openbeos-midi] Re: MIDI parser source (bytestream->MIDI messages)
- From: "Martijn Sipkema" <msipkema@xxxxxxxxxxxxxxxxxxx>
- To: <openbeos-midi@xxxxxxxxxxxxx>
- Date: Wed, 28 Jan 2004 21:53:53 +0100
Why don't you look at the code for the unitor_server I made
available earlier? It had a MIDI stream parser that if I remeber
correctly should be reasonably ok, at least it doesn't have as
obvious "features" as you mention your current one has :).
--ms
----- Original Message -----
From: "Christian Packmann" <Christian.Packmann@xxxxxx>
To: <openbeos-midi@xxxxxxxxxxxxx>
Sent: Wednesday, January 28, 2004 20:59
Subject: [openbeos-midi] Re: MIDI parser source (bytestream->MIDI messages)
Matthijs Hollemans wrote:
> Christian wrote:
> > But I think there's a bug, or rather a missing workaround, in the code.
>
> Thanks. I'll add that to the never-ending to-do list :-)
Uhm... bad news: I started coding my parser, and soon realized that
MidiPortProducer::GetData() is utterly broken.
It does not keep track of Running Status, nor will it handle RealTime
messages interspersed into multi-byte messages correctly (only RealTime
within SysEx is handled okay).
<http://www.borg.com/~jglatt/tech/midispec/run.htm> says:
"The MIDI spec allows for a MIDI message to be sent without its Status byte
(ie, just its data bytes are sent) as long as the previous, transmitted
message had the same Status. This is referred to as running status. Running
status is simply a clever scheme to maximize the efficiency of MIDI
transmission (by removing extraneous Status bytes). The basic philosophy of
running status is that a device must always remember the last Status byte
that it received (except for RealTime), and if it doesn't receive a Status
byte when expected (on subsequent messages), it should assume that it's
dealing with a running status situation. A device that generates MIDI
messages should always remember the last Status byte that it sent (except
for RealTime), and if it needs to send another message with the same
Status, the Status byte may be omitted."
And <http://www.borg.com/~jglatt/tech/midispec/real.htm> tells us:
"Each RealTime Category message (ie, Status of 0xF8 to 0xFF) consists of
only 1 byte, the Status. These messages are primarily concerned with
timing/syncing functions which means that they must be sent and received at
specific times without any delays. Because of this, MIDI allows a RealTime
message to be sent at any time, even interspersed within some other MIDI
message. For example, a RealTime message could be sent inbetween the two
data bytes of a Note On message. A device should always be prepared to
handle such a situation; processing the 1 byte RealTime message, and then
subsequently resume processing the previously interrupted message as if the
RealTime message had never occurred."
Basically this means that MidiPortProducer::GetData() can be thrown away -
it'll have to be totally rewritten to parse MIDI streams correctly.
But... good news: as I need a MIDI parser urgently, I've started coding one
which takes the above requirements into account. It should be ready within
1-2 weeks (if I can hide from Murphy).
I'll test it within SerialMidiHost, and once it works okay, I can write a
fixed MidiPortProducer::GetData(). I currently don't have time to setup
OBOS CVS on my machine, so somebody else would have to do integration &
testing. But I guess that's preferable to having to write that stuff from
the ground up. ;-)
Bye,
Chris
Other related posts:
