On Tue, 23 Aug 2016, Maurizio Berti wrote:
I was playing with pyalsa and I realized an unexpected behavior with pitchbend events. The pitchbend range should be, by MIDI standard, between -8192 and +8191, or 0-16384. Being a 3 byte event, it should ignore any subsequent byte received.
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.
Using pyalsa I'm able to create events with values greater than 127 and they are translated using as many bytes as possible; in fact, if I create a note event with a note value of 8193, I receive a value 1 (using the first byte of a 2 byte value with 7bit format).
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.
/Ricard