Gian, this is a workaround at best.
- For MIDI one definitely wants a range with 128 steps and 129 steps (7-bit midi + “off”), maybe some more for offsets( 63, 64)
- for large ranges that can’t be integers (like BPM) constraining the range so that one of the currently available (17, 33, 65) steps matches as integer multiplies is a not a solution. 168 steps or 192 are warranted.
In any case, I think it’s a flaw in the current MOD host that it simply ignores existing LV2 meta-data.
There is http://lv2plug.in/ns/ext/port-props/#rangeSteps precisely for that case:
This value indicates into how many evenly-divided points the (control) port range should be divided for step-wise control. This may be used for changing the value with step-based controllers like arrow keys, mouse wheel, rotary encoders, etc.
seems exactly what is called for here (and dates back to LV2 from 2012).
The reasoning is simple: The host cannot know what a suitable sub-division is and should not even try. Casual users may know even less about this and should not be bothered (I’d even argue that a user should not be allowed to change it: more possible bugs, unwanted side-effects for odd ranges).
It takes a Plugin author a significant amount of time to pick proper ranges, calibrate steps and fine tune it. The MOD currently ignores all this (e.g. a EQ bandwidth control in 1/Octraves and 3 steps per octave, a BPM control with 0.1 BPM per step in the range or 40…208 , or a -18…+18 dB control and a -20…+20dB control both with 0.5 dB steps alike).
Those are details expected from professional plugins, most users don’t even realize this because the knob sensitivity just feels right. Users only notice when it’s not good… in which case they should file a bug report and get it fixed, and users should not hack around this using some advanced preference pane, IMHO.
PS. I’m sorry if this sounds rather harsh, but I find it best to hash out technical issues that way. And while this level of detail is not unimportant, the MOD rocks!