ALSA: ump: Data Entry without a selected RPN goes to the next RPN

ALSA: ump: Data Entry without a selected RPN goes to the next RPN

[HyeongJun An]

Hello Takashi,

While writing a KUnit test for the UMP converter, I found that a Data
Entry received while no RPN or NRPN is selected is kept and sent later
under the next selection. Both the UMP core and the sequencer
converters do this. For example, at MIDI 2.0:

  CC101=7f CC100=7f, CC6=40 CC38=00, CC101=00 CC100=01
  -> RPN 0/0 = 0x40 (40200000 80000000), with nothing sent for 0/1

The fill_rpn() returns from its skip branch without clearing the data,
and the flush on CC 98 to 101 sends it with the number as it is at
that point.

Dropping the data in the skip branch stops this, but it breaks another
case. The fill_rpn() also clears the RPN selection after each send, so
a repeated Data Entry for the same RPN only goes out through this path,
when the next RPN is selected:

  RPN 0/0 + 02/00, then CC6=0c CC38=00, then RPN 0/1 + 40/00
  -> today 0/0=2, 0/0=12, 0/1=0x40. With the drop, 0/0=12 is lost.

The other way would be to keep the RPN/NRPN selection after a send,
like fe85f6e607d7 does for the bank, and drop data only while nothing
is selected. Then a repeated Data Entry is sent right away. Selecting
an RPN would also have to clear the NRPN selection and vice versa. The
spec's translation rule (M2-104-UM D.3.3) says the translator "shall
hold the latest values for controllers CC 6, 98, 99, 100, and 101".

Which do you prefer? I can send patches for both converters with a
KUnit test that covers these cases.

I found and checked this with Claude Code, on x86_64 (KUnit under UML,
and a sequencer test on 6.17 and under qemu).

Best regards,
HyeongJun

Re: ALSA: ump: Data Entry without a selected RPN goes to the next RPN

[Takashi Iwai]

On Wed, 04 Nov 2026 13:15:08 +0100,
HyeongJun An wrote:
> 
> Hello Takashi,
> 
> While writing a KUnit test for the UMP converter, I found that a Data
> Entry received while no RPN or NRPN is selected is kept and sent later
> under the next selection. Both the UMP core and the sequencer
> converters do this. For example, at MIDI 2.0:
> 
>   CC101=7f CC100=7f, CC6=40 CC38=00, CC101=00 CC100=01
>   -> RPN 0/0 = 0x40 (40200000 80000000), with nothing sent for 0/1
> 
> The fill_rpn() returns from its skip branch without clearing the data,
> and the flush on CC 98 to 101 sends it with the number as it is at
> that point.
> 
> Dropping the data in the skip branch stops this, but it breaks another
> case. The fill_rpn() also clears the RPN selection after each send, so
> a repeated Data Entry for the same RPN only goes out through this path,
> when the next RPN is selected:
> 
>   RPN 0/0 + 02/00, then CC6=0c CC38=00, then RPN 0/1 + 40/00
>   -> today 0/0=2, 0/0=12, 0/1=0x40. With the drop, 0/0=12 is lost.
> 
> The other way would be to keep the RPN/NRPN selection after a send,
> like fe85f6e607d7 does for the bank, and drop data only while nothing
> is selected. Then a repeated Data Entry is sent right away. Selecting
> an RPN would also have to clear the NRPN selection and vice versa. The
> spec's translation rule (M2-104-UM D.3.3) says the translator "shall
> hold the latest values for controllers CC 6, 98, 99, 100, and 101".
> 
> Which do you prefer? I can send patches for both converters with a
> KUnit test that covers these cases.
> 
> I found and checked this with Claude Code, on x86_64 (KUnit under UML,
> and a sequencer test on 6.17 and under qemu).

A good question, and I'm afraid that there is no perfect answer for
it, because the handling of RPN/NRPN is very ambiguous, per
definition.

My gut feeling is that it'd be safer to keep the values.
The Null (0x7f) is provided for explicitly clearing for that purpose,
after all.


thanks,

Takashi