Zynthian UI parameter editing resolution drop in oram

[polluxsynth]

Describe the bug
In the old 32-bit image, the resolution of parameters when editing using the Zynthian UI seemed to be about 1/200th of the parameter range. By resolution, I mean how much the parameter changes when the encoder is moved one click. So, for instance, a parameter whose range is 0..10 would have increments of 0.05 . Parameters with a range of 0..1 would have increments of 0.005 . This offers excellent control of parameters.

With oram, this seems to have changed, in a somewhat haphazard way. To take one example, all OB-Xd parameters have a range of 0..1, and the resolution is now 0.01 . This means that there are 100 steps for the whole range, which is borderline acceptable compared to the way it was before. Classically hardware synths have ranges of 0..63, 0..100 or 0..127, so it's in the same ballpark at least, but it's step back from the previous version.

However, in some cases, such as the MiMi-d, the resolution seems not to be based on the parameter itself but ... something else (maximum range of parameters on the same page? No idea. I just note that the resolution seems to be different compared OB-Xd for similarly ranged parameters). For instance, the oscillator detune range of the MiMi-d is -1..+1 (semitones). In the old 32-bit stable image, the resolution was around 0.01 or so, but with oram, it is 0.1, yielding a mere 20 values (10 cent increments) within the range, which makes editing this parameter in the Zynthian UI useless.

EDIT I'd missed the fact that oram has a fine adjustment mode which is entered by holding the knob down while turning it. However, it still seems to me that the resolution in the coarse mode does not track the actual parameter range, meaning that some parameters (such as the MiMi-d detune) get unacceptably large steps in the coarse mode.

To Reproduce

1. Create a chain with MiMi-d
2. Go to an oscillator page
3. Adjust the oscillator detune parameter
4. Note how the resolution is 0.1, so the whole range is a mere 20 steps

Expected behavior
The resolution should not be worse than it was with the old 32 bit stable image.

Setup:

• SD-image: 2024-09-23-zynthianos-bookworm-aarch64-oram-2409.img (plus updates)

• Hardware Config (Zynthian v4 - in the webconf, Kit is set to v4):
  Raspberry Pi 4 Model B Rev 1.4
  Audio: HifiBerry DAC+ ADC PRO
  Display: ZynScreen 3.5 (v1)
  Wiring: MCP23017_ZynScreen
  I2C: MCP23017@0x20, MCP23017@0x21, ADS1115@0x48, MCP4728@0x61

• Software Version
  zyncoder: oram (71de6d2)
  zynthian-ui: oram (bbc7246)
  zynthian-sys: oram (a717e49)
  zynthian-data: oram (ddfa009)
  zynthian-webconf: oram (b530397)

[riban-bw]

There is a new coarse/fine control. With encoders, you press and turn for fine control. With touchscreen you swipel left/right for fine control. I haven't yet looked to see how you might do the fine control with bound control like CUIA binding. @jofemodo, did you consider this when adding this feature?

[polluxsynth]

Ah, that explains the discrepancy between different versions.

I still think that, in that case, the coarse resolution should follow the parameter range to a higher degree. For instance, the OB-Xd filter cutoff (parameter range 0..1, coarse resolution 0.01), or MiMi-d filter tracking (parameter range 0..1) has a coarse resolution of 0.01 which is 100 values for the whole range, and is completely manageable (corresponding to the resolution of many hardware synth parameters), whereas the MiMi-d oscillator detune (parameter range -1..1), has a coarse resolution of 0.1, i.e. a twofold increase in parameter value range results in a tenfold increase in coarse resolution. I think the coarse resolution should be a fixed fraction of the total range, so for a parameter that is -1..1, the coarse resolution should be 2/100 = 0.02 . This would give a more consistent behavior across different parameter value ranges.

As it is now, it looks like the coarse resolution attempts to be an even power of ten, which numerically looks nice, but I don't think users look at continuous parameter values in terms of nice numbers, but rather in terms of the effect they have on the sound, or in terms of how fast the illustrative red arc advances when the knob is turned.

If anything, the coarse resolution should err on the smaller side than on the large side - the problem with too large a coarse resolution is that it makes it more awkward for especially live tweaking, because the steps are audible, whereas if the coarse resolution is on the small side the only downside is that the knob must be turned further than it otherwise would have to.