MIDI 2.0 Protocol: Using Relative Registered/Assignable Controls
Introduction
The Universal MIDI Packet (UMP) Format and MIDI 2.0 Protocol introduced Relative Registered Controllers and Relative Assignable Controllers:
Section 7.4.8 of Version 1.1.2 Registered Controller Messages and Assignable Controller Messages directly set the values of the destination properties. With the MIDI 2.0 Protocol’s Relative Registered Controller and Relative Assignable Controller Messages, it is now also possible to make relative increases or decreases to the current values of those same properties. These new messages act upon the same address space as the MIDI 2.0 Protocol’s Registered Controllers and MIDI 2.0 Assignable Controllers, and use the same controller Banks [and Indexes]. However, these Relative controllers cannot be translated to the MIDI 1.0 Protocol. ![]() Figure 62 MIDI 2.0 Relative Registered Controller Message ![]() Figure 63 MIDI 2.0 Relative Assignable Controller Message Data The data field in the MIDI 2.0 Relative Registered Controller and Relative Assignable Controller messages contains a Two’s Complement value, to provide negative and positive relative control of the destination value. |
This article uses the term “Relative Controllers” to mean both Relative Registered Controllers and Relative Assignable Controllers.
However, the specification does not provide implementers details of how the data field values are used. The following article provides a set of generic ways for Relative Controllers’ values to be sent from a variety of different physical rotary devices. The receiver does not need to know how the sender is creating a value (or the type of rotary encoder), and the sender does not need to know how a receiver is converting the sent value into a parameter or action.
This work is important to several upcoming Profile specifications. These Profiles will be the first MA specifications where Relative Controllers are defined.
Relative Controllers: How do they work
Relative Registered Controllers (RRC) are an addition to a matched Registered Controllers(RC); the RRC is matched at the same Bank and Index of a RC and adjusts the same parameter on the Receiver. An RRC does not exist without the matching RC. This relationship is the same for Relative Assignable Controllers (RAC) and Assignable Controllers (AC).
The values sent in a relative controllers are not immediately obvious, and can change depending on the type of physical control that is used. A Profile specification might define specific values that should be sent, where it may suggest different values for different encoders.
Different types Encoders

A Rotary Encoder generally has detents, with most mechanical encoders commonly having 24 detents per 360 degrees.

Like a normal potentiometer, a Rotary potentiometer provides a voltage that is read by an ADC. Unlike a standard potentiometer it rotates a full 360°. Depending on the circuits involved this can have resolutions as high as 1024 steps (or higher) per full revolution.
Relative Controller Values
The value of a Relative Controller is a Two’s Complement value ranging from -2,147,483,647 to +2,147,483,647.
To understand what value we should send we must first look to the matched RC/AC. The RC/AC has a value from 0 to 4,294,967,295. For example: The sender doe not know the current value of the RC/AC. The sender sends an Relative Controller to increase the RC/AC value by 10% (sends 429,496,729). As a result:
Receivers New RC/AC Value = Receivers Current RC/AC Value + 429,496,729
.
In other words, we need to send the value of 429,496,729 in the Relative Controller to move the RC/AC value by 10%.
Relative Controller Value Formula for Resolution of the Encoder
If the value being adjusted has a value between 0% and 100%, how many revolutions are required to move from 0% to 100%? An encoder with 24 detents may require a lot more revolutions than a Rotary Potentiometer with 1024 steps.
Step Value = TRUNCATE ( 0xFFFFFFFF / (steps per revolution * rotations) )
If the Rotary Encoder has 24 detents and it takes 8 revolutions to go from 0%-100% then the formula is:
Step Value = TRUNCATE (0xFFFFFFFF / (24*8))
Step Value = 22,369,621
If the Rotary Potentiometer has 1024 steps and it takes 2 revolutions to go from 0%-100% then the formula is:
Step Value = TRUNCATE (0xFFFFFFFF / (1024*2))
Step Value = 2,097,151
Not Sending Every Step
Sending an Relative Controller message for every step when the encoder is moving quickly could very quickly flood a connection, especially if the encoder has a high resolution.
Instead the encoder might use a longer service interval between sent messages, with a cumulation of changes during that interval. For example, the sender’s Rotary Potentiometer above moves 30 steps in a single service interval. Then the sender would send 2,097,151 * 30 = 62,914,530 as the value in the Relative Controller.
Fine Grain Control
Devices often support sending a finer grain control by holding down a button and then sending through a value that is less than the default step value. It is up to the implementation to decide what fraction of the default step value is sent when using a fine grained Relative Controller message.
Receiver should handle the accumulation of values
Regardless of the value sent, the Receiver of an Relative Controller message should accumulate the values and store them against the local RC/AC value. This avoids situations where receiving a single step value is too small to trigger a change in the parameter value. However, additional step values sent are enough to trigger a change. By using this accumulation method the user does not experience a situation where sending multiple single steps does not move the parameter value.
Step Size vs. Acceleration
Step Size sent is in the domain of the Sender. For example, a Sender might select from 2 values to send: one larger value for each step of the encoder and a smaller value when in Fine Grain mode.
Acceleration is usually in the domain of the Receiver. When the Receiver receives an incoming message, it interprets and implements that change. But if the Receiver receives multiple incoming messages in a short period of time, then the Receiver might implement a larger change for each incoming value.
Bounded Controls vs Non-Bounded Controls
Some properties have clear boundaries of values (such as Min to Max). Such properties are addressable by a Registered Controller or Assignable Controller. Therefore, it may be useful to address the same property in a relative manner.
Some properties or mechanisms are not clearly bound to a fixed range of values (e.g. Scrubbing through a Timeline) and are not easily addressed by a Registered Controller or Assignable Controller. In such cases, it is not appropriate to define a Relative Controller.
Avoid Recording and Playback of Relative Controllers
Recording and Playback of Relative Controllers is problematic because they act upon the current value in the Receiver which can be different at a later time.
For Example:
If a Relative Registered Controller addresses the 1′ drawbar to increase its setting by one step, every time the track plays back that drawbar will get louder and louder.
To mitigate against the issue, the recording device should use the Relative Controller value to adjust its known internal RC/AC value.
For Example:
A DAW has a plugin in focus and an Relative Registered Controller is attached to edit the plugin parameter controlled by an RC. As the user moves the encoder then the automation lane records the adjusted RC value of the plugin parameter, not the RRC from the sender.
There may be exceptions to this use case and recording Relative Controllers is not prohibited. Relative Controller may exist in an environment where the value should be recorded and sent back to a device that understands the Relative Controller.