Yeah of course, it’s just changing the parameter value in Cubase - it’s nothing that amazing is it? You just take the return value and divide it into the steps that the display is wanting.
Or if it’s an LCD screen just return the parameter - as i done with the cutoff val to console.log.
Everyone knows that parameter control way exceeds 127 steps - otherwise what would be the point of 14 bit controllers?!
Kindly posted by skijumptoes above.
And where did you prove any of your claims?
Tell you what, if you go back and edit every single post you posted on this topic to read “I’m sorry, but I was wrong on everything that I wrote.”, then I’ll give you the script. Until then, enjoy your low resolution encoders.
Not quite everyone.
And this is working?
I asked the same question to @Martin.Jirsak during his process of scripting stuff for the Mackie C4. In fact, it was one of the first things i wanted to become true. He explained me, that this is not possible to do and he explained me this, in a very same manner as my graphic.
Also, if this is true, why the MCU vpots are not working this way? These are 14 bit controllers too, just like the vpots on the C4.
Can you alter your script, so that we move the cutoff filter of the Retrologue? It´s range goes from 10 to 22000. Since this range is exponential, if using a 127 step range, i am curious what my feedback value will be, if i have 1000 steps and if the feedback value will be the same, like it is shown in the inspector.
So this is your code? Just posted by skijumptoes?
That only shows off your obnoxious behaviour. I tell you what, i might do this, if the code skijumptoes posted is working like expected for me.
Yes, how else are people running MCU emulations and god knows what else? That script was just part of a script I’m working on for the Komplete Kontrol, and just modified a piece of the code as an example.
It’s all really simple in the API… But you can’t do this within the surface editor, sadly. And if you build the mapping in the API, you can’t then map to the controls due to the need to use custom variables to fill in the gaps left by SB.
Well, I don’t need to alter it, I just add Retrologue as a track and it’s already mapped via the quick controls, and yes, it’s the same concept…
Did you want me to run an example to show you?
Just incase you’re not aware, you have to create that custom variable when you define your surface first. i.e.:
surfaceElements.dummy_trigger = surface.makeCustomValueVariable('dummy1');
I dont understand this. What gaps needs to be filled? What do you mean?
Ok… seems not plausible to me, but if i see it, i cant deny it 
.
Yes please. It would help me.
As bad as i am, i doubt that i am able to adapt your code, into the script i have 
.
Well, if you need to manipulate any of the incoming MIDI to act in a different way than the few methods available, I mean. i.e. there’s no kind of encoder acceleration options or ‘grain size’ as some people call it.
i.e. the reason for this thread!
Do you have a JS Script at the moment then? Or did you use the surface editor so only have a .json file?
It’s pretty simple once you get your head around it - getting your head around it does take a few attempts however!
You’re just adding in a custom variable that can be bound/linked to a parameter in Cubase, and then using your hardware controls to trigger an action to increment or decrement that custom variable.
Obviously, when you change that custom variable the parameter changes by whatever amount you want.
That’s the basic concept if it helps?
This is what i understand, but what do you mean with gaps that needs to be filled?
I have a JS Script, but i cant share it here, at least i will not do it without the permission of @Martin.Jirsak. I would share it in a PM discussion.
As far as i understand this, all you do is to create custom values for the (custom) stepping. Your returned feedback values, will not be the same like the ones shown in the inspector, but maybe i still miss something here. Thats why i wanted the Retrologue example, because the values shown here, are exponential.
Again i need to ask why the MCU vpots are not working this way? These are 14 bit controllers too, just like the vpots on the C4.
It’s hard to show this really as the data goes off the screen when you’re using such fine adjustments. But I just set the resolution to 1/1000th and it took 10+ clicks counterwise to change the cutoff from 10hz to 11hz.
But further up the scale it’s one click per hz value:
And then at the highest point you get multiple hz per single click:
So yes, you’re still seeing the exponential manner there, but at a resolution that you want on the controller.
This is great. So what is the problem? This is still your console.log. What is happening inside the inspector? Is the value shown there still the same?
The gaps in the software that doesn’t allow you to do this without having to learn JS. i.e. these options could be in the surface editor interface as a relative scale or something.
Well, they’ll work however you want to manipulate them, I’m getting this fine detail from a CC controller that sends a value of 1 everytime it moves - so it’s more like 1-bit resolution in regards to the hardware!
This is great!
But don’t we lose the pretty labels that say which parameter we’re controlling on the surface if we use a custom variable?
If you’re talking about Quick Controls, the assignment of the QC is still shown in the plugin window if you expand that top portion.
Sadly yes, this is what I’m trying to explain to @u-man with the gaps left by Steinberg. If we had some manipulation at point of creating the surface elements and not after, it would be so much easier!
No, I mean when we assign a value binding between a knob and any parameter, we can see below the knob what the parameter is. But when I used custom variables, to split an encoder “in half”, for nudge commands etc., i get a blank assignment on the surface editor. Just “-”.
If only it was as simple as sticking .setResolution(number) to the end of a value binding, like .setTypeToggle. it would be so simple to use. 
I see. Yes, that feature is lost when binding to custom variable. It took me a bit because I never have the surface editor open.
Indeed. That’s why I initially started this thread.
The only way around that I’ve found to be reliable is to use BOME MIDI Translator - trouble is it costs about $50.
But you route your device through that and split the values into their own unique CC Addresses, and then pick it up in Cubase.
I bought it myself last week, as I was looking up the price of different controllers and worked out that software like that will probably save me money as I can do whatever I want with my existing.
I have Bome, but I’m trying to keep things as much “plain Cubase” as possible. Not a bad idea splitting it to two whole different CCs. 
Thats not what i meant. I meant the MCU device from the studio setup. The MCU protocol that is used there. Why did not they used 14 bit in this. Why there range is only 0-127?
I will be AFK the next hour
