General, switchable „Step size zoom“ factor for encoder and incremental button Targets

[vonglan]

As a VST user, I would like to be able to switch easily and between the normal encoder (or incremental button) step size, and a mode for fine tuning of VST parameters, in which the step size is automatically much smaller.
It should be a general switch, so I do not have to duplicate all my mappings.

Possible implementation (I think):
The switch should be connected to a ReaLearn parameter, and affect all encoder/incremental button Targets of one ReaLearn instance.
There should be a new configuration possibility in the header:
„Step size zoom in with parameter“ and a selection box for the parameter (with default <Constant 100%>“).
If a parameter has been chosen, its value determines the zoom factor (100% = like without zoom, 1% = 100 times finer).
I could also be implemented to work both ways (10% = like without zoom, 1% = 10 times finer/slower, 100% = 10 times bigger/faster).
Could also fulfill the "user needs" behind requests 133 and 32, I think.

[helgoboss]

Sounds very useful workflow-wise.

I like to implement features in a generic way, first to not artificially limit the ways in which they can be used and second to have as few as possible redundance in concepts and implementation. So I would first need to think about how this can be well integrated and potentially be married with other features to achieve something even more powerful.

Some thoughts:

1. Conditional activation: As I understand it, one main novelty of this feature would be the ability to do this without duplicating mappings. I mean, you can switch between different step size "zoom" levels already now by defining one mapping per zoom level and switching between them using conditional activation. One downside is that this means management overhead. Another (maybe more severe) downside is that you can't change the zoom factor dynamically.
2. Dynamic values: One aspect of your request is to make a certain mapping setting value depend on a ReaLearn parameter value. Dynamic track calculation #160 is something that is looking into generalizing this idea and I want to implement it within the next days. This should definitely be considered with regard to a potential feature marriage.
3. Inheritance: Another aspect of your request is that you want to apply this not just to one mapping but to many. The generalization of this is Add instance track and possibility to change it (e.g. for track pinning) #161, which deals with inheritance of certain mapping settings from the whole instance or group.

[vonglan]

With regard to 2 and 3: yes, sounds like that could be married.

With regard to 1:
Not sure what you mean with "Management overhead".
Changing the zoom size dynamically: yes, this would be possible the way I imagine it. Whenever an encoder change is received and the step size is evaluated, the ReaLearn runtime checks if a Zoom parameter is configured. If yes, the step size is (sort of) multiplied by the current value of that parameter.

[helgoboss]

With regard to 1:
Not sure what you mean with "Management overhead".
Changing the zoom size dynamically: yes, this would be possible the way I imagine it. Whenever an encoder change is received and the step size is evaluated, the ReaLearn runtime checks if a Zoom parameter is configured. If yes, the step size is (sort of) multiplied by the current value of that parameter.

The mentioned downsides were not about your implementation idea but about explaining (mostly to myself) why the aready available "Conditional activation" feature is not an adequate tool for this.

[vonglan]

This could be implemented in
Main Mapping / Tuning / For encoders and incremental buttons, under Step Size
with a new field
Dynamic Zoom Factor (optional)
with possibility to enter a formula including a parameter, like you suggested in #203 .

I think this function is useful for (result) values between 0.01 and 100.0 (any maybe 0 for some use cases).

[helgoboss]

I thought you were more thinking about a factor (multiplication of the existing setting)?

[helgoboss]

Oh sorry, I was not reading carefully enough. Of course, a formula would allow for multiplication.

[vonglan]

the formula could be like this:
p1 > 0.5 ? 10 : 0.1
or even better with 3 cases:
p1 < 0.3 ? 10 : p1 > 0.7 ? 0.1 : 1

[vonglan]

or it could be done in a more general way:
Transformation for encoder movements:
y = x * (p1 < 0.3 ? 10 : p1 > 0.7 ? 0.1 : 1)

And thinking about it again, it could be useful to have it available for Controller as well as Main Mappings.

[vonglan]

Just to let you know: this use case seems less important to me now, than I thought.
In all the VST mappings that I made, I think the only parameter where the "fine" control was necessary, was u-he Diva's combined Oscillator Pitch (they have two different screen elements for Octave Range and Semitone/Detune, but only one parameter). And I could implement that by using Step Size min=max=0.05 for the "pitch fine" source.
I have no experience how ReaLearn works with Reaper parameters relating to the position on the timeline. It might be useful for that as well.

[vonglan]

Just to let you know: this use case seems less important to me now, than I thought.
In all the VST mappings that I made, I think the only parameter where the "fine" control was necessary, was u-he Diva's combined Oscillator Pitch

Update:I recently encountered the problem again, with GForce's Oddity and SEM VSTs.