I was using a @x42’s MIDI Clock plugin ( Plugin Idea... Start/Stop real time midi message plug in ) and assigned the BPM to a knob. Unfortunately the knob will not change the BPM in single increments even at the most sensitive setting. It currently goes in 2.63 increments… 68.87BPM to 71.50BPM…
Can you make the knob so that it will increment one value at a time?
Continuing the discussion from Plugin Idea… Start/Stop real time midi message plug in:
well
there are two ways 
one is not to change the plugin and select a range that matches the sensivity steps, so that each range step is a integer number
the other is to change the plugi to use integers in the BPM control port.
Interesting…
I’m learning quite a bit about how to problem solve from all the discussions…
@x42 - What do you think?
Gian, this is a workaround at best.
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!
The only part that is ignored is during the UI setup.
The hardware can do as many steps as needed (but it will take a longer time to change a value from min to max).
rangeSteps are implemented in the host. it’s not “implemented” in the UI knobs because the knobs use filmstrips and we currently map the user click&drag step to the number of those filmstrips.
if your knob has 127 filmstrips, it will use them as step number (again, UI wise only).
when you address a plugin parameter to a hw knob, the rangeSteps property is read from the plugin and used as default value (plus the usual 15, 33, and 63).
for MIDI the step is always 127 or 2, for obvious reasons.
indeed, I wasn’t aware that it’s only the UI that ignores rangeSteps.
Still, while the LV2 rangeSteps property does affect the knob granularity, the mapping to the encoder is useless for anything real-world: If one adds pprop:rangeSteps 169; to mclk.lv2’s BPM (40…208) control port, the mapped value increments/decrements in 1 BPM, but at about 10 BPM per 360 degree turn of the knob. It takes about 17 turns to sweep the range.
Ideally the steps would be more fine grained, but asking a user to turn the knob 170 times for a step-size of 0.1 BPM or even just 34 times for a 0.5 BPM granularity is, for want of a better word, absurd.
So the problem is rather that the knob’s step mapping is not related in any way to the range.
Toying with the knobs on the MOD I’d expect 4 or 5 turns from min to max will be a good result for most parameters.
As for MIDI, what meta-data is used to enforce the range on the given control ports? units:midiNote ?
While speaking of knob turns: Every time I need to turn the knob more than 180 deg, either my thumb or middle-finger gets stuck on the handle-bar. I work around this by touching the knob with only one finger on the top, but that does not feel right. I even considered removing the handle, am I the only one?
Hi @x42
Yes. I know it is a workaround
The ideal case, in my perspective, is to have these 3 options - 17, 33 and 65 - available as an option when the plugins does not explicitly sets a rangestep size. If the plugin does, then we use the specified one.
In @Skydiver’s case, is the problem the fact that the steps are too big or the fact that their are not treated as integers?
In automotive applications – at least in recent AUDI models – the mapping is adjusted by how fast the user turns a knob. If it is turned slowly, the iterable (e.g. a playlist or a list of street names) is moved item by item and if the user rotates the knob quickly, only every 10th item (or so) is selected.
This might work well for the Duo, too… but it needs some user testing, to find the best threshold for this, it is not as straight forward, and it would be some work to implement…
PS: who needs 0.1steps for BPM?
We have this feature in the roadmap but that is for the very future when we put the controller through a big overhaul.
Acceleration of the knob seems to be, by far, the best apporach.
Those who do match tempo to existing material. Then again 0.125 (1/8) steps are more useful to factor in musical time.
Hahaha… more things to look forward to! 
@x42 Ah, makes sense. But wouldn’t it be easier to adjust this in the software rather than with the physical buttons?