Pattern names difficult to read

[musikBear]

Difference between notes and letters are not sufficient, if they overlap -Maby more dark in the letters? (mouse over tooltips still shows 'open in piano-roll')

[tresf]

Reproduced.

[michaelgregorius]

A solution to that problem was proposed in this comment:

At that time @musikBear preferred a mouse over as the solution.

[musikBear]

@michaelgregorius It is better with a shadowed box 👍 , but mouse-over-tooltip would still be a good addition, also because the current 'message' is self-explanatory, i believe its something most would do intuitively. Right-click also opens context options.
Tooltip is 'free' to use (imo

[RebeccaDeField]

I am concerned with how that overlay obscures a lot of the track. I did a bit of research and it might be worth noting that I couldn't find any major DAWs that don't have a space dedicated to the pattern names without any overlap.

A couple examples:

My 2 cents

[musikBear]

@RebeccaDeField You are 100% on target !
I looks ugly with the text-box overlay
I think the whole issue is real-estate. LMMS has narrow tracks, compared to the above examples. The real issue is where the notes overlap the names, that issue does not exists in 2. image, and 1. 'simply' has a dedicated name-space over the blocks.
This issue has two sides:

1. user should be able to read block-names, even where there are lots of notes

2. User need to be able to read full block-name, even in very short blocks

3. is addressed with real-estate over the block, so name and notes never overlab

4. is achieved with mouse-over
   Imo, LMMS needs both.

( Later a search method for a named block, (drop-down) would be super)

[michaelgregorius]

I have experimented a bit and this is what I have come up with so far:

This screenshot shows some patterns at the default minimum height of 32 pixels.

The first two patterns have names that are different from the instrument name which is why they are rendered in the first place. The first one shows the rendering of a muted pattern while the second one shows a pattern that's not muted. I have decided to elide the text in the middle because I assume that people might user names like for example "Pattern 1" and "Pattern 2" and that way it's still possible to distinguish between such patterns as can be seen in the screenshot.

The current implementation renders a black transparent rectangle beneath the text (RGB(0, 0, 0, 64)). This way it will hopefully also work with different colors.

And this is how it looks with a bigger height and zoom factor where no elision is needed:

In my opinion the default height and width of the tracks should be bigger anyway. Rendering everything so small and confined makes it feel like a software with an inferior complex to me. 😉

[tresf]

In my experience with text contrast white text with a black stoke does the trick 99.9% of the time.

That said, @michaelgregorius, the proposal looks very nice.

[Umcaruje]

why don't we just reserve some space in the pattern where the text will go, and just change the note drawing routine to draw underneath that space?

[michaelgregorius]

@Umcaruje This would be another option which would look similar to @RebeccaDeField first example (which I think is FL Studio). However, for that to work we'd really have to increase the default height of tracks because otherwise you'd see almost nothing of the notes (see my first screenshot). This in turn would imply that we need to fix the rendering of the beats and basslines patterns at increased heights.

So the proposed option is the simplest for now.

On a side note: it might be a good idea to make the resize option for the tracks a bit more obvious, e.g. by changing the cursor at the bottom of tracks to an up/down arrow which can be used to change the height of the track. Currently this functionality is very hidden. On the other hand I have just noticed that the changed track heights are not saved anyway.

[Umcaruje]

On the other hand I have just noticed that the changed track heights are not saved anyway.

Not to mention that the elements don't center themselves when the track height is changed. It's a pretty broken feature

This would be another option which would look similar to @RebeccaDeField's first example (which I think is FL Studio).

Oh and also my proposal would look very similar to the 2nd option, which is Bitwig 🙂

[RebeccaDeField]

The Bitwig and FL screenshots are essentially the same concepts, only FL uses a lighter gradient in the same space set aside for the text. I think both of those proposals would need to have the default height of tracks increased to really work.

So the proposed option is the simplest for now.

If we are looking for a temporary solution, I might decrease the height of the overlay and text to make it more compact.

[Spekular]

I think that in order to be flexible with vertical real estate it should be possible to show/hide names, or maybe even show above/show inside/hide. The first system that comes to my mind would be a global setting somewhere (Song Editor toolbar?) with individual track overrides and the ability to show/hide one single pattern name with hover. On Jul 3, 2017 05:11, "Rebecca DeField" <notifications@github.com> wrote: The Bitwig and FL screenshots are essentially the same concepts, only FL uses a lighter gradient in the same space set aside for the text. I think both of those proposals would need to have the default height of tracks increased to really work. So the proposed option is the simplest for now. If we are looking for a temporary solution, I might decrease the height of the overlay and text to make it more compact. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIgVmlwSaG_aY_Hows-RhMj-taT9g-IOks5sKE3fgaJpZM4OKmCL> .

[musikBear]

If we are looking for a temporary solution, I might decrease the height of the overlay and text to make it more compact.

That would make it worse. The important thing is reading named tracks. For hide resp show, i would actually think that it would be better to hide the notes and not the names
Currently a user can only identify a block-segment by the 'bar-code' made up of lines of notes, and letters used as names
It is obvious to me, that it would be far superior to have both readable names (looks like bitWig has that, FLs is imo way to tiny) tooltip and color-options.
@michaelgregorius wider proposal gives the necessary space for much better readability. That looks good!
No-ones mentions tool-tip, that is needed for small blocks

[RebeccaDeField]

@musikBear To clarify, I was talking about making @michaelgregorius's proposed overlay slightly more compact because even FL uses a smaller font and we have to be mindful of real-estate. The font could be bigger than what we have now, but let's not go too far. 👍

[tresf]

I think that in order to be flexible with vertical real estate it should be possible to show/hide names, or maybe even show above/show inside/hide.

I really don't like adding more configuration options to the software, especially something so trivial. If people don't want names on the patterns, they shouldn't name the patterns.

The important thing is reading named tracks.

I agree. The name of the segment is often more important than the thumbnail of it. The proposed text size looks reasonable and sane.

I was talking about making @michaelgregorius's proposed overlay slightly more compact because even FL uses a smaller font

This is a good point. The more text we can fit in small segments the more useful. @michaelgregorius can you do a mockup with a slightly smaller font? :)

[tresf]

And credit where credit is due... the proposal does fix the bug. (proper 72dpi examples all on modern theme should be used for side-by-side)

[michaelgregorius]

Here are some renderings at different font sizes. First image is rendered with a point size of 5:

Point size 6:

Point size 7:

In my opinion it starts to become usable with a point size of 6.

I also would not add it to the configuration but we might consider to expose the pattern font in the CSS at a later point.

[RebeccaDeField]

In my opinion it starts to become usable with a point size of 6.

@michaelgregorius I agree with you. I would be curious to know what size we are currently using.

You could probably also get away with increasing the alpha value in the overlay to 75 for a bit more contrast. 👍

[musikBear]

Me, the sight impaired 'bat' i am, can only read the Point size 7, but a css option would completely shut me up :)

[RebeccaDeField]

@musikBear Yes, a 6pt font is pretty small. I would think that is the very minimum. Knowing what size we are using now would give us a much better idea on which size to choose. :)

[michaelgregorius]

@RebeccaDeField The current size is 8 points if that makes the decision easier. :)

It's also the size that's shown in the first experimental screenshots from two days ago. Currently the font size of the pattern is bigger than the size used to display the instrument's name which seems a bit off to me anyway.

[michaelgregorius]

@RebeccaDeField Here's how it looks with a background of RGBA(0, 0, 0, 75) by the way:

The notes are still distinguishable from the text so I'd say we get away with this. :)

[musikBear]

@michaelgregorius I like the wide one 👍

[RebeccaDeField]

Currently the font size of the pattern is bigger than the size used to display the instrument's name which seems a bit off to me anyway.

From what I can tell, changing the font size of the pattern to 7 will also match the instrument name size.

[musikBear]

Looking at picture from comment #3674 (comment)
I think it would better the set the instrument.name font up to the size of the block-labels.
But i would, wouldent I.. 🙈 🦇 :mole .. me

[michaelgregorius]

I have now changed it so that the font properties are taken from the style sheets. The font sizes of the instrument names are defined in pixels (11px) therefore I have set the font size for the patterns to 11px as well. Both style sheets (classic and default) have been adjusted.

The pull request is #3691.

[michaelgregorius]

Closed via #3691.