Your input requested: Default FX Parameters

[vonglan]

In #231 , @helgoboss suggested to define and provide a set of default parameter names (instead of P1 etc.).
These would appear to the user as default names for these parameters, but can be replaced by the user (#209 ).

I suggest we collect and discuss ideas here.

For FX Parameters in Controller Mappings:
Bank (#231 ; when this is processed internally in Controller Mappings)
Shift (#231 ; when this is processed internally in Controller Mappings)
Make-Relative (#203 )

For FX Parameters in Main Mappings:
Bank (#231 ; when this is processed in Main Mappings; maybe because there is no Controller Mapping)
Shift (#231 ; when this is processed in Main Mappings; maybe because there is no Controller Mapping)
Zoom Factor (#204 )
Track Index Offset (haven’t used this myself yet, but assume this is useful)
Track Parameter Type (thinking about: Volume, Pan, Mute, …)

[helgoboss]

I thought about this a good deal this morning and my conclusion is that it would make much more sense to provide factory default meanings (shipped with ReaLearn itself) for virtual control elements than for parameters. Let me explain why.

The difference between parameters and virtual control elements

First, it's important to understand the difference in purpose between ReaLearn's virtual control elements (the subjects of virtual targets and sources) and ReaLearn's FX parameters. I'll explain it so we are all on the same track.

ReaLearn's virtual control element: The point of invoking (moving/pressing/turning/...) a virtual control element is to actually control something within REAPER. The effect is there immediately.

ReaLearn's FX parameters: The point of changing one of ReaLearn's FX parameters is to set a course (as in "railway switch"). Some typical use cases: Changing a bank, enabling a modifier, setting the affected track. All of that has an effect, but not immediately. The effect won't become visible until you actually control something (e.g. change a track volume).

Why factory default meanings for parameters don't make too much sense

Let's first talk about controller compartment parameters.

• Actually I found only one use case for controller compartment parameters so far (@vonglan's one): Pretending that a controller has a control element X although it actually doesn't have it.
• Doing this makes a lot of sense in the context of what @vonglan wants to build: A well-integrated set of controller and main presets in the analog synth domain that can be mixed and matched arbitrarily - and it always works, even if some controllers don't offer all control elements that main presets rely on (controller-compartment conditional activation to the rescue)! (Standardized set of Analog Synth virtual parameters, for easier exchange of Mappings #205).
• However, the general idea of the controller presets shipped with ReaLearn (in the Helgoboss ReaPack repository) is another one: To offer controller presets that just map all control elements on the hardware controller 1:1, leaving their purpose totally open, even if the control elements are labeled with "Bank" or "Shift". Using conditional activation in these controller presets would defeat that purpose. Let's call this the "General controller presets use case".
• Also, I think if controller compartment parameters are being used, they will never "leave the controller preset". They are supposed to be changed only within the controller preset, not from outside: Not via automation, not via other ReaLearn instances etc. It just wouldn't make sense.
• Therefore I think assigning default meaning to controller compartment parameters is too opinionated and confusing.
• But: Within @vonglan's scenario it would make sense, as I said. So @vonglan: I would suggest that you offer a kind of controller preset template instead which contains the default parameter names suitable for your cause.

Now let's have a look at main compartment parameters:

• In @vonglan's use case, it could make sense to have default meanings of main compartment parameters. As with controller compartment parameters, a preset template can be a good way to approach that.
• In the "General controller preset use case", having default meanings could make some sense but not too much. It could make sense because main compartment parameters are not unlikely to be controlled from outside (e.g. by other ReaLearn instances, see video). But I wouldn't say it's urgent.

Why factory default names for virtual control elements would make a lot of sense

In the "General controller presets use case", it would be great if a virtual control element that represents a button which is labeled "Shift" on the actual controller would also have the name "shift" (and would be addressable by that name in virtual main mapping sources)! Across all general controller presets! Same with "Bank/Channel". The point of separating controller presets and main presets is that you can freely combine them on a mix and match basis. How cool would it be if no matter which controller you use, you can combine it with any well-designed main preset and it just works!

Example

Someone could build a "Typical Mackie control" main preset which deals with the conventional typical albeit boring control-surface stuff: Setting track volumes, pans, record arming, solo, mute etc. Now imagine this main preset could be used with any controller that has such controls ... and it would just work out of the box! I think this would be really cool. It would exhaust the full potential of Realearn: There are tons of control-surface-specific extensions out there, all hand-written. For ReaLearn most of the same things could be achieved with just ... a preset! No extra extension necessary.

In theory, this is possible already now, but in practice it will not "just work" because the existing controller presets for control surfaces have only numbered virtual controls, not named ones. If they would have meaningful standardized names such as "bank" or "ch5/solo" or "solo", this would really work in practice.

Conclusion/suggestion

Therefore I suggest:

• We find default names for virtual control elements instead of parameters (maybe inspired by the Mackie standard?).
• I put these default names into a dropdown next to the virtual control element name text field. Choosing one of the default names simply fills the text field with that name.

[vonglan]

Sounds reasonable.
I'm afraid I won't be a big help in defining that set of standard virtual sources/targets, because I have nearly no experience with that (in contrast to the topic of controlling synth VSTs).