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

Basic view and Expert view #233

Closed
vonglan opened this issue Mar 14, 2021 · 12 comments
Closed

Basic view and Expert view #233

vonglan opened this issue Mar 14, 2021 · 12 comments
Labels
enhancement New feature or request high priority low priority question Further information is requested

Comments

@vonglan
Copy link

vonglan commented Mar 14, 2021

Now that you add more and more features, maybe it would be good to offer a (default) basic view of all GUIs, where the more advanced features are hidden. For users that just want a simple but very convenient way to map a few controllers ad-hoc.
And then a button "Expert view" or whatever, where the user can make the inoput fields for advanced features visible (EEL formula fields, mapping group, ...).

Another idea for simplification - if that has a positive effect in simplifying the code base: Restrict that one ReaLearn instance can either be a Controller Mapping OR (exclusive) a Main Mapping, but not a combination.

@helgoboss helgoboss added enhancement New feature or request low priority labels Mar 14, 2021
@helgoboss
Copy link
Owner

To be honest, in almost all software which has this distinction between a "Normal" and "Expert" view, I dislike it ;) It often causes more confusion than help. Mostly because what's for one person an "Expert" feature is for another person a "Normal" feature and vice versa. Plus, tutorials tend to get more often out of date with that kind of UI design. So ... I think before I'm going to invest any effort into this (if at all), there would need to be a carefully thought-through concept.

Right now I simply hope that not too many top-level elements will be added to ReaLearn. The things that I don't consider important, I already put them into the context menu.

@vonglan
Copy link
Author

vonglan commented Mar 14, 2021

Do you think you're an average user (of software in general)?
;-)

Anyway, your decision of course.

@vonglan vonglan closed this as completed Mar 14, 2021
@helgoboss
Copy link
Owner

@vonglan You don't need to close that if you consider it as important. I was simply trying to express that someone would need to come up with a convincing concept for it in order to avoid the mentioned issues with such a UI design. That someone could be you or someone else who feels overwhelmed by the amount of options.

@vonglan
Copy link
Author

vonglan commented Mar 14, 2021

ok. Let's leave it open then for the time being.

@vonglan vonglan reopened this Mar 14, 2021
@vonglan
Copy link
Author

vonglan commented Mar 14, 2021

Just looked at the parameters in the UIs again with that question in mind.
I currently think, nearly all fields are "simple" and "necessary for basic use".

I still have trouble with the "autoload preset" and "focused FX" fields, but that might be mostly because I did not try these out yet.

In the long run (further development of ReaLearn, and big mapping sets/Rea Learn instance constellations), I think things can get quite complicated and hard for many users to understand. For this, I think a good solution would be an optional, global "tracing/logging" output that can be switched on temporarily to let the system explain, which source signal entered ReaLearn, why which mapping was chosen, how the values were transformed, and to which VST the output was sent.

@jackmau
Copy link

jackmau commented Mar 17, 2021

Even if I wholeheartedly support @helgoboss opinion on the multiple GUIs according the the user type, I agree with @vonglan assessment that realearn GUI (specifically the mapping page, which was much cleaner in v1) looks a bit daunting. I am not in love with the new header, and in particularly puzzled by the choice of burying realearn presets under the respective drop-down compartments, which is very counter-intuitive. At the same time I do not understand why all the mapping option for specific controllers (such as buttons/encoders etc) are always visible, whereas I would expect them to be visible according to the source type (as it was in v1). In general I think the users would appreciate if certain advanced functionality (such as transformations) would be available only if the users wishes so.

What realearn GUI misses the most, in my opinion, as similarly assessed by @vonglan, is feedback to the user. With the exception of the controlled parameter in the mapping view, and active assignments, very little gives the user an idea of what is happening. I would love to have two sliders per each mapping in the main window which clearly show MIDI/OSC input and target output values. An easier way to see internal parameter values, than going onto automation lanes would also be very welcomed. In terms of GUI inspiration, I personally love (full disclosure: I am also a beta tester) MidiPaw, a midi application for the Leap Motion Controller with a similar mapping-based (but with much less functionality) interface.

The reason I have never opened any FR on the points mentioned in the previous two paragraphs is because of the (I would dare do to say) exponential increase in realearn features. In my opinion it would make sense to think about GUI updates only once features have stabilised. And I am sure for the average realearn user functionality trumps aesthetics. To use a car metaphor (mostly for European audiences), I like to think of realearn a bit as a German car, with a bit edgy design, not as comfortable as an Italian one, but significantly more realiable, because at the end you care about the software working, not looking beautiful. I think @helgoboss approach in this regard mirrors the one of Reaper in the DAW world.

@helgoboss
Copy link
Owner

It's okay that people raise feature requests because they raise valid concerns. However, let's stay realistic. This is not about want or not want, it's about time and budget. The GUI is a trade-off. I want to make this clear: If there would be recurring donations or high one-time donations, I could make it better. Or if someone else joins the party and writes a new UI. But without that, it's not going to happen (apart from minor improvements).

Until then, ReaLearn's feature set and flexibility is far more important to me than having the perfect GUI. Having a comprehensive feature set lets you achieve great things even without the most intuitive GUI. The opposite (having a super nice GUI but lacking flexibility and features) is not true.

The current GUI demands something from users, yes. I consider this as a kind of contribution, or as an implicit price users should be ready to pay. The only reason why ReaLearn is being developed so fast at the moment, is that I'm putting everything into it, without any compensation. Users should understand that when they use that software. If you truly want a more intuitive ReaLearn, tell other users about ReaLearn, tell them to donate, donate yourself and/or contribute in terms of development.

Even if I wholeheartedly support @helgoboss opinion on the multiple GUIs according the the user type, I agree with @vonglan assessment that realearn GUI (specifically the mapping page, which was much cleaner in v1) looks a bit daunting. I am not in love with the new header, and in particularly puzzled by the choice of burying realearn presets under the respective drop-down compartments, which is very counter-intuitive.

That's because each compartment has its own presets. In an ideal world I would probably create tabs. One for "Controller mappings" and one for "Main mappings" though. Choosing a dropdown for it is due to lack of budget.

At the same time I do not understand why all the mapping option for specific controllers (such as buttons/encoders etc) are always visible, whereas I would expect them to be visible according to the source type (as it was in v1). In general I think the users would appreciate if certain advanced functionality (such as transformations) would be available only if the users wishes so.

Because ReaLearn 2 works in a totally different way than version 1: It can deal both with relative and absolute messages at the same time. That's why the concept of "Virtual controllers" works in the first place. There are possibilities to improve the UI for this, but not in the way you would think.

What realearn GUI misses the most, in my opinion, as similarly assessed by @vonglan, is feedback to the user. With the exception of the controlled parameter in the mapping view, and active assignments, very little gives the user an idea of what is happening. I would love to have two sliders per each mapping in the main window which clearly show MIDI/OSC input and target output values. An easier way to see internal parameter values, than going onto automation lanes would also be very welcomed.

Again: Budget. That said, you can do some of the things that you mention already now with REAPER's built-in means:

  • Showing MIDI output: Set "Feedback output" to <FX output> and slap a "ReaControlMIDI" below it and press "Show log".
  • See internal parameters: Press the "UI" button.

The reason I have never opened any FR on the points mentioned in the previous two paragraphs is because of the (I would dare do to say) exponential increase in realearn features. In my opinion it would make sense to think about GUI updates only once features have stabilised.

That's true.

And I am sure for the average realearn user functionality trumps aesthetics. To use a car metaphor (mostly for European audiences), I like to think of realearn a bit as a German car, with a bit edgy design, not as comfortable as an Italian one, but significantly more realiable, because at the end you care about the software working, not looking beautiful. I think @helgoboss approach in this regard mirrors the one of Reaper in the DAW world.

You hit the nail with that statement. Exactly. But again: With more budget I would be ready to improve the UI because I also like good UIs.

@DLongoni
Copy link

I totally understands and agree with @helgoboss . Again let's consider an average ReaLearn user... You have to be using reaper, using midi controllers, and wanting to tinker with it to tweak its midi capability... You search for a dedicated plugin which is user made, and it's free... At this point I am pretty confident that you are ok with spending 2/3 hour trying to figure out how to do what you need given the UI you have in exchange for flexible and robust functionalities. But maybe being a developer myself I'm a bit biased in this view.

Anyway all requests should be made and considered so absolutely nothing wrong with the issue itself!

Cheers

@helgoboss helgoboss added the question Further information is requested label Mar 19, 2021
@helgoboss
Copy link
Owner

The time has come that I want to do something about this: In the mapping window by showing/hiding stuff if possible (according to the insights collected in #314). The main panel has already been improved recently.

@vonglan
Copy link
Author

vonglan commented Apr 11, 2021

Do you plan a switch ("show all"), or will it be a general simplification (that you cannot switch off)?

@helgoboss
Copy link
Owner

Cannot switch off. I will make sure that I only hide things if they really don't have any effect.

@helgoboss
Copy link
Owner

Accidentally committed relevant stuff on #310.

helgoboss added a commit that referenced this issue Apr 15, 2021
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 low priority question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants