Conditional activation for the ReaLearn instance itself #109
Here in the video I use the Midi Fighter Twister's internal bank to switch to a mode where the Twister always controls the currently focused FX (using "Auto-load preset"). The reason why I didn't use ReaLearn's conditional activation program/bank feature is that it wouldn't work. But it would be great if it did because it has advantages over the built-in banks!
Why doesn't it work? Because "Auto-load preset" loads main presets - when loaded, they replace all main mappings. No other main mappings can survive this preset switch. 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.
My idea was to pursue another direction: To take advantage of the fact that you can have multiple instances of ReaLearn. One instance would use "Auto-load preset: Depending on focused FX", the other one would have the normal main mappings. The problem I faced and why I used the Twister's internal banks: There's no way (of using conditional activation) to switch between ReaLearn instances! This is what this issue is about. Making that possible.
We could achieve that by taking the idea of conditional activation one level higher: We can set it for a single mapping, we can set it for a complete group ... and now we just need to make it possible to set it for the complete instance (not overwritten by main mapping compartment preset changes of course). Then we can have the following setup to make above usage scenario work:
Before this was about Add "ReaLearn parameter" source
This would allow another level of indirection and e.g. allow multiple ReaLearn instances to control each other. E.g. that would enable instance-spanning paging functionality because we could enable/disable ReaLearn instances based on parameter changes/values.
That's useful especially if we use "Auto-load preset" in an instance because then we can't use preset-spanning conditional activation in that instance. An alternative way to implement this use case would be to offer conditional activation for the complete ReaLearn instance, in addition to the group and mapping scoped conditional activation.
The text was updated successfully, but these errors were encountered:
The appeal of using multiple instances
It's maybe not easy to explain, but once users grasp the concept of combining multiple instances and using parameters (which anyone using VSTs should already be familiar with to some degree), they will be able to figure out what to do. The sooner they understand this concept, the better it is for them. Because there's one thing in ReaLearn that's unlikely to ever change: 1 instance → 1 controller. This means 1 instance is never meant to be controlled by more than 1 controller (while 1 controller can always control multiple instances).
So as soon as you want to use multiple controllers - which I consider as very likely and is one main "selling point" of ReaLearn (I hate that word because I don't sell it) - you need to know about the concept of multiple instances. And then you will be happy to find out that in order to achieve things like this, all you have to do is doing what you always do with ReaLearn when you want to "switch" and "modify" behaviors: Changing VST parameters.
In other words: If you want to achieve something sufficiently complex with ReaLearn, involving multiple controllers, you will need to take the multi-instance route anyway and you won't be able to use the features anymore that only work within a single instance.
Summary: It's not knowledge which is explained easily, true. But: It's very reusable knowledge. That's what I like about this approach.
The appeal of having it in only one instance
But let's have a fair look at the alternative of doing this within one single instance, leaving considerations such as implementation complexity/effort aside for a moment!
One benefit would be that we could push ReaLearn more into the direction of "1 controller → 1 instance" (in addition to "1 instance → 1 controller") ... and hence arrive at the rule of thumb 1 controller = 1 instance. Which is easy to grasp. Less need to fire up multiple ReaLearn instances for only one controller.
What additional features would we need in order to do it in a single ReaLearn instance?
@stereokai @vonglan I'm willing to give the "3rd compartment" idea a bit more thought. I want to check what exactly it would take and which usage scenarios would really benefit from it when compared to the multi-instance solution outlined in the issue description. I think it making the 3rd compartment just a replication of the "Main mappings" compartment wouldn't provide any benefit over using multiple instances. I'm rather thinking about tailoring it specifically to FX mapping use cases and therefore call it e.g. "FX mappings" compartment.
Could we brainstorm a list of use cases which potentially can benefit from such a new compartment? Here are the ones I came across so far:
As soon as we have that list, I would like to have a closer look if and how exactly the new compartment could be designed to support these use cases.
Thank you for the very lengthy and communicative reply. Honestly, the more we discuss ReaLearn, the better I understand your way of thinking and appreciate the choices you made.
In our other discussions and pivotally, in your last reply here, you've more then made the virtues of a multi-instance approach clear to me. I can say that I finally get it now.
But of course :)
Please explain this, I'm not sure I'm getting it.
That sounds like a given, unless I'm missing out on something. What does controller mappings have to do with FX only mappings? Or do you mean virtual mappings cannot be used? (And then, why?)
Not necessarily... It could be another level of focusing the controller on a particular FX, (without focusing it). Not so different than what ReaLearn is already capable of now, but perhaps an easier or more obvious way to configure ReaLearn, instead of having the setting per mapping
So as I wrote in #227 I think the automatic activation is ideal and a must have feature for ReaLearn.
After reading also the linked issue, I would like to ask, because you have only touched on that vaguely in your reply above: What exactly are "FX mappings" in their current early concept?
I'm asking because I can't think of other reasons for FX mappings, except for activating complete or partial mappings for FX in situations where the users would want it, be it automatic when an effect is focused, or at the call of a button, for example during a live performance. What other use could it have?
I have another question, that was inspired by a combination of #230 and #227: The scenario begins with an FX mapping that is currently activated, so all of the physical controls available on the controller are mapped to VST A. Now let's say, either by a button (#109 style) or automatically (#227 style) you would like to activate a mapping where now only some of the controls are mapped to specific features of VST B, while the rest of the controls keep their current mapping to VST A. Questions:
I think I have not fully understood the advantage of separate instances and access to the parameters. (But I believe you that it is a huge effort to change the concept.)
I also did not understand this. Do you mean: 1 Instance = 1 Controller controlling multiple FX? But this is already possible (although you then have a "mixed target" ReaLearn preset, if you use ReaLearn presets).
I currently do not see the advantage of that.
That is not a strong use case, as it can be solved using multiple instances.
My strong use cases that I am sure of (just to have them all in place - maybe none of them relates to this issue):
Coming back to Best Practice for combining multiple controllers and multiple VSTs, with the current "multiple instances" concept:
A feature that would allow us to use "Presets", "Auto-load preset" etc. on group level (as opposed to compartment level) might appear as an alternative to the current way of doing things. It's one level deeper in the hierarchy than compartments and might feel more granular, better composable, etc. However, if we would do that, users would soon ask for groups in groups - in order to be able to structure the mappings in their preset in a better way. With that "BTW" comment above I just wanted to say that this is not something I want to do. For me, the basic unit of reuse is a "Compartment preset", period. By design, groups are intended just as a tool that helps with organising mappings, not more. The possible improvements that I have mentioned here is the maximum of meaning that I want to give to groups. Just wanted to make this clear so we have this out of the way and are synchronized.
You are right, that's a given. That whole part "Conditional activation on compartment level" was me thinking out loud and I basically discarded it as soon as I finished writing it ;)
Yes! But I think that the complete set of "Conditional activation" features (program-based, modifier-based, EEL) is a too big hammer for this. I mean, the motivation for adding a 3rd compartment is to make things more intuitive and easier, not to make ReaLearn more flexible. It's already flexible enough when using multiple instances (at least after adding the improvement mentioned in the title of this issue). So I think what we really should be trying is to come up with a "Click here and be happy" kind of solution for the typical 3rd-compartment use cases.
Yes, I think so far this is the use case that would benefit most from a 3rd compartment.
That's the picture which I currently have in mind.
For me it's the same, no additional use cases come to my mind.
I think that's the "One open question" which I outlined further above. Feel free to comment on it.
Just realizing that we don't have the same naming conventions. For me "Main mappings" (compartment 2) are the normal default mappings (the ones which cannot be swapped via "Auto-load preset"). They can also point to FX parameters of course. "FX mappings" (compartment 3) are "Auto-load preset" mappings - which is mainly applicable for FX plug-ins (at least I can't think of anything else now).
That's what I would have thought, yes.
Not sure I fully understand. So it's a new checkbox for a mapping. When you check it, it will always load when focused in #227 style and overshadow a possible main mapping. When you don't check it, it will only load if you use it as a normal preset. Did I get this right?
If yes ... mmh, isn't that a bit hard for the user to keep track of things? Yes, it would release you from the burden of defining 2 presets for the same VST with overlapping stuff. But is it worth the complexity? Not sure yet.
Also, #241 needs to be considered.
It's about ReaLearn's FX/VST Parameters 1 - 100, yes. Let's stick to the word "FX parameters". I want to use the word "Virtual parameter" for something else (#241).
ReaLearn instances internally don't need parameters to talk to each other. That's indeed possible using the "backbone". The advantage is for the user, not the developer.
That's one advantage, yes. Although I have not figured out yet what exactly to do with that ;) But I'm sure it will have some use. I always love automatable VST plug-ins and I tend to avoid those that are not.
The main advantage for me is that it's a concept that most serious users (except maybe absolute beginners) are already familiar with. They know they can control something with it, in super many ways: REAPER's built-in MIDI learn, REAPER's built-in OSC, ReaScript, parameter modulation, automation ... Wow! And of course: By ReaLearn itself. And that's another advantage: You can simply use ReaLearn's "FX parameter" target to configure another ReaLearn instances. No need to learn yet another concept.
ReaLearn needed some kind of internal freely assignable parameters anyway. Making them FX parameters greatly adds to the flexibility.
However, if we discover (as result of this discussion for example) that some kind of communication between ReaLearn instances would be useful that cannot easily be done via ReaLearn's FX parameters, I can introduce something new. E.g. the thing @stereokai is asking for #227, disabling mappings of another instance when a certain FX is focused, it wouldn't be clever to solve this by changing ReaLearn's FX parameters. I will implement this in the backbone.
Summary: FX parameters are generally useful IF the user wants to make a configurational change within ReaLearn from outside.
Yes. And of course, for me the most obvious: Being able to use more then one controller!
No, I meant the following: Many people wonder, how many ReaLearn instances should I use? What's the best practice? When should I split?
It would be cool to be able to give them the simple answer: "Use 1 ReaLearn instance per controller!" (where controller = MIDI hardware device).
Automatically by the system, via "Auto-load FX preset". If you have not tried that yet, give it a go. Otherwise I imagine it's pretty difficult to understand what's talked about.
Exactly, that's the main use case (#227). (Although for me a "conflict" only exists if the source is the same, not the target. If a target is the same, so what.)
But read my response to @stereokai's reply to get the full picture. The complete "Conditional activation on compartment level" feature doesn't make sense to me either.
Okay, got it. So maybe we have only one really strong use case for this: #227.
You are right, they don't relate to this issue.
This you can do.
Now you are pushing the amount of indirection really far. It sounds you want something like the existing "Virtual sources" and "Virtual targets", but between instances. Actually, the initial idea of this ticket (#109) was to make this possible, via ReaLearn's FX parameters (see "Old description"). I can think of many reasons why I wouldn't do that:
I don't exactly understand what you would try to achieve with this. Can you tell me more?
Thanks for the detailed answer/reaction!
Just to avoid misunderstanding on my side: That is theoretically possible, but it is not currently implemented like that, correct?
As you wrote in the title „The appeal of having it in only one instance“, I (mis)understood you wanted to compare it to a design where there is only one ReaLearn instance which caters for multiple controllers AND multiple targets, with separate compartments for each controller and each target (and an overview in the UI). If the comparison was against that, then this advantage would not exist.
Sorry, I think this was a result of my misunderstanding described above. Anyway, I just like to think through radically different designs (and usually settle for something pragmatic in the end ;-).
What I had in mind was something much simpler:
They would communicate via Virtual parameters in exactly the same way that Controller Mapping and Main Mapping can currently communicate inside one Instance - nothing complex. (And it would be easier and no disadvantage if these virtual parameters were not identical to ReaLearn’s FX Parameters - see my comment in #241 about identifying them by a name instead of a number.)
(You could also describe this concept as: allowing the user to separate Controller Mapping and Main Mapping into different ReaLearn instances, and arranging for communication between them as if they were in one instance.)
With this, the theoretical (!) disadvantage of needing
Thinking about it longer: maybe this is just a theoretical consideration, and not relevant in practice.
Still, another advantage of this "two-layer, inter-Instance communication model" would be that I would not have to load/copy the preset for the Main Mapping to the instrument VST redundantly into the ReaLearn instances.
They talk to each other using the "backbone", already now! But for other things and purposes than #109.
Ah, I get it! No, having one ReaLearn instance that deals with multiple control inputs was not part of my mind game. For me it's so obvious that I don't want to go down this road that I didn't even mention it. If you insist, I can explain the reasons behind that decision. But I'm pretty sure I won't change my mind about that.
I also like to do it that way :) I think it's a good approach to design.
Ah, okay. I think now I understand your comment in #241 a bit better.
Feedback is an integral part and USP of ReaLearn. If a new feature is being built or designed, I will always treat the "feedback direction" with the same priority as the "control direction".
Okay, this was the key comment for my understanding. Thanks.
I would have asked you "Why would you have
... but you answered it here already. Besides, adding many ReaLearn instances is not really a problem. One instance is designed to be very lightweight.
But this is not something you would do every day, is it? Project templates, track templates etc. can help with that. Or even one ReaScript that initializes all instances (yes, ReaScripts can talk to ReaLearn and tell it to load a specific JSON text).
Summary: At this point, I have the impression that this "controller/main mapping thing spanning multiple instances" is not really worth the additional complexity. If one day we learn more about how ReaLearn is being used and things suddenly go into this direction, then okay. Maybe you can open an extra issue for this and I could give it a "low priority" flag?
With "no feedback" I meant: „no risk of unwanted feedback loops“ (but I did not write that ...).
I will open a separate, low priority issue.
Good news! Manual switching between instances (at least simple on/off-style) is already possible, even without #109 - well, at least in today arriving pre8! It works by simply enabling/disabling ReaLearn instances. The idea is that you have 3 instances:
I'm considering to go completely without instance-wide conditional activation because even a kind of bank-style switching between multiple instances could easily be achieved using the "FX: Enable/disable" target if we add an "Exclusive" option, just as with track-based on/off targets.