Simplify the way notes are drawn in piano roll

[unfa]

I love all the new features in LMMS, but one visual change is a major drawback in my opinion.

The notes look overly fat, clumsy and needlessly complicated. None DAW I have worked in has ever draw notes this complicated - it makes reading the piano roll harder.

1. I think that rounded corners are a bad idea - they needlessly make it harder to see where the note starts and ends;
2. I don't see the point of having this white marker ant the end of note - I can clearly tell where it ends just by the rectangle;
3. The notes are vertically ovelapping on the grid by 1 pixel - I prefer to make them thinner by 2 pixels, so there's 1 pixel of blank space between them (the grid line fits there nicely) which makes the piano roll look cleaner and tighter.

A mockup:

[Spekular]

• Agree, dislike rounded corners
• Disagree, I think of it as a handle for resizing
• Unsure.

I edited your mockup to include every combination, although the ones I added use a different style for the handles. I think the small space between the handle and outline looks odd, but full white with larger handles is an eyesore. Personally I think the last one is best.

[midi-pascal]

:+1: For the Totally flat + "resize" mark for its readability (big plus for my eyes)

[BaraMGB]

Totally flat + resize mark +1

[tresf]

Related https://github.com/LMMS/lmms/pull/1507

[Umcaruje]

One concern I have with removing the borders is that the notes with lower velocity would become invisible, here's a picture from #2285:

As you see, the border color was made constant so notes would always be recognisable regardless of the velocity.

[Spekular]

@Umcaruje One alternative could be an outline that is the same color as the base fill, but I'm not sure that's a good idea. We could also change the way velocity is represented to use other colors or something, but that's a bit drastic.

[midi-pascal]

@Umcaruje You have a good point there. What if the darkest color was less dark so it was always visible (along with its resize mark)?

[mikobuntu]

@Umcaruje I believe the OP is referring to removing the actual drag points to the right side of the bars and only reducing the size of the container to fit between the grid lines, not removing them entirely. In my opinion I still like the curved edges, but agree on scaling down the border.

[unfa]

@Spekular I really like the tottaly flat viariant, but for readability of notes that are low in velocity, I'd vote for outline + endmark.

[Umcaruje]

Ok then, I'll assign myself for this task, unless someone beats me to implementing it.

[musikBear]

It was changed from simple to rounded-and-bulky as late as Dec 2014 #1507 I dislike rounded notes for readability reasons, especially in screenshots, but i think it was a common opinion, that since fls rounded their notes, lmms should too.. Outline is definitively needed for the reason @Umcaruje points out.

[zapashcanon]

What about something like:

if note.velocity < x then 
    border.color = minColor
else
    border.color = background.color

With minColor set to the background color of a note with a velocity equals to x. And x the velocity under which notes become hard to see.

[musikBear]

@Sancho-Panza unnecessary overhead in draw, imo kis(s) design will always be my favourite, and a depend clause in drawing is an overhead.

[tresf]

unnecessary overhead in draw, imo

Hmmm.. not sure I agree.

The CPU cycles are cheap and it addresses both use-cases (accommodates flat themes without sacrificing visibility on low-velocity notes). I like the idea, personally. :)

[zapashcanon]

The main problem imo, it's that it may not be clear. I mean, having notes with borders and some without, it may be confusing. Otherwise, I agree with tresf.

But, personally, I don't think very low velocity is a much used thing, but it's only based on my own use, so idk how it's for other users. But if I'm right, the first point shouldn't be a problem then.

[Umcaruje]

Here's how tottaly flat notes with endlines look like. It was just a matter of tuning the gradient. If you think the lowest velocity notes should be even more lighter, let me know

[midi-pascal]

:+1:

[BaraMGB]

Why the velocity bars are still green?

[Spekular]

:+1:

[musikBear]

:+1:

[Umcaruje]

Should I get rid of the rounded rectangles altogether? Otherwise I'll need to implement a clipping rectangle for the endmark, so it also gets rounded. By removing the rounded rectrangle, I can disable the antialiasing and just use regular rectrangles instread of rounded ones.

[midi-pascal]

Rounded corners look bad on small rectangles anyway. My opinion :smile:

[Spekular]

I personally dislike the rounded edges as well, but I'm sure there are people who like them. What is the downside to setting a corner radius of 0 to remove the round edges?

[Umcaruje]

What is the downside to setting a corner radius of 0 to remove the round edges?

Well, the problem is that the endmark is now drawn at the full height, so when notes are rounded, the endmark needs to get rounded accordingly. Now, Qt, as far as I can tell, can't set a rounded rectangle as a clipping mask, so I'm not sure how I could solve that problem

[Spekular]

@Umcaruje in that case it sounds like it won't be fully themeable either way, so I guess it makes more sense to have fully sharp edges.

[musikBear]

fully sharp edges

:+1: clearly visually better readable

[Umcaruje]

Ok, well here's a major dealbreaker for the flat notes: you can't tell if you have overlapping notes, they get completely merged together (until you select one of them).

If you guys think that this is fine, I could do a PR right now, or I can bring back the borders.

[Spekular]

This actually makes a good case for not only outlines, but rounded outlines. With flat and outline notes you still can't tell what's on top of what.

To be fair, overlapping notes don't make sense in real life. There's probably usecases for overlap though. Say, letting a sample play a specific length but at a shorter interval.

[Umcaruje]

To be fair, overlapping notes don't make sense in real life.

Yes, overlapping notes is a bad design and we shouldn't allow them, but I don't have time or skill to fix that.

[tresf]

Ok, well here's a major dealbreaker for the flat notes: you can't tell if you have overlapping notes, they get completely merged together (until you select one of them).

Then satisfy everyone's wishes: 1. Remove round edges. 2. Keeping the borders 3. Leaving the borders themable.

[midi-pascal]

@tresf :+1:

[musikBear]

1. Remove round edges. 2. Keeping the borders 3. Leaving the borders themable.

:+1:

[Umcaruje]

Leaving the borders themable.

Can you please elaborate? You want to make the border width themeable?

[tresf]

Can you please elaborate? You want to make the border width themeable?

I was only commenting in regards to color, so that a flat theme could eliminate them -- albeit confusing -- as needed.

[IvanMaldonado]

I really don't get this post, the notes LMMS already has look really fine and they are already as described, with the exception of the note ending indicator.

[tresf]

@IvanMaldonado can you explain? Did you achieve this using pure CSS? If so, please post it so that we can close the issue out.

Is that space invaders?

[IvanMaldonado]

Yes it is, the style.css file allows you to change the border radio but what it doesn't allow is to change the border's colour of the note, just the note's and the border gets adjusted to the note's colour.

Yeah, I tried to draw pacman but it was way too hard. :-1:

[softrabbit]

To be fair, overlapping notes don't make sense in real life. There's probably usecases for overlap though. Say, letting a sample play a specific length but at a shorter interval.

I'd lean towards leaving them. There are physical instruments (e.g. guitar) that are capable of playing the same note simultaneously on more than one string, why should LMMS be more limited?

[DestyNova]

Yes, overlapping notes is a bad design and we shouldn't allow them, but I don't have time or skill to fix that.

Whoa, let's not do that. Overlapping notes is a totally legit thing to do if there is an interesting ADSR envelope. Plenty of piano pieces use repeated notes with the sustain pedal held down. It produces a very different and darker effect that would be lost if the first note had to terminate before the second started. What would help though is some way of indicating overlap in the UI in cases where it's not currently obvious (e.g. when a note of the same or shorter duration is completely hidden behind another note - this often happens by accident when editing).

[musikBear]

Whoa, let's not do that.

Absolutely agree :+1:

some way of indicating overlap

Could the shortest note always be drawn in the highest 'layer', then no note could be hidden

[Spekular]

Could the shortest note always be drawn in the highest 'layer', then no note could be hidden

Sounds like a decent start, but four quarter notes could still hide a whole note, for example.

Regarding overlapping notes, it would still be possible to play several notes at once without them, by using several instrument tracks. Ghost notes and track groups could eventually bring back a similar level of convenience.

[Umcaruje]

Ok, I think I have a solution for the problem: by drawing the notes semi-transparent, we can easily distinguish overlapping notes:

---

On the side of making the border width themeable, the only way I see of implementing it would be a Boolean like we have for the TCO's, because of the different drawing sizes that you get when drawing with no border/border (width and height get changed for a pixel). In my opinion that is an overkill and I would suggest we just decide if we want borderless notes or not.

[musikBear]

need to to see this 'live'. I am a little bit scared of the almost invisible tick-marks/ lines, and the low contrast of the now transparent notes, but if i have understood the design-process, these lines are CSS-controlable, so @Umcaruje :+1: for your transparency solution. One Q, though. Does note alpha matters for CPU usage? Eg, Does it stress the CPU more Drawing transparent notes?

[Umcaruje]

One Q, though. Does note alpha matters for CPU usage? Eg, Does it stress the CPU more Drawing transparent notes?

Transparency does take a bit more processing, but considering we don't redraw the notes that often, its safe to say you probably won't notice any increase in CPU performance.

[musikBear]

Transparency does take a bit more processing, but considering we don't redraw the notes that often, its safe to say you probably won't notice any increase in CPU performance.

..Ok :pray: