MIDI Remote, Relative value mode

Cubase
, ,
1

Thank you Steinberg for including different relative value modes.

As I see it, the downside with using Absolute MIDI CC values is the limited resolution of 7 bits (0-127).
Using an encoder that sends Relative MIDI CC values can potentially overcome this limitation.
Unfortunately, Cubase 12 currently does not take advantage of this as the scaling of the controller value to its destination is fixed and cannot be altered.

Example 1 (Absolute CC value):
The controller sends CC values between 0 and 127.
The smallest change in value at the destination (the parameter you want to control with your MIDI Controller) is always going to be MAX_RANGE / 128. So if the parameter you want to control can be between 0 and 100.0, then the smallest step will be 0.78125 (100 / 128). Changing the parameter from say 50.0 to 50.5 is therefor not possible with an absolute MIDI CC value.

Example 2 (Relative CC value):
The controller (a rotary encoder) sends relative CC. Turning the encoder clockwise, it sends a value of +1. Turning the encoder counter-clockwise, it will send a value of -1.
The encoder does not have a fixed range as the the controller in the previous example (0-127), meaning a scale has to be superimposed.

The Issue:
Lets say you want to control the Gain value of EQ1 of the channel strip with your controller. If the value for Gain can be between -24.0 and +24.0 and you are using a controller that sends absolute CC values between 0 and 127 the effective resolution would be 0.375 Gain per CC step.
Switching to a relative encoder, that does not inherently have fixed range, it seems Cubase is scaling each CC step as if it was an absolute value. This means that you are stuck with the same resolution of 0.375 Gain per relative increment/decrement.

The Solution:
Include a setting for scale factor or range when using Relative Value Modes.
Example:
Using an encoder that sends relative MIDI CC as in example 2 and by setting a user defined value for scaling range to 1,000 for example, the resolution has now increased from 0.375 / MIDI CC to 0.048 / MIDI CC.

Not being able to define the range (or scale) of a relative controller message takes away its greatest advantage - not being constricted to a 7-bit (0-127) value.

3 Likes
2

Have you seen these elements?

image

image

image

3

Hi Steve,
Yes, I have.
I do not think the “Takeover” setting relates to what I’m talking about and the “Resolution” setting does not seem to apply to Relative controller data.

I appreciate your response, but I still believe that when using Relative CC values, the user needs an additional setting for scaling that into a range. Right now, the user is missing out on the best part of using relative CC messages—breaking free from the old 7-bit constriction.

2 Likes
4

You mean a hardware encoder that send relative values? What is an example?

5

Yes, a hardware encoder (as oppose to a potentiometer).

I have a MIDI controller with 8 rotary knobs. These are encoders and not potentiometers.
I can set these encoders to either send Absolute MIDI CC data or Relative. If set to Absolute, the MIDI controller will send a CC value between 0 and 127 and Cubase interprets the value as such—a value 0-127.
If I set my MIDI controller to have the encoders send relative CC values, they will send a +1 value/message when I turn the encoder clockwise and a -1 value when I turn the encoder counter-clockwise. (This is somewhat simplified, but in essence, that is how it works.)
With Relative CC messages Cubase has to impose a scale to the +1 and -1 values it receives.
If my encoder knob is meant to control the Volume Fader of the selected mixer channel for example, Cubase needs to know how much to increase the Volume with when it receives a +1 message from the connected MIDI Controller (my encoder knob). This is also true with Absolute CC values except the scaling is already defined as an absolute CC value can only have 128 different unique values. Relative CC values/messages does not have scale attached by default. Every time I turn the encoder knob one “click” clockwise, a +1 message is sent. But what is the range? What is the minimum and maximum? Is it still 0-127? It does not have to be, and that is the charm of relative values.
Imagine having a parameter in the MIDI Remote Editor for scale when you are using relative CC. You could then set up your encoder for a 0-500 range for instance. In the example of the Volume Fader; if the fader is all the way down, exactly 500 little clockwise turns/“clicks” is required to reach max volume. The resolution is almost 4 times greater than with a traditional, absolute MIDI CC potentiometer.
Being able to define the scale with a rotary encoder that sends +1/-1 values is exactly what makes them so powerful compared to MIDI controllers that send absolute values between 0 and 127.

2 Likes
6

Example 2 (Relative CC value):
The controller (a rotary encoder) sends relative CC. Turning the encoder clockwise, it sends a value of +1. Turning the encoder counter-clockwise, it will send a value of -1.

Well technically speaking, on each click of the dial, it sends a value of 63 or 64 depending on the direction you turn it. This is different from what you described.

Anyway, have you actually experimented in the midi-remote GUI with this?

7

This is why I added the disclaimer “(This is somewhat simplified, but in essence, that is how it works.)”.
For all intents and purposes, they are plus and minus values. Also, there are several “standards” on how relative values are interpreted. Cubase 12 supports 3 ways as described under Value Mode in the manual.
But this is besides the point as it doesn’t really impact what I’m talking about.

Yes, extensively.

You do understand the “scaling” of values I am talking about, right? And that it is a scaling that is straight forward for absolute MIDI CC values but requires a scaling factor for relative MIDI CC? This is the key point.

If we stick to an audio channel volume fader, how many unique values can the volume fader have? I don’t know, but it is a fairly large value. Much larger than 128. For the sake of argument, let’s say it is 10,000. Let’s say the volume fader can have ten thousand unique values ranging from all the way at the bottom (no audio) to max volume (all the way up).
Mapping a traditional MIDI CC value to that fader lets you control the volume in steps of 78.125 on our scale of 0-10000. The MIDI CC has a fixed range of 0-127, so the formula is 1000 / 128 = 78.125.
Now since I am not using absolute CC values, I should be able to scale the MIDI CC to allow greater granularity.
If I use my MIDI Controller to change the volume level, I might want to change the value in steps of 0.2dB. This is not possible with a controller sending absolute CC values since the resolution of it (only 128 unique values) is too coarse. But I should be able to if Cubase would expose the scaling factor it uses for relative CC messages.

2 Likes
8

This depends entirely on the receiving device. How would you propose to scale values like 1 and -1?

9

Yes, of course it does.

How do you scale a 0-127 value if the receiving device is a Mixer Volume Fader?
Cubase is already scaling ALL of the CC data it receives, both Absolute and Relative data.
The issue is, Cubase does not expose the scaling factor (or Min/Max values if you will).

So, I’ll explain this again using the Mixer Volume Fader as an example.
How many unique values can a Volume Fader have? Lets say it is 10,000 where 0 (zero) represents the lowest setting (fader all the way down) and 10,000 is the maximum value (fader all the way up).
(The actual dB value that is displayed is unimportant here.)

Now, lets say you connect a “traditional” MIDI controller—a knob that sends MIDI CC. A value 0-127.
Cubase needs to convert the 0-127 CC value to the 0-10000 Volume Fader value.
If it is scaled linear, the formula is easy:
10000 / 128 = 78.125

So when your MIDI controller sends a value of 1, Cubase translates that into an appropriate Volume Level value of 78.125. If the controller sends a value of 30, the conversion result is 2343.75, since 30 * 78.125 = 2343.75.

So what about Relative CC messages? There has to be a conversion there too, a scale if you will.
Right now, Cubase is using the same scaling as with Absolute CC values, which is severely limiting. I’ll show you.
We’ll use the same Volume Fader in this example but now we are controlling it with a rotary encoder that sends relative CC messages, basically a +1 or a -1 value. If we start with the fader all the way down and turn the encoder one “click” clockwise, the controller will send a +1 message (or 065 if you must). Cubase responds by raising the Volume Fader by 78.125.

So why does it raise the volume by 78.125? It is because it uses the same scaling as if it was a traditional, absolute MIDI CC value. Cubase sets up a scale that is 0-127 and applies that scale to the Relative CC message of +1. Another “click” of the encoder to the right/clockwise and the Volume Fader goes up to 156.25.

There is NO logical reason why Cubase should scale Relative CC messages the same as Absolute CC messages. By doing so, the massive advantage of sending relative messages is completely lost!

And here is the solution:
When you set up your MIDI Controllers and you select one of the three Relative Value Modes, the user also gets to enter a scale value.
If you like the 0-127 resolution, you simply enter 128 as a scale value (128 unique values/steps/clicks…).
If you would like the ability to adjust the Volume Fader with finer adjustments, you enter a larger value as your scale value. Like “10000” as in my example above.

Does it make sense now?

2 Likes
10

This could be what is missing in the new MIDI Remote editor.
From the Cubase 10 Manual - MIDI Remote Control Configuration Section

Max. Value
Allows you to specify the maximum value that the control transmits. This value is used by the program to scale the value range of the MIDI controller to the value range of the program parameter.

11

I just got word from one of the Steinberg developers that this is indeed a feature that is missing.
I will keep my fingers crossed that it will find its way into a future update.

4 Likes
12

@mlib is absolutely right with everything he wrote here about relative encoders. With Cubase 12 we have at least now three options for relative encoders (previous versions had only one). This is what makes me really wondering, because there must be at least someone at Steinberg that knows how relative encoders work.

I need to use Bome Midi Translator Pro, to make my Mackie C4 working properly with Cubase. With Bome, i am able to adjust a scaling factor, that is literally so fine that i would need to turn a encoder a few hundred times to make the volume fader travel from bottom to top. This would not be much practical, but it is possible. What i did, is to add the scaling factor to a button. So whenever this button is pressed, i will have that fine resolution for the encoders i want to use. If i press the button again, i return to the (absolute) values and have the 7-bit resolution back again.

There is one more great advantage of relative encoders. If implemented properly, a relative encoder is ALWAYS at the correct value. There is NO jump, pickup or whatever crippled method needed. The encoder always moves from the CURRENT value to left or right.
Cheap absolute encoders, dont know the CURRENT value, they ALWAYS move from the last position where you left them, that is the reason why they jump or need to pickup a new CURRENT value. So everytime you change a patch from a VSTi it is very likely that you have jumps or need to pickup the new parameter values. Relative encoders do not have that disadvantage, they are ALWAYS correct.

We need that scaling factor so badly not only for the encoder itself, we although need it for the LED rings. Depending how many LED rings you have for a encoder, they will need scaling as well.
For example: My Mackie C4 has eleven LED segments for the ring on a single encoder. In absolute value terms, i need to scale the value like this: 127 / 11 = 11,54 . Only then we know which LED segment needs to be lit and visualizing where the CURRENT value is.
Further more, we sadly have no options for the LED rings at all. I simply cannot define a CC for the receiving data from the DAW. I assume the data is send back to the same CC you define for the encoder. But in my case, this does not work, because the LED rings receive on a different CC, as the encoder sends, resulting in no visual feedback at all.
People have reported that the LED rings on Behringer devices are working, once they put them into “mackie” mode. So there is already a solution inside the Cubase DAW. The Mackie C4 uses the SAME encoders as a MCU, but the sad thing is, i can not put the C4 into “mackie” mode, as it is more a controller and simply dont have such a option.

1 Like
13

I Was hoping this could be got around with the API, but i’m not having any luck.

Trying to integrate with a controller who’s hardware sends large relative increment and decrement values by default, and then finer adjustments when shift is held down. I just presumed you’d be able to filter such messages.

But with how the system binds controls to surface elements that you’re stuck with the basic 3 relative options with no scale adjustments still.

Unless anyone has found a way to manipulate :frowning:

14

One alternative to getting higher resolution from encoders is to make them send pitchbend values (14 bit, with the range +/- 8191)

Of course this would have to be sorted out before the MIDI message hits Cubase.

For example, you could use MIDI-OX (windows) or Bome MIDI translator and translate an encoder controller cc value 65 to instead send pitchbend +8191. When assigned to a Channel Volume, this will cause -0.16dB change when fader is at 0 (the resolution will change depending on where the fader because of the log thing).
On the other side, if you translate the relative encoder cc value of 63 to send pitchbend -8191, it will cause a +0.16dB change when the faders is at -0.20.

I’ve only done this by sending pitchbend values via Pocket MIDI just test this idea. And it appears to work.

What I’ve also found is that the closer the PB values are to zero, the higher the change in absolute value. So there is the potential to use that in velocity sensing if you’re so inclined.

In order to make this work, I used generic remote and “learned” the pitchbend message from Pocket MIDI. Generic will say the MIDI message is “unknown” but it will receive it in all of it’s 14bit glory. You can see for your self if you also activate the transmit flag to Pocket MIDI via virtual MIDI port. The PB values are sent back out (and it will be beyond the “Max Value 127” that the Generic Remote says).

In order for the +/- 8191 to work with the encoder, you’ll also need to activate the “relative” flag.

I’m still on Cubase 11, so I don’t know if the C12’s new MIDI remote API thing will accept pitchbend but I suspect it will.

15

That is exactly what the Mackie MCU protocol does, if you press the flip button. The only difference is, that you use the faders for the fine resolution (the pitchbend values). I used the same pitchbend method for my encoders in Bome Midi Translator and added a scaling factor for this.

Be aware that most of the time, you will be dealing with absolute values. The 14bit resolution makes only sense for cases that dont use absolute values. That is the reason, why i use a (shift) button for this.

16

I feel with you. While the API is better than nothing, it is useless for a musician/artist that has no java knowledge. The Midi Remote on the other side, is simply to basic. It is a dilemma i am afraid.

I feel disappointed, because you can not use a midi implentation chart (that is mandatory in every good manual of hardware midi controllers) to its full potential. A language known for nearly 40 years, is of no use in Cubase… that is really sad.

Summarize:

  1. Midi receiving options needed. (Why do we even need to setup midi in AND outs in the midi-remote???)
  2. Support for the LED segment rings around the encoders.
  3. Scaling factor values for both LED segments and encoders.
17

Hi @u-man, we are just getting started with the new MIDI Remote system. The features you’re requesting are mostly all implemented in the “old” Mackie Control implementation. Please stick to that if MIDI Remote doesn’t suit your needs.

18

If it could be THAT easy, i would have done this years ago. The Mackie C4 is NOT a MCU. The display adressing is a little different, so no display on the C4 is working. I can not stick to the “old” Mackie Control implementation, since it is NOT OPEN. If you would change some really tiny things with that “old” Mackie Control implementation, we could have a full working equivalent of a MCU on a Mackie C4.

To properly adress the displays from a Mackie C4, here is my picture:

C4_SPECS
C4_SPECS3508Ă—2480 505 KB

The sysex for a MCU has ONLY a different ID (14 instead of 17) and a different display ID (12 instead of 30). How can i change that in the “old” Mackie Control implementation???

All of this, would not be a problem, if we would have a MCU script, that we can change to our like. Sadly, it is not there, even if “old”.

19

The MCU fader’s use of pitchbend is what gave me the idea to this out!

But it’s not exactly like the MCU fader flip, right? That uses pitchbend in an absolute way. What’s particularly interesting with how Generic Remote treats relative pitchbend is not only increment/decrement, but also the degree of that change. eg. -8191 is +0.16dB, -8191 is +0.32dB, etc.

So the 14 bit resolution of relative pitchbend and how Cubase implements it is still a good use case for parameters that use absolute values such as volume and most VST parameters.

I tried it on the jog wheel but it doesn’t quite work there.

20

It depends where you press the flip button. Lets say you do it in the pan section of the MCU, then you are right with what you wrote. But if you do it in the EQ section, then you will have the finer 14bit resolution.

Thats what the Remote Control Devices manual is saying:
Switching Fader and V-Pot Functions
In some cases, you can edit a parameter more subtly with the faders than with the stepped V-Pots. In this case, you can switch the functions of faders and V-Pots.

In other words, a function needs to support 14bit values or you just deal with absolute values (1-127).