I am midi mapping Control 24 control surface on Cubase 12 Pro.
I would like to map this one encoder for EQ slope ←
So when I mapped it with ‘standard’
I had to scroll(?) so much to reach different type and so on.
The same thing applies to Hi-cut, and Lo-cut shape.
I am sure you would know what I mean…?
I actually tried button, but it acts as (on and off) button, not ‘next shape’ button you know?
So I now made it encoder,
but so unsure which resolution/set-up I need to make to get exactly what I want…?
It’s like, as if, ‘I do not want this to be this much fine-tuning…’
I would like few clicks then just changing the parameter
for hi-cut shape and also EQ slope for each band
I wish I made myself clear and hope someone can help with midi remote mapping!
Come over. For the time being, there is no obvious way to control “how fine” of a change an encoder click to any direction makes. I wish we were wrong and there is a way we have overlooked.
@ggmanestraki : I am pretty sure that @JohnShin talks about a different problem
I experienced the same problem he describes: changing the different shapes of a EQ i.e. hi-cut, low-cut etc. with a encoder. The problem with this is, that you need to turn the encoder a few times to even see a change in the shapes. It’s like 3 or 4 full turns for each shape. At first I even thought this function doesn’t work. Pure accident that I found out, that you really need to turn the encoder a few times.
Unfortunately I don’t know how to solve this behavior. If you put that on a button, then the button behaves like a on/off thing and is not „scrolling“ through all the different shapes in a loop like behavior that is wanted.
I chose the, one below the ‘standard’ option, I think it was, something (under value mode), something above ‘binary’ one, it is defintiely the 2nd one!
Then what happens is, the slop type may ‘JUMP’ or ‘SKIP’ but you DO get one change per click.
So it is just much better for me.
Ok, but this is news to me! Different encoders exhibiting different behaviour controlling the same parameters!
My X-Touch compact can be set up so that each encoder controlling CC can be set to cryptic “Relative 1”, cryptic “Relative 2”, cryptic “Relative 3” mode. I just randomly decided on Relative 2, which Cubase recognized as Binary Offset. Since it was working ok, I didn’t experiment any further with different modes. But now I see that maybe I should?
Edit: Oh wait. If your encoders are 14-bit, and mine are 7-bit, isn’t it logical to assume that you will have more steps to cover until you reach the next parameter step?
Out of curiosity, when you do a single click right on an EQ band’s frequency from 250 Hz, where does the click take you?
Yes, that is true. Absolute encoders use 7-bit and (endless) relative encoders use 14-bit.
To solve the problem, we would need to define the range for the 14-bit encoders to behave the same like the 7-bit ones.
This can be solved, but scripting wise, you need to write exceptions, where a encoder behaves different. My experience was that this can lead to little chaos (depending on how much exceptions are used).
@JohnShin Much of what you’re asking for, such as using a push button to cycle through EQ types can only be done by scripting in JavaScript and not by using the Mapping Assistant.
I’m not sure there is such a thing as “absolute encoders” and relative encoders are not 14-bit by design. What data a rotary encoder sends is dictated by the software of its controller. Many controllers with rotary encoders allow the user to choose how the encoder operates and what it is sending. Such modes can include an “absolute” mode where the encoder sends CC 0-127, it could include sending pitchbend data or relative CC ( of which there are several standards) or perhaps an NRPN mode.
Not sure I understood the question, but the data a controller sends has to conform to what the recipient expects. Cubase’s MIDI Remote excepts a few different forms of sending MIDI CC (such as Absolute and a number of different Relative modes.
I mean that in the case of a relative encoder, we have a range of 127 incoming values that don’t have a direct effect on the controlled parameter. Two of those 127 values are “step up” and “step down”, the rest 126 are “speed modifiers”/“multipliers”/“how many steps at once” values. There’s nothing absolute in there. The step is NOT defined.
That’s what I mean. It’s not like an absolute CC fader for example, where a value x/127 is plug-in parameter’s xmax/127. Right?
I see now.
I think you hit the nail on the head. As I see it, there are two major advantages to a rotary encoder compared to a classic potentiometer. The first is that the encoder never has a specific state (or value) which is advantageous when you want one controller controlling more than one parameter. The encoder is always in the “right position” as opposed to a potentiometer when switching between two parameters.
The second advantage, and this is what I think we’re talking about, is that the data from an encoder in a Relative mode should be able to be interpreted as any “grain size”. If controlling a Pan for example, you might want to have 101 unique values between the encoders Min and Max. When controlling the EQ type you may only want 5.
The problem in Cubase is that any controller is assumed to have a range of 0-127 regardless of it being used in Relative or Absolute modes. Under the hood, Cubase then translates the MIDI CC value (0-127) into a normalized floating point value (0.0-1.0).
The workaround is to use a custom variable with the API and bind that to the parameter. Now you have a greater control over what’s being sent. In the call back routine of the encoder you would check what direction the encoder is being turned and add/subtract to your custom variable as needed. Something like this:
I hope that makes some sort of sense.
The above workaround seemed to work for me when I was evaluating the MIDI Remote API. However, issues arose when I was trying to get feedback from Cubase to the controller for displaying the value on the encoders LED rings.
Ok, good to know I’m not hallucinating about this. I just hope this option to manually assign the “step size” comes to the surface editor one day. (Or any old number it needs to be)
I think it’s the “Resolution” setting that messes things up. It takes the possible values a relative encoder can output as the range of values it can control. (which would be true if it was an absolute encoder, but not if it’s a relative encoder.)
For relative controllers, it could be an open field that we fill in. (So that we could have an encoder with a “resolution” of 2, that would work like a switch, an encoder with a resolution of 40.000 so that we could do 0.5 hertz steps in EQ, an encoder with a resolution of 100 so that we could eventually reach that high frequency. Or we could just set the resolution be the same on all encoders and have some kind of shift button that multiplies by 100 or divides by 100. This is all for the surface editor. For scripts, I’m certain there are ways to do much of this.
I agree 100%. This is the exact reason I started this thread:
There are workarounds. But they seem to introduce their own set of issues. Especially if you want some feedback on the current value of the encoder (ring LEDs or displays for instance).
Hello guys! I… have no clear solution but! I found the solution on my end… turns out, there was a button called ‘VEL SENS ENCODERS’ on Digidesign Control 24 that I am using as control surface now… haha… this made me able to fine-tune? fine-skip?
So… for me this sort of made it better…
but yeah, I am ok with this function and the other value mode option for slope/shape scrolling
Absolute encoders have a fixed range. They have a start and end point in terms of turning. They are potentiometers and not endless encoders like the relative encoders. I haven’t seen a single relative encoder, that doesn’t support 14-bit.
You are right with the data it sends, that should be dictated by the software. In our case it is dictated by the midi remote and if you don’t create rules, the encoder will use its default relative values. How this looks, depends on what relative mode is used by default from the encoder.
It’s quite the opposite, I think. Cubase handles everything with floating point internally (0.0-1.0) and translate this to 0-127 CC values.
Please link me to an example of an “absolute encoder”. I have a feeling you’re thinking of a potentiometer which is a different technology completely.
No. It is dictated by the embedded software in the controller itself.
Again, what the controller sends is configured on the controller. Cubase does not tell the controller what to send.
Read what I wrote again. If the controller in question sends MIDI CC with a value range of 0-127, Cubase converts that internally to a 0.0-1.0 floating point value.
yeah, thanks for linking me to my own thread.
You should read it.
Yes, I am thinking of potentiometers. These potentiometers use absolute values, never seen any that do relative values.
Ok, you refer to the default values the controller itself sends. This is a fixed value and I can’t change that with my controller itself.
I can’t configure anything on my controller. What he send and receive are fixed values. Cubase needs to know how to interpret these values send from the controller. This was not possible for me prior Cubase 12. Only Cubase 12 provides the necessary relative mode I need, so that Cubase understand what I want to send with my controller. Otherwise, without the new relative modes, my controller is pretty much useless in Cubase. So if you don’t tell Cubase how to deal with the controller data send, it simply can’t work.
My controller sends relative 14-bit values. In CC terms this would mean he sends 65 value for one step and would be useless, if Cubase wouldn’t know how to deal with. Once you do that, I can use a CC value of O-127.
