Sorry for the mouthful of a title.
Tried to record the behavior - sorry it’s a bit hard to hear, I can re-record if needed when I’m back.
The tl;dr is that
I have a control with 4 discrete states (0, 1, 2, 3)
A mapped knob seems to set the values between all those states correctly, but the last value doesn’t actually change anything in the plugin.
Whereas if I manually adjust with the encoder, it does.
On dev 2.0 latest.
I think this has to do with how the knob mappings map to discrete states.
I notice that for 4 states, the mapped knobs will go from 0-1 in the first 33% of the knob, 1-2 in the next 33%, and then 2-3 in the next 33%. I don’t know if, when the knob is turned all the way clockwise, we are actually hitting the value of “3” if that makes sense, either due to the potentiometer reads or otherwise.
Take a look at the code where the param is being read. Does it require the param value hitting 1.0 (exactly)? That could be a problem for a few reasons…
Due to mappings and other math done on the param value, the knobs might only reach 0.999999999 or something. So it might be that the module never sees 1.0.
Also, it could be a hardware pot calibration issue and we don’t have a user-accessible pot re-calibration routine exposed, so that’s a tough one to work around.
I would suggest changing the code to have it switch at the mid-points, rather than at the extremes. So for four states you want:
if (val < 0.25f) state = 0;
else if (val < 0.5f) state = 1;
else if (val < 0.75f) state = 2;
else state = 3;
That not only alleviates the effects of any small rounding errors or calibration, it also makes it more natural to use a knob as a selector switch-- you don’t have to turn it as far to change positions. And it probably won’t interfere with how the VCV version operates.
Even better is to introduce a little anti-hystersis into that logic so you don’t get chatter if the knob is right on the border.
Awesome, this worked. I just used std::round wherever this was necessary.
Hey @danngreen - wondering if you had any ideas about more universal solutions here - this seems like a very common pattern in a lot of modules and are sometimes difficult to catch unless you check each param for whether or not it measures in discrete states. Could it be possible to adjust an internal hysteresis where perhaps the knob extremes snap to 0 or 1 sooner in their rotation, if that makes sense?
Yeah, I can probably do that.
Though from a UX perspective, it’s still nicer to scale params like switches and buttons so that they transition at the midpoints. Mapping a knob to a button that only changes at 0 or 1 means you have to turn the knob all the way down or all the way up to change it. But putting the points at 0.45 and 0.55 (or just have one point at 0.5) means you can just wiggle the knob a bit to toggle the switch.
There is one thing I’ve done in the SDK which is modify the default low/high threshold values for the rack::SchmittTrigger class. So a module can override this if it needs to but by default buttons/switches based on that class will have a nicer feel to them when mapped.
Yes, you are right. But then I can sell more MM button expanders for you and 4ms.
Ha ha… I guess I need to finish up the Button Expander then!
Hi,
I noticed thats its also a problem when you try to access the first and/or last step of an addressable sequencer like bogaudio addrs.
It really looks like a calibration issue.
I found it! – The pots themselves are well calibrated (phew!), but in the interpolation algorithm which smooths out the values between pot readings, it would often go to 1.0 briefly and then jump back down to 0.999999. Likewise it might go to 0.0 and then stick at 1e-27 or something. So if the module didn’t catch the brief 1.0/0.0 then it would miss it. I fixed this and pushed to v2.0-dev, and will merge into the main branch of v1.x. Should show up in the next release for both branches.
awesome, looking forward to the next release