Loop enabled/disabled button should be more obvious

[tresf]

The enable/disable loop points button is a bit backwards. It's gray-ed out when it's inactive and just "regular" when it's active.

At a glance, this makes it hard to know when the loop points are enabled:

Gray-ed out from a UI perspective generally means it's not accessible. I think instead, the loop points should behave more like an LED toggle and be very obvious when enabled.

This way when a composer finds their project arbitrarily jumping away from the cursor area, they have a visual indicator as to why.

[BaraMGB]

This looks a little bit like a overkill to me. Perhaps we can make it like the pencil button. When it's active it looks pushed in.

[tresf]

This looks a little bit like a overkill to me. Perhaps we can make it like the pencil button. When it's active it looks pushed in.

Pencil is a radio button, not an on/off toggle. Also, Pencil has a persistent cursor which illustrates it's action to the user. Looping should be very obvious to the end-user. Furthermore, suppressed... does this mean looping is enabled or disabled? If your mind needs to think for 0.5 seconds about it to use it, it's bad UI.

[RebeccaDeField]

Does anyone know how other DAWs handle the enable/disable loop points function?

[SirBothersome]

@RebeccaDeField Of my brief use of FL Studio, not much different than this AFAIK, I believe it may have been a radio button

[tresf]

Does anyone know how other DAWs handle the enable/disable loop points function?

• Ableton and Pro Tools will highlight the entire loop region (patterns too) and use a separate button for playing the loop. sample
• Audacity (not a DAW) just loops what's selected, assuming that's what you wanted.
• Logic Pro uses a very, very distinguishable loop area but I've no idea how it's toggled.
• Bitwig studio appears to use a bright button although others that have used it would need to confirm.

[mikobuntu]

Bitwig studio appears to use a bright button although others that have used it would need to confirm.

• All Bitwig buttons when not in use are grey with a white logo and when in use ( toggled ) are orange with a black logo. [ this is a very good way of showing what is going on ] [[ imo :) ]]
• Ardour5 : when buttons are not in use are grey with white logos ( small black outline ) and when in use ( toggled ) only the grey changes to green. Also the loop region on the song editor is all highlighted with a green transparency. I find this behaviour the most obvious from most DAWS that I use.
• QTractor : Is probably the worst to see what is going on regarding loop area. Hovering over the loop button uses the same image/colour/css/whatever as actually enabling loop play.
• Hydrogen ( drum machine ) Just changes the button colour from grey to blue on toggle.

[Umcaruje]

I think also that a nicer icon should be on the button. The current icon made sense back when we had the loop markers, but now its just confusing. Most DAW's have an icon similar to this: a simple line that clearly indicates looping.

I also like @BaraMGB's idea of making all the toggle buttons get creased in as pressed, like we do with the radio buttons.

[RebeccaDeField]

I agree with @Umcaruje about changing the icon.

I would like to propose that we start with changing the button to be pressed so that it matches the other behavior in the program and then if users do not find that to be distinguishable enough, we could use the colored button idea instead.

I can tackle the new icon, but someone more familiar with the code side of things would need to change the loop button styling.

[tresf]

Rough mockup...

I agree this is better visually although now we're starting to introduce some inconsistencies in our GUI. (play toggle, auto-scrolling toggle, etc). If we are to keep this consistent, I'd like auto-scroll to be default and non-autoscroll to be the supressed button. Play should be supressed while playing, etc.

[RebeccaDeField]

Idea for new loop points icon:

@tresf @Umcaruje

[RebeccaDeField]

After some discussion on Discord, this is what the icon looks like:


👆 Transparent .png here

Now that we have an icon to work with, is there someone that would like to code up @tresf's proposal for the pressed button?

[smithjessk]

@RebeccaDeField I am interested!

[Umcaruje]

Could we just make the icon green when its enabled and do the same with the autoscroll button? I think it would fit.

[tresf]

Auto scroll is on by default. Would that be confusing from a UI perspective to have it bright green on project load?

[Spekular]

@tresf I think so.

[RebeccaDeField]

Would that be confusing from a UI perspective to have it bright green on project load?

@tresf I think so as well. I've come up with a few alternate ideas for this, but none of them made sense to me from a UI consistency standpoint when tested in the program.

Anyone have any other ideas?

[tresf]

I think consensus is the combination of a few posts above:

• Make the color different per: @mikobuntu
  • All Bitwig buttons when not in use are grey with a white logo and when in use ( toggled ) are orange with a black logo. [ this is a very good way of showing what is going on ] [[ imo :) ]]
• Improve the loop logo per @Umcaruje:
  • I think also that a nicer icon should be on the button. The current icon made sense back when we had the loop markers, but now its just confusing.

If the only way to make this consistent is to also do this to the pencil (play, etc) in the same fashion, so be it.

[tresf]

If the only way to make this consistent is to also do this to the pencil (play, etc) in the same fashion, so be it.

Going out on a limb... One other idea from a UI perspective is to make two tones of green as to illustrate severity. I'll call these tones "Meh" and "OMG". Stuff like Loop and Play can use "OMG" where pencil and section can use "Meh". That way we can maintain a consistent UI theme without sacrificing usability. Ugh. ;)

[RebeccaDeField]

Improve the loop logo per @Umcaruje:

So we're halfway there, then.

[mikobuntu]

Here's how I envisage my Loop_Region_Overlay to look in LMMS.

Comparing to Ardours view of Loop_Region.

[musikBear]

@mikobuntu it looks good, but only ok If the transparency is cpu-lean, imo

[tresf]

but only ok If the transparency is cpu-lean, imo

Please stop making these statements. No one wants the software to run slowly and blindly mentioning it on every UI change is obvious and superfluous, especially so if the person commenting hasn't even looked at the draw routines.

The draw routine for the Song Editor should be able to handle this with little or no additional overhead. The transparency itself can add additional GPU/CPU resources however we're already using it in several other places, so the impact should be minimal.

[RebeccaDeField]

@mikobuntu I would turn down the opacity a touch, but I think your idea makes the loop point a lot more obvious.

I noticed in your screenshot of Ardour the white audio graph and midi track notes are above the transparent layer which I believe is done so that the producer can still easily identify those elements. Does anyone know if that would be possible for us to implement as well?

[tresf]

Does anyone know if that would be possible for us to implement as well?

Theoretically, anything is possible, but I believe the highlighted region is a topic for another issue, unless of course @mikobuntu plans to work on this. 🏖

[mikobuntu]

@RebeccaDeField Yes I think the opacity may have been a bit higher than needed, this was just a mockup to show roughly how my idea would look. I will leave the colour stuff up to the experts like yourself :) @tresf I'm unsure if I would have enough knowledge to be able to work on this to be honest tho. I could probably have a look through the QT docs for some info regarding overlays.

[Umcaruje]

I like @mikobuntu's idea and I would be willing to work on it, but I'm in middle of my semester so I don't have that much free time on my hands. So maybe when things cool down I can take this on and finish that piano roll grid

[tresf]

@mikobuntu if you have time to start this, @Umcaruje's PR is a good place to start looking at the code (examples are for other editors, but can be adapted in principal to the Song Editor):

https://github.com/LMMS/lmms/pull/3062/files

The paintEvent stuff is about as straight forward as it gets. Unfortunately the routines are huge, so finding out where best to put the paint code can get tricky. 👍

[RebeccaDeField]

And then out of the blue, a wild idea attacks..

This would be consistent with the UI because:

EDIT: I'm not 100% sure about this idea, but I thought I'd post it anyway

[RebeccaDeField]

Since changing the button to be green seems to be at a standstill, I'm thinking about changing active icons to be green. It solves the immediate issue of confusion which is making some newer icons already outside of the palette and style.

If I don't hear any objections about this, I will make a PR for it.

[musikBear]

@RebeccaDeField Good idea, except maby for this
, because it is always selected in one of its states. Else all should be green i guess..

[RoxasKH]

I know probably importante decision had already been made. But anyway i think in the future LMMS should get an highlighted background for that button whn is active, something like this (i know it's horrible it's just to give an understanding, so like pressed but with a green background)

This because it's the most common behaviour in DAWs.

Here's some examples

FL Studio 12:
Bitwig:
Ableton:
Reason:
Cubase:
Ardour:

Even if Budislav concept shows an FL20 like behaviour, so maybe that'll be like that.

Budislav:
FL20:

[RebeccaDeField]

@RoxasKH I agree, this would be ideal. The coding work behind implementing that seemed to be at a standstill so I was looking for a workaround that I could make happen. If we could implement it this way, we already have the improved icon ready.

An older mockup we had settled on some time ago:

A possible good addition with some design tweaking:

[RebeccaDeField]

As a follow up, if someone is able to team up with me to work on this, I can make improved mockups for it.

[ryuukumar]

Not a designer, but I can help in coding if required.

[RoxasKH]

@RoxasKH I agree, this would be ideal. The coding work behind implementing that seemed to be at a standstill so I was looking for a workaround that I could make happen. If we could implement it this way, we already have the improved icon ready.

An older mockup we had settled on some time ago:

A possible good addition with some design tweaking:

That green gradient is kinda weird, maybe it shuld be lighter, but i got it. I love the transaprency of the second mockup.

The problem is that that button can't be styled in the css because all buttons use the same class as i experienced when i was making my theme.
If we can get a separate class for that button that could be implemented through css and be also themeable. But maybe is a bad workaround, let's see what developers say.

[tresf]

LcdWidget uses a style parameter to change its behavior.

lmms/src/gui/widgets/LcdWidget.cpp

Line 255 in 1746300

void LcdWidget::initUi(const QString& name , const QString& style)

This isn't the same thing as overloading the CSS, but might be helpful.

Knob does something closer to what's being described, it makes a special class for implementation-specific version:

lmms/plugins/kicker/kicker.cpp

Line 230 in ce5c744

class kickerKnob : public Knob

Last, and perhaps the simplest -- is to allow multi-state buttons to be an alternate color when they're non-default values. This would encourage consistency (such as the example @musikBear makes with the play head behavior) so that it can benefit from the same "I'm obviously toggled right now" visual appearance.

[RebeccaDeField]

Not a designer, but I can help in coding if required.

I'll take care of the design refinements.

That green gradient is kinda weird, maybe it should be lighter, but i got it. I love the transparency of the second mockup.

Yeah, I agree that the old mockup needs some revisiting and rethinking but I think we've got the basic concept down.

[tresf]

That green gradient is kinda weird

that the old mockup needs some revisiting

Also will need to be tested against the selection-rectangle.

[zacius]

FWIW i came to this thread to find out how to turn it off.

+1 unintuitive UI

But again, my deepest gratitude, this software has enabled me to express myself and feel a creative connection to the sounds of the world around me.

[Rossmaxx]

At current master, looks like the icon has changed and setting loop on seems to have become more obvious. If anyone disagrees, we can reopen.

[musikBear]

At current master, looks like the icon has changed and setting loop on seems to have become more obvious. If anyone disagrees, we can reopen.

Can you screen-shoot the on/off behaviour of Master?

[Rossmaxx]

Here's loop marker on

And here's loop marker off. There is change from what is defined in the PR and it is obvious for regular users. The green is missing. If the green background should be added, just lmk and I'll reopen this.

[Rossmaxx]

#5588 was the fix.

[Rossmaxx]

Got a hint from discord that the icon change is not the fix. The button should still be highlighted. Reopening.

[musikBear]

The button should still be highlighted.

Agree.

[Rossmaxx]

@zonkmachine how viable is it to add this change too to #7314

If you can't, I'll try something but I'll have to do some learning before i land the fix.

[zonkmachine]

@zonkmachine how viable is it to add this change too to #7314

I'll look into it.

[zonkmachine]

Something like this? It's just a matter of editing the colors of loop_points_on.png

[Rossmaxx]

Nope, more like changing the button's background colour to highlight to green

Refer #3069 (comment)

[zonkmachine]

Nope, more like changing the button's background colour to highlight to green

Similar how the modes draw/knife/edit in the editor change background when selected? Darker on the Default theme and lighter on Classic.

[Rossmaxx]

Similar but the active background should be green like in the linked comment above.

[zonkmachine]

Similar but the active background should be green like in the linked comment above.

Yes, I occasionally do green. I don't get where that background is set in the case of the edit buttons though?

[Rossmaxx]

It's currently not available for theming. #3069 (comment) in combination with a theme entry should do the trick.