CV input + Knob value expected/standard behavior, and params[PARAM].setValue()

Hi everyone!
So I found out setValue is available for knobs and switches, already did some tests and works great!

But I have a question:
What’s the expected/standard behavior when a CV input is affecting a knob/button value:

  1. To override the knob value and just use the CV input to control the parameter.

  2. To read the knob value + the CV input and clamp/rescale the result

It seems like option 1 makes things easier.

Also, using params[PARAM].setValue() affects Rack performance?
It looks neat when automating stuff but I can imagine Rack slowing down if lots of modules have this implemented with all the extra drawing, but is there, so we could take advantage of it to spice things up.

I usually simply add the CV signal (appropriately scaled) to the knob value. In most cases, I’m perfectly happy letting the un-clamped result go above or below the knob’s nominal range. In a few cases (such as on the CURVE knobs in some of my modules), the result would do something horrendous if it fell outside the knob’s nominal range, so I clamp the result.

Perhaps in some cases it can make sense to use the CV signal to attenuate the knob. For those cases, scale the CV signal and multiply it by the knob value.

I haven’t noticed any modules using a CV signal to override the knob value. As a user of a module, I probably would not expect that behavior. Are there modules that do that?

Hi Dale!
I think I saw some modules where CV override the knob setting back in v0.5 but can’t remember which ones now hehe.
I’m inclined to keep the clamp/rescale/sum of CV + knob (all my modules work like that where needed now), but I’m having a difficult time trying to tie this along with params[PARAM].setValue() functionality.

Hmmm. It sounds as if you’re trying to animate the knob according to the CV signal. Is that right?

Yeah, if you do that, your computation will go weird. On one step, you’ll read the knob value, add the CV, and set the knob to that value. Then on the next step, when you read the knob value, it already has the CV added in from the previous step. If you add the CV again, you’re double-adding the CV. Then on the next step you add it again, and then again, and so on.

Instead of animating the knob (by setting its value), can you animate something else (some non-parameter graphic) to show the modulation? Like an arc around the edge of the knob? Or a spot on the edge of the knob?

I use momentary buttons to set the knobs on some of my modules works fine for momentary but when using the normal switch it can be a bit buggy. For instance using one knob to set another you will lose control on the slave knob unless you use member and local variables (can still be buggy) see here. Same would hold true for setValue() on the knob on cv/midi signals, when the knob is being controlled by an external signal you will lose control.

Animating the knob I think is only meant for Midi-Map, so using some sort of indicator around or on the knob would probably best suit for cv signals, as it is impossible for two way communication with the cv source output. Lindenberg’s solution for animating the cv is very simple and elegant!

I usually add the CV to the knob param. In some modules I override the knob value entirely if CV is connected but in those cases I use a visual cue to indicate that the knob is inactive; a light or something.

I only set the param for a knob if the user picks a preset from a menu (custom menu, not the built in presets menu)

Indeed, found out that too, and you are right, animating some other graphic seems like the best way to handle it for CV input visual feedback if needed or wanted.

Phil: “Animating the knob I think is only meant for Midi-Map”, this may be it, I wonder if there’s an official word about it. And yes, Lindenberg’s implementation looks great, just took a look, but I guess it’s doing some extra work to accomplish it though? I’m also trying to move away from hacking sutff.

David: visual cue light when overriding a knob, nice idea.

Thinking more about this, I feel like overriding the knob value altogether and animating it when variable CV is present (as a visual cue to remind the user what’s happening) would end being more intuitive, but could only work if it were a Rack standard, and only if there was the possibility of still being able to manually control the knob if a wire is connected but no variable voltage is present.

I will use two kbon widgets.
A normal knob and other that the user can not interact with that shows the param+cv.

You can draw one over the other.

More of a workaround than a hack…

Not tested but I reckon you could get away with drawing a normal svg component over the other knob as long as it takes into account the space required for the first knob.

If you were to do a dot/line which you already have on some of your components you could separate these into two svg files drawing one on top of the other. Lets say the control knob is the outline this could be a circle with a another transparent circle in its centre to fit the cv automated knob into.

might have a line where the two lines will join (just overlap)

When cv isConnected() control of the inner knob could be given up to cv. !isConnected() knob would look normal and the first knob is setting its value or vise versa. because they would be the same values when cv is not connected they should set each other nicely.

if (!INPUT.isConnected()) {
} else {
    //outer knob controls

only drawback is having 2 different tooltips if you set the strings in the config to look the same you can get around it. otherwise it would displays as #n #n

Same could be done with the line or a dot but it would have to have its centre and box size the same as the first knob to rotate. Trick I learned whilst trying to do something similar: you could grab the outer circle of the knob, position the line/dot then bring the transparency all the way down to 0 on the outer circle, shift select the dot/line and group. As long as the dot/line is inside the 0 alpha circle it will always be centred to the box size of the invisible circle. Not a hack, I swear!


Kind of like adding a cap graphic to the knob, but with more control hehe.

I did something similar on an unreleased module, using a led switch and a knob, it worked just fine back then.
I guess I can update that module to V1 and do further tests, and see if there’s a not so hacky way to disable the inner knob from user interaction :wink:

Yep movable cap!

Isn’t this more or less what the Lindenberg modules do?

It’s similar, he draws a triangle on the knob and offsets its centre difference being it is done internally with NVG