LMMS 1.3.0 Alpha PianoRoll Minor Graphic Adjustments

[RoxasKH]

A couple of things feel a bit off to me from a design standpoint in the Alpha build.

This is how the pianoroll looks like at the moment

In my opinion, the contrast of the gradient of the new pianoroll keyboard is way too high compared to the rest of LMMS, and this makes it feels a bit annoying and unprofessional. An analog things counts for the new implemented ghost notes. They are a bit too little visible, and on the contrary the black link at the end feels too much saturated and uncomfortable.

Something like this would probably fit better

The color adjustements aren't big, but they make the difference. Speking of the keys i kept the gradient but i reduced the contrast, instead for ghost notes, i made them a little brighter so that they stand out more and used a dark grey for the end of the note, which imo is better than the old black.

Obviously this are just suggestions based on my personal opinion, let me know what you think about it.

[he29-net]

IIRC, when Veratil made the Piano Roll refactor, he mentioned in the PR that the color of keys is more of a "placeholder" and should be replaced if needed.

Subjectively, I also felt that the contrast is too high. But I would only make the black keys lighter and keep the white keys pure white. In your mockup they seem kind of "bland" and "dirty" to me, and it would also make them more difficult to distinguish from disabled keys, which will be added in #5522 :

One more consideration for the black keys is that they should be light enough to allow a noticeable color hue to be added. I want to add a way to assign user-defined colors to the keys in a future microtuner update, to help with orientation in scales that are longer or shorter than the repeating 12-key pattern. For example, you may know that your scale in 24-EDO tuning starts at C, but is it C2 / C4 / C6 /.., or an odd-numbered C? With a color assigned to the first degree it would be clear at a glance and you would not need to even read the labels. For non-repeating scales this would be even more important as the traditional visual cues lose all meaning.

Of course, the black keys could be individually lightened when the coloring is enabled, but I fear that the variation in brightness between colorized and "plain" black keys would look weird, so it is probably better to bear this in mind from the beginning.

[RoxasKH]

IIRC, when Veratil made the Piano Roll refactor, he mentioned in the PR that the color of keys is more of a "placeholder" and should be replaced if needed.

Subjectively, I also felt that the contrast is too high. But I would only make the black keys lighter and keep the white keys pure white. In your mockup they seem kind of "bland" and "dirty" to me, and it would also make them more difficult to distinguish from disabled keys, which will be added in #5522 : One more consideration for the black keys is that they should be light enough to allow a noticeable color hue to be added. I want to add a way to assign user-defined colors to the keys in a future microtuner update, to help with orientation in scales that are longer or shorter than the repeating 12-key pattern. For example, you may know that your scale in 24-EDO tuning starts at C, but is it C2 / C4 / C6 /.., or an odd-numbered C? With a color assigned to the first degree it would be clear at a glance and you would not need to even read the labels. For non-repeating scales this would be even more important as the traditional visual cues lose all meaning.

Of course, the black keys could be individually lightened when the coloring is enabled, but I fear that the variation in brightness between colorized and "plain" black keys would look weird, so it is probably better to bear this in mind from the beginning.

I didn't know that they were supposed to be a placeholder, neither about the disabled keys, which should be easily implemented by just darkening the white keys and brightnening the black ones.

Taking inspiration from the modern professional DAWS, mostly none of them use a pure white for they're keys, because less bright color are better for the eyes, so they use a shade of grey

Reaper:

FL Studio:

Bitwig:

Logic Pro:

Studio One:

Ardour:

Cakewalk:

Cubase:

The only one i found using pure black & white flat colors was ableton, but in that specific case they fit the theme of ableton which is mostly flat.

Also consider how the gradient in most DAWs is the exact contrary of the one used in the actual LMMS pianoroll, so with darker colors on the left that become brighter moving to the left.

Also aren't images used for the pianoroll keys at the moment?

P.S: I'm sorry for the long list of examples

[he29-net]

Images were used for the keys before the refactor, now they are drawn procedurally. That's also why the colors changed in 1.3.0 alpha. Images are still used in Piano View, though (that will eventually have to change as well if coloring is to be implemented).

The examples you posted are interesting, I did not expect to see so much variety. My opinion is, of course, only a sample of one; I don't have a problem with darker white keys as long as there is enough margin for further darkening to indicate disabled / unavailable keys. From the examples, Cubase looks especially bad in that regard.

EDIT: Also, I see that the original bitmap in 1.2.x keys had the lighter side on the right, so the reversed gradient may not be intentional?

[RoxasKH]

Images were used for the keys before the refactor, now they are drawn procedurally. That's also why the colors changed in 1.3.0 alpha. Images are still used in Piano View, though (that will eventually have to change as well if coloring is to be implemented).

The examples you posted are interesting, I did not expect to see so much variety. My opinion is, of course, only a sample of one; I don't have a problem with darker white keys as long as there is enough margin for further darkening to indicate disabled / unavailable keys. From the examples, Cubase looks especially bad in that regard.

EDIT: Also, I see that the original bitmap in 1.2.x keys had the lighter side on the right, so the reversed gradient may not be intentional?

Probably? I haven't checked. I agree that cubase is waaay too grey-ish.

[he29-net]

Just a small update to my previous remarks: please ignore the part about possible coloring of the keys.

I thought some more about how it could be used, how it would work and what color schemes could be actually useful and look good in the LMMS theme at the same time, and found only a lot of problems and not many real workflow gains. I think the issue I was trying to solve could be better addressed by simply updating the note labeling code, so it does not blindly generate repeating A to F when non-12-tone tuning is used. So my only remaining concern is with the white keys possibly being too gray and not clearly distinct from disabled keys (but looking at the values again, when they are right side by side it should not be problem).

@RoxasKH Do you plan to make a PR for the change, or should I do it? I already touched the xml in question before, so it should be a quick work.

[RoxasKH]

Just a small update to my previous remarks: please ignore the part about possible coloring of the keys.

I thought some more about how it could be used, how it would work and what color schemes could be actually useful and look good in the LMMS theme at the same time, and found only a lot of problems and not many real workflow gains. I think the issue I was trying to solve could be better addressed by simply updating the note labeling code, so it does not blindly generate repeating A to F when non-12-tone tuning is used. So my only remaining concern is with the white keys possibly being too gray and not clearly distinct from disabled keys (but looking at the values again, when they are right side by side it should not be problem).

@RoxasKH Do you plan to make a PR for the change, or should I do it? I already touched the xml in question before, so it should be a quick work.

Ok, perfect. Don't know, if this is not code related and it's store in the css file or somewhere else easy to fix, i'd be glad to try make a pr, but i'm not experienced so much with prs atm. Otherwise if you think you can quickly fix it, and you know faster where to put your hands on it, i'll let you do it, as this was mostly to underline the issue.

[he29-net]

Did you work with GIT before? This would be a good first issue for learning and gaining experience. ;)

In data/themes/default/style.css and data/themes/classic/style.css search for whiteKeyInactiveBackground (around the line 197 currently). There it should be clear from the names what does what. After you make the changes you could try to test the modified theme in another LMMS build (if you don't want to build it yourself), or push the changes to a branch in your fork, open the PR and wait for the LMMS bot to provide binaries.

[RoxasKH]

Did you work with GIT before? This would be a good first issue for learning and gaining experience. ;)

In data/themes/default/style.css and data/themes/classic/style.css search for whiteKeyInactiveBackground (around the line 197 currently). There it should be clear from the names what does what. After you make the changes you could try to test the modified theme in another LMMS build (if you don't want to build it yourself), or push the changes to a branch in your fork, open the PR and wait for the LMMS bot to provide binaries.

Yeah, i knew my way around css (as i made a theme in the past), so i easily made the changes, changing the gradient and increasing from 50 to 60 the ghost notes opacity.

Now i have a couple of questions, tho. I still have no idea on how to change the last little line of the ghost notes (the one for resizing) or if it's possible (i can't seem to find it in the css style file). Also, should i make the gradient of the keys the opposite? This should be discussed.

Other than that, i have zero experience with git and prs, but if there's any guide to follow to fork LMMS, change the files and pull a PR, i have no problem doing it (hoping i don't got something wrong).

[RoxasKH]

Uh, also, resizing the pianoroll window, is really buggy graphically speaking about keys for me.

[he29-net]

I still have no idea on how to change the last little line of the ghost notes (the one for resizing)

I think it's simply the ghostNoteColor, it is just completely opaque unlike the rest of the ghost note.

The black-key gradient was in the opposite direction before, so it should be no problem reversing it? You could always do a mockup and let some people vote if needed. Or it can be fine-tuned in the PR if someone has a problem with that.

I don't know if we have a detailed PR guide, you could ask for help on Discord (or google a bit). You are unlikely to break anything since your PR will be reviewed by another dev before merge.

[RoxasKH]

I still have no idea on how to change the last little line of the ghost notes (the one for resizing)

I think it's simply the ghostNoteColor, it is just completely opaque unlike the rest of the ghost note.

The black-key gradient was in the opposite direction before, so it should be no problem reversing it? You could always do a mockup and let some people vote if needed. Or it can be fine-tuned in the PR if someone has a problem with that.

I don't know if we have a detailed PR guide, you could ask for help on Discord (or google a bit). You are unlikely to break anything since your PR will be reviewed by another dev before merge.

Ok, i reversed the keys gradient (because in the actual stable is reversed) and thanks to your suggestions i fixed ghost notes, too

Now i'm preparing a PR

There's still the resizing problem, but that's more code related, so i'm gonna make a separate issue.

[RoxasKH]

Closing because solved by #5953