Your shopping cart is empty.

Interpreting Relative Encoders

Submitted by Image_Engine on Tue, 09/01/2020 - 03:42
Control Surface Studio User

I have an issue whereby the definition of an encoder in the surface script is quite simple
Type = Relative
Left = 1
Right = 127
Steps = 127

That was fine while I was prototyping and you move an encoder slowly. When using encoders with acceleration, the Left value can range between eg 1,2,3,4 and the right 127, 126, 125, 124

What is the correct way to manage this as the actions seem to be ignored when I turn the encoder quickly? What is the controller filter actually doing when it comes to relative encoders?


Topic Category: 

12 Responses


Control Surface Studio User

if I understood your doubt:

that hapens beacuse it takes 127 steps to make a action. try drecreassing the step value, like this

Left = 127
Right = 1
Steps = 1

check which value is being sent with a midi signal monitor. (Chrome Only)

Control Surface Studio User

In relative encoders works like this:

when the knob is rotated to the left, the midi value sent is 127
when the knob is rotated to the right, the midi value sent is 1

Control Surface Studio User

Hmm, not sure you understood my post;
Everything works great
1 = left, 1`27 = right with 127 steps...until I apply acceleration in firmware which now modifies the relative compliment to apply faster movement to the interpreting software
ie slow = 1, slightly faster = 2, fast = 3, really fast =4 and so on
If you modify the steps in CSS, then the resolution is lost.
The way its meant to work is that eg a value of 4 send by the firmware is interpreted in Live as a 'faster' rotation by reducing the resolution.
CSS seems to be using a rigid interpretation and now allowing acclerative relative values.
I just dont want to be using reactions everywhere for simple stuff when relative acceleration is common standard.
Thanks for your reply

Robert Büttner
Control Surface Studio User

I have the same problem.
I really want to use the relative behavior of my x-touch mini.
It has acceleration as described by Image_Engine and therefor only registers really slow movements.
When i turn the encoder faster it sends values either higher then 1 or lower then 127 and CSS is not picking them up.

Is there a way to make it work?

I just bought the app and really love it so far,.
It would be a bummer if i could not use it for my setup as it is so quick and easy :-)

Robert Büttner
Control Surface Studio User

i tried to do a little patch in max, that would transform midicontrol messages that have a value of 2 in two messages with a value of 1... and so on. I think this should work.
But i do not find a way to route the midi through max to live and into the script.

I tried virtual midi cable and even though they are not red in live, somehow it is not working...

Anyone knows why?

Control Surface Studio User

Hi Robert
Firstly...adding max makes it far to complicated...I used m4l for quite a while and Im not joking when I say that whilst native is harder...what you are doing is making it way too complicated. If you already understand max, then the key is creating a behaviour in CSS and using the values to create a pass through. I ended up just changing the hardware to send the same value based on acceleration ie val 1 but repeating the faster you turn...but not everyone has access the the firmware engineers; I ended up working it after the firmware update but the issue becomes the controller. which is the issue. CSS must allow a relative controller to not just respond to eg 1 and 127 but respond to the RANGE 1-63 and 64-127; if you look into the remotes scripts ie STC single track control, it tells you how the absolute/relative is handled and can help understand but all of that management is now available in Ableton framework. HTH in some way...KEY IS Controller Script Fix! imho

Robert Büttner
Control Surface Studio User

Hey Image_Engine,

thanks for your answer.
As it seems there is no internal option in CSS to use accelerated relative messages and i have no way to change the firmware of my controller the only way i see ist to put something (eg max) in between the controller and the script that transforms the messages in something the script can handle.

The patch that i did in max, does exactly what you did in the firmware. sending more and faster 1-values instead of 2-63 values..

Maybe John will say something here if this is a change we might see in the future.

Bye and thanks again for the answer

Control Surface Studio User

I guess if max gets you by for now...all good.
Im hoping it will get mentioned I know its all now managed nicely in framework but I realise John has tons of work with CSS at the moment.
Actually, I wonder if the controller was actually set as an absolute cc in the controller script and then the behaviour could just scan the val but pass the status as a relative cc? Im at work atm so cant look at it but perhaps there is a kludge to do it?

Robert Büttner
Control Surface Studio User

I just realized that the web-app has relative controlling behaviour the way it should be.
There are 3 different standards: "two compliement", Signed bit" and "binary offset"
They all have acceleration just in different ways.

two compliement works great with one of the relative behaviours my controller offers.

But in CSS this is not possible.
To me it looks like the devs wanted the relative behaviour in CSS to be editable and the feature became a bug...

The problem is that the Web-App is not able to do what i need.
And i just payd 80 bucks for the premium version... :-(

please can you change the relative behaviour to the beheaviour in the web app, or add the 3 standarts that you can choose from in the web app to CSS!

John C
Forum Admin

Hi Robert,

With CSS we dropped using the Web App / framework style of encoder/relative control as there were a number of issues with it. One of the main ones being that it wasn't possible to add multiple mappings to a single controller input using that method. So we went for our own custom solution which also allowed for more editable options (as you mentioned).

I thought it would be possible to use the web app control via a Reaction but after having a dig around it can't quite do it at the moment. But! we are working on a huge update to the Reactions ecosystem and I'm pretty sure you'll be able to add web app/framework controls using it.

One thing I need to ask is, what functionality/mappings are you looking to control with your relative controls?

Robert Büttner
Control Surface Studio User

Hey John,

thanks a lot for the answer!
I am looking forward to the update, i also fiddled around a bit with the reactions but could not make it work.

I created a simple script for my Behringer x-touch mini:

I can scroll through the highlighted tracks
On the active track i can choose a device, mute the devices, choose banks and change parameters of the active device.

i realized when i add feedback to the encoders from live for quiet some parameters it would messy... I think it happens when the resolution of the live parameter is different then the 128 steps of the encoder and then the feedback would be different then the just set step.

This problem was solved wen i tried to use relative control instead of absolute.
Another possibility would be to send the feedback just to the LEDs instead of the encoder.
This is possible with the X-Touch mini but the resolution of this control is 14 (i would have to be able to set a separate min and max for the feedback) and it happens on the global midi channel that cant be addressed trough CSS.

If there is a better way to do this, and i just did not realize, i am happy to hear.

Beside this problems and some Limitations, i really love the program and i think the idea behind it is genius :)

Best Robert

John C
Forum Admin

Maybe you could try doing feedback via Reactions?
here's a blog post on sending led feedback to your controller using reactions: