[alsa-devel] Range of pitchbend MIDI events

[Maurizio Berti]

> Actually, no, after the first three bytes (status byte and two data
> bytes), running status is employed, so that if the third byte received is
> not a status byte, it will be regarded as the first data byte of a
> subsequent pitch bend message.
>
> e.g. for channel 1:
>
> 0xE0 0x00 0x40 is a complete pitch bend message, if two subsequent bytes
> 0x12 0x40 are received, they are interpreted as another pitch bend value,
> the 0xE0 being implicit since no new status byte has been given. If the
> bytes are sent in quick succession, the first bend value (0x00 0x40 in
> this case) might not have any audible effect, and the impression one gets
> as a listener is that it's the last two bytes which are the only ones
> received or acted on.

That's what I thought it was happening, and I don't know how to intercept
the incoming byte data, but it looks to me that this does not involve the
implicit status byte: what aseqdump actually prints (and I get from
alsaseq) is a single pitchbend event using a value out of range, as I
mentioned vkeybd too is able to send and get accepted a 8192 pitchbend.
Correct me if I'm wrong, but looks like a single 3 bytes message (or a 4
byte one, maybe). If that's not the case, I think I should see two
pitchbend event, being the first equal 0, and the second 127.

> I don't know anything about pyalsa, but if it creates more bytes than
> specified in the protocol because higher values than allowed are requested
> I'd say it's buggy.

I think that it's "allowed" for performance reasons, provided that the
programmer shouldn't send out of range events, still, the conversion can
generate confusion, if there is no consistence with other 2 bytes limited
events from alsa.

Maurizio