General discussion of step size / speed use cases, UI and documentation

[vonglan]

Terminology
One thing, where I am not sure if there is a different, "special" definition in the technical details of the VST parameter API.
I will use the following terms:
"toggle target" - Target parameter that can (semantically) only be on or off (or 2 other states). No matter if technically this is implemented as a 0-127 value or 0.00000000 to 1.00000000 or 0 to 100% or whatever.
"discrete target" - Target parameter that can (semantically) have "few" distinct states, let's say less than 20. Again, no matter how this is technically implemented.
"continuous target" - Target parameter that is semantically a continuous range. No matter that it is technically always implemented as discrete values (because we are in a digital system, not analog).

General use cases / Requirements

G1 Decoupling
Controller-dependent configurations should not creep into the Main Mapping.
Target (e.g. VST parameter)-dependent configurations should not creep into the Controller Mapping.
--> I think this is currently not 100% fulfilled, see #311

G2 Every kind of mapping should be achievable in Main Mapping alone (?)
Not sure whether this is your goal. But it might be something "basic" users want when they create mappings.
--> I would sacrifice this requirement if it stands in the way of other goals, but I wanted to list it here.

G3 Drop the "Virtual Button" concept if it does not have any advantages (?)
You already said you would like to keep that concept. (And I already configured it like that in the Analog Synth Set.)
However, I suspect that everything that is possible with Virtual Button is also possible with Virtual Multi. In other words, that there is no (necessary) technical difference in your coding. I suspect that currently it is only good for documentation: "This virtual target is always on/off".
--> If this is the case, I think the distinction and concept should be dropped, for the sake of simplicity and minimalism.
A related observation: sometimes I think "ah, this virtual target is certainly on/off only", only to discover later on that there is a VST parameter for that virtual target that allows more than just on/off. (Example: Synthesizer Unison on/off, but then some synths have different unison and polyphony modes)

Another general comment:
I would rename the Main Mapping to Target/Main Mapping.

Controller-related use cases / Requirements

Note: For discussion of Controller Mapping, I will not distinguish between continuous and discrete targets, because a) they are both transferred via virtual multis, and b) often it is VST-specific whether the parameter is discrete or continuous.

C1 Absolute knob or fader (or velocity-sensitive pad or key), controlling a continuous (or discrete, see above) target
--> no problems

C2 Simple controller button, used for a toggle target
Note that it might be that the controller sends 0-2 (example: OB6 filter key track), but still we might want to map that to a toggle target.
--> no problem (might have to use source character = toggle-only in Controller Mapping; Main Mapping mode should be Toggle)

C3 Encoder, used for continuous target
It should be possible to decide in the Controller Mapping whether the acceleration feature is used or not.
--> Currently not possible, see #311

C3b The same, with a zoom in or out factor from a ReaLearn parameter
--> new requirement #204

C4 Absolute knob or fader, controlling a continuous target in "make relative" mode
--> new requirement #203

C4b The same, with a zoom in (fine control) factor from a ReaLearn parameter
--> new requirement, combination of #203 and #204

C5 Simple controller button, used for continuous target
Uses the incremental button mechanism.
The whole range should be travelled in n steps (typically n is odd, so a neutral 50% position can also be reached)
--> Currently not possible without violating G1 Decoupling, see #311

C5b The same, with a zoom in (fine control) factor from a ReaLearn parameter
--> new requirement #204

C6 Velocity-sensitive controller (pad or keyboard key), used in incremental mode for continuous target
(or decremental)
Here, it is required to scale the value, or restrict to a certain range. This is possible with the EEL transformation and/or source min/max in combination with out-of-range behavior.
--> no problem

C6b The same, with a zoom in or out factor from a ReaLearn parameter
--> new requirement #204

Target-related use cases / Requirements

T1 Continuous virtual source, continuous target parameter
For example Volume or Cutoff Frequency
--> no problem

T2 Continuous virtual source, toggle or discrete target parameter
Example: Cutoff Frequency Velocity Sensitivity. Some VSTs only offer on/off for this.
--> no problem

T3 Toggle virtual source, toggle target parameter
--> no problem

T4 "Discrete" virtual source, discrete target parameter
With "Discrete" virtual source I mean either the controller sends 0-4 directly (e.g. LFO wave shapes), or it is an incremental button using the Controller Mapping mechanism.
Now the problem arises, that the target parameter might have a different number of discrete values (in the User Guide, you give the example "navigate within presets".
It should be possible in the Main Mapping to say: my target parameter is discrete, interpret every incoming signal as "move to the next discrete value" (or 2 or 3, like you wrote in the User Guide)
--> not sure whether this is already possible, without violation of G1

UI and Documentation

I am a bit confused with the UI and documentation of step size and speed.

My main point is that I would swap the terms speed and step size.

Details:

For encoders and incremental buttons (control only)
also for velocity-sensitive pads or keys. Or maybe easier: Not for absolute knobs or faders

Of "speed" and "step size", I would explain the one that is only available in the Controller Mapping first.

Step size Min/Max: When you deal with relative adjustments of target values in terms of increments/decrements, then you have great flexibility because you can influence the amount of those increments/decrements.

I would remove the sentence, because it does not apply specifically to "step size". The whole section (including "speed") is related to non-absolute sources.

This is done via the Step size setting, which is available for all continuous targets.

a) As said before, I would call this "speed". And what exactly is meant with "continuous" here, especially in the context of VST parameters?

(for rotary encoders which support acceleration and virtual control elements that are mapped as "Incremental buttons" and have a "Speed" > 1x)

need to add velocity-sensitive pads or keys, I think

If you set this to the same value like Step size Min, encoder acceleration or changes in velocity will have absolutely no effect on the incrementation/decrementation amount.

As said before, this topic (switch acceleration on or off) should be in the Controller Mapping.

Speed Min/Max: When you choose a discrete target, the Step size label will change into Speed.

As I wrote elsewhere, it should be mentioned here at the beginning that this is also obligatory for Controller Mappings.

Discrete means there's a concrete number of possible values - it's the opposite of continuous.

In the controller mapping, it can not always be known whether the VST parameter target is (semantically) discrete or continuous, see example above.
Or is "discrete" here a technical term, like a technical attribute of the VST Parameter API?

If a target is discrete, it cannot have arbitrarily small step sizes.

The Controller Mapping can not always (and should not need to) know whether the target parameter is semantically discrete or continuous.

It rather has one predefined atomic step size which never should be deceeded. ... That's why Speed allows you to multiply (positive numbers) or "divide" (negative numbers) value increments with a factor instead.

That seems like a contradiction to me: an atomic step size that should not be "crossed" (the actual value should not fall below the atomic step size), but then division is possible?
But here we are in the controller mapping, so I think it is not actually about the target, but rather the zoom in or zoom out.

Example:
Let's assume you selected the discrete target FX: Navigate within presets, which is considered discrete because an FX with for example 5 presets has 6 well-defined possible values (including the option), there's nothing inbetween. And let's also assume that you have a controller like Midi Fighter Twister whose rotary encoders don't support built-in acceleration. Now you slightly move an encoder clock-wise and your controller sends an increment +1. If the Speed Min slider was at 1 (default), this will just navigate to the next preset (+1). If the Speed Min slider was at 2, this will jump to the 2nd-next preset (+2). And so on.

The topic "how many discrete values does the target have" belongs to the Main Mapping, so this should not be discussed here, I think. And for the discrete values I would prefer speaking of "steps" instead of "speed".

For the example, maybe incremental buttons are a more typical source?

There are FX plug-ins out there which report their parameter as discrete with an insanely small step size (e.g. some Native Instrument plug-ins).

This sentence is where I got the suspicion that "discrete" and "continuous" in the user guide does not mean semantically discrete or continuous, but a technical attribute in the API.

[helgoboss]

Terminology
One thing, where I am not sure if there is a different, "special" definition in the technical details of the VST parameter API.
I will use the following terms:
"toggle target" - Target parameter that can (semantically) only be on or off (or 2 other states). No matter if technically this is implemented as a 0-127 value or 0.00000000 to 1.00000000 or 0 to 100% or whatever.
"discrete target" - Target parameter that can (semantically) have "few" distinct states, let's say less than 20. Again, no matter how this is technically implemented.
"continuous target" - Target parameter that is semantically a continuous range. No matter that it is technically always implemented as discrete values (because we are in a digital system, not analog).

Got it, roughly the same way I use these terms.

General use cases / Requirements

Is this your requirements or your understanding of what requirements I had in mind when creating ReaLearn?

G1 Decoupling
Controller-dependent configurations should not creep into the Main Mapping.
Target (e.g. VST parameter)-dependent configurations should not creep into the Controller Mapping.
--> I think this is currently not 100% fulfilled, see #311

With the exception of "Rotate" (your request) and "Send feedback after control", there's no connection between controller and main mappings. A main mapping doesn't know about its controller mapping and vice versa. Both only communicate in form of virtual control element messages. That was my vision for the concept of virtual controllers and it's fulfilled.

G2 Every kind of mapping should be achievable in Main Mapping alone (?)
Not sure whether this is your goal. But it might be something "basic" users want when they create mappings.
--> I would sacrifice this requirement if it stands in the way of other goals, but I wanted to list it here.

Has always been like that. You don't need controller mappings, they are completely optional.

G3 Drop the "Virtual Button" concept if it does not have any advantages (?)
You already said you would like to keep that concept. (And I already configured it like that in the Analog Synth Set.)
However, I suspect that everything that is possible with Virtual Button is also possible with Virtual Multi. In other words, that there is no (necessary) technical difference in your coding. I suspect that currently it is only good for documentation: "This virtual target is always on/off".
--> If this is the case, I think the distinction and concept should be dropped, for the sake of simplicity and minimalism.

It's true that everything that *technically is possible with Virtual Buttons is also possible with Virtual Multis. Of course. You don't need a bool type if you have an int type. The distinction is made mainly because of this:

1. Before there were named virtual control elements, I mainly thought of 8 buttons + 8 multis layouts. So this distinction was needed. I agree that for this reason alone it's not needed anymore because it could be part of the name (e.g. button-8).
2. With buttons (pure non-velocity-sensitive buttons), you interact and do other things than with multis. Some settings make sense for multis which don't make sense for buttons (and the other way around but that is less clear). This is information that could be used to simplify the GUI (which also many users request). If I now remove that, I waste that possibility.

For reason 2 I would like to keep this distinction. I don't find it so bad, it's also quite intuitive and maybe a helpful info for a main preset author if he can rely on the fact that the source is a button, and not some multi ... come on, they are very different. I would feel kind of lost if I wouldn't know this very basic character of the source.

Something that I could imagine: To make the button/multi information an additional thing, not part of the ID. But then I would have to write a migration for all presets that use numbered virtual controls and convert them into named ones (by prefixing button/ or multi/) - in order to avoid name clashes.

A related observation: sometimes I think "ah, this virtual target is certainly on/off only", only to discover later on that there is a VST parameter for that virtual target that allows more than just on/off. (Example: Synthesizer Unison on/off, but then some synths have different unison and polyphony modes)

When I think about a virtual target, I don't think about the final target (e.g. VST parameters) at all. That's because we use these very different philosophies when designin controller presets. For me, a controller preset is only a representation of the controller itself. A main preset is written for a controller preset (or rather a set of standardized virtual control elements), not the other way around.

For the special case #205 it makes sense to partially think in terms of targets. Then my recommendation is to use Virtual Button only if you are absolutely sure that the target is never more than on/off. If in doubt, use Multi everywhere. I had a look in the code and I think that the only difference between Button and Multi (apart from current or future UI differences in the main mapping) is that some control messages are not forwarded with buttons because they wouldn't make sense. So you should be safe using Multi everywhere.

I think if I hide different UI elements in future depending on the virtual control element type, I will hide them for Virtual Buttons only. They are like a subset of Virtual Multis. I will look into this in detail in #314.

Another general comment:
I would rename the Main Mapping to Target/Main Mapping.

That doesn't look like an improvement to me.

C3 Encoder, used for continuous target
It should be possible to decide in the Controller Mapping whether the acceleration feature is used or not.
--> Currently not possible, see #311

You can decide it, but only for the controller. Not for the actual mapping to a REAPER target. This needs to opt-in for acceleration as well. Not planning to offer an "Enforce acceleration from controller mapping" feature (see #311).

C5 Simple controller button, used for continuous target
Uses the incremental button mechanism.
The whole range should be travelled in n steps (typically n is odd, so a neutral 50% position can also be reached)
--> Currently not possible without violating G1 Decoupling, see #311

I think you solved this in another ticket (#282) using a quick and dirty way (setting the speed to 20x or something) and were satisfied with it. If you are not satisfied anymore with this anymore, let's not approach this with yet another workaround but with a new control type as suggested in #282 (comment) and #311 (comment). One workaround just leads to more workarounds. If you want your controller to send steps of 20% in order to let 5 presses cover the whole value range, this is a completely new feature, has nothing to do with main/controller mapping differences. Tracked from now on in #315.

T4 "Discrete" virtual source, discrete target parameter
With "Discrete" virtual source I mean either the controller sends 0-4 directly (e.g. LFO wave shapes), or it is an incremental button using the Controller Mapping mechanism.
Now the problem arises, that the target parameter might have a different number of discrete values (in the User Guide, you give the example "navigate within presets".
It should be possible in the Main Mapping to say: my target parameter is discrete, interpret every incoming signal as "move to the next discrete value" (or 2 or 3, like you wrote in the User Guide)
--> not sure whether this is already possible, without violation of G1

For incremental buttons this is already supported. Each discrete target (e.g. Project: Navigate within tracks) has "Speed Min/Max", not "Step Min/Max". No matter how much you press, you can move always to the next track.

For discrete multis, #184 is the solution.

The rest of this post is a bit much, maybe looking into it later. Please prefer more small posts if possible. At some point I will have to skip either the post reading or the programming.

[vonglan]

General use cases / Requirements

Is this your requirements or your understanding of what requirements I had in mind when creating ReaLearn?

No, this section together with the other sections are all use cases/requirements that I think are generally important, related to the area of speed/step size. Of course, I have a special focus on #205 . But the goal was to list all valid use cases (related to speed/step size).

G3 Drop the "Virtual Button" concept if it does not have any advantages (?)
...

For reason 2 I would like to keep this distinction. ...

Yes, it is not so important and a matter of taste. And I also think possible GUI simplifications are good.

Something that I could imagine: To make the button/multi information an additional thing, not part of the ID. But then I would have to write a migration for all presets that use numbered virtual controls and convert them into named ones (by prefixing button/ or multi/) - in order to avoid name clashes.

No, I would not do that. Making it optional would add complexity (and the effort does not seem justified).

A related observation: sometimes I think "ah, this virtual target is certainly on/off only", only to discover later on that there is a VST parameter for that virtual target that allows more than just on/off. (Example: Synthesizer Unison on/off, but then some synths have different unison and polyphony modes)

When I think about a virtual target, I don't think about the final target (e.g. VST parameters) at all. That's because we use these very different philosophies when designin controller presets. For me, a controller preset is only a representation of the controller itself. A main preset is written for a controller preset (or rather a set of standardized virtual control elements), not the other way around.

Yes, they are both interface layers, which happen to be implemented technically by the same infrastructure, but have a completely different kind of content.

For the special case #205 it makes sense to partially think in terms of targets. Then my recommendation is to use Virtual Button only if you are absolutely sure that the target is never more than on/off.

I did it like that. Will keep it like that.

C5 Simple controller button, used for continuous target
Uses the incremental button mechanism.
The whole range should be travelled in n steps (typically n is odd, so a neutral 50% position can also be reached)
--> Currently not possible without violating G1 Decoupling, see #311

I think you solved this in another ticket (#282) using a quick and dirty way (setting the speed to 20x or something) and were satisfied with it. If you are not satisfied anymore with this anymore, let's not approach this with yet another workaround but with a new control type as suggested in #282 (comment) and #311 (comment). One workaround just leads to more workarounds. If you want your controller to send steps of 20% in order to let 5 presses cover the whole value range, this is a completely new feature, has nothing to do with main/controller mapping differences. Tracked from now on in #315.

I used to think that was what "incremental button" was about (and it can be achieved with that method, with some small disadvantages).
I will add some info to #315 .
Whether or not it is worth implementing, depends on whether other ReaLearn users find it interesting to control their VSTs with their hardware synths.

T4 "Discrete" virtual source, discrete target parameter
With "Discrete" virtual source I mean either the controller sends 0-4 directly (e.g. LFO wave shapes), or it is an incremental button using the Controller Mapping mechanism.
Now the problem arises, that the target parameter might have a different number of discrete values (in the User Guide, you give the example "navigate within presets".
It should be possible in the Main Mapping to say: my target parameter is discrete, interpret every incoming signal as "move to the next discrete value" (or 2 or 3, like you wrote in the User Guide)
--> not sure whether this is already possible, without violation of G1

For incremental buttons this is already supported. Each discrete target (e.g. Project: Navigate within tracks) has "Speed Min/Max", not "Step Min/Max". No matter how much you press, you can move always to the next track.

Does this also work for (semantically) discrete VST parameters, or only Reaper targets? The VSTs (that I saw) don't receive discrete values (I assume this is different for Reaper targets) but seem to receive a continuous value and then map internally, e.g. 0-0.199 = discrete setting 1, 0.2-0.399 = discrete setting 2, etc.
Would this example work as desired if I set the step size to 0.2?

[helgoboss]

I think you solved this in another ticket (#282) using a quick and dirty way (setting the speed to 20x or something) and were satisfied with it. If you are not satisfied anymore with this anymore, let's not approach this with yet another workaround but with a new control type as suggested in #282 (comment) and #311 (comment). One workaround just leads to more workarounds. If you want your controller to send steps of 20% in order to let 5 presses cover the whole value range, this is a completely new feature, has nothing to do with main/controller mapping differences. Tracked from now on in #315.

I used to think that was what "incremental button" was about (and it can be achieved with that method, with some small disadvantages).

"Incremental buttons" converts an incoming absolute value (e.g. a 100% button press) to a step of e.g. 20%, yes! But it doesn't send these 20% further to another processing stage. It uses it immediately by querying the current target value, adding the 20% to that value and sending the resulting absolute value (e.g. 30% if the target value was at 10% before) to the target processing stage.

What you want/need (if I understand correctly) is a way to define a particular step size (e.g. 20%) already in a virtual controller mapping. This virtual control element then sends the 20% to the main compartment - which is a totally different processing stage (controller and main compartment are strictly separated). Conceptually, ReaLearn doesn't support this kind of message yet. Because real MIDI controllers never send this kind of messages. They only send absolute values (e.g. "Set to 30%") or relative ones (add 1).

For incremental buttons this is already supported. Each discrete target (e.g. Project: Navigate within tracks) has "Speed Min/Max", not "Step Min/Max". No matter how much you press, you can move always to the next track.

Does this also work for (semantically) discrete VST parameters, or only Reaper targets? The VSTs (that I saw) don't receive discrete values (I assume this is different for Reaper targets) but seem to receive a continuous value and then map internally, e.g. 0-0.199 = discrete setting 1, 0.2-0.399 = discrete setting 2, etc.
Would this example work as desired if I set the step size to 0.2?

It only works if the plug-in reports the parameter as discrete, e.g. if with VST 2 if VstParameterProperties stepFloat is set. Unfortunately this is not supported by many plug-ins. To be fair, at the moment ReaLearn also doesn't support it. Configuring step sizes is something I want to add (#209). I've heard NI plug-ins often seem to report continuous parameters as discrete (with 10000 steps). Annoying.

If the plug-in doesn't report a step size, it's completely up to you to find the correct step size in ReaLearn.

[vonglan]

The rest of this post is a bit much, maybe looking into it later.

Sorry. I just wanted to get the complete picture (about that area) clear in my head, then give feedback, then be finished with it. Whatever and whenever you do anything with the feedback.

Please prefer more small posts if possible.

This felt like one big discussion topic for me, so I put that into one big discussion post intentionally.

At some point I will have to skip either the post reading or the programming.

We certainly don't want you to skip the programming!
I don't think I have any other bigger topics. And I also don't want to spend too much time on discussion, rather finish #205 and then move on with other "projects".

I'll give reactions to your other answers maybe later in the day.