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.