Update mute and solo buttons, add them to instrument windows

[rubiefawn]

Updates mute/solo buttons with new assets (slashed speaker icon, headphone icon) to better communicate their purpose, since the current LED assets can be ambiguous without labels. Additionally, resolves #2685 by adding mute and solo controls to instrument track windows and sample track windows next to the volume knob.

• todo: Replace icons sourced from twbs/icons with new CC0-licensed icons from @StakeoutPunch
• todo (non-blocking): Add assets for classic theme
• todo (non-blocking): Adjust SVG icons to be pixel perfect (on hold, need to get the CC0 icons first, may or may not be a problem)

[sakertooth]

From the screenshot you provided, it looks like the mute and solo buttons are being merged into the same space as that of the volume knob. I'm thinking having a separate section for the mute and solo buttons (with a label like M/S) might be better.

[rubiefawn]

Here's what that looks like:

[sakertooth]

Here's what that looks like:

That looks a lot better IMO!

[sakertooth]

Code changes look good to me. Will test and wait for CI before approving.

[regulus79]

To me the knobs feel a bit crowded, almost like the pitch range lcd should be moved closer to the channel lcd, idk

[sakertooth]

To me the knobs feel a bit crowded, almost like the pitch range lcd should be moved closer to the channel lcd, idk

I think there was some separation already added before this PR, but since we need that space now it's probably okay to remove.

[rubiefawn]

If we're going to address the lack of real estate in this PR, I would like to move the oversized preset save button to the left of the preset name, and make it the same size as the previous/next instrument buttons.

Wait, do we really need the previous/next instrument buttons in the first place? I don't think I've ever used them, since I just click on the specific instrument I want to edit from the track view.

Here's what it could look like if the previous/next buttons were replaced by the save button (this one is a hasty photoshop job)

[rubiefawn]

After some discussion in the Discord, the save button size and other such layout issues not directly related to the addition of these buttons will be addressed elsewhere.

After some more discussion in the Discord, there may be some other changes after all.

[AW1534]

The icons are missing on my windows system (msvc)

And in compact mode for some reason the track labels are missing

[rubiefawn]

Good catch! I am able to replicate it as well using the CI build artifacts on my Windows system. Running it from the console reveals the following output:

Error loading icon pixmap "mute_active": "File not found"
Error loading icon pixmap "mute_inactive": "File not found"
Error loading icon pixmap "solo_active": "File not found"
Error loading icon pixmap "solo_inactive": "File not found"

Spectrum Analyzer's SVG controls show up fine, so this is likely a problem with my code. I'll reference Spectrum Analyzer to see how it should be done.

Edit: It looks like the new assets were just not being included in the installer at all.

Also, track labels disappear in compact mode, that's part of how it becomes compact. That is intended behavior. You can still open the track window by clicking on the icon instead.

[rubiefawn]

@AW1534 That should be fixed, it was an issue with SVG theme resources not getting packaged into the installer. Can you test it again?

[bratpeki]

And in compact mode for some reason the track labels are missing

That's how compact mode works

[AW1534]

Looks great!

[sakertooth]

I don't know if its just my system acting odd, but can you check the Greppi demo for me real quick? I had an issue where I couldn't mute the mixer channels in the project ranging from [1, 7]. Both regular mode and compacted mode had this issue. The solo button works fine however.

[sakertooth]

I don't know if its just my system acting odd, but can you check the Greppi demo for me real quick? I had an issue where I couldn't mute the mixer channels in the project ranging from [1, 7]. Both regular mode and compacted mode had this issue. The solo button works fine however.

Okay, so it might be an issue elsewhere because master has the same problem.

Edit: Nevermind, the mute buttons were connected to MIDI 🤯

[sakertooth]

Tested it in regular mode and compacted mode. The PR works fine AFAICT.

[bratpeki]

How about green, grey and red in the color scheme? More LMMS-compatible IMO.

[sakertooth]

How about green, grey and red in the color scheme? More LMMS-compatible IMO.

Yes 👍
I felt like something was off but didn't know what..

[StakeoutPunch]

Original icons sourced from twbs/icons, which is MIT licensed. How should I include attribution? In the .svg metadata?

This escaped my attention until now. We want to avoid anything that requires attrition for program assets. CC0 or equivalent public domain.

Unless somebody corrects me and that is actually fine, I can create new svg icons later today if needed.

[tresf]

@rubiefawn thanks for the work on this, it's awesome and uses SVGs!

Having said that, I'm providing this feedback in hopes that it does not turn into a feedback war <3 . I know these types of things bring strong opinions; I'll try to summarize the thought process as briefly and as clearly as possible.

These are the design goals that @StakeoutPunch @RoxasKH and @tresf predominatly agreed upon:

• The default state of a button should be subtle and should blend in. (Differs from the existing "bright green" we have today)
• The "activated" state of a button should be clear to identify
• Users tend to prefer a 🟥 red color for the mute to be consistent with existing workflow
• Users are mixed between 🟨 yellow/ 🟧 orange/ 🟦 blue for the solo.

@RoxasKH kindly provided the following mockups. I believe the last mock-up most properly describes the above. (Please ignore any logical fallacies in the mockups)

[rubiefawn]

Did we determine how the active state should be represented? Currently, active just changes the icon color and subtly changes the background color to look "pressed", but these mockups have the active state change the color of the background instead while the icon remains the same.

Aesthetically I prefer the current method (icon color changes), but from a UX standpoint having the higher contrast between active/inactive states has a lot of value. Thoughts?

Edit: A more visual example: which is preferred between these two, considering colors only? or ?

[tresf]

I'm providing this feedback

One more thing... the above mockups fail to provide the speaker option

• 🔊 (NORMAL)
• 🔇 (MUTE 1)
• 🔈 (MUTE 2)
• 🔈 x (MUTE 3)

There was not a consensus on the best "mute" option. I've compared this to other software and they all seem to be pretty common techniques to illustrate a "mute". My only feedback in regards to this is that at the current icon size, the x may be hard to see for some users. This is a minor detail if the "activated" state is easy to see, but it was also something we discussed.

[tresf]

Did we determine how the active state should be represented?

Sorry this is wordy...

• The below points are a direct result of the mockups reversing of our "mute" state from being ON/OFF to DEFAULT/ON.
• With regards to DEFAUL/ON: We compared this (for lack of better analogy) to a 🎄(busy interface of bright lights). The PR as it exists today is in alignment with the "NO 🎄" however I also think it fails to bring strong attention to the muted channels.
• In addition the PR as it exists today may have accessibility concerns for colorblind users. For this reason, we sort of universally agreed that we DO want a 🎄 under non-default circumstances, as it makes it clear to the user. (Please see NOTES: on this below)
• The slightly darker background makes the button appear recessed instead of raised. This is how we do it in some other parts of the software for radio-type toggles however I think it does not provide proper feedback to the user (or if it does, it's providing the backwards of what's intended). This is not a criticism of choice (the current design is an accurate reproduction of how we do it today) but that's why I think this conversation is important to have now as this PR has an opportunity to improve upon this.

Aesthetically I prefer the current method (icon color changes), but from a UX standpoint having the higher contrast between active/inactive states has a lot of value.

When comparing to other software, FLStudio was the outlier and uses a similar LED system. This was likely copied to inspire how we use it today. It takes up less space, but for reasons clearly explained in this PR's description, we're aiming to move from this. Some DAWs have a high contrast "ON", some do not. All seem to have a heavy contrast between states.

Thoughts?

My vote is a very prominent DEFAULT/ON as illustrated in the third mockup. The blue may be outside of our color palette. GarageBand uses yellow for the same, so I think using an alternate color is well justified since the solo state is a deliberate outlier to most other control mechanisms.

• GarageBand even goes as far as to blink the mute icon for tracks affected, creating a THIRD state for MUTE which is "MUTED BY SOMETHING ELSE", likely to illustrate to the user that they didn't press mute, but it's muted.
• In the case of GarageBand, the volume icon changes to the mute color but the button does not appear pressed. I think something similar would justify a colored icon, albeit under a new enhanced version of this behavior.

NOTES:

Click to expand

When comparing LMMS to professional DAWs, we noticed that professional DAWs vary greatly in this regard, but the consensus from conversations yesterday seemed to be in agreement that MUTED or SOLO'D tracks can only benefit from being bright and easy to find. Naturally, the more people we ask, the more polarizing this change can become as people get emotionally invested in UI, so this this needs to be explained again.... Assuming that it's impossible to get a pure consensus on this, but the three of us were able to come to a common ground, which I feel is a great step forward and will help define the experience for future UI elements moving forward.

[rubiefawn]

New CC0 assets have been added, PR description updated with new screenshots. This should be ready to go!