mini fx rewrite without merge conflicts #7438

enp2s0 · 2024-08-07T16:39:05Z

Recent commits introduced some merge conflicts with #7242; this PR replaces that one. This PR also does not attempt to make the EffectView resizable or modify the wet/dry behavior and instead just focuses on UI improvements:

Hide the auto quit decay knob if autoquit is disabled in settings.
Remove the gate knob.
Shrink the height of effects from 60px to 35px.
Use the effect label itself as the button to open the controls rather than a separate button.

The new design in action:

And in the classic theme (as an aside, the new mixer strip design doesn't seem to be compatible at all with the classic theme, but the FX rack is good enough):

~~This is mostly complete. Currently hunting down a small bug where the controls button stays in the "open" state even when you close the FX window, but this is likely an easy fix.~~ Issue is fixed.

Replaces #7242.

Rossmaxx · 2024-08-08T02:43:14Z

I said it there and I'll say it again, consider spinning up the gate knob removal into it's own seperate PR. Makes it easier to review.

Rossmaxx

My initial review. It's mostly on style.

src/gui/EffectView.cpp

src/core/Effect.cpp

src/gui/EffectView.cpp

Rossmaxx

Follow up style review

include/EffectLabelButton.h

src/gui/EffectView.cpp

src/gui/widgets/EffectLabelButton.cpp

Rossmaxx

Looks good now.

michaelgregorius

The new effect view looks much more polished and less crowded than the old one! 👍

include/EffectLabelButton.h

include/Effect.h

src/gui/widgets/EffectLabelButton.cpp

michaelgregorius · 2024-08-08T16:01:11Z

src/gui/widgets/EffectLabelButton.cpp

+	setAcceptDrops(false);
+
+	setCursor(QCursor(embed::getIconPixmap("hand"), 3, 3));
+	setStyleSheet("text-align:left;padding:2px;");


This line should be removed and the definition should be done in the style sheets of the default and classic theme. This way users can override the style.

Did you check the look of the changes with the classic theme by the way?

This line is identical to the one in the TrackLabelButton class (which I based this class off of), so I think for consistency it makes sense to keep it this way unless we want to change both of them.

Added classic theme screenshots to the top message. As an aside, it looks like the recent mixer strip PR was not tested in the classic theme since it's completely black...

You're right. I have just checked version 1.2 with the classic theme and here the mixer strip is gray:

Might be something for a new issue.

include/EffectView.h

src/gui/EffectView.cpp

src/gui/widgets/EffectLabelButton.cpp

include/EffectLabelButton.h

src/gui/widgets/EffectLabelButton.cpp

Newline at the end of the `EffectLabelButton` files. Cleanup of includes and forward declarations. Remove commented out friend declaration.

michaelgregorius · 2024-08-09T18:15:02Z

@enp2s0, I took the liberty to apply some changes (forward includes, newline at end of file) myself. That's faster than some back and forth in comment. I hope that's okay for you.

enp2s0 · 2024-08-09T19:06:43Z

@michaelgregorius all good, thanks!

DomClark · 2024-08-09T21:14:51Z

Can we preserve the knob labels? I think it would be clearer that way. Also, how about making the effect buttons more consistent in style to the track buttons (i.e. they're flat and borderless when not pressed)?

enp2s0 · 2024-08-11T01:38:13Z

@DomClark As far as knob labels are concerned the reason for removing them is to significantly reduce the required height. I did try adding labels to the left or right at one point, but it leaves very little space for the effect name/button itself, and increasing the width of the effect chain widget causes it to not fit properly inside the 400x400 windows for instruments.

As far as making the FX buttons match the track buttons, this is a good idea. Working on implementing that now.

Rossmaxx · 2024-08-11T03:21:18Z

I personally am willing to trade a little bit of size reduction for clear knob labels

Rossmaxx · 2024-08-12T00:59:54Z

Updated screenshots?

enp2s0 · 2024-08-12T01:00:47Z

Knob labels are back. I honestly prefer the look without them but it seems I am in the minority on this.

Rossmaxx · 2024-08-12T01:03:17Z

Great. Sounds like a nitpick at this point, but can you vertically make the effect button larger? That way, it'll look slightly better.

include/EffectView.h

enp2s0 · 2024-08-12T01:07:04Z

It looks better height-wise but the knobs don't look centered with the labels -- any idea why that is? I'd like to avoid just ->move()ing them since the rest is done with layouts.

Rossmaxx · 2024-08-12T01:09:37Z

any idea why that is?

Consider wrapping the knob + label on a QVBoxLayout and see if it fixes it.

enp2s0 · 2024-08-12T01:14:22Z

The label and the knob are already wrapped together -- I'm just running setLabel on the knob directly. It almost seems like the label and the knob have different margin settings (without the label, the knob was centered).

michaelgregorius · 2024-08-12T15:37:26Z

Great. Sounds like a nitpick at this point, but can you vertically make the effect button larger? That way, it'll look slightly better.

I second this request. IMO the button should be almost as big as the surrounding effect box so that it is easy to hit.

The text in the buttons also looks very cramped. I think some larger margins would be good here.

RoxasKH · 2024-08-12T16:09:46Z

Knob labels are back. I honestly prefer the look without them but it seems I am in the minority on this.

I'm actually in favour of removing label too, as there's tooltips. The issue is that tooltips aren't enough and those knobs should just be there for convenience and should be mirrored in a bar on top of the FX windows (which would have labels, just like it's done for LMMS instruments Volume and Panning knobs), which, as of now, doesn't exist yet.
So it's probably better to keep the for now, although it clearly reduces in effectiveness the compactness the PR was trying to achieve.

Rossmaxx · 2024-08-20T06:38:40Z

Great. Sounds like a nitpick at this point, but can you vertically make the effect button larger? That way, it'll look slightly better.

I second this request. IMO the button should be almost as big as the surrounding effect box so that it is easy to hit.
The text in the buttons also looks very cramped. I think some larger margins would be good here.

This is left and we good for merge.

Gabrielxd195 · 2024-08-21T00:01:31Z

I tried this, but the only problem is the "W/D" label next to the knob, because visually it makes the plugin space look unnecessarily larger and the difference with the old design is not very noticeable. Please remove the label before merging so that it looks more minimalist like the one in the first image.

RoxasKH · 2024-08-22T20:26:22Z

I tried this, but the only problem is the "W/D" label next to the knob, because visually it makes the plugin space look unnecessarily larger and the difference with the old design is not very noticeable. Please remove the label before merging so that it looks more minimalist like the one in the first image.

Wholeheartedly agree (but please don't thumb up yourself). The label honestly shouldn't be in such a place where it's a convenient knob but as i said in a mirrored bigger knob inside the fx window.

The real beneft coming from this PR is actually there only with the size proposed at the beginning, and it's pretty clear how effective it gets. You should still be able to distinguish the 2 knobs as one starts from the center while the other doesn't, and through tooltips. The difference isn't quite as effective with labels added back in

Before vs after. A simple bar with at most w/d knob is also usually the default behaviour afaik in most daws.

Gabrielxd195 · 2024-08-22T21:16:22Z

@RoxasKH Actually without the labels the change is quite noticeable, look at all the space that is saved, it looks more modern. I think that all labels should be optional in LMMS, because that is why we have tooltips.

DomClark · 2024-09-03T23:49:55Z

Tooltips are for additional information, and are not meant to be the sole way of distinguishing UI elements. Labelling elements with tooltips is fine if the elements have sufficiently distinct and suggestive icons, but LMMS has a huge number of near-identical knobs.

Omitting labels hampers feature discovery, as the user has to hover over the appropriate knob even to know that a feature exists. Users familiar with other DAWs, who might reasonably anticipate a particular feature to exist, still have to hover over each knob to find it. Even experienced LMMS users, who know what features are available, have to memorise which knob is which or face the same problem.

Here's some relevant guidance from an article on tooltips by a UX company:

Don’t use tooltips for information that is vital to task completion.

Users shouldn’t need to find a tooltip in order to complete their task. Tooltips are best when they provide additional explanation for a form field unfamiliar to some users or reasoning for what may seem like an unusual request. Remember that tooltips disappear, so instructions or other directly actionable information, like field requirements, shouldn’t be in a tooltip. (If it is, people will have to commit it to their working memory in order to be able to act upon it.)

Surely the name of the knob isn't "additional information" or "reasoning"? And I would consider "which knob does what" to be fairly vital information when trying to do something, that users shouldn't have to memorise.

I realise this is just two knobs for now (the screenshots don't show the decay knob), but it already has minor issues with feature discovery and distinguishing controls, and would quickly degrade the usability of the program if taken as a precedent. While aesthetics should of course be considered, they shouldn't be prioritised over UX.

bratpeki · 2024-09-04T09:59:16Z

Looks great, I would love to test this! Can I get a little summary of everything so far, and points that are worth testing?

bratpeki · 2024-09-04T10:10:39Z

Knob labels are back. I honestly prefer the look without them but it seems I am in the minority on this.

Definitely keep the labels, it makes for better UX.

RoxasKH · 2024-09-04T18:26:52Z

Tooltips are for additional information, and are not meant to be the sole way of distinguishing UI elements. Labelling elements with tooltips is fine if the elements have sufficiently distinct and suggestive icons, but LMMS has a huge number of near-identical knobs.

Omitting labels hampers feature discovery, as the user has to hover over the appropriate knob even to know that a feature exists. Users familiar with other DAWs, who might reasonably anticipate a particular feature to exist, still have to hover over each knob to find it. Even experienced LMMS users, who know what features are available, have to memorise which knob is which or face the same problem.

Here's some relevant guidance from an article on tooltips by a UX company:

Don’t use tooltips for information that is vital to task completion.

Users shouldn’t need to find a tooltip in order to complete their task. Tooltips are best when they provide additional explanation for a form field unfamiliar to some users or reasoning for what may seem like an unusual request. Remember that tooltips disappear, so instructions or other directly actionable information, like field requirements, shouldn’t be in a tooltip. (If it is, people will have to commit it to their working memory in order to be able to act upon it.)

Surely the name of the knob isn't "additional information" or "reasoning"? And I would consider "which knob does what" to be fairly vital information when trying to do something, that users shouldn't have to memorise.

I realise this is just two knobs for now (the screenshots don't show the decay knob), but it already has minor issues with feature discovery and distinguishing controls, and would quickly degrade the usability of the program if taken as a precedent. While aesthetics should of course be considered, they shouldn't be prioritised over UX.

I agree
But it's not just about "aesthetics", slimmer effects improve usability of the drag and drop reordering fx chain, and help to get a better understanding of an fx chain at a glance.
This is obviously still an improvement over the initial design, and i'm all for it, but i believe from my screenshot it's kind of easy to tell how less effective the rework becomes once label are added.
It goes from 27px saved to 14, basically a 50% reduction in height reduction. The first implementation almost slims the original 57px it by 50%, compared to just 28% with added labels.

About "Users familiar with other DAWs, who might reasonably anticipate a particular feature to exist", to my knowledge and after a quick research, users familiar with other DAWs would most likely not anticipate this. As far as i've seen most daws actually don't have additional controls in the effects chain list aside from active/inactive, but just keep them inside the effect window, usually with a topbar. Unless they integrate the effect window inside the chain, like ableton does afaik
The only DAW which has something like that is FL Studio, which only has 1 knobs, Wet/Dry, which is mirrored in the effect window inside a topbar. The thing is, controls here should be there just for convenience, and i believe LMMS will also need in the future to move them or at least mirror those controls inside the effect window. It makes sense, even just from a consistency standpoint, as this is already how it's done for instruments, with convenience controls on the track that are also in the instrument window. Once mirrored, convenience controls could possibly not need a label, as the main control inside the effect window would, at least that's how i see it.
It's also to be noted that mos DAWs don't have such an height for FX chains elements, and it's probably for the same reasons.

All of this to just say either way it's an improvement, i'm ok with it, and there's always room for possible changes later

Gabrielxd195 · 2024-09-04T20:55:30Z

@DomClark It should be noted that in this specific case there is only one knob with a very basic function, with the option to "restore" it to default value and with the tooltips with the information of the knob with the mouse movement, so new users already have enough information to know what that knob does. Adding the label makes this pr pointless because I guess the idea is to simplify the effects chain and make it more intuitive. Also there are cases in music composition and sound design where you need to add many plugins to get the desired sound, and this improvement in the effects chain (without the label) makes the workflow better, because now you can see the plugins at a glance and not have to keep scrolling.

messmerd · 2024-09-04T21:09:31Z

If we want to keep the "W/D" label, maybe it could be placed to the side of the knob and rotated 90 degrees? It shouldn't impact the vertical height that way. I'm not sure how nice it would look, but might be worth trying.

The auto quit knob probably shouldn't be in the EffectView widget at all since it provides such a specific functionality that few people use, though moving it to a topbar in the effect window as @RoxasKH mentioned could be done in a later PR.

michaelgregorius · 2024-09-05T15:59:52Z

I think the best solution might be to make the list widget of the plugins more flexible so that it can deal with effect widgets that render themselves at different sizes.

The effect widget could then be implemented in such a way that it checks a setting which decides whether users want to see the labels or not. Seeing the labels should be the default settings so that users can learn the interface. Once they know it they could decide to switch to a "compact mode" in the settings where the labels are not shown and not much space is used.

mini fx rewrite without merge conflicts

34daf03

enp2s0 mentioned this pull request Aug 7, 2024

WIP: new effect rack interface and features #7242

Closed

7 tasks

enp2s0 changed the title ~~WIP: mini fx rewrite without merge conflicts~~ mini fx rewrite without merge conflicts Aug 7, 2024

clear checked status of label button when fx window is closed

124a894

Rossmaxx reviewed Aug 8, 2024

View reviewed changes

enp2s0 added 2 commits August 8, 2024 09:56

style & cleanup

9d01945

add spaces

efd8cfe

Rossmaxx reviewed Aug 8, 2024

View reviewed changes

enp2s0 added 3 commits August 8, 2024 10:07

more

eaf94e4

effectlabelbutton style cleanup

889818a

remove unused graphics

5b3ce79

Rossmaxx approved these changes Aug 8, 2024

View reviewed changes

Rossmaxx requested a review from michaelgregorius August 8, 2024 14:26

michaelgregorius requested changes Aug 8, 2024

View reviewed changes

enp2s0 added 6 commits August 8, 2024 23:26

effectlabelbutton cleanup

af9ed03

classes are no longer friends, they hate eachother now

34a48d8

simpler margin calc and connect()

7f541f5

missing space

5127544

one more space

89cb23f

wrong place

809a152

michaelgregorius reviewed Aug 9, 2024

View reviewed changes

include/EffectLabelButton.h Outdated Show resolved Hide resolved

michaelgregorius reviewed Aug 9, 2024

View reviewed changes

src/gui/widgets/EffectLabelButton.cpp Outdated Show resolved Hide resolved

Code cleanup

e6aa0ea

Newline at the end of the `EffectLabelButton` files. Cleanup of includes and forward declarations. Remove commented out friend declaration.

michaelgregorius approved these changes Aug 9, 2024

View reviewed changes

bring back knob labels

b09286e

Rossmaxx reviewed Aug 12, 2024

View reviewed changes

include/EffectView.h Show resolved Hide resolved

messmerd mentioned this pull request Sep 4, 2024

Remove "gate" option completely #7486

Closed

mini fx rewrite without merge conflicts #7438

Are you sure you want to change the base?

mini fx rewrite without merge conflicts #7438

Conversation

enp2s0 commented Aug 7, 2024 • edited Loading

Rossmaxx commented Aug 8, 2024

Rossmaxx left a comment

Choose a reason for hiding this comment

Rossmaxx left a comment

Choose a reason for hiding this comment

Rossmaxx left a comment

Choose a reason for hiding this comment

michaelgregorius left a comment

Choose a reason for hiding this comment

michaelgregorius Aug 8, 2024

Choose a reason for hiding this comment

enp2s0 Aug 9, 2024

Choose a reason for hiding this comment

enp2s0 Aug 9, 2024

Choose a reason for hiding this comment

michaelgregorius Aug 9, 2024

Choose a reason for hiding this comment

michaelgregorius commented Aug 9, 2024

enp2s0 commented Aug 9, 2024

DomClark commented Aug 9, 2024

enp2s0 commented Aug 11, 2024

Rossmaxx commented Aug 11, 2024

Rossmaxx commented Aug 12, 2024

enp2s0 commented Aug 12, 2024

Rossmaxx commented Aug 12, 2024

enp2s0 commented Aug 12, 2024

Rossmaxx commented Aug 12, 2024

enp2s0 commented Aug 12, 2024

michaelgregorius commented Aug 12, 2024

RoxasKH commented Aug 12, 2024 • edited Loading

Rossmaxx commented Aug 20, 2024

Gabrielxd195 commented Aug 21, 2024

RoxasKH commented Aug 22, 2024 • edited Loading

Gabrielxd195 commented Aug 22, 2024

DomClark commented Sep 3, 2024

Don’t use tooltips for information that is vital to task completion.

bratpeki commented Sep 4, 2024

bratpeki commented Sep 4, 2024 • edited Loading

RoxasKH commented Sep 4, 2024

Don’t use tooltips for information that is vital to task completion.

Gabrielxd195 commented Sep 4, 2024

messmerd commented Sep 4, 2024

michaelgregorius commented Sep 5, 2024

enp2s0 commented Aug 7, 2024 •

edited

Loading

RoxasKH commented Aug 12, 2024 •

edited

Loading

RoxasKH commented Aug 22, 2024 •

edited

Loading

bratpeki commented Sep 4, 2024 •

edited

Loading