24 Jul
2006
24 Jul
'06
6:38 p.m.
I've never been a MIDI expert but I'm now having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1.
00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[..<y.p.9s..
00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C..<&..0D..
00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.>^
00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.>
Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in
the first line for example. I know that 0x80 is note-off, and 0x3D are
note number and 0x35 the velocity of the note-off. But what the heck is
the next byte, 0x31? The MIDI standard says note-off is one status byte
followed by 2 data bytes!
Lee
24 Jul
24 Jul
6:51 p.m.
Le 24 juil. 06 à 22:38, Lee Revell a écrit :
I've never been a MIDI expert but I'm now
having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F
".=51.:9..71..1.
00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0
[..<y.p.9s..
00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.
6C..<&..0D..
00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...
7c..C{.p.>^
00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E
11 ..:f..70..C21.>
Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in
the first line for example. I know that 0x80 is note-off, and 0x3D
are
note number and 0x35 the velocity of the note-off. But what the
heck is
the next byte, 0x31? The MIDI standard says note-off is one status
byte
followed by 2 data bytes!
Lee
Midi events in a Midi file are separated by time stamps
see :
http://www.borg.com/~jglatt/tech/midifile.htm
Stephane
6:57 p.m.
On Mon, 2006-07-24 at 16:38 -0400, Lee Revell wrote:
I've never been a MIDI expert but I'm now
having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1.
00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[..<y.p.9s..
00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C..<&..0D..
00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.>^
00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.>
Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in
the first line for example. I know that 0x80 is note-off, and 0x3D are
note number and 0x35 the velocity of the note-off. But what the heck is
the next byte, 0x31? The MIDI standard says note-off is one status byte
followed by 2 data bytes!
That's the standard for MIDI that is sent realtime over a wire. When it
is stored in a file you also need some sort of timestamp for each event.
The extra byte is the number of clock ticks to wait before you play the
event (since the last event).
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
7:08 p.m.
On Mon, 2006-07-24 at 22:57 +0200, Lars Luthman wrote:
On Mon, 2006-07-24 at 16:38 -0400, Lee Revell wrote:
OK. I was confused because I also see these timestamps when snooping
the MIDI output stream inside the kernel's MPU401 driver. I guess I
assumed that aplaymidi would deliver the events with correct timing,
rather than passing the timestamps through.
I guess if I played back the same MIDI file with a full featured
sequencer, I would only see the actual MIDI events in the driver?
Also, why doesn't every event have a timestamp? For example "81 0C 90
30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in
one "tick"?
Lee
I've never been a MIDI expert but I'm now
having to learn. I have a
question about this excerpt of a MIDI file viewed with hexedit.
00001BB0 22 80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F ".=51.:9..71..1.
00001BC0 81 0C 90 30 5B 00 90 3C 79 81 70 90 39 73 00 90 ...0[..<y.p.9s..
00001BD0 36 69 4B 80 36 43 0A 80 3C 26 01 80 30 44 0A 80 6iK.6C..<&..0D..
00001BE0 39 42 82 08 90 37 63 00 90 43 7B 81 70 90 3E 5E 9B...7c..C{.p.>^
00001BF0 00 90 3A 66 08 80 37 30 02 80 43 32 31 80 3E 11 ..:f..70..C21.>
Take the sequence "80 3D 35 31 80 3A 39 0E 80 37 31 03 80 31 1F" in
the first line for example. I know that 0x80 is note-off, and 0x3D are
note number and 0x35 the velocity of the note-off. But what the heck is
the next byte, 0x31? The MIDI standard says note-off is one status byte
followed by 2 data bytes!
That's the standard for MIDI that is sent realtime over a wire. When it
is stored in a file you also need some sort of timestamp for each event.
The extra byte is the number of clock ticks to wait before you play the
event (since the last event).
7:44 p.m.
[Mon, 24 Jul 2006 17:09:02 -0400]
Lee Revell <rlrevell(a)joe-job.com> eut le bonheur d'_crire:
Also, why doesn't every event have a timestamp?
For example "81 0C 90
30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in
one "tick"?
Actually delta times between events are encoded with a variable length
value. As long as bit 7 is 1, you must drop this very bit and add next
byte in the value decoding. Here; 81 0c is a variable length value:
delta 81 0c which is ((0x7f & 0x81) << 7) | 0x0c = 0x8c
event 90 30 5b
delta 00
event 90 3c 78
delta 81 70 which is 0xf0
hth
--
Nipo <nipo(a)ssji.net>
7:54 p.m.
On Tue, 2006-07-25 at 01:43 +0200, Nicolas Pouillon wrote:
[Mon, 24 Jul 2006 17:09:02 -0400]
Lee Revell <rlrevell(a)joe-job.com> eut le bonheur d'_crire:
Ugh. All I need to do is snoop note on, note off, and the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
So you are saying my driver needs to have full knowledge of the MIDI
state machine in order to snoop note on and note off?
Lee
Also, why doesn't every event have a
timestamp? For example "81 0C 90
30 5B 00 90 3C 79 81 70"? I guess multiple events can be scheduled in
one "tick"?
Actually delta times between events are encoded with a variable length
value. As long as bit 7 is 1, you must drop this very bit and add next
byte in the value decoding. Here; 81 0c is a variable length value:
delta 81 0c which is ((0x7f & 0x81) << 7) | 0x0c = 0x8c
event 90 30 5b
delta 00
event 90 3c 78
delta 81 70 which is 0xf0
hth
8:23 p.m.
[Mon, 24 Jul 2006 17:55:17 -0400]
Lee Revell <rlrevell(a)joe-job.com> eut le bonheur d'_crire:
Ugh. All I need to do is snoop note on, note off, and
the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
Bytes you read, when decoding smf-like stream (which is to say with
delta times in between) must be decoded differently whether you are
reading an event or a delta time, yes
So you are saying my driver needs to have full
knowledge of the MIDI
state machine in order to snoop note on and note off?
I believe so. You also may have to care about other midi specific
things to parse like
-Running command: Command byte (the one with 1 on bit 7) may be ommited
if it is the same as last one
-"Note on" with velocity 0 is considered as "note off" (most of the
time)
91 42 7f
81 30
91 41 3e
88 37
81 42 00
30
81 41 00
may be optimized as
(-- is an ommited repeated "running" command byte)
91 42 7f
81 30
-- 41 3e
88 37
81 42 00
30
-- 41 00
or even
91 42 7f
81 30
-- 41 3e
88 37
-- 42 00
30
-- 41 00
--
Nipo <nipo(a)ssji.net>
9:19 p.m.
On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote:
Ugh. All I need to do is snoop note on, note off, and
the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
So you are saying my driver needs to have full knowledge of the MIDI
state machine in order to snoop note on and note off?
Driver? This is a driver for a midi-port on a sound-card or a some kind
of midi-file player?
/jens
Lee
--
9:28 p.m.
On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen wrote:
On Mon, 2006-07-24 at 17:55 -0400, Lee Revell wrote:
It's similar to a driver for a MIDI port on a sound card, except the
driver additionally has to respond to note on and note off by twiddling
some other bits in the hardware. It's equivalent to having to flash an
LED for note on and another for note off.
I wrote the driver as an ALSA rawmidi device, which was probably not the
best idea - I did not realize at the time that I would have to interpret
the MIDI stream. An ALSA kernel sequencer client would have been more
appropriate.
I think I can get away with always treating 0x90 as note on and 0x80 as
note off regardless of the context.
(I can't release source or give the hardware details now, as the
hardware is still being developed)
Lee
Ugh. All I need to do is snoop note on, note
off, and the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
So you are saying my driver needs to have full knowledge of the MIDI
state machine in order to snoop note on and note off?
Driver? This is a driver for a midi-port on a sound-card or a some kind
of midi-file player?
9:33 p.m.
On Mon, 2006-07-24 at 19:28 -0400, Lee Revell wrote:
On Tue, 2006-07-25 at 01:19 +0200, Jens M Andreasen
wrote:
Confused again here. There are no delta-times in the midi-stream. You
mean: " ... have to interpret the midi *file*"
On Mon, 2006-07-24 at 17:55 -0400, Lee Revell
wrote:
It's similar to a driver for a MIDI port on a sound card, except the
driver additionally has to respond to note on and note off by twiddling
some other bits in the hardware. It's equivalent to having to flash an
LED for note on and another for note off.
I wrote the driver as an ALSA rawmidi device, which was probably not the
best idea - I did not realize at the time that I would have to interpret
the MIDI stream. An ALSA kernel sequencer client would have been more
appropriate. Ugh. All I need to do is snoop note on, note
off, and the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
So you are saying my driver needs to have full knowledge of the MIDI
state machine in order to snoop note on and note off?
Driver? This is a driver for a midi-port on a sound-card or a some kind
of midi-file player?
I think I can get away with always treating 0x90 as note on and 0x80 as
note off regardless of the context.
(I can't release source or give the hardware details now, as the
hardware is still being developed)
Lee
--
9:38 p.m.
On Tue, 2006-07-25 at 01:33 +0200, Jens M Andreasen wrote:
On Mon, 2006-07-24 at 19:28 -0400, Lee Revell wrote:
I think it's me that's confused - as you can see I'm certainly not a
MIDI expert.
When playing a MIDI file to a rawmidi port with aplaymidi, it was not
clear to me that it just passes the file through - I was under the
impression that the driver would only see the actual events, not the
timestamps and other metadata.
Lee
On Tue, 2006-07-25 at 01:19 +0200, Jens M
Andreasen wrote:
Confused again here. There are no delta-times in the midi-stream. You
mean: " ... have to interpret the midi *file*"
On Mon, 2006-07-24 at 17:55 -0400, Lee Revell
wrote:
It's similar to a driver for a MIDI port on a sound card, except the
driver additionally has to respond to note on and note off by twiddling
some other bits in the hardware. It's equivalent to having to flash an
LED for note on and another for note off.
I wrote the driver as an ALSA rawmidi device, which was probably not the
best idea - I did not realize at the time that I would have to interpret
the MIDI stream. An ALSA kernel sequencer client would have been more
appropriate. Ugh. All I need to do is snoop note on, note
off, and the note number.
But you're saying that 0x81 is sometimes part of a timestamp, and other
times it means note off on channel 1?
So you are saying my driver needs to have full knowledge of the MIDI
state machine in order to snoop note on and note off?
Driver? This is a driver for a midi-port on a sound-card or a some kind
of midi-file player?
9:47 p.m.
On Mon, 2006-07-24 at 19:38 -0400, Lee Revell wrote:
I think it's me that's confused - as you can
see I'm certainly not a
MIDI expert.
When playing a MIDI file to a rawmidi port ...
$man aplaymidi
-p, --port=client:port,...
Sets the sequencer port(s) to which the events
in the MIDI file(s) are sent.
-------------------------------------------------
I think it is unpossible to make it use rawmidi. Says sequencer (which
will do the timing.) Can you jack in after the sequencer has performed
its magic, and you have the actual midi-stream?
with aplaymidi, it was not
clear to me that it just passes the file through - I was under the
impression that the driver would only see the actual events, not the
timestamps and other metadata.
Lee
--
9:52 p.m.
On Tue, 2006-07-25 at 01:47 +0200, Jens M Andreasen wrote:
On Mon, 2006-07-24 at 19:38 -0400, Lee Revell wrote:
ALSA takes care of the sequencer port<->rawmidi device translation.
I think it's me that's confused - as you
can see I'm certainly not a
MIDI expert.
When playing a MIDI file to a rawmidi port ...
$man aplaymidi
-p, --port=client:port,...
Sets the sequencer port(s) to which the events
in the MIDI file(s) are sent.
-------------------------------------------------
I think it is unpossible to make it use rawmidi. Says sequencer (which
will do the timing.) Can you jack in after the sequencer has performed
its magic, and you have the actual midi-stream?
I thought I was doing exactly what you suggect, by looking at the data
in the driver right before it goes to the hardware.
I'll just use a real sequencer for testing rather than aplaymidi.
Lee
10:29 p.m.
On Mon, 2006-07-24 at 19:53 -0400, Lee Revell wrote:
Virtual Midi perhaps? a virtual midi device that shows up in both ALSA
and OSS. Route aplaymidi to the first virtual port and read the raw
stream from the new port called /dev/midi? (one number higher than the
highest number you had before)
# insmod snd_virmidi
will do the
timing.) Can you jack in after the sequencer has performed
its magic, and you have the actual midi-stream?
I thought I was doing exactly what you suggect, by looking at the data
in the driver right before it goes to the hardware.
I'll just use a real sequencer for testing rather than aplaymidi.
Lee
--
25 Jul
25 Jul
7:04 a.m.
Lee Revell wrote:
I was confused because I also see these timestamps
when snooping
the MIDI output stream inside the kernel's MPU401 driver. I guess I
assumed that aplaymidi would deliver the events with correct timing,
rather than passing the timestamps through.
The MIDI data at a raw MIDI port never has timestamps. What you see are
the data bytes of the next MIDI command where the command byte itself
has been omitted because it would be identical to the last one. (ALSA's
sequencer event -> rawmidi converter uses running status by default.)
The running status and the zero note-on velocity (see Nicolas' mail) are
the only special cases your parser has to look out for.
HTH
Clemens
2:11 p.m.
Lee Revell wrote:
On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch
wrote:
snd_midi_event_no_status(), but this cannot be changed by a driver.
This setting wouldn't apply to data written directly to the rawmidi port
anyway.
Regards,
Clemens
(ALSA's
sequencer event -> rawmidi converter uses running status by default.)
"By default" - so it can it be disabled? How?
2:31 p.m.
On Tue, 2006-07-25 at 18:11 +0200, Clemens Ladisch wrote:
Lee Revell wrote:
It would in fact be useful for my testing to add a command line option
to aplaymidi to have it not use running status. But, I see that
aplaymidi rolls its own events rather than using snd_midi_event_t, so
it's not at all clear how to do it.
Lee
On Tue, 2006-07-25 at 11:03 +0200, Clemens
Ladisch wrote:
snd_midi_event_no_status(), but this cannot be changed by a driver.
This setting wouldn't apply to data written directly to the rawmidi port
anyway. (ALSA's
sequencer event -> rawmidi converter uses running status by default.)
"By default" - so it can it be disabled? How?
2:53 p.m.
On Tue, 2006-07-25 at 10:26 -0400, Lee Revell wrote:
On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch
wrote:
Are you sure you would want to do that? Because running status by itself
would be just:
for(;;)
{
thisByte = nextByte();
if(thisByte & 0x80)
runningStatus = thisByte;
//... after which we get that:
if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
{
thisByte = nextByte();
thisByte = nextByte();
// note_on with zero velocity is note_off
if(thisByte == 0 || runningStatus == NOTE_OFF)
setLed(NOTE_OFF);
else
setLed(NOTE_ON);
}
}
(ALSA's
sequencer event -> rawmidi converter uses running status by default.)
"By default" - so it can it be disabled? How?
Lee
--
3 p.m.
Bzzzt ... My wrong!
thisByte = nextByte();
for(;;)
{
if(thisByte & 0x80)
runningStatus = thisByte;
//... after which we get that:
if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
{
thisByte = nextByte();
thisByte = nextByte();
// note_on with zero velocity is note_off
if(thisByte == 0 || runningStatus == NOTE_OFF)
setLed(NOTE_OFF);
else
setLed(NOTE_ON);
}
else
thisByte = nextByte();
}
> Lee
>
--
5:55 p.m.
Hmmm, does this really work? I don't think so.
Example:
1. status: note on (-> thisByte -> runningStatus)
2. data: key (-> thisByte, ignored)
3. data: vel (-> thisByte, checked against 0, checked againt 0x80)
4. status: note off (read as key !!!)
5. data: key (read as vel, checked against 0x80 !!!)
6. data: vel (read as key !!!)
7. status: note on (read as vel, checked against 0x80 !!!)
The Problem is, that the second data byte is used for the running status
byte test.
Yours,
Jacob
On Tue, Jul 25, 2006 at 07:00:54PM +0200, Jens M Andreasen wrote:
Bzzzt ... My wrong!
thisByte = nextByte();
for(;;)
{
if(thisByte & 0x80)
runningStatus = thisByte;
//... after which we get that:
if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
{
thisByte = nextByte();
thisByte = nextByte();
// note_on with zero velocity is note_off
if(thisByte == 0 || runningStatus == NOTE_OFF)
setLed(NOTE_OFF);
else
setLed(NOTE_ON);
}
else
thisByte = nextByte();
}
> Lee
>
--
9:55 p.m.
On Tue, 2006-07-25 at 21:55 +0200, Jacob wrote:
Hmmm, does this really work? I don't think so.
Example:
1. status: note on (-> thisByte -> runningStatus)
2. data: key (-> thisByte, ignored)
3. data: vel (-> thisByte, checked against 0, checked againt 0x80)
4. status: note off (read as key !!!)
5. data: key (read as vel, checked against 0x80 !!!)
6. data: vel (read as key !!!)
7. status: note on (read as vel, checked against 0x80 !!!)
The Problem is, that the second data byte is used for the running status
byte test.
Yours,
Jacob
Ehmm ... Right! Just checking if you were awake :-D
Furthermore, it did not do the single byte SysRt either. But there ought
to be a small, reasonable solution out there somewhere ... Giving it one
more try:
for(;;)
{
thisByte = nextByte();
if(thisByte & 0x80) // got new status
runningStatus = thisByte, count = 0;
if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
{
while(count < 2) // we need data1 and data2
{
thisByte = nextByte();
// filter out single byte SysRt
count += !(thisByte & 0x80);
}
if(thisByte == 0 || runningStatus == NOTE_OFF)
setLed(NOTE_OFF);
else
setLed(NOTE_ON);
// assume we will keep runningStatus
count = 1;
}
}
On Tue, Jul 25, 2006 at 07:00:54PM +0200, Jens M
Andreasen wrote:
> Bzzzt ... My wrong!
>
>
> thisByte = nextByte();
>
> for(;;)
> {
>
> if(thisByte & 0x80)
> runningStatus = thisByte;
>
> //... after which we get that:
>
> if(runningStatus == NOTE_ON || runningStatus == NOTE_OFF)
> {
> thisByte = nextByte();
> thisByte = nextByte();
>
> // note_on with zero velocity is note_off
> if(thisByte == 0 || runningStatus == NOTE_OFF)
> setLed(NOTE_OFF);
> else
> setLed(NOTE_ON);
> }
> else
> thisByte = nextByte();
> }
> > > Lee
> > >
> --
>
--
26 Jul
26 Jul
4:51 a.m.
On Wed, 26 Jul 2006, Jens M Andreasen wrote:
if(runningStatus == NOTE_ON || runningStatus ==
NOTE_OFF)
If you plan to receive messages from other channels than 0 you have to
use (runningStatus & 0xF0) instead of the full runningStatus and perhaps
check for (runningStaus & 0x0F) == receiveChannel..
--
Ari
6:01 a.m.
Ari Kauppi wrote:
On Wed, 26 Jul 2006, Jens M Andreasen wrote:
Okay, here is my entry to the Official LAD MIDI Parser Contest 2006:
void handleByte(u8 byte)
{
/* in a driver, these static variables should go into some struct: */
static enum {
STATE_UNKNOWN, /* not a note command */
STATE_NOTE1, /* expecting 1st data byte (note) */
STATE_NOTE2, /* expecting 2nd data byte (velocity) */
} state = STATE_UNKNOWN;
static u8 command;
static u8 note;
if (byte >= 0xf8) /* real-time command */
;
else if (byte & 0x80) { /* status byte */
command = byte;
/* note-on or note-off? */
state = (byte & 0xf0) <= 0x90 ? STATE_NOTE1 : STATE_UNKNOWN;
} else { /* data byte */
if (state == STATE_NOTE1) {
note = byte;
state = STATE_NOTE2;
} else if (state == STATE_NOTE2) {
if ((command & 0xf0) == 0x90 && byte > 0) {
/* note on */
} else {
/* note off */
}
state = STATE_NOTE1;
}
}
}
Regards,
Clemens
if(runningStatus == NOTE_ON || runningStatus
== NOTE_OFF)
If you plan to receive messages from other channels than 0 you have to
use (runningStatus & 0xF0) instead of the full runningStatus and perhaps
check for (runningStaus & 0x0F) == receiveChannel..
8:26 a.m.
On Wed, 26 Jul 2006, Clemens Ladisch wrote:
Ari Kauppi wrote:
Good try but it still has at least one potential problem: according to
MIDI spec running status should be set only with channel messages.
Sysex/common messages should reset it to undefined (0).
With this exact implementation it shouldn't cause any problems but if the
parser is extended/modified later it might become a pretty hard to find
bug with some input..
On Wed, 26 Jul 2006, Jens M Andreasen wrote:
Okay, here is my entry to the Official LAD MIDI Parser Contest 2006: if(runningStatus == NOTE_ON || runningStatus
== NOTE_OFF)
If you plan to receive messages from other channels than 0 you have to
use (runningStatus & 0xF0) instead of the full runningStatus and perhaps
check for (runningStaus & 0x0F) == receiveChannel.. void handleByte(u8 byte)
{
/* in a driver, these static variables should go into some struct: */
static enum {
STATE_UNKNOWN, /* not a note command */
STATE_NOTE1, /* expecting 1st data byte (note) */
STATE_NOTE2, /* expecting 2nd data byte (velocity) */
} state = STATE_UNKNOWN;
static u8 command;
static u8 note;
if (byte >= 0xf8) /* real-time command */
;
else if (byte & 0x80) { /* status byte */
command = byte;
/* note-on or note-off? */
state = (byte & 0xf0) <= 0x90 ? STATE_NOTE1 : STATE_UNKNOWN;
} else { /* data byte */
if (state == STATE_NOTE1) {
note = byte;
state = STATE_NOTE2;
} else if (state == STATE_NOTE2) {
if ((command & 0xf0) == 0x90 && byte > 0) {
/* note on */
} else {
/* note off */
}
state = STATE_NOTE1;
}
}
}
--
Ari
10:06 a.m.
On Wed, Jul 26, 2006 at 01:25:38PM +0300, Ari Kauppi wrote:
Good try but it still has at least one potential
problem: according to
MIDI spec running status should be set only with channel messages.
Sysex/common messages should reset it to undefined (0).
I don't have a midi spec at hand here. Do you mean running status
is shared by all channels and not per channel ? This would make
it less than trivial to combine or split midi streams.
Say chan 1 has set RS to some value, and the next command on this
channel doesn't have a status byte but uses the RS. Now we merge in
a second channel that modifies RS in between the two commands on chan 1.
Suddenly the second one of those _does_ need a status byte...
--
FA
Lascia la spina, cogli la rosa.
10:16 a.m.
On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen wrote:
I don't have a midi spec at hand here. Do you mean
running status
is shared by all channels and not per channel ? This would make
it less than trivial to combine or split midi streams.
The channel is part of the status byte.
Chris
11:19 a.m.
On Wed, 26 Jul 2006, Chris Cannam wrote:
On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen
wrote:
Yep. Channel message means MIDI events with status byte 0x80 - 0xEF. For
status bytes 0xF0 - 0xFF running status should not be used and the
internal running status buffer should be cleared.
--
Ari
I don't have a midi spec at hand here. Do you
mean running status
is shared by all channels and not per channel ? This would make
it less than trivial to combine or split midi streams.
The channel is part of the status byte.
12:38 p.m.
On Wed, 2006-07-26 at 16:18 +0300, Ari Kauppi wrote:
On Wed, 26 Jul 2006, Chris Cannam wrote:
You meant to say: For status bytes 0xF0 - 0xF7 running status should be
cleared. For 0xF8 - 0xFF (single byte SysRt) it should be maintained.
Isn't the status implicitly cleared if you set it to, say 0xF0? Which is
to say that it is the SysRt exceptions that matters.
Who said it was hot today?
--
On Wednesday 26 Jul 2006 13:06, Alfons Adriaensen
wrote:
Yep. Channel message means MIDI events with status byte 0x80 - 0xEF. For
status bytes 0xF0 - 0xFF running status should not be used and the
internal running status buffer should be cleared.
I don't have a midi spec at hand here. Do you
mean running status
is shared by all channels and not per channel ? This would make
it less than trivial to combine or split midi streams.
The channel is part of the status byte.
9:56 a.m.
On Wed, 2006-07-26 at 09:51 +0300, Ari Kauppi wrote:
On Wed, 26 Jul 2006, Jens M Andreasen wrote:
Thanx!
In this case I think we can get by without increasing instruction count,
like this:
if((runningStatus - NOTE_OFF) < 0x20) // note_on or note_off
{
... and keep switch(runningStatus & 0xF0) in mind for an extension.
The receive channel is better handled in the note on/off function(s).
There can be all kinds of differences between channels that the parser
need not to have any knowledge of.
If this is going to be some kind of Official Blinking Light Parser
Contest, I better do an explicit rewrite so it can compile :-)
Those who chip in, get to share the prize!
--
if(runningStatus == NOTE_ON || runningStatus
== NOTE_OFF)
If you plan to receive messages from other channels than 0 you have to
use (runningStatus & 0xF0) instead of the full runningStatus and perhaps
check for (runningStaus & 0x0F) == receiveChannel.. 
25 Jul
25 Jul
2:38 p.m.
On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch wrote:
Lee Revell wrote:
What about the 1-byte "realtime" events?
(un-normalized MIDI reeally sucks...)
-DR-
I was confused because I also see these
timestamps when snooping
the MIDI output stream inside the kernel's MPU401 driver. I guess I
assumed that aplaymidi would deliver the events with correct timing,
rather than passing the timestamps through.
The MIDI data at a raw MIDI port never has timestamps. What you see are
the data bytes of the next MIDI command where the command byte itself
has been omitted because it would be identical to the last one. (ALSA's
sequencer event -> rawmidi converter uses running status by default.)
The running status and the zero note-on velocity (see Nicolas' mail) are
the only special cases your parser has to look out for.
5:34 p.m.
On Tue, Jul 25, 2006 at 12:38:50PM -0400, Dave Robillard wrote:
On Tue, 2006-07-25 at 11:03 +0200, Clemens Ladisch
wrote:
IIRC, real-time events (1 byte, status byte 0xf8 - 0xff) may happen at
_any time_ (even between 2 data bytes) without affecting the current message.
That includes that it must not be remembered as last status byte
(real-time messages don't have data bytes).
Another issue are system common messages (0xf0 - 0xf7). These status
codes must not be stored as running status either, so there must be a
status byte after each system common message. But this is not an issue
here I think, I just added it for completeness.
Jacob
Lee Revell wrote:
The running status and the zero note-on velocity (see Nicolas' mail) are
the only special cases your parser has to look out for.
What about the 1-byte "realtime" events?
(un-normalized MIDI reeally sucks...)
-DR-
6478
days inactive
6480
days old
linux-audio-dev@lists.linuxaudio.org
32 comments
11 participants
participants (11)
-
Alfons Adriaensen -
Ari Kauppi -
Chris Cannam -
Clemens Ladisch -
Dave Robillard -
Jacob -
Jens M Andreasen -
Lars Luthman -
Lee Revell -
Nicolas Pouillon -
Stéphane LETZ