Override current mappings when focused-FX mappings are activated (automatically)

[stereokai]

In more depth, let's say I want to control two separate FX plugins. The plugins are by default hidden - the windows are closed and I don't have to see them.

Until now, in order to choose which of the two plugins I want to control with my MIDI Fighter Twister, I would press the side button to change the built-in bank, and that would give me a whole new set of controllers. The controllers on each bank were mapped exclusively to each plugin.

Now that I have finally implemented ReaLearn the recommended way, it opens the door to more complex and interesting UI possibilities.

I know I can recreate that behavior using the bank/program feature, through changing the current active set of mappings (aka program) using an internal ReaLearn parameter.

The question is, is it possible to have both the bank & program behavior, and in addition, also activate the correct configuration when I bring up one of the aforementioned VSTs into focus?

Here's my ideal configuration: Let's say I'm currently on the program mapped to VST 1. At this point I can control VST 1 without it even being focused. That's obvious. I can also use the controller I mapped for changing programs, switch to the VST 2 program and then control VST 2 without it being focused. So far so good. Now here comes the interesting part: At this point, with the VST 2 program active, I would like to focus on VST 1, and have its mapping activated. Finally, when I close VST 1, ReaLearn should restore the previously active mapping, meaning VST 2 in this example.

I tried figuring out how to do this, with one instance or even two instances of ReaLearn, but I couldn't so far find a way to connect these two behaviors.

Thanks for reading.

[helgoboss]

Very good description. Short answer: No, it't not possible at the moment - but we can get there.

Long answer

I think what you want boils down to a priority/precedence problem. Here are some thoughts I have:

1. The way to achieve this will definitely involve using multiple instances.
2. Even it doesn't directly solve your problem, I think Conditional activation for the ReaLearn instance itself #109 would be great for you.
   • For the non-auto-load stuff, you could use 2 ReaLearn instances A and B instead of just one and using instance-wide conditional activation to switch between them.
   • That way you don't have to put the rather unrelated mappings for both VSTs into one huge ReaLearn instance.
   • And you would be able to reuse the same presets for your VSTs that will be auto-loaded with the "Auto-load preset" ReaLearn instance (instead of using groups for that).
     • Edit: Just realized, this particular improvement would need another puzzle piece to be possible. Presets must be designed for "Auto-load preset" at the moment by letting the mappings refer to <Focused> FX. Would be good to have an "FX selector" that is more reusable and relates to certain FX or the focused FX - depending on the context. See my new FR Add instance FX and possibility to change it (e.g. for FX pinning) #228.
   • Gives you overall better composability.
3. If you add the "Auto-load FX" instance C to the mix, you have one problem though: Both [A and C] or [B and C] will be active.
   • What you want is that if an FX is focused, only C is active ... and if not, it will fall back to either A or B (depending on your current program). How can we achieve that?
   • I can think of the following ways:
     1. Introduce a kind of layering possibility for ReaLearn instances (something like z-index in CSS).
        • ReaLearn instances in higher layers cover (disable) instances on lower layers.
        • ReaLearn instances on the same layers are always active at the same time.
        • ReaLearn instances don't have to take part in layering, they can also just be always active.
        • In your case, you would have A and B in layer 1 (lower) and C in layer 2 (higher).
        • This sounds like a powerful and generic way that models your use case quite well, though we would need to define what active means exactly. Maybe in your case we could declare a ReaLearn instance as active if it has mappings (= if a preset is loaded).
     2. Rather than having such a generic solution, we could simply add a check box "Disable when FX focused"
        • You would apply that to instance A and B.
        • Mmh, but that could lead to quite annoying side effects.

#188 is related and should be considered when designing the solution.

Let me know if you have further ideas. At the moment the z-index approach looks quite appealing to me.

[helgoboss]

Or maybe a more simple construction: Add a checkbox "Cover other ReaLearn instances that use the same control input if a preset is loaded".

[stereokai]

This is indeed a conceptually complicated problem to solve. And it is definitely a very important enhancement - it seems that not only were multiple orthogonal issues already posted before, but even since I posted this, quite a bit has been discussed around it :)

2. Even it doesn't directly solve your problem, I think Conditional activation for the ReaLearn instance itself #109 would be great for you.

Haha! I knew that you'll have some simple, creative solution for this :)

Edit: Just realized, this particular improvement would need another puzzle piece to be possible. Presets must be designed for "Auto-load preset" at the moment by letting the mappings refer to <Focused> FX. Would be good to have an "FX selector" that is more reusable and relates to certain FX or the focused FX - depending on the context. See my new FR #228.

So, I have also read #228, but still don't exactly understand why #109 is not already attainable today.

• And you would be able to reuse the same presets for your VSTs that will be auto-loaded with the "Auto-load preset" ReaLearn instance (instead of using groups for that).

Call me crazy, but in fact I have my mappings saved both as presets and as groups. I did it to experiment with the feature in question. Of course that is not something we want everyone to do. Which leads me to:

• Gives you overall better composability.

Let's pause for a moment and talk about good composability, shall we? Good composability would be having mapping groups a first class citizen in ReaLearn, and being able to reference them in other mapping groups and in presets. "Write Once Use Everywhere". Kind of like OOP... Now imagine that, together with your "z-index" concept... mind blowing. It's ideal, if you're asking me.

3. If you add the "Auto-load FX" instance C to the mix, you have one problem though: Both [A and C] or [B and C] will be active.

   • What you want is that if an FX is focused, only C is active ... and if not, it will fall back to either A or B (depending on your current program). How can we achieve that?

   • I can think of the following ways:

     1. Introduce a kind of layering possibility for ReaLearn instances (something like z-index in CSS).

        • ReaLearn instances in higher layers cover (disable) instances on lower layers.
        • ReaLearn instances on the same layers are always active at the same time.
        • ReaLearn instances don't have to take part in layering, they can also just be always active.
        • In your case, you would have A and B in layer 1 (lower) and C in layer 2 (higher).
        • This sounds like a powerful and generic way that models your use case quite well, though we would need to define what active means exactly. Maybe in your case we could declare a ReaLearn instance as active if it has mappings (= if a preset is loaded).

     2. Rather than having such a generic solution, we could simply add a check box "Disable when FX focused"

        • You would apply that to instance A and B.
        • Mmh, but that could lead to quite annoying side effects.

I think you nailed the concept man. This is the best generic solution that ReaLearn deserves. And it needs a dedicated UI. Can't run away from it. Please allow me to quote you from #109:

This is by design. I didn't want ReaLearn to get unnecessarily complex (both for user and developer) by providing additional compartments or group presets.

Totally get what you're saying there. But can you look at solution 3 and think "yup, that will be easy to explain!"? Complexity is a crux of the matter here. When I think about it, connecting multiple ReaLearn instances doesn't sound simple or straightforward to me at all. That is definitely an implicit behavior, that would require people to dig into the user guide to understand. Not to mention, not having a dedicated UI for communicating the implicit relationships between these mappings, that get activated in different situations, would be a lot more difficult to follow and maintain without it all being in one organized place. This sounds a whole lot more complex to me than a good UI in a single ReaLearn instance that communicates itself clearly to the user. I do believe the behavior in question here is in fact very useful, and definitely has a mass appeal: have your backbone of generic, essential or live-performace mappings available at all times and have your controller immediately adapt as you're focusing on an effect/instrument VST – who wouldn't want something so genius? It's really ideal. Therefore, I think investing in this feature and making it more accessible and easily attainable is worth it.

On a more personal note, I actually prefer that all of the mappings are in one huge ReaLearn instance - but I'll be my own devil's advocate – that works for my use case and doesn't necessarily fit everyone. To get more technical however, less instances of ReaLearn, presumably less CPU usage? (assuming every instance listens to MIDI input on it's own and not through a central, shared thread), but I digress.

Please allow me to suggest a UI for this. I'm burrowing this from Photoshop, (a relatively unknown and unpopular piece of software, but, maybe you've heard of it :P)

I think that the screenshot speaks for itself :) And while the relevant section is obviously the big list of layers, I included however the surrounding UI as well, for inspiration.

Now all of this is really an ideal goal in my eyes. But then of course, there is this simple-yet-effective, quick-and-dirty solution:

Or maybe a more simple construction: Add a checkbox "Cover other ReaLearn instances that use the same control input if a preset is loaded".

;)

[helgoboss]

1. Even it doesn't directly solve your problem, I think Conditional activation for the ReaLearn instance itself #109 would be great for you.
   Edit: Just realized, this particular improvement would need another puzzle piece to be possible. Presets must be designed for "Auto-load preset" at the moment by letting the mappings refer to <Focused> FX. Would be good to have an "FX selector" that is more reusable and relates to certain FX or the focused FX - depending on the context. See my new FR Add instance FX and possibility to change it (e.g. for FX pinning) #228.

So, I have also read #228, but still don't exactly understand why #109 is not already attainable today.

#109 is attainable today already and doesn't depend on #228 at all. But for your particular case of using one set of mappings for both "Auto-load preset" and regular usage, the story wouldn't be complete without #228.

• And you would be able to reuse the same presets for your VSTs that will be auto-loaded with the "Auto-load preset" ReaLearn instance (instead of using groups for that).

Call me crazy, but in fact I have my mappings saved both as presets and as groups. I did it to experiment with the feature in question. Of course that is not something we want everyone to do. Which leads me to:

Yes, that sounds crazy ;) This is something I would want to avoid at all costs because of the redundance.

• Gives you overall better composability.

Let's pause for a moment and talk about good composability, shall we? Good composability would be having mapping groups a first class citizen in ReaLearn, and being able to reference them in other mapping groups and in presets. "Write Once Use Everywhere". Kind of like OOP... Now imagine that, together with your "z-index" concept... mind blowing. It's ideal, if you're asking me.

Can you go more into detail with the mapping groups and what you mean by "referencing them in other mapping groups and in presets"? I think I don't get that at all.

I think you nailed the concept man. This is the best generic solution that ReaLearn deserves.

Oh no, it seems I have opened Pandora's box ;) Actually, I'm not so sure about the generic layering concept anymore. It sounds great in theory and insanely flexible but it could be overengineering. After that initial idea I thought about the use cases a bit and I couldn't come up with anything except yours: Wanting a "currently active" set of mappings to have precedence over another conflicting set of mappings (conflicting because it uses the same control elements). This usually only happens in the context of "Auto-load preset". Or can you come up with a few other practical examples for which layering could be very interesting?

And it needs a dedicated UI. Can't run away from it. Please allow me to quote you from #109:

This is by design. I didn't want ReaLearn to get unnecessarily complex (both for user and developer) by providing additional compartments or group presets.

Totally get what you're saying there. But can you look at solution 3 and think "yup, that will be easy to explain!"?

Since this particular discussion rather belongs to #109, I will reply there.

Complexity is a crux of the matter here. When I think about it, connecting multiple ReaLearn instances doesn't sound simple or straightforward to me at all. That is definitely an implicit behavior, that would require people to dig into the user guide to understand.

If users want to do more complex things, I expect them to read the user guide or at least watch a tutorial, yes.

Not to mention, not having a dedicated UI for communicating the implicit relationships between these mappings, that get activated in different situations, would be a lot more difficult to follow and maintain without it all being in one organized place. This sounds a whole lot more complex to me than a good UI in a single ReaLearn instance that communicates itself clearly to the user.

It would be perfectly possible to use multiple ReaLearn instances and still have a dedicated UI that shows the relationships between them. On code level, all ReaLearn instances are connected via a sort of backbone anyway.

I do believe the behavior in question here is in fact very useful, and definitely has a mass appeal: have your backbone of generic, essential or live-performace mappings available at all times and have your controller immediately adapt as you're focusing on an effect/instrument VST – who wouldn't want something so genius? It's really ideal. Therefore, I think investing in this feature and making it more accessible and easily attainable is worth it.

I'm all in for making things more accessible (at least as an ideal) but first let's find out whether generic layering is really necessary.

On a more personal note, I actually prefer that all of the mappings are in one huge ReaLearn instance - but I'll be my own devil's advocate – that works for my use case and doesn't necessarily fit everyone. To get more technical however, less instances of ReaLearn, presumably less CPU usage? (assuming every instance listens to MIDI input on it's own and not through a central, shared thread), but I digress.

Don't worry about that. From a processing perspective (leaving open GUI windows out of the equation), more ReaLearn instances don't mean more CPU usage - because there's this shared backbone which connects all ReaLearn instances and does the heavy lifting for all of them, only once per main loop cycle. A bit more memory usage, yes, but that's a drop in the ocean really. CPU usage mainly grows with the number of mappings, not with the number of ReaLearn instances. So it doesn't matter.

Please allow me to suggest a UI for this. I'm burrowing this from Photoshop, (a relatively unknown and unpopular piece of software, but, maybe you've heard of it :P)

I think that the screenshot speaks for itself :) And while the relevant section is obviously the big list of layers, I included however the surrounding UI as well, for inspiration.

Thanks, that's indeed the perfect UI for layering ... if layering is justified.

Now all of this is really an ideal goal in my eyes. But then of course, there is this simple-yet-effective, quick-and-dirty solution:

Or maybe a more simple construction: Add a checkbox "Cover other ReaLearn instances that use the same control input if a preset is loaded".

;)

Convince me otherwise, but at the moment I think this simple solution gets the job done and is much easier to understand than layering.

[stereokai]

Can you go more into detail with the mapping groups and what you mean by "referencing them in other mapping groups and in presets"? I think I don't get that at all.

Maybe it will be more clear if I called it "reusable mappings"?

For instance, you define a group with 4 mappings: play, record, pause and stop, name it "Playback Controls". You can then reference this "Playback Control" group in any other mapping group, preset, or instance, instead of redefining these mapping over again when or where you want to use them.

can you come up with a few other practical examples for which layering could be very interesting?

I think it all depends on what kind of conditional mappings are useful. I can only think of two at the moment (And I have included both in the UI example): When an FX is focused and when tracks are selected. So, in other words:

1. Base layer of generic/essential/live-performance controls that should always be available
2. Special mappings tailored to VSTs and activated when either of these VSTs are in focus, deactivated when VST loses focus
3. A generic mapping for tracks that is activated when a mixer track is selected, deactivated when deselected

Now the question that should be answered is: Are there additional components of Reaper that users might want to control with their MIDI controllers?

One more use case I can think about, is splitting a MIDI controller into always-active mappings (aka persistent), and dynamic mappings (aka feature in question). For example, I want to always have the play, record, pause and stop controls mapped and available, irregardless of what other mappings are currently activated on the rest of the available controls in my MIDI controller.

That was an important mind exercise. These are the only examples I can think about, and to be honest, I haven't even convinced myself that the z-index/layers solution is necessary the right solution :)

[helgoboss]

Can you go more into detail with the mapping groups and what you mean by "referencing them in other mapping groups and in presets"? I think I don't get that at all.

Maybe it will be more clear if I called it "reusable mappings"?

For instance, you define a group with 4 mappings: play, record, pause and stop, name it "Playback Controls". You can then reference this "Playback Control" group in any other mapping group, preset, or instance, instead of redefining these mapping over again when or where you want to use them.

Okay, I get it. So you mean an actual reference, not a copy (template) of the mappings in that group? Here are some thoughts that I have about that:

• Doing this within one instance doesn't make much sense to me (Why would you have the same mappings twice?). But this is probably not what you meant.
• Doing this among instances/projects comes with the challenge of preventing potentially unwanted side effects.
  • "Compartment presets" solve this by always copying the mappings but at the same time memorizing which preset is active. So if you change the preset (globally), it doesn't have any side effects on other instances (which saves you from surprises). But when you open another instance, you can see that the global presets now deviates (and by the press of 2 buttons you can "upgrade" to the state of the global preset).
• I can see something like "Group presets" happening.
  • But then I would rather do it simply in a template/copy fashion, not with the reference logic that compartment presets provide. Otherwise it gets too complicated in my opinion.
    • If you want "reference" semantics, you can always have them - with compartment presets on instance level.
  • Therefore I would call it "Group templates" ... or rather "Mapping templates". Because we could also support the use case of inserting it into a group that already has mappings.
  • I can see it working just like REAPER track or FX chain templates:
    1. Right click on a mapping row.
    2. Choose "Templates" → "Save all group mappings as template..."
    3. Enter a name.
    4. At a later point, right click on a mapping row (or empty space), hover over "Templates" and find the template that you want to insert.
  • That would also go in line with Add possibility to declare one mapping as default mapping #159.
• Copy and paste of mappings and groups #121 and Allow copying only the mappings between instances of ReaLearn #157 are related
• Again: Don't fear instantiating multiple instances.
  • REAPER has very comprehensive ways of coping with FXs (naming, showing in track control , ...)
  • I really don't want to rebuild all of that within ReaLearn, it's a waste of time that I could spend writing more interesting things.

can you come up with a few other practical examples for which layering could be very interesting?

I think it all depends on what kind of conditional mappings are useful. I can only think of two at the moment (And I have included both in the UI example): When an FX is focused and when tracks are selected. So, in other words:

1. Base layer of generic/essential/live-performance controls that should always be available
2. Special mappings tailored to VSTs and activated when either of these VSTs are in focus, deactivated when VST loses focus
3. A generic mapping for tracks that is activated when a mixer track is selected, deactivated when deselected

1 and 3 can be done already without much effort. This is what I showed in the Midi Fighter Twister part of the video. So this doesn't need z-index. And 2 is the thing that triggered this issue in the first place.

Now the question that should be answered is: Are there additional components of Reaper that users might want to control with their MIDI controllers?

Exactly. Is there any other thing that can be "current", in addition to "Currently focused FX" and "Currently selected track"? Would be indeed interesting to think about.

One more use case I can think about, is splitting a MIDI controller into always-active mappings (aka persistent), and dynamic mappings (aka feature in question). For example, I want to always have the play, record, pause and stop controls mapped and available, irregardless of what other mappings are currently activated on the rest of the available controls in my MIDI controller.

This is relatively easy and can be done using normal conditional activation. Have done that in the video with the Twister (https://www.youtube.com/watch?v=dUPyqYaIkYA&t=2299s, there I have done it even within one instance).

That was an important mind exercise. These are the only examples I can think about, and to be honest, I haven't even convinced myself that the z-index/layers solution is necessary the right solution :)

I'm thinking more and more that it's a too big hammer for solving a small problem.

[stereokai]

Exactly. Is there any other thing that can be "current", in addition to "Currently focused FX" and "Currently selected track"? Would be indeed interesting to think about.

Ok so after thinking about this quite a bit, and reinforced with your expansive reply, I have to say that I am now convinced that this proposal is overkill for ReaLearn. The small value it could bring to a few edge cases doesn't justify it's complex development.

What I did like to read in your comment is how all of the scenarios (except for the subject of this issue) can already be created using the current offering. It's amazing how you thought about all those potential requirements.

• REAPER has very comprehensive ways of coping with FXs (naming, showing in track control

I am not exactly sure what you're showing me here. (I don't use the track controls on the side so much, I mostly rely on the track strips in the mixer). Can you please be more specific? :)

• I really don't want to rebuild all of that within ReaLearn, it's a waste of time that I could spend writing more interesting things.

Totally understood & appreciated, I would most definitely prefer to not stand in the way of that ;)

That would also go in line with #159.

I joined the discussion there.

#121 and #157 are in my opinion an important concept for user experience and ease of use.

I feel like this issue needs to be scrapped and folded into #109, and there we could focus on the better solution :)

[helgoboss]

• REAPER has very comprehensive ways of coping with FXs (naming, showing in track control

I am not exactly sure what you're showing me here. (I don't use the track controls on the side so much, I mostly rely on the track strips in the mixer). Can you please be more specific? :)

I wanted to show you that having multiple instances can actually improve the structure and give you a better overview - make your setup digestable more easily instead of making it more convoluted. REAPER provides the necessary means for that. The screenshot shows a track that has 2 ReaLearn instances, one called "Transport" (for play and stop etc.) and another one named "Current FX" (for controlling the currently focused FX). I think this is cool and something you can't do if you put everything into one instance. Track strips in the mixer! Exactly, another nice means of project organization that REAPER provides.

#121 and #157 are in my opinion an important concept for user experience and ease of use.

Agreed.

I feel like this issue needs to be scrapped and folded into #109, and there we could focus on the better solution :)

I would keep it. In #109 we are discussing the big picture and you already made many backreferences to #227. Personally I would prefer renaming it to "Automatically shadow other mappings when focused-FX mappings are active" or something similar.

[stereokai]

I wanted to show you that having multiple instances can actually improve the structure and give you a better overview - make your setup digestable more easily instead of making it more convoluted. REAPER provides the necessary means for that. The screenshot shows a track that has 2 ReaLearn instances, one called "Transport" (for play and stop etc.) and another one named "Current FX" (for controlling the currently focused FX). I think this is cool and something you can't do if you put everything into one instance. Track strips in the mixer! Exactly, another nice means of project organization that REAPER provides.

I get it now. Thanks for expanding on that. It is nice to have in my definition, but arguments can be held on both sides whether or not it is better to display this information to the user at this level (outside of ReaLearn, on the track controls) or inside ReaLearn, in some top level UI. Just a note, I don't want to get into this discussion :)

I would keep it. In #109 we are discussing the big picture and you already made many backreferences to #227. Personally I would prefer renaming it to "Automatically shadow other mappings when focused-FX mappings are active" or something similar.

Got it ;)