This code snippet below is to take a single polyphonic CV input, send the voltages to 16 individual outputs and set each of 16 knobs to indicate the value.
What’s the difference between this and using params[i].setValue(v); ?
I can’t tell from the API docs. They both work, but give slightly different behaviours. Using ‘params[]’ if I use the cursor to move the knob on screen (which I don’t want to do, but hey) then the knob oscillates between the input V and the on-screen V. With the alternative, it does what I’d expect i.e. momentarily show the cursor value then flick back to the input V.
Any tips gratefully received!
void SoxsaMinilabIndicator::process(const ProcessArgs &args) {
if (knobUpdateDivider.process()) {
//Set all 16 knobs to reflect the voltages of each
//channel of the single polyphonic input
float v;
for (int i=0;i<NUM_OUTPUTS;i++) {
v = inputs[0].getVoltage(i);
paramQuantities[i]->setValue(v);
outputs[i].setVoltage(v);
}
}
};
That’s a shame, seemed like a simple solution. It does work, in fact. But if it’s going against the grain I’ll have to look at writing some visual indicator instead.
As param.setValue() and quantity.setValue() exist, where would you normally use them?
Edit - or do you mean using quantity.setValue() is ok, but param.setValue() is not?
As of Rack v1, params are read/write from any code.
ParamQuantity::setValue() interrupts the engine from smoothing parameters when the user changes them with a knob. You usually want to call this one from DSP code.
Thanks. By ‘from DSP code’ you mean the module’s process() method? You’ll have to forgive me, I’m still tuning in.
Just so I’m clear - is it legit to do what I’m doing i.e. have the module set the value? The practical result is that the knob does reflect this value change, but I appreciate that just because I can doesn’t mean I should.
Not knowing enough about the API yet I could imagine there’s some other way to do this e.g. firing an event that mimics a user changing the knob setting, and that percolates through.
please ignore my totally incorrect reply, above. In case you don’t already know, @Vortico is the author or VCV Rack, so his info is much more accurate. But, yes, module’s process() function is where the DSP code runs.
Thanks, yes. The broader question was whether I should be using the param mechanism to get a knob widget to indicate a value set within the module at all. I’ve noticed that other modules don’t do that, although it’s would like here. So I suspect it’s irregular, and that’s not good.
I’ve just this minute finished putting in my own widget - just a text indicator although it does the job. No subversion of the params mechanism involved in this. And I’ve moved the learning on a notch…
I’ve seen the Lindenberg modules put an indicator inside the knob so that knob shows the final value, but the “physical” part of the knob (the part you grab) doesn’t move. Seems like a good compromise. having your code move around the same knobs that the user moves is something that a lot of people would consider odd.
One idea that emerged (not shown in the snippet above) was that it would be behave differently depending on whether the input was connected/not connected: with input connected, the user can’t move the knobs on screen, rather only via the midi controller. With it connected, they can. So you could use it with MIDI-STEP/PILE or MIDI-MAP or even standalone.
But I see now it’s unconventional UI so I’ll drop that idea. Thanks for the advice
