Basic view and Expert view

[vonglan]

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]

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]

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

Anyway, your decision of course.

[helgoboss]

@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]

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

[vonglan]

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]

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]

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]

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]

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.