getDisplayValue and consistency

I’m not filing a feature request at the moment, but just asking: how to keep the display value of a knob consistent with the process method?

Let me explain:
Suppose I have a knob using the displayBase, displayMultiplier and displayOffset fields. Rack calculates the value to display in its own way. If I want the exact same value to be used in the process method I have to repeat the same computation that Rack is doing inside ParamQuantity::getDisplayValue().
I see the following issues:

  • CPU waste (repeating 2 logs or 1 pow for something that has already been computed)
  • code doubling
  • possible inconsistency if the value returned by getDisplayValue is computed differently in a future release of Rack (some more maintenance work required from the devs).

The ideal thing would be to have a params[i].getDisplayValue().
Best regatds

Use ParamQuantity::getDisplayValueString();

The engine should never call getDisplayValue(), that’s for displaying the value only.
It should use whatever method it needs to convert the linear value to a useful value for processing.

I want the float value, not the string

Yes, clearly. The point is that any operation needs to be replicated, that’s a pity.

The reason that it’s highly discouraged to call getDisplayValue() is because you almost always should compute the relationship in a different way as the GUI. In the GUI, it’s perfectly fine to call std::pow or log every frame because it’s accurate, simple, and relatively cheap, but in the engine, you’ll want to compute this with a different method, including

  • lookup tables
  • faster pow or log functions with less accuracy (you typically don’t need ULP accuracy in DSP code)
  • vectorized pow/log functions
  • No log/pow functions at all. Perhaps your DSP algorithm works in linear space (gain/amplitude) while users want to see log space (dB).

getValue() I think!?

This makes sense, thanks.
Also, one can just store the value and recompute it only if the knob has been changed by the user, to save resources.