can you provide some code example? i have same problemon my arturia mini lab
Hi mlindeb,
I have been looking at a midi controller with 16 Endless rotary encoders. In the product description (its on ebay) it states:
" The map mode must be set to āRELATIVEā mode and āBinOffsetā in your DAW software for the rotary encoders to work correctly".
I gather this is the same as the Midi Fighter Twister. A question for you if you donāt mind.
Do the endless encoders of the Midi Fighter Twister work with cc values of 0-127 in Cubase 12 Midi remote? I donāt need fine resolution.
Thanks
Oh, since this thread resurfaced, I might as well ask a question too, in case anyone knows.
What determines the āgrain sizeā of the parameter? (Sorry, I donāt know what itās called.)
For example. I have an encoder. It sends 65 when I twist to the right, and this is an increase x. I twist faster, it sends 66, or 67, or 70. This is some multiple of x.
But is this x the same value, when weāre in one plug-in controlling frequency, and then gain for the same plug-in? Is it a standard than one encoder click increases a frequency parameter by 1 Hz, and a gain parameter by 0.1dB?
I just donāt get it. If someone could explain it to meā¦ I do agree that finer control is needed in some cases, but shouldnāt this be handled globally, on demand, by some scale parameter available on the surface itself? (Kind of like the shift key we use with the mouse for finer control?)
The MF Twister can be configured to send either relative MIDI CC or standard 0-127 values.
Both modes are supported in Cubase 12. However, using a relative mode, Cubase can not natively scale the range and thus treats both modes as 0-127 absolute.
Hope that helps.
This was the entire purpose of this thread. The only way to set the āgrain sizeā is through the API using custom code. Cubase does not have anything natively that allows you to scale a relative encoder.
Every VST value in Cubase is handled as normalized absolute value between 0 and 1. MIDI Remote functions throughout the application then scales that to 0-127.
Unfortunately in my experience, trying to scale a relative encoded in JavaScript through the API introduced issues on its own. It works well unless you want Cubase to also send values back to the controller for feedback (such as an LED ring or a display showing the current value).
1 Like
Thanks for the info mlindebā¦ not completely familiar with this so have another question - to clarify how that works in the real world
For example,
You are on track 1 with āfilter cut offā assigned to QC1 and you adjust the parameter from 5000 hz to 2000.
Then you move to track 2 with āfilter cut offā assigned to QC1 at 500 hz - you wish to change it to 1000hz.
Is there a jump when adjusting track 2, QC1 on MF Twister? Does it work smoothly? I donāt need the LED feedback
Thanks
This depends on the assignment you have made in the mapping assistant. If you have the entry for the encoder set to āJumpā, you are done tweaking track 1 filter cut off at 2000, change to track 2, the filter cut off is at 500, you twist the knob a bit, now itās at 500 something.
Moreover, if you are lucky and the twister uses the same CC for the LEDS, the moment you change the track (in jump mode always), the LEDs will change from displaying 2000 (last value of track 1) to displaying 500 (first value of track 2).
Hey, thanks for the inputā¦ that should do the job for me - will report back to confirm how it works !!
1 Like
Itās really annoying that this is still an issue, youād think the API would have a simple scale option by now. 
I had a mapping which uses the custom variable option but like you say you canāt feed it back to the display or LED rings, and you canāt map to the controls using the surface editor as the binds link to the triggers, not the controls.
Itās such a pain as Iād like to use the āselected trackā options to control inserts and instruments with multi-page options.
Can you both explain it a little more, why you canāt or is a problem to send back to displays or LED rings? Canāt you use both, surface Editor and API? What exactly is the problem with scaling?
These are my observations from when I was actively tinkering with the API and my Midi Fighter Twister that I thought would be a good candidate.
The only way I found I could change the granularity of a rotary controller (in a Relative CC mode) was by utilizing custom variables. For example, if you want your encoder to have a range of 1,000 unique values for controlling something like a filter Cutoff with a greater granularity than standard MIDI CC (which has 128 unique values) or much fewer, like 5 values if you want to control something that has 5 options, like EQ type e.g.
I could scale the Automation value (not sure this is the correct nomenclature), which is the normalized absolute value of 0.0-1.0 Cubase uses for all parameters under the hood, as I wanted. In theory, it should be as easy as dividing the number 1.0 with the number of āunique stepsā minus 1 of the target parameter.
In the example of controlling the EQ type where we have 5 options, each EQ option is separated by 0.25. So,
EQ Type 1 = 0.0
EQ Type 2 = 0.25
EQ Type 3 = 0.5
EQ Type 4 = 0.75
EQ Type 5 = 1.0
This made sense and worked well. My issues arose when getting feedback from Cubase to drive the LED rings around my rotary encoders. Turned out that changing to EQ type 3 didnāt return a value of 0.5 as expected. I was not able to predict the return value sent by Cubase upon parameter change.
To a certain extent, yes. You can define the controller with JavaScript and assign controllers to parameters using the surface editor. There are limitations with this approach. You canāt bind to custom variables for example.
See above.
Iām not an expert on the subject, just reporting my findings which may or may not be accurate or valuable. 
The problem for me is when the hardware is sending out a fixed scale and thereās nothing you can do to correct it. Other than go via a virtual MIDI port and use a translator like BOMEās.
For example, Iām working on a DAW mapping for the Komplete Kontrol Mk2 and it has a fixed DAW mode which sends out Relative twos complement messagesā¦ Except theyāre incredibly coarse.
The smallest movement on the rotaries is giving a 0.07 difference between values on the MR which is equivalent of 8 steps in CC world (0.07*127). This is because the smallest movement gives you 9 one way and 119 the other, so I need a method to bring the 9 down to a 1 and the 119 to a 127, to give useable control.
I can create a custom variable within the API to deal with that fine, but that then means you canāt map via the surface editor, as feedback gets broken as the value no longer corresponds with the control.
Iād ideally like to share the MR script for others to make use of, but have given up hope that SB will add the option in to provide some kind of scaling or evaluation to the incoming data.
So am now going the BOME route, which is a shame as that is a paid for third party tool - but Iām going to make it for my own use, and perhaps something will change further down the road.
This would only make sense if a parameter support this (your 1000 steps), myself have only seen this on the faders (you can use a shortcut for volume up or down. Each press of the shortcut moves one step and you really have 1000 or more. You can use this āgranularityā for your faders or the encoders, but besides this, i did not found any other parameter that supports this. So in the right now situation, where 99% is 0-127 steps (or better said 0-1 with 127 steps), it would make no sense to scale these values (to anything else) as there is no real benefit, because your parameter has still only 127 steps. The only thing you do with scaling is to make the range, fine or coarse for the āturnā of your encoder, but you canāt magically create more steps for the parameter itself. This means for your Cutoff parameter, that it would still display only 127 unique steps (and not 1000) for the full range.
Maybe i dont understand that properly, but in my case i have eleven segments for the LED ring. So the returning value range needs to be divided by eleven, to have equal eleven steps. This rule should work for all returning values.
What value was returned? I would expect, it returns a value that is in the range of that EQ type parameter. Again the same would apply to this example. You created 0.25 steps for the encoder, but not for the parameter itself (it probably cycle loops all EQ types with i.e. 127 steps). So the returning value for your feedback is broken or different from expected.
I have no clue about scripting, but if you can create a custom variable for the encoder, why you canāt create a second variable for the LED rings?
I will look into the existing C4 script and how the EQ type parameter is handled there. From what I remember the value range was hardcoded.
Completely inaccurate as I have already successfully mapped encoders to any range, be it 5 or 1000, by using custom variable in JavaScript.
This depends on your controller. My controller accepts regular MIDI CC (0-127) for driving the LED rings.
Thatās not the issue. The problem is that Cubase feedback signal does not correspond to the value sent.
You donāt understand what I am trying to tell you. I never said, that you canāt map any range to the encoder. I said, that you canāt control the range of the parameter itself. Your Cutoff filter example doesnāt create 1000 steps for the parameter, only for the encoder and therefore this is barely useful to do that. In most cases the parameters use 0-127 steps, but not more and you canāt change that, no matter what you try. The result of your method is that you need to turn your encoder a few more times, to scroll through O-127 stepsā¦ nothing more. The parameter itself still has only 127 steps, not 1000ā¦
So itās not completely inaccurate, you simply donāt understand the problem/difference I am trying to tell you. You ignore the fact, that you canāt change, how many steps a parameter is using.
My controller accepts regular MIDI CC (0-127) for driving the LED rings too. But in fact it uses only a 0-11 range, but because of the different modes I can use for the LED ring, I need the 0-127 range. Effectively only a 0-11 CC range is used for a single Dot LED mode.
Thatās not the issue. The problem is that Cubase feedback signal does not correspond to the value sent.
And to what correspond the feedback signal, if not to the value send?
Dude, youāre out of your element. Either educate yourself or butt out.
No parameter in Cubase is using 7-bit integer values. The all use normalized, absolute, floating point values (0.0 - 1.0). In the API, this is called āprocessValueā. With custom code, you can scale this to whatever you want. Itās not mapping to the encoder, itās mapping the data from the encoder to the process value.
Iām not familiar with your controller. My controllers expects a 7-bit MIDI CC, no more, no less.
Thatās the crux. The value appears to be unpredictable.
If thatās true, how come we can double click on a field and type 110.459, and frequency of EQ becomes 110.5? This rounding implies that the minimum parameter step is 0.1 Hz.
Are you aware that you can send MIDI CC back to your controller using the API (.mOnValueChange for example) and then manipulate it however you want to get the lighting required?
i.e.: if the parameter being controlled had 8 states but they were 1 step apart, this example would spread them across the 127 value range your controller is expecting and return them out the CC and value expected:
.mOnValueChange = (function (activeDevice, obj, param_val) {
var num_of_states = 8; //Number of states (i.e. EQ types)
var return_val = (param_val*num_of_states)*127; // Convert 0-1 to 0-127
var return_cc = 60; //The CC of this LED Ring
midiOutput.sendMidi(activeDevice, [0xBF, return_cc, return_val])
})This sounds rude. Educate yourself, how about that?
Call it what you want, you donāt want to accept the fact, that you canāt change the steps of a given parameter and most parameters will deal with 127 steps. I will give a poopies to your hairsplitting blunt. 127 steps inbetween 0.0-1.0 . Itās fundamental that you understand that you canāt change these 127 steps for a given parameter to 1000ā¦ Period.
The crux is you donāt understand what is written above. If you would understand that, you would understand why your value is unpredictable. I gave my best 
.
Yeah and I said the method can work, if the parameter provides it. In case of the EQ there might be more then 127 steps. I did not tried. But what I know is that the steps are not equally, linear spread in Hz terms. If a 0.1 Hz step is possible, try to type 4.401 kHz 
I know this, if he does , I donāt know 
Please provide some examples. I donāt know a single parameter in Cubase that only has 127 steps. This includes Volume, EQ parameters, Sends, plugin parameters on VSTi and VSTfx, and so on. Create an automation lane and see how many unique values you can get out of any given parameter.
Yes, Iām well aware. I will see if I can find an actual example that showcases the unpredictability Iām talking about.
PS. your code has a mistake in the return_val formula.