ReaLearn FAQ

How many instances and where to put them?

Since ReaLearn is a VST instrument, you can have many instances of it, not just one. A question that comes up pretty often is how many is right and where to put them?

There’s no definitive answer to that, it all depends on what you want. Here are some basic rules of thumb:

1. It’s common to use at least one ReaLearn instance per controller. However, with ReaLearn’s new Unit feature, this is not a requirement anymore: You can handle multiple controllers with just one instance. In this instance, you have one unit per controller.

2. For mappings that shall be available in any existing or new project automatically, create a ReaLearn instance on the monitoring FX chain

   • If you want to use multiple controllers, simply add multiple instances to the monitoring FX chain.

3. For in-project mappings which control arbitrary parameters on arbitrary tracks, you are totally free to choose where to put ReaLearn, there shouldn’t be any differences in behavior.

   • Putting it on the master FX chain is a good choice if you want it out of your way and usually not be visible.

   • However, in order to be reminded that I use ReaLearn, I usually add some track at the very top and put all ReaLearn instances on its FX chain.

4. Let’s say you have a VST instrument that you want to activate/deactivate for live playing by arming/disarming the corresponding track. And now you want to use ReaLearn as a kind of "Insert" effect for controlling parameters of that VST instrument (or other track-local parameters such as the track volume), only when it’s active. Then put ReaLearn exactly on that track, somewhere above your VST instrument and select MIDI input <FX input>.

   • That way your VST instrument won’t receive MIDI that’s already processed by ReaLearn, which is cool.

   • If you want ReaLearn to only receive MIDI messages that originate from live playing and ignore MIDI that originates from track MIDI items, put it on the input FX chain of that track.

Should I use conditional activation or the "Enable/disable mapping" target?

ReaLearn 2.11.0 introduces an alternative to [conditional-activation]: The ability to tag mappings and enable/disable them via the [realearn-enable-disable-mappings] target. In general, one can say that conditional activation is slightly more powerful but that the enable/disable target is easier to use and enough in most common use cases.

You strictly need to use conditional activation if you …​

• …​ want to activate/deactivate mappings using REAPER automation envelopes.

• …​ want to sync the active/inactive state of a mapping with a dynamic track selector expression.

• …​ want to activate/deactivate mappings in another ReaLearn instance.

• …​ want to activate/deactivate mappings in another compartment within the same ReaLearn instance.

  Note	This particular limitation of the enable/disable target might disappear in the future.

You might prefer conditional activation if you …​

• …​ have a modifier use case (not a bank switching use case).

  • It can be quite intuitive to think of modifiers as parameters that you define once and refer to them in the mapping (to be activated or deactivated) itself.

• …​ have a modifier use case in which you want to combine multiple modifiers (e.g. activate a mapping only if the Shift and Control button is pressed at the same time)

  • This is really much easier to achieve using conditional activation, think about it.

• …​ prefer that the mapping itself defines when it should be active or not (instead of dictating it via tags).

In all other circumstances the enable/disable target should be fine.

More technical explanation

Conditional activation introduces a level of indirection. It allows you to look at the act of enabling/disabling mappings as two different concerns by introducing an intermediate concept called a "modifier" (respectively a "bank").

In particular, it separates the following two concerns:

1. Switching a modifier on/off (respectively activating a bank)

2. Let other mappings follow the on/off state of the modifier (respectively the active bank)

You define these two concerns in different mappings:

1. "Modifier/bank-changing mappings"

2. "Modifier/bank-dependent mappings" (as activation condition)

If you use the alternative to conditional activation, [realearn-enable-disable-mappings], you throw both of these concerns into one mapping!

The advantage of separating these two concerns is that you can change 1 (the modifier/bank-changing mappings, e.g. which button controls the modifier and how) without having to touch 2 (the dependent mappings)! And vice versa. That can make complex setups easier to understand and reason about!

The disadvantage is that it makes simple setups a bit harder to understand than necessary since you need at least two mappings instead of only one.

As always: Choose the right tool for the job and consider starting off with the easiest tool.