Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stereokai opened this issue Mar 13, 2021 · 19 comments
Labels
enhancement New feature or request high priority question Further information is requested

Comments

@stereokai
Copy link

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
Copy link
Owner

helgoboss commented Mar 13, 2021

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
Copy link
Owner

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
Copy link
Author

stereokai commented Mar 14, 2021

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 :)

  1. 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.

  1. 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)

image

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
Copy link
Owner

  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)

image

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
Copy link
Author

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
Copy link
Owner

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 image, ...)
    • 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
Copy link
Author

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 image

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
Copy link
Owner

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

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 stereokai changed the title Possible to use auto-load preset on FX focus and bank/program at the same time? Override current mappings when focused-FX mappings are activated (automatically) Mar 19, 2021
@stereokai
Copy link
Author

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 ;)

@helgoboss helgoboss added question Further information is requested high priority labels Mar 19, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
…devices

precondition for next step of making it possible that one ReaLearn instance "cancels"
another one if both actively use the same input or output devices
helgoboss added a commit that referenced this issue Mar 25, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
…elling other instances

Auto-load preset when changing focus (vs. opening/closing) still has bug
helgoboss added a commit that referenced this issue Mar 25, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
helgoboss added a commit that referenced this issue Mar 25, 2021
@helgoboss
Copy link
Owner

@stereokai This will be possible in upcoming 2.8.0-pre6! The multi-instance solution is implemented.

Example: Let's assume you have 3 ReaLearn instances A, B and C which all use the same input and/or output device. A and B make use of different control elements of this device, so they can easily coexist together (this was always allowed by ReaLearn). However, C uses "Auto-load preset: Depending on focused FX" and it has some overlaps with the control elements of A and B. Conflict!

But from now on you can "cancel" A and B whenever C has a preset loaded (= whenever an FX which has a linked preset has focus). All you have to do is this:

  1. Open instance C
  2. Right-click its header panel → Options → Move to upper floor

This will make C "cancel" any instance that shares the same input and/or output and is not on the upper floor as well. So it's a kind of layering, but only 2 layers: Lower and upper floor.

BTW, if you have a better word instead of "cancel", let me know. I also came up with "cover", "mute", "overlie", "override" ... not sure.

This solution completely cancels the other instances. Even if some control elements are not in control by C, it still cancels them. I think that's the most reasonable and most easy to understand way. Also, merging would be much harder implementation-wise (already now it's not trivial to get the feedback updates right, but I managed to get some kind of "eventual feedback consistency"). Anyway, you can still have multiple instances take control of your controller, even if a preset is loaded in the upper-floor instance: Simply make the other instance also an upper-floor instance (so it doesn't get cancelled) and make sure they talk to different control elements.

helgoboss added a commit that referenced this issue Mar 25, 2021
@vonglan
Copy link

vonglan commented Mar 26, 2021

"upper floor" is a very good image, I think.
Some other ideas for describing it:
Whenever one ore more upper floor instances are active (by having a preset loaded), all ordinary ("ground level") instances are temporarily suspended. The upper floor instances are active exclusively.

Would it be useful (and easy to implement) to have that "instance attribute" "upper floor" available as ReaLearn FX Parameter?

@helgoboss
Copy link
Owner

"Suspend" sounds good! It emphasizes the fact that it's only of temporary nature. I will adjust the user guide.

Mmh, not sure what use cases could profit from making this an FX parameter.

@stereokai
Copy link
Author

@helgoboss Amazing! Thanks a lot for this. I really appreciate all the time and thought put into this. I foresee that many people will enjoy this feature and can't wait to play with it as soon as you release it in the production version. :)

I have some feedback:

  1. @vonglan "suspend" is definitely a perfect word for this! However, "Upper floor" is not a very good wording in my honest opinion. The term "floor" has nothing to do in the context of ReaLearn or what ReaLearn is trying to achieve, and even more so, it is not at all a common term used in computing. Without knowing what this feature is, it's totally cryptic, and doesn't make sense. (Ok, after having invested so many words in why it's bad –) here are some alternatives:

    • Best and most obvious: "Suspend other ReaLearn instances when active" (this is literally what it does)
      All of these will work too but the first one above is the most accurate:
    • "Instance takes precedence when active"
    • "Bring to foreground"
    • "Set priority to high"
    • "Set level to 2"
  2. How did you handle a situation where two instances are set to take precedence over others when active, and both share the same controls? Both of them will simply react to the control just like in a normal situation right?

Thanks

@helgoboss
Copy link
Owner

  1. @vonglan "suspend" is definitely a perfect word for this! However, "Upper floor" is not a very good wording in my honest opinion. The term "floor" has nothing to do in the context of ReaLearn or what ReaLearn is trying to achieve, and even more so, it is not at all a common term used in computing. Without knowing what this feature is, it's totally cryptic, and doesn't make sense. (Ok, after having invested so many words in why it's bad –) here are some alternatives:

    • Best and most obvious: "Suspend other ReaLearn instances when active" (this is literally what it does)

That sounds good indeed. The only problem is that it's wrong ;)

What it really does is: "Suspend other lower-level ReaLearn instances with the same input/output when active".

That's a bit long. And it doesn't even explain what lower-level or same input/output means.

 All of these will work too but the first one above is the most accurate:
  • "Instance takes precedence when active"

That would then be "Instance - when active - takes precedence over other lower-level instances with the same input/output"

  • "Bring to foreground"

That's more feasible because it doesn't attempt to explain everything. However, it's also a bit misleading because it suggests only one instance can be in the foreground. That's wrong. ReaLearn instance can live happily together on the upper floor.

  • "Set priority to high"

That sounds like a performance thing.

  • "Set level to 2"

This is the best in your list I think because it accounts for the fact that multiple instances can be on the same level and it doesn't try to explain everything.

ReaLearn only has 2 levels. That's why I think using the terms "Upper and lower floor" is a good picture. And it allows one to use the analogy to neighbours as done in the user guide :) (https://github.com/helgoboss/realearn/blob/master/doc/user-guide.md - search for "Move to upper floor").

  1. How did you handle a situation where two instances are set to take precedence over others when active, and both share the same controls? Both of them will simply react to the control just like in a normal situation right?

Yes.

@helgoboss
Copy link
Owner

Another possibility: Upper level, ground level

Or: Upper floor, ground floor

Whatever it's gonna be, it should express that there are only 2 levels and it should be rather short.

helgoboss added a commit that referenced this issue Mar 31, 2021
@vonglan
Copy link

vonglan commented Mar 31, 2021

One more idea for wording:
"Exclusive Area".
Active Instances in this area automatically suspend all conflicting instances in the "Basic Area"

@stereokai
Copy link
Author

stereokai commented Apr 10, 2021

@helgoboss The subject matter of language in product design is close to my heart, so I've given this a lot thought, and in the end felt compelled to write something :)

"Upper and lower floor" is a good picture. And it allows one to use the analogy to neighbours as done in the user guide :)

That's a cute communication style, but ultimately the terminology is cryptic and confusing. The proof is in the pudding - it took you writing several paragraphs (in the user guide) to explain this relatively simple feature.

But even more objectively, "upper floor" and "lower floor" have nothing to do with what ReaLearn is about, its context or subject matter, and the interaction of the user with it. At the end of the day, it's definitely the opposite of the recommended practice in product design of modern software.

Whatever it's gonna be, it should express that there are only 2 levels and it should be rather short.

Naturally. So here are some ideas I came up with (text [in brackets] is optional/alternative):

  • Alternative 1: A button such as: "Override similar input"/"Take over [similar] input", "Give instance superiority [or exclusivity]", "Make instance superior [or exclusive]" (or even shorter: "Make exclusive/Give exclusivity" etc.), also, "Override [other/inferior] instances", or variations thereof
  • Alternative 2: Radio buttons such as:
    • Override similar input / Instance is superior [or exclusive] / Instance takes over input [+ when active] / Instance overrides inferior input
    • Don't override similar input / Instance can lose exclusivity / Instance can be overridden [+ by superior instances] / Instance is inferior
  • Alternative 3: A toggle-able option in the context-menu (that's a pattern you're already using) with the above examples
  • In addition and necessary to the above, a tooltip or a confirmation box (with a "Don't show this message again" checkbox) explaining something like: "When this instance of ReaLearn is active, it will disable other ReaLearn instances [with the same input/with input conflicts/listening to the same input/controls] that don't have this setting turned on"

I consider all 3 alternatives equally good.

That's much less implicit and cryptic than "upper/lower floor", in my humble opinion :)

@helgoboss
Copy link
Owner

@stereokai Definitely some good alternatives there, thanks! I will look at it a bit closer later this weekend.

@stereokai
Copy link
Author

stereokai commented Apr 10, 2021

Cool. I'm curious what you'll end up using. I've been so busy and haven't even had time to start using this feature! Can't wait to implement it in my setup. Will do soon and will provide feedback too!

helgoboss added a commit that referenced this issue Apr 14, 2021
and add confirmation box which explains what that means if enabled
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants