param-resolutions extension
see in-code documentation. If something is not specified enough, please ask/propose changes of course 👍
could these two be combined into a 'param-extended-info' extension which was also somehow extensible easily?
could these two be combined into a 'param-extended-info' extension which was also somehow extensible easily?
I think it is cool that they have their own interface. In the undo ext we did split the interface to lower the requirements on implementing one or the other.
Regarding the extension, in the semitone example, would the user wants to be able to "quantize" the steps?
So if he is at 0.23 he'd jump to 1.0 instead of 1.23?
Would the host implicitly quantize or there would be a flag?
Toward which value should we quantize the distance? Would it be the value origin?
Regarding the extension, in the semitone example, would the user wants to be able to "quantize" the steps?
So if he is at
0.23he'd jump to1.0instead of1.23? Would the host implicitly quantize or there would be a flag? Toward which value should we quantize the distance? Would it be the value origin?
This is a good question.
Concerning quantizing the distance (0.23 -> 1.23) vs. quantizing the absolute value, I think both can be the desired behaviour. E.g. let's use a coarse octave resolution as an example:
- for a relative "Transpose" parameter it might be good to snap to whole octave values (+7.23st -> +12.00st)
- but for an absolute "Pitch" parameter it might be more adequate to move the parameter by exactly one octave (from C1+56cents to C2+56cents)
I'm against depending on param-origin here. But instead just depend on param so a resolution together with min_value and max_value define an absolute grid of the value range. If implementing both extensions, it would probably be good to place the origin_value exactly on one of the grid points. But more as a recommendation but not a hard requirement.
Defining the "absolute grid" also implies that at each grid point there potentially is a meaningful value (e.g. a whole semitone). Thus I think it is always good to snap to the next meaningful value.
But there could be a flag "prefer_relative_increments" to give the host a hint that it it can quantize the distance, not the absolute value for better user experience.
Makes sense?