Piano Roll Grid Contrast

[tresf]

I'm trying to adjust to the new theme and find it particularly hard to locate quarter notes. This may be a matter of an old dog trying to learn a new trick, but I continuously find myself misjudging where to place notes.

At a glance, the major difference seems to be the grid contrast on the background. Is anyone else experiencing this same problem? If this is an overwhelming "no", we can close this out as invalid.

Old	New

[Umcaruje]

@tresf the problem is in the horizontal lines, not the vertical ones

[tresf]

@tresf the problem is in the horizontal lines, not the vertical ones

Sorry, my advise was rubbish you beat me to it. This logic is confusing though. Where're the horizontal lines being drawn? We just need to make that later in the monster 👹 paint event.

[Umcaruje]

@tresf when the white keys are being drawn, we also have the grid drawing in the same for loop. Now, here we need seperate for loops for everything, as you read we need the lines to intersect properly. So we need a loop for 16th, then normal horizontal lines, then beat lines, then accented horizontal lines and then bar lines at the end.

https://github.com/LMMS/lmms/blob/master/src/gui/editors/PianoRoll.cpp#L2692-L2704 is where the horizontal line rendering's at

[tresf]

If bright lines are to always to be drawn above darker lines, they shouldn't be in the same draw routine then.

Furthermore, the draw routines are misleading because efficiencies were made to reuse the key loop to also draw the horizontal grid and it makes the code extremely confusing to contribute to.

For example... the loop is improperly commented "draw all white keys". This is entirely wrong as the black keys are draw inside the same loop as well as the horizontal lines. Ideally, the section would be renamed "draw horizontal items" and each draw routine should be farmed off into a sub-function for clarity.

Anyway... the quick fix would be to write any bright lines lower in the code in a separate loop as you've identified. Another alternative would be to draw a bunch of small line segments vertically that don't ever overlap the horizontal lines (would still need a similar "horizontal line position" type loop, so the CPU overhead would be about the same as a single additional loop).

Regardless, you're trying to fix a single bulb in a string of old used Christmas lights so you have to decide what's worth your time.

[tresf]

Another option is to use one loop to place the lines into a stack for calculation purposes and then use a separate loop to draw them onto the screen for display purposes. The underlying problem is the code was written to efficiently utilize the horizontal key positions to do everything inside the grid. This is great conceptually until we want layering and then this catch-22 happens.

[vlad0337187]

" are to always to be drawn above darker lines" - this would make impossible quick changing of colors (to search for better result, or to tweak the theme).

I think that better would to draw lines according to their appointment.

[tresf]

this would make impossible quick changing of colors (to search for better result, or to tweak the theme).

Please do not take words out of context. "Bright colors" chromatically is different than "bright colors" functionally. I'm talking about the code reference, not anything specific to color.

[vlad0337187]

@tresf , ok, I didn't knew. Such interesting system =)

[Umcaruje]

(the lines on notes are from GIF compression, not actually happening)

Some progress, snatched the loop from the automation editor so it renders lines based on quantization level.

It gets crazy at 1/192 Q though:

[musikBear]

(the lines on notes are from GIF compression, not actually happening)

LOL when i saw that i spontaneously went WOW! It looked sooo sexy :dancer: Guess they would look like that, if the grid was drawn after the notes was drawn!

Love the shading! -And with that no bar-lines are needed at all! The difference in shade denotes bars. I just hope that shades are not an efficiency slap. Maby the shades should be a tad more different, though. But it very difficult to see difference between beat and ticks-lines.

It gets crazy at 1/192 Q though:

I cant see any lines at all, but i also do not have a flatscreen, just a tube-monitor, on that there is nothing -neither horizontal or vertical at all.

[Umcaruje]

Some progress, vertical lines are all in seperate loops now, though the horizontal lines are giving me a very hard time as they are offsetted when put in a seperate loop...

[tresf]

@Umcaruje does resetting key_line_y = keyAreaBottom() - 1; before the loop fix it?