RPNs
GM defines several Registered Parameters, which act like Controllers but are addressed in a different way. In MIDI, every Registered Parameter is assigned a Registered Parameter Number or RPN. Registered Parameters are usually called RPNs for short.

Setting Registered Parameters requires sending (numbers are decimal):

Two Control Change messages using Control Numbers 101 and 100 to select the parameter, followed by
any number of Data Entry messages of one or two bytes (MSB = Controller #6, LSB = Controller #38), and finally
an "End of RPN" message
The following global Registered Parameter Numbers (RPNs) are standardised [2] (the parameter is specified by RPN LSB/MSB pair and the value is set by Data Entry LSB/MSB pair):

0,0 Pitch bend range
1,0 Channel Fine tuning
2,0 Channel Coarse tuning

For example: RPN control sequence to set coarse tuning to A440 (parm 2, value 64):
101:0, 100:2, 6:64, 101:127, 100:127

So given the time frame and the fact that these are MIDI files, these RPNs were probably used to set the pitch bend range of the channels in GM sequences or for tuning/detuning tracks via Channel Fine Tuning or changing octaves or transposing a part in whole steps via Coarse Tuning.

Hope that helps!

The pitch bend makes sense, since I do remember working with it often back in the day. I need to do some more reading about MIDI Again. I remember quite a lot, but some of it escapes me now. Controllers 98 and 99, for instance. I see a lot of that in my sequences as well.

Thanks for that informative reply! 🙂

You can also have a look at a Web page I put up (many moons ago) that explains the how and the why of RPN and NRPN. Hopefully it will also help jog your memory.

Cheers
Eddie

Very helpful as well, Eddie. Thanks!

... and finally
an "End of RPN" message

Well, an "End of (N)RPN" message would be very useful on receiver side. But in practice, how many vendors do that? Maybe it would make sense to clearly emphasize this in the specs? ATM this is not mentioned in the CC table on midi.org at all: Control Change Messages (Data Bytes)

Nor on Wikipedia: NRPN (Wikipedia)

Currently the status quo is that (N)RPN LSB data message is optional, and almost no MIDI sender is actually sending a final "End of (N)RPN" message. And many are just sending "data MSB". Which leaves the receiving side with the problem to be uncertain when exactly it can assume the (N)RPN message sequence to be complete. Should it wait for the next MIDI message to arrive in order to see whether there's also LSB data? But what if the next MIDI message arrives seconds away or even not at all?

As implementer of a MIDI receiver it is currently almost inevitable to react both on "data MSB" and "data LSB". Which is problematic, because depending on what that parameter actually does, it can lead to audible glitches. Keep in mind that (N)RPNs are nowadays used for use cases beyond of what it was originally designed for. For instance (N)RPNs are heavily used in event-driven scripts of virtual instruments to trigger certain behaviours, and there it matters whether certain behaviour is triggered once or twice, and then even with a wrong value.

Maybe this issue is a candidate to be addressed in upcoming MIDI 2.0?

Maybe this issue is a candidate to be addressed in upcoming MIDI 2.0?

In MIDI 2.0, RPN and NRPN (now called Registered Controller Message and Assignable Controller Message respectively) send the entire message in one packet with a single 32-bit payload instead of a 7-bit MSB and a 7-bit LSB.
See the article Details about MIDI 2.0™

Hi,

I have a question related to this topic.

In DP 11 there’s a window to enter Registered Parameters. I entered 0x40. Grabbed a Square Wave pencil and quantized it to quarter notes.

I drew about two measures of that square wave then sent the output to MIDI Monitor. Here’s what I got.

CC7 127
CC10 64
CC101 0
CC100 0
CC6 0
CC38 0
CC58 (this might have been an articulation that used CC58, not sure).
Then that sequence began to repeat, (except for CC7 and CC10 of course).

The first repeat had CC6 and CC38 set at 0, then the 2nd repeat, the value of CC6 and CC38 were 127. Odd number repeats were 127 and even number repeats were 0.

This made perfect sense to me that this was just a CC64 at value 0 for a beat, then value 127 for a beat and so on.

I’ve added a couple of attachments.

Here’s my questions.

1. I know that 0x40 is a MIDI 1.0 RPN. And it worked in MIDI 2.0. But how would this be written as a true MIDI 2.0 Registered Parameter?

2. Why would I learn these fairly arcane hex numbers instead of just drawing in CC64 and perhaps making a couple of easy edits? (I realize this wasn’t a detailed and deep example).

3. What’s one good example of a Registered Parameter that I could enter into the Enter Registered Controller dialog box that would represent a good or common use of Registered Parameters or Assignable Parameters?

Thank you very much.

Steve

1. See section D.3.3 in the official Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol specification for a good explanation of how to convert a MIDI 1.0 message to a MIDI 2.0 message.
2. There is no reason other than that some software will allow you to enter the values directly, if you know what you are doing, otherwise you can use features built into the software like the "pencil" you used.
3. Assignable Parameters are product specific and will not have a "common use", however, Registered Parameters are defined in the specification.