Continuous model type

[DomClark]

Currently, none of LMMS's models are continuous. For example, the volume of a track can only be set to the nearest multiple of 0.1. Often, there is no reason to restrict the precision of a model within its range, and frustrations with this can be seen, for example, in #4565 and #5404, along with a temporary fix for LADSPA plugins in #4574.

I propose adding a continuous model type, which can hold any (normal) floating point value between its minimum and maximum. It, or knobs that use it, should have the following behaviour:

• Modifying the value through a dialog box should not quantise the value to any step size, unlike current models.
• Modifying the value using the scroll wheel should still obey a specified step size, like current models, in order for scrolling to make a usable difference to the value. I'm not sure whether this should simply change the existing value by the step size, or whether it should snap to a multiple of the step size above the minimum value.
• Modifying the value by dragging a knob should not quantise the value to any step size, unlike current models. However, the dragging modification rate should still be chosen so that the model can reach its minimum and maximum value without excessive mouse movement, and so that dragging the knob does not introduce long, scary-looking fractional parts to the value.
• Modifying the value through automation should not quantise the value to any step size. Current models quantise the end points of automation in each buffer, but sample-exact automation can interpolate between these without quantisation. Once the new model type is implemented and has been substituted where appropriate, discrete models should be changed so that sample-exact automation is quantised.

[he29-net]

Wouldn't it be enough to just modify the existing float model? Just add a new "continuous" parameter to the constructor, defaulting to false to keep it compatible with old code. If enabled, quantization would be turned off and the step size parameter could be instead treated as the recommended step size or rate factor for GUI elements, so that the mouse does not have to be moved to extremes and so that "weird fractions" are not produced.