i can speak the last point a little (with apologies for tediousness.)
i agree it would be better if the parameter value were quantized to nearest decibel.
i think there is no design reason for the present behavior, just expedience:
-
these are parameters of type control. this means they map a ārawā value in [0, 1] to an arbitrary range, quantum, &c, as defined in a ControlSpec. for example, the output range for compressor post-gain is [-20db, +60db]. (here.)
-
the :delta method for control params accepts an incoming number, scales it by 1/100, adds to the raw value, and updates the scaled value. (here.)
-
the output of the raw->ranged mapping is optionally quantized (according to the ControlSpec.) the audio parameter specs do not declare quantization values. (see first link.) so you could try simply changing the line
local cs_POSTGAIN = cs.new(-20,60,'db',0,9,'dB')
to
local cs_POSTGAIN = cs.new(-20,60,'db',1,9,'dB')
[norns/lua/core/audio.lua, line 450]
to round to 1db, and see how that feels.
- however, the other factor is the input to the
:delta function. this is an integer corresponding to the number of positions the encoder moved on the last tick. in fine adjustment mode, the encoder movement is scaled by 1/20.
so, it might feel a little weird to round the scaled parameter values to 1db when changing the raw values by multiples of 0.01 (since encoder movements are integers) - in the case of postgain you will be moving the value in increments of 0.8db that are then rounded to 1db, producing a funky jitter, but maybe that is OK. āfine adjustmentā mode will probably feel better. the encoder scaling in ācoarseā mode could be made smaller.
more generally, iāve had this fleeting thought before, which writing this has ācrystallizedā: i think it would be good if a ControlSpec could define the :delta step (iow, the input quantization) as well as the output quantization. otherwise, its often not a very usable abstraction for sensitive parameters, and the solution so far has been to manually fiddle with the input scaling (iow, encoder sensitivity). it would be cleaner to make this an optional property of the parameter (or its spec, i dunno.)
i donāt have much of an opinion about the other points.