On Wed, 24 Aug 2016, Maurizio Berti wrote:
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.
I did some tests using a couple of real-world devices (ok, synthesizers), both connected via USB and via good ole' fashioned 5-pin MIDI.
In both cases, when vkeybd says it's sending a pitch bend value of 8192, the resulting data that is actually output on MIDI is -8192, even though aseqdump and other MIDI dump programs I tried (kmidimon for one) displayed it as 8192. It is very evident when sending to a real world device, because as you bend upwards in vkeybd the pitch rises as expected, then suddenly jumps to the minimum value when vkeybd reaches 8192.
Conversely, when a real-world device sends a maximum positive MIDI pitch bend value, it is displayed as 8191 in aseqdump as would be expected.
I haven't done any further investigation, but it suggests to me that there are a couple of bugs here. First of all, that vkeybd attempts to send a pitch bend value that is larger than 8191, and secondly that such a large value is actually propagated within ALSA.
But perhaps larger-than-14-bit MIDI pitch bend messages are in fact allowed within ALSA, and only truncated once they're transferred over USB or MIDI ??? I would find that very odd, as they obviously never can be propagated in the real world, but I can't say I know for sure.
(BTW, thanks for mentioning vkeybd, I'd never heard of it before, but I've been looking for such a lightweight keyboard application for quick tests. Special bonus that you can actually play the computer keyboard to generate note messages. A bit odd with the Reverb and Chorus menus sending Roland sysex messages though...)
/Ricard