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

[tresf]

Valiant idea. From a UI perspective, I'd say the green is less bold than white, so it actually has the opposite effect. 😕

[RebeccaDeField]

@tresf Ok, then maybe let's just code up the green button idea and test that out. It seems to be the best option so far.