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 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
