Update LMMS knob design

[LostRobotMusic]

Before:

After:

New design approved by @Umcaruje and a few others if I remember right.

In summary, colored knob centers suck. This PR also adds many more theming options to the existing knobs.

[LmmsBot]

🤖 Hey, I'm @LmmsBot from github.com/lmms/bot and I made downloads for this pull request, click me to make them magically appear! 🎩

Windows

• Windows 64-bit: lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mingw-win64.exe (build link)
• Windows 32-bit: lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mingw-win32.exe (build link)
• Windows 32-bit: lmms-1.3.0-alpha-msvc2017-win32.exe (build link)
• Windows 64-bit: lmms-1.3.0-alpha-msvc2017-win64.exe (build link)

Linux

• Linux (AppImage): lmms-1.3.0-alpha.1.92%2Bg25334ce-linux-x86_64.AppImage (build link)

macOS

• macOS : lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mac10.14.dmg (build link)

🤖

{"platform_name_to_artifacts": {"Windows": [{"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://13039-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mingw-win64.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13039?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://13038-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mingw-win32.exe"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13038?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}, {"artifact": {"title": {"title": "32-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/8c74ler96ttl8kio/artifacts/build/lmms-1.3.0-alpha-msvc2017-win32.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/38239045"}, {"artifact": {"title": {"title": "64-bit", "platform_name": "Windows"}, "link": {"link": "https://ci.appveyor.com/api/buildjobs/6tkcwoxrpubj8sww/artifacts/build/lmms-1.3.0-alpha-msvc2017-win64.exe"}}, "build_link": "https://ci.appveyor.com/project/Lukas-W/lmms/builds/38239045"}], "Linux": [{"artifact": {"title": {"title": "(AppImage)", "platform_name": "Linux"}, "link": {"link": "https://13037-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.92%2Bg25334ce-linux-x86_64.AppImage"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13037?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}], "macOS": [{"artifact": {"title": {"title": "", "platform_name": "macOS"}, "link": {"link": "https://13036-15778896-gh.circle-artifacts.com/0/lmms-1.3.0-alpha.1.92%2Bg25334ce2e-mac10.14.dmg"}}, "build_link": "https://circleci.com/gh/LMMS/lmms/13036?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link"}]}, "commit_sha": "7bae9cced27696d940aa41da409f607eff7b39e3"}

[he29-net]

I like the new look on the standard-size knobs, but those smaller volume / pan knobs in the song editor look way too tiny to me. The black edge of the tiny knob also does not fit that well; I would say it has too much contrast against the relatively bright background, and it also visually seems "thicker" compared to the edge of a full-size knob, so it does not look consistent.

[Veratil]

Kind of hard to read with this spacing and all.

Suggested change

	setFixedSize( qMax<int>( m_origWidth,
	QFontMetrics( pointSizeF( font(), 6.5) ).width( m_label ) ),
	m_origHeight + 10 );
	setFixedSize(
	qMax<int>(m_origWidth, QFontMetrics(pointSizeF(font(), 6.5)).width(m_label)),
	m_origHeight + 10
	);

[Veratil]

currentCenterTopColor and currentCenterBottomColor are the same between all knobs, we can probably pull this out and always set it after the switch.

[Veratil]

If we remove default a new knob size added should cause the compiler will raise a warning about not having all cases covered.

[Veratil]

Suggested change

	p.drawPixmap( static_cast<int>(
	width() / 2 - m_knobPixmap->width() / 2 ), 0,
	*m_knobPixmap );
	p.drawPixmap(static_cast<int>(width() / 2 - m_knobPixmap->width() / 2), 0, *m_knobPixmap);

[Veratil]

knobSmall_17 and knobBright_26 are the same, we could combine these cases.

[Veratil]

Should these colors be customizable, too?

[Spekular]

I approve of getting rid of the green, but I'm not sure we have to revert to 1.1.3 style knobs to do it.

[RoxasKH]

I like the new look on the standard-size knobs, but those smaller volume / pan knobs in the song editor look way too tiny to me. The black edge of the tiny knob also does not fit that well; I would say it has too much contrast against the relatively bright background, and it also visually seems "thicker" compared to the edge of a full-size knob, so it does not look consistent.

Yeah, little knobs aren't that good, but the result with the normal one is crazy good.

Here there are a couple of workaround which may or may not be a good idea.

First: require making the default trackspace a little larger, and putting the normal dimension knobs there, too, removing the labels.

This is not a really drastic change, but it'd work. The cons are that we lose the visible labels, tho.
Still there's the tooltip and it's pretty clear which one is the pan and which is the volume.

FL Studio doesn't label those knobs, too, and there it's even more difficult to recognize which is the correct one, as they don't have the green outline, like these ones.

Second: It actually still put the normal knobs there, but make the default trackspace taller than it is, to make the labels fit.

Although this would be a bigger change.

The third option is to make the little knobs someway looks good, but there is so little space there...

Now that i think about it, even Budislav mockup doesn't label them, and neither do Reaper i think, so this is probably the right way to go

[Spekular]

Compared to Ableton and Logic Pro (and from what I can tell, FL Studio) our minimum track height is already huge. IMHO any changes to the track labels should keep this in mind so that we can eventually lower the minimum height.

[vlad0337187]

They're nice, but I would miss old ones...
They made LMMS look like more futuristic.

[he29-net]

The third option is to make the little knobs someway looks good, but there is so little space there...

I don't think it should be hard to improve them. I tried just a few small changes:

From left to right: first is the original, the second one uses a thinner line by changing line 455 to:

  p.setPen( QPen( QColor(11, 12, 17), m_origWidth / 26.f, Qt::SolidLine, Qt::RoundCap ) );

so that the stroke width gets thinner the smaller the knob gets (relative to the most used "size 26", which remains exactly the same).

Then for the next one I simply added 1 to the radius on line 444. It looks quite nice (IMO), but perhaps is a little too big. The last one uses automatic adjustment similar to the stroke width:

  const float radius = m_origWidth / 2.f - 2.5f - (2 * m_origWidth / 26.f);

The constant here can be again tweaked a bit, I went for a size somewhere between the current too small and the "+1 too big" one. To match the third, biggest variant the adjustment would be - 1.5f - (3.f * m_origWidth / 26.f); (I think I still like that one the best).

Overall, when designing UI elements for different size variants, it is good to be reactive and adjust the individual elements in a way that better fits the target size. Some time ago I saw a picture that perfectly illustrated the concept, it looked similar to this:

[he29-net]

And one more addition: since we are dealing with knobs that are procedurally drawn, we could also draw them at the native resolution. It took me a while to figure out why are they still ugly and pixelated on a high DPI screen, and it seems that the cause is that the knob is first painted to a QImage cache, and then the cache is drawn on the screen at the end.

That's an interesting concept; do we actually know if it is any faster? It can be forced into native drawing, but it is a bit of a hack (the Spectrum Analyzer also uses it to draw sharp SVG icons). Here is what it looks like (a proof of concept, no idea what happened with the offset and the label):

(Take this just as a side note, this is probably out of scope of this PR.)

[RebeccaDeField]

I reviewed the feedback on the thread here and also received feedback from others that the design not sitting well with a fair number of people for style and scale.

I still agree that the original full-knobs are not the way to go for updating the design (about time we leave them behind), and 100% support drawing them instead of using raster designs.

I would like to propose some designs with the goal of usability, scaling, theming, and different user groups as the focus above all else. If we want to create some more stylish or creative knobs, we might do that as a separate effort for larger knobs (I attached a few starting concepts for this), but these would just complicate the scaling issue, so let's strip down our standard knob to work well in all areas first and if there is to be any efforts into more style elements on bigger knobs, that can be a future project.

As mentioned in a previous comment about scaling, it is common to reduce detail as one scales the design down, but so long as we don't remove any important details for scaling up, this should work both ways. Let's break each element down into priorities for the user from a functional perspective.

The center area of our knob is essentially not used at all, and completely unnecessary outside of aesthetics, skeuomorphism maybe (giving cues and nostalgia to analog knobs), and creating a round point to define the center to avoid awkward sharp rotating lines. It's taking up the most space, and making the design more difficult to work with.

On the flip side, our dial area is a pretty small line, which is really the most important part. I strongly believe that we should minimize or remove the center, and expand on the dial instead of keeping it the other way around.

The pointer serves the purpose of potentially making the position of the knob clearer, although it is not completely necessary given that the position is still very clear without and fully functional.

As for colors, I suggest that we further minimize the use of green to create options that are friendly to people of all with a range of eye-sight, giving clear contrast solely from the shades of white and not on the saturation of green. This will also make the knobs easy to integrate into any color schemes for alt themes, and room for anyone to add a custom color where they see fit. By making both layers of white slightly transparent, we also avoid eye strain from pure white.

By minimizing the center, and expanding the dial, this is what we get to start:

It scales pretty well, though the tiny center area might still end up looking fuzzy or squarish, so I would like to suggest removing it completely and instead give the pointer a rounded cap so that it can be placed in the exact center of the circle.

Now onto the most minimalistic option, we can scale everything back to the dial alone, retaining the clearest and most elegant scale.

There are ways we can play with style within this still, playing with the thickness for larger or smaller knobs if that is desired.

Now, using these designs as a basis, we might be able to later explore some more stylistic elements for areas where (we might) have more space for pixels, but I don't suggest any of these as a standard knob overall, just showing as examples of how even the more minimalistic design can be expanded if anyone wants to make an effort for aesthetics alone for areas where there is more room to do so.

I wanted to illustrate very clear stripped-down concepts here, but I understand it may make more sense to add the start and endpoints, so here are a few examples of how we could apply that.

[Spekular]

This looks like a much cleaner direction to me. Personally I think the dial with indicator would work well as a slot in replacement for our medium-sized knobs (volume, pan, etc.) and the indicator-less one would work well for smaller knobs (mixer sends could do well with smaller knobs, for example).

[RoxasKH]

I reviewed the feedback on the thread here and also received feedback from others that the design not sitting well with a fair number of people for style and scale.

I still agree that the original full-knobs are not the way to go for updating the design (about time we leave them behind), and 100% support drawing them instead of using raster designs.

I would like to propose some designs with the goal of usability, scaling, theming, and different user groups as the focus above all else. If we want to create some more stylish or creative knobs, we might do that as a separate effort for larger knobs (I attached a few starting concepts for this), but these would just complicate the scaling issue, so let's strip down our standard knob to work well in all areas first and if there is to be any efforts into more style elements on bigger knobs, that can be a future project.

The center area of our knob is essentially not used at all, and completely unnecessary outside of aesthetics, skeuomorphism maybe (giving cues and nostalgia to analog knobs), and creating a round point to define the center to avoid awkward sharp rotating lines. It's taking up the most space, and making the design more difficult to work with.

Personally i don't agree with all of this. Well, you're totally right from a usability perspective, but from a graphical standpoint, even if it's true that the center of the knobs isn't used, i think it's really important for aesthetics, as you said. DAWs were created after analog equipment, and most of them tried to imitate that in a digital way, so analog-knobs are kinda the standard nowadays.
The example you proposed are good, flat and modern, but i wouldn't like them in a DAW, honestly.

Let's just take a look at the industry standard nowadays: the only one which is using kinda that style is ableton (and personally i'm not a fan of ableton flat gui). Every other DAW use a knob that reminds of an analog one. Flat knobs are more common in vsts, but also there, a lot of them use knobs with a center.

Even if it's true that the little knobs at the moment are a problem, i find that the design of the bigger knobs in the original post fits the LMMS theme well, and it's really good.

I understand that an update could be done later, but i can't see why. I know that we need to move on totally graphically coded knobs, but i can't see why we can't find a good design here. I mean, we already have "usable" knobs in the meantime (even if they rely on images), and if we have to update them to be dinamically drawn, i think it'd be better to find a more creative knob at the same time, also considering that the 1.3 release will probably take as much time as 1.2, if not more (apart from nightly builds).

That said that's my feedback, if others think those knobs doesn't fit LMMS i'm nobody to go against them obv.

[RebeccaDeField]

I wasn't intending to say that we need to leave good or stylish designs behind for the sake of usability alone, but that our design choices can be narrowed down and instructed by it. I understood there may be some pushback and it really comes down to the classic skeuomorphic debate. There is definitely some value that can be argued to keeping resemblance to physical objects, though it does also limit our designs to the past if there is room to improve based on the new capabilities of working with digital design compared to the past limitations of analog equipment.

I personally love the style of the new ones I proposed, so when it comes down to taste, differences are understandable, but my intention is again, not to cast aside style entirely.

There are many examples of this already working its way into many new designs, and I expect the same will become more and more common in existing programs. Quite honestly, I just wonder if we can improve usability beyond what is existing, should we confine ourselves to only those innovations? Inkscape offers features and UI elements that are not standard in Adobe yet, which differentiates it from a clone to a stand alone program. I don't see this breaking any standards in the way of "floppy disk as save icon" or confusing users, but I could be wrong here.

I already showed an example of how we can still leave in the center area of the knob as well, so I'm not stuck on that. There's also space to include gradients and color or more creative elements. My focus was starting with the smallest knob and then adding more details or fancy versions scaled up to match instead of trying to design something creative and struggle to scale it down. I'm also thinking given the number of different opinions we are sure to receive, something that is very easy to customize and easy to work with on many backgrounds or color schemes is a plus.

Now, if this is too soon and we want to combine some elements to scale well while still matching some older designs, I'm willing to come up with some compromises.

[RoxasKH]

Actually, i got what you meant, but yeah, imo it's a bit too soon and personally i love the analog feel.

I just don't want them to get too minimalistic
But something like this you posted, could be a good compromise: flat but still convey the knob feel well

Even if i'm still not sure how'd that fit in LMMS until i see it, let's say

[WrillicR]

I'll add my two cents on this issue. I find that the best option moving forward will be the one most consistent with the entirety of LMMS's aesthetic. Minimalism has its place within the design, but much of LMMS's current GUI revolves around a kind of simplified realism. Take any of the button designs, for example. If we were to go in the direction of extreme minimalism with the knobs, I don't think it would be as consistent with the rest of the interface as some of the alternatives.

Just to illustrate the various directions the knobs could go in and how they'd fit in our current interface, I've taken the liberty to edit a few designs inspired by the knob ideas posted here onto the Bitcrush image above.

I personally think the the two on the bottom left and the original design do not fit well in our current GUI.

[Spekular]

I'll add my two cents on this issue. I find that the best option moving forward will be the one most consistent with the entirety of LMMS's aesthetic.

This rules out the possibility of incremental improvement, which IMHO is the best bet for things to actually get done. If new features all have to be consistent above all else, we're stuck with the dated gradient buttons, narrow instrument windows, MDI system, etc.

If a more modern knob design clashes with some other UI aspect, perhaps the other element should be updated rather than restricting improvements for the sake of consistency.

[WrillicR]

I agree. Incremental improvement is the best way of working towards a specific goal, but my concern for consistency is limited to the scope of this PR.

If this PR is to be part of a process of moving toward a specific goal (like a more flat/modern theme in LMMS), we should definitely incrementally improve the knobs toward that goal; however, AFAIK the only redesign of the UI that we're working towards is the Single-Window Concept, which has little to do with this knob design PR, unless we're considering using Budislav's knob concept.

If a more modern knob design clashes with some other UI aspect, perhaps the other element should be updated rather than restricting improvements for the sake of consistency.

Perhaps redesigning the theme to be more flat is where the discussion of this PR is leading, but currently, I believe it is isolated to improving the knob design within our current theme, hence a concern for consistency.

Redesigning elements of the UI without a concern for consistency or a goal in mind may be less restrictive, but will likely make those elements stick out like a sore thumb. For example, if our entire UI were flat/modern and someone suggested making the knobs gradients, those knobs likely just wouldn't fit within the UI and wouldn't be added unless there was a unified goal of redesigning the UI to implement more realism.

[RebeccaDeField]

Thanks for the feedback everyone, I'm going to create a new version with these in mind. I understand there are a lot of strong and mixed preferences on this, so I'm going to start with usability first, what is possible to implement right now with what we have, and the feedback I have received. Considering the drastic differences of preference here, I won't be able to fulfill all of them, but I will look at the roots behind the requests and see what I can do.

As far as consistency goes, please keep in mind that the current theme was designed with many flat elements and some highlighted gradients. I didn't and won't propose something that breaks the conventions completely or clashes as an "in progress" type development, but as long as we stay within our palette and current written standards for the theme (see the artwork directory) we are pretty safe to update some elements.

[Rossmaxx]

So i read all this and i am putting in my opinion on this. Its just my opinion so if you differ, feel free.

Though i am pretty neutral with the knobs we have now, the redesign could help us move towards a flat ui (which is good afaik). But let's not be overly minimalist.
For the volume and pan knobs, just remove the vol and pan texts below the knobs. What we can do instead is making the volume knob slightly bigger than the pan knob.
This is all for now. I will add new comments as and when i get ideas

[luzpaz]

Any traction on this ?

[RoxasKH]

So i read all this and i am putting in my opinion on this. Its just my opinion so if you differ, feel free.

Though i am pretty neutral with the knobs we have now, the redesign could help us move towards a flat ui (which is good afaik). But let's not be overly minimalist. For the volume and pan knobs, just remove the vol and pan texts below the knobs. What we can do instead is making the volume knob slightly bigger than the pan knob. This is all for now. I will add new comments as and when i get ideas

I do agree on this, cause it seems to be common behaviour on other DAWS. I don't think it's even needed to get the volume knob to be bigger, as pan moves from the center while volume moves from the left, and the popup comes out when you start dragging them, they're pretty distinguishable even without the big text, which other than being kinda unaestethic, would anyway still be present in the instrument window.

That said, even if those small knobs seems not to be used anywhere else in the DAW GUI, i wanna stress that if we don't find a good compromise for small knobs, a couple of the newer plugins, #6540 and #5731, still rely on them and would either need it or have a graphical fix to move to standard dimension knobs. I guess they could also keep the old style but that would be kind of an inconsistency.

There's also small knobs in instruments like LB302 and TripleOscillators, ecc, but especially on triple oscillators they seems to be using custom knobs separated from the common knobs used generally in the daw, so i'm guessing they shouldn't be affected by the change.

[RoxasKH]

Just to add this, if we ever wanna even just temporarily modernize the knobs using the design proposed in this PR (as it's still good imo), the small knobs not looking good are easy to fix if we're willing to give up on the outline, by simply using just the center of the normal knobs.

FL has 2 approaches on this, one is removing the outline, while the other involves keeping no space between the outline and the knob, unlike we do with LMMS normal knobs. Reaper does the same, while other daws like Bitwig seems not to have such small knobs but instead bigger ones.

Leaving a mockup here where you can see them in the Stereo Control plugin.

[Rossmaxx]

@LostRobotMusic you coming back to this?