Range of pitchbend MIDI events

Range of pitchbend MIDI events

[Maurizio Berti]

Hello,
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.

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).
That's fine, I suppose it's by architecture (I'm not a programmer, I just
play around with python, I'm just assuming this).
The problem comes with pitchbend values, since it looks like alsa accepts
values greater than 8191 and does not ignore the exceeding bytes as it
should; that is, I'm able to send 8192, and that's what vkeybd does.
The transformation here is the issue, since receiving programs seem to
translate only the latest two bytes, that's why vkeybd (and other software
too) shouldn't have a 8192 value.
That can be confusing, for example, using a2jmidi: the end of the pitchbend
scale is suddenly a 0 value; I know that vkeybd is not the ultimate
software in music production, but, still, it shouldn't be able to do so, I
think :)

I don't know if, maybe, there's some less known aspect regarding pitchbend,
and, as I mentioned before, I don't know a thing about programming, nor how
actually works ALSA under the hood. Anyway, I think there should be some
kind of range control, at least with pyalsa, if not by alsa at all.

What do you think?

Regards,
Maurizio

-- 
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Range of pitchbend MIDI events

[Ricard Wanderlof]

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
-- 
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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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

Re: Range of pitchbend MIDI events

[Ricard Wanderlof]

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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Range of pitchbend MIDI events

[Maurizio Berti]

[...]
> 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.

I just made a new test, thinking about the status byte, I created a pitch
bend event with value 123456789, which has bit length of 27, hence 4 7-bit
bytes.
If I've understood correctly how MIDI works, that should mean that I've
sent a 5 bytes group, being the first the status byte, the first pair the
first pitch bend, and the last a second pitch bend event without the status
byte. That's not the case, I can actually see a pitch bend value of
123456789 on aseqdump.
According to every program I've seen that relates to ALSA but works with an
"external" environment (as you mentioned, physical devices, but also
a2jmidi and others) just gets the first two bytes of the event value.


> 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.

I also thought about ALSA being "permissive" with malformed events, but
then I remembered that that range is clearly specified in the alsaseq
documentation:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___seq_middle.html#ga8da40bfd56e00ebec775e5241d86a3e3
One would expect that out of range values should be at least corrected to a
default (maximum?) value or, eventually, raise an exception or return null.
I might be speaking nonsense here, as far as I know ALSA is written in C
and C doesn't have exceptions. But, still.

Now. I already know that this is actually a trivial issue, and, if it's a
real bug, that trivialness might explain why nobody found out about it in
more than 15 years. ;)
It can be still confusing, though, and I think it should be corrected (or,
at least, explained) eventually.

> (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...)

You're welcome :) vkeybd is really a tiny yet very useful piece of
software, I use it indeed everytime I need quick tests.
By the way, its developer is Takashi Iwai, which is active here too, so we
should alert him about this thread and ask him about those sysex messages :)

Maurizio

--
È difficile avere una convinzione precisa quando si parla delle ragioni del
cuore. - "Sostiene Pereira", Antonio Tabucchi
http://www.jidesk.net
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Range of pitchbend MIDI events

[Clemens Ladisch]

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.
>
> Using pyalsa I'm able to create events with values greater than 127

The ALSA sequencer does not use the MIDI byte format for its events.

Sequencer events use a 32-bit field for controller values:
http://www.alsa-project.org/alsa-doc/alsa-lib/structsnd__seq__ev__ctrl__t.html
and the entire structure is delivered unchanged to the receiving
sequencer client.

Events get converted into actual MIDI bytes only when they end up at
a real MIDI port.  In that case, only the lowest 14 bits of the value
are put into the two data bytes of the pitchbend event.


Regards,
Clemens