![]() There it should be clear from the names what does what. In data/themes/default/style.css and data/themes/classic/style.css search for whiteKeyInactiveBackground (around the line 197 currently). ![]() 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.ĭid you work with GIT before? This would be a good first issue for learning and gaining experience. 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. 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 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. 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. 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. Just a small update to my previous remarks: please ignore the part about possible coloring of the keys. P.S: I'm sorry for the long list of examples 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.Īlso 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.Īlso aren't images used for the pianoroll keys at the moment? 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 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. ![]() 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. For non-repeating scales this would be even more important as the traditional visual cues lose all meaning. 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. 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. One more consideration for the black keys is that they should be light enough to allow a noticeable color hue to be added. 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 : But I would only make the black keys lighter and keep the white keys pure white. Subjectively, I also felt that the contrast is too high. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |