helgoboss
commented
3 years ago Actually, conditional activation for the ReaLearn instance itself sounds better and more consequent!
Closed helgoboss closed 2 years ago
helgoboss
commented
3 years ago Actually, conditional activation for the ReaLearn instance itself sounds better and more consequent!
helgoboss
commented
3 years ago In #227, @stereokai commented about the multi-instance approach explained in the description of this issue (#109) and I want to reply here.
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.
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.
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:
It is also not clear to me what is Best Practice if I want to flexibly combine such a VST instrument mapping with a separate mapping for an effect VST (like Colour Copy). Is there a possibility to store these separately, and load them together in the "Main Mapping" compartment of an instance? Or is the current preset always replaced when I load a different one?
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.
stereokai
commented
3 years ago 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.
Could we brainstorm?
But of course :)
BTW, using a group for that instead of a compartment would not be okay because the preset itself could contain groups and then we would have nested groups ... let's not go there.
Please explain this, I'm not sure I'm getting it.
"Controller mappings" compartment should not be involved in the conditional activation.
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?)
I have the feeling though that apart from the "switching" function, this new compartment would not profit from the whole "Conditional activation" thing (on compartment level) ... so maybe this is overkill.
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
- Temporarily switching the controller to a mode in which it controls the currently focused FX - automatically whenever an FX is focused (as requested by @stereokai in #227)
So as I wrote in #227 I think the automatic activation is ideal and a must have feature for ReaLearn.
As for:
- Make it easier to combine VST instrument mapping with a separate mapping for an effect VST (as mentioned by @vonglan in #230)
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:
If the switch is #109 style, it's simple to reason about. But what if both mappings (VST A and VST B) are activated #227 style? How do we know to only load some controls and not the complete mapping of VST B?
Perhaps the user will have to define only a partial FX mapping for VST B
Or alternatively, the user could define both a complete mapping for VST B (if they so wish), as well as a partial one, and we provide a conditional for FX mappings such as:
Is this a level of complexity you are comfortable with?
Or otherwise, (and not surprisingly) can these behaviors already be configured with ReaLearn today?
vonglan
commented
3 years ago 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. ...
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.
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.) ReaLearn's parameters (as seen from Reaper) seem to be the virtual parameters 1-100. Correct? (Or is it about other parameters, like ControlInput, Main Mapping Preset, or maybe a new one "InstanceActivation"?) Is the advantage that presenting them as VST parameters to Reaper allows them to be shared among all instances? I always thought that would somehow be done in the "backbone". Or that I can use them in an automation lane? Sorry, I have the impression that I am blind to something important. (Some other advantages are more clear to me:
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.
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).
- The initial idea was exactly that - to have 3 compartments instead of 2: One for virtual controller mappings, one for stable mappings and one for dynamically exchanged mappings. "dynamically exchanged mappings" - do you mean manually by the user, or by the system?
- Conditional activation on compartment level so that we can switch the controller between "Main mappings" and "FX mappings" .
I currently do not see the advantage of that. As I wrote somewhere else, I could see a use case (though not important for me personally) to have a third compartment type "ad hoc", which automatically takes priority over all other mappings, if they are in conflict, i.e. relate to the same source or target.
Could we brainstorm a list of use cases which potentially can benefit from such a new compartment? ...
- Make it easier to combine VST instrument mapping with a separate mapping for an effect VST (as mentioned by @vonglan in #230)
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: If I have 3 controllers. Can I put 3 ReaLearn instances for them in the Monitor FX chain, mapping everything to virtual parameters (with overlaps, e.g. control Filter Decay with either the OB6 or the APC20 if I sit at the digital piano). And then put ReaLearn instances in the Tracks (for example one for a VST instrument, one for a VST effect), and they can consume those virtual parameters? That might be another use case / feature wish.
helgoboss
commented
3 years ago BTW, using a group for that instead of a compartment would not be okay because the preset itself could contain groups and then we would have nested groups ... let's not go there.
Please explain this, I'm not sure I'm getting it.
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.
"Controller mappings" compartment should not be involved in the conditional activation.
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?)
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 ;)
I have the feeling though that apart from the "switching" function, this new compartment would not profit from the whole "Conditional activation" thing (on compartment level) ... so maybe this is overkill. 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
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.
- Temporarily switching the controller to a mode in which it controls the currently focused FX - automatically whenever an FX is focused (as requested by @stereokai in #227)
So as I wrote in #227 I think the automatic activation is ideal and a must have feature for ReaLearn.
Yes, I think so far this is the use case that would benefit most from a 3rd compartment.
As for:
- Make it easier to combine VST instrument mapping with a separate mapping for an effect VST (as mentioned by @vonglan in #230)
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?
That's the picture which I currently have in mind.
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?
For me it's the same, no additional use cases come to my mind.
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:
- Is this behavior handled by the proposed FX mapping compartment?
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).
If the switch is #109 style, it's simple to reason about. But what if both mappings (VST A and VST B) are activated #227 style? How do we know to only load some controls and not the complete mapping of VST B?
- Perhaps the user will have to define only a partial FX mapping for VST B
That's what I would have thought, yes.
Or alternatively, the user could define both a complete mapping for VST B (if they so wish), as well as a partial one, and we provide a conditional for FX mappings such as:
- "Activate this mapping if any FX mapping is already activated"
- Or even more specific: "Activate this mapping if [select FX mapping] is already activated"
- Is this a level of complexity you are comfortable with?
- Or otherwise, (and not surprisingly) can these behaviors already be configured with ReaLearn today?
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.
For #109 style it's already possible to define such behavior on mapping level by using conditional activation in the mapping panel, but for #227 (automatic shadowing when focused) not.
Also, #241 needs to be considered.
helgoboss
commented
3 years ago 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.) ReaLearn's parameters (as seen from Reaper) seem to be the virtual parameters 1-100. Correct? (Or is it about other parameters, like ControlInput, Main Mapping Preset, or maybe a new one "InstanceActivation"?)
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).
Is the advantage that presenting them as VST parameters to Reaper allows them to be shared among all instances? I always thought that would somehow be done in the "backbone".
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.
Or that I can use them in an automation lane?
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.
Sorry, I have the impression that I am blind to something important.
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.
(Some other advantages are more clear to me:
- Being able to name the ReaLearn instances
- Being able to save them with another VST(s) as FX Chain)
Yes. And of course, for me the most obvious: Being able to use more then one controller!
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.
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).
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).
- The initial idea was exactly that - to have 3 compartments instead of 2: One for virtual controller mappings, one for stable mappings and one for dynamically exchanged mappings. "dynamically exchanged mappings" - do you mean manually by the user, or by the system?
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.
- Conditional activation on compartment level so that we can switch the controller between "Main mappings" and "FX mappings" .
I currently do not see the advantage of that. As I wrote somewhere else, I could see a use case (though not important for me personally) to have a third compartment type "ad hoc", which automatically takes priority over all other mappings, if they are in conflict, i.e. relate to the same source or target.
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.
Could we brainstorm a list of use cases which potentially can benefit from such a new compartment? ...
- Make it easier to combine VST instrument mapping with a separate mapping for an effect VST (as mentioned by @vonglan in #230)
That is not a strong use case, as it can be solved using multiple instances.
Okay, got it. So maybe we have only one really strong use case for this: #227.
My strong use cases that I am sure of (just to have them all in place - maybe none of them relates to this issue):
203 make relative (generally switchable for one controller; possible already via activating/deactivating an instance, but this means duplicate mappings - not good for easily creating/maintaining/sharing ReaLearn mapping sets)
204 zoom factor (multiply step size with virtual parameter)
231 shift+bank function for Controller Mappings (in whatever way, maybe hardcoded instead of conditional activation)
You are right, they don't relate to this issue.
Coming back to Best Practice for combining multiple controllers and multiple VSTs, with the current "multiple instances" concept: If I have 3 controllers. Can I put 3 ReaLearn instances for them in the Monitor FX chain,
This you can do.
mapping everything to virtual parameters (with overlaps, e.g. control Filter Decay with either the OB6 or the APC20 if I sit at the digital piano). And then put ReaLearn instances in the Tracks (for example one for a VST instrument, one for a VST effect), and they can consume those virtual parameters? That might be another use case / feature wish.
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?
vonglan
commented
3 years ago Thanks for the detailed answer/reaction!
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.
Just to avoid misunderstanding on my side: That is theoretically possible, but it is not currently implemented like that, correct?
Yes. And of course, for me the most obvious: Being able to use more then one controller!
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.
Now you are pushing the amount of indirection really far.
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 ;-).
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:
- It would be a super complex implementation. ...
What I had in mind was something much simpler: Just to decouple controllers and VSTs, by having two fixed layers (no feedback etc.):
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
nr_of_controllers * nr_of_VSTs_in_track ReaLearn Instances
would be reduced to a requirement of only
nr_of_controllers + nr_of_VSTs_in_track Instances.
Thinking about it longer: maybe this is just a theoretical consideration, and not relevant in practice. I assume Reaper users usually have one instrument VST and multiple effect VSTs in a track. And you would normally not want to modify all those effect VSTs at the same time, but rather modify only the currently focused (or active) effect VST, with a generic set of virtual parameters (for example 8 physical encoders of ONE controller, mapped to FXParam#1 to FXParam#8, and then working on the focused or active effect VST). Therefore, only one Instance is needed for each effect VST, I think. No multiplication with the number of controllers.
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
helgoboss
commented
3 years ago 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.
Just to avoid misunderstanding on my side: That is theoretically possible, but it is not currently implemented like that, correct?
They talk to each other using the "backbone", already now! But for other things and purposes than #109.
Yes. And of course, for me the most obvious: Being able to use more then one controller!
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.
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.
Now you are pushing the amount of indirection really far.
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 ;-).
I also like to do it that way :) I think it's a good approach to design.
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:
- It would be a super complex implementation. ...
What I had in mind was something much simpler: Just to decouple controllers and VSTs, by having two fixed layers (no feedback etc.):
- Layer One would hold one ReaLearn Instance for each Controller (like described above, using only the Controller Mapping compartment).
- Layer Two would hold one Instance for each VST in that track (using only the Main Mapping compartment).
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.)
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".
(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.)
Okay, this was the key comment for my understanding. Thanks.
With this, the theoretical (!) disadvantage of needing
nr_of_controllers * nr_of_VSTs_in_trackReaLearn Instances would be reduced to a requirement of onlynr_of_controllers + nr_of_VSTs_in_trackInstances.
I would have asked you "Why would you have nr_of_controllers * nr_of_VSTs_in_track ReaLearn Instances?" ...
Thinking about it longer: maybe this is just a theoretical consideration, and not relevant in practice. I assume Reaper users usually have one instrument VST and multiple effect VSTs in a track. And you would normally not want to modify all those effect VSTs at the same time, but rather modify only the currently focused (or active) effect VST, with a generic set of virtual parameters (for example 8 physical encoders of ONE controller, mapped to FXParam#1 to FXParam#8, and then working on the focused or active effect VST). Therefore, only one Instance is needed for each effect VST, I think. No multiplication with the number of controllers.
... but you answered it here already. Besides, adding many ReaLearn instances is not really a problem. One instance is designed to be very lightweight.
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.
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?
vonglan
commented
3 years ago What I had in mind was something much simpler: Just to decouple controllers and VSTs, by having two fixed layers (no feedback etc.): ...
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".
With "no feedback" I meant: „no risk of unwanted feedback loops“ (but I did not write that ...). Normal feedback would still be possible with this concept. And for me, the feedback is also one of the USPs of Realearn (even though I don’t have a device with LED ring encoders or motorfaders yet).
I will open a separate, low priority issue.
helgoboss
commented
3 years ago 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:
helgoboss
commented
3 years ago 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.
helgoboss
commented
2 years ago With #449, this old idea is now clearly superseded.
New description
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:
Old description
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.