[alsa-devel] Range of pitchbend MIDI events

Ricard Wanderlof ricard.wanderlof at axis.com
Wed Aug 24 21:32:33 CEST 2016


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


More information about the Alsa-devel mailing list