Also we need to think of future native, lv2 and other effect plugins for LMMS, so a native "midi note send" plugin might be the way to go that will send midi notes to the next FX plugin in the FX chain. 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).Yes I'm thinking this feature will be useful for plugins such as Gsnap auto-tune and many more vst effect plugins out there. Also, should i make the gradient of the keys the opposite? This should be discussed. 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). 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. 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. 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 |