Beats and Basslines patterns look off when the height of their track is increased

[michaelgregorius]

Beats and Basslines patterns look off when their height is increased via shift click drag:

Because the implementation is based on images which become pixelated when being resized I propose to always render the steps at the top so that they always align with the left hand side:

The fix that you can see in the image above also places the steps more in the middle of the track compared to the current implementation which looks like this:

[BaraMGB]

But increasing the height of bb tracks is obsolete at all.

[michaelgregorius]

@BaraMGB What do you mean exactly? Currently it's possible to increase the height of Beats and Basslines tracks in stable-1.2 and in master. Is there a pull request that will prevent the resizing of B&B tracks in one of these?

In #3674 it was discussed that it might make sense to increase the default height of tracks to make them look less minuscule. Of course we might consider to keep the beats and bassline tracks at their current height. On the other hand, with regards to the problems reported for HDPI displays it might make sense to render the Beats and Basslines tracks in a different manner where they adjust to different sizes dynamically.

[RebeccaDeField]

If we are going to increase the height of the tracks in the song editor, I can see why we might want to keep the sizes consistent throughout the program. Regardless of whether or not we want to increase the height, the way that we are currently rendering the patterns with pixmaps is not ideal for horizontal scaling either.

[michaelgregorius]

@RebeccaLaVie I have experimented with using SVGs as the image source for the beats and basslines buttons. This is the result of a rather quick attempt (recorded at 10 frames per second for a smaller video size, please click on the image to see it in full size and better quality):

The buttons for that prototype are obviously developer art. :) It would be great if you could provide me with nicer looking SVGs that would replace step_btn_off.png, step_btn_off_light.png, step_btn_on_0.png and step_btn_on_200.png in the theme directories. I have created these buttons in Inkscape with a page size of 24x24 pixels.

Here's a still image for completeness:

[michaelgregorius]

The nice thing about using SVG images is that elements can still be customized for themes while still being rendered in great quality at different sizes.

Rendering in code would make everything scalable to different sizes while sacrificing customization. Rendering with pixmaps as is done now keeps customization but does not scale to bigger sizes nicely. So using SVGs would offer the best of both worlds.

[RebeccaDeField]

@michaelgregorius :clap: :clap: :clap:

Here is the .svg for the design we are currently using, but this might need to be simplified depending on how small we want to allow users to scale the window.

I believe I remember @liushuyu mentioning that there were problems with how Qt renders .svg files so it may be important to get their input on this.

[michaelgregorius]

@RebeccaLaVie Thanks for the file! It only contains one image though. I guess this image contains all groups that are needed to compose the four different aforementioned images. However, I have no idea which ones these exactly are. Can you provide me with four SVGs that correspond to step_btn_off.png, step_btn_off_light.png, step_btn_on_0.png and step_btn_on_200.png so that I can directly replace my developer SVGs?

Then we could also quickly check if there are some differences between the SVGs rendered by Qt and the PNGs.

[michaelgregorius]

I found out that the first group contains three of the elements and this is what I have got now (please click on the image for the original size):

Buttons that are on are currently rendered without taking the velocity into consideration because both "on" images are the same.

[RebeccaDeField]

@michaelgregorius The file is organized in layers. Here is a new version of the file that includes the 0 velocity step. I also updated the names for each layer to correlate with the names of the pixmaps.

[michaelgregorius]

@RebeccaLaVie Thanks for the new file! I am already using it in my local branch.

However, I have noticed that I need to change the way the resizing works because with my current implementation the steps would not align when different sizes for the tracks are used. I assume that this is something the users want to get an immediate overview of how the beats relate to each other.

[RebeccaDeField]

Related #2636

[RebeccaDeField]

With my current implementation the steps would not align when different sizes for the tracks are used.

If the steps scale in X and Y freely without a locked ratio, I believe it will fix your alignment problem.

(Very rough mockup of my idea above)

The downside to this is that the design will look stretched/squished depending on how the window is sized whether we use raster images or .svg graphics. I already want to simplify the step designs which will help, but not entirely solve that issue.

[michaelgregorius]

@RebeccaLaVie I have also thought about implementing it like this and will give do a test implementation. Depending on how the user scales the tracks and sizes the window the buttons might indeed look stretched and squished but if we use SVGs they will always be rendered without any artefacts and in good quality. Also if we implement it like this it is up to the user how he wants it to look.

[Spekular]

Using several differently aligned svgs/pngs would give maximum customization and perfectly scaleable tiles at the cost of complexity. Could be as simple as "corner, border, center" (assuming we can rotate the images) or as complex as "top left corner, top border, top right corner, ...".

EDIT: It seems these are called 9-Patches, at least on Android, although those are one image with regions marked rather than several, the conceptis the same. I'm assuming the svg standard doesn't support this though.

Unless I'm mistaken there's no way to do that with a single image, so the border will get thicker/thinner as the tile changes size, on both x and y axes independently.

Alternatively drawing the tiles in code should be able to fix that problem at the cost of flexibility. Allowing different border and fill colors as well as maybe border thickness via CSS isn't that restrictive though, imo.

Apologies if this is all obvious or late to the conversation.

[michaelgregorius]

I have revisited this oldie. :sweat_smile:

Should be fixed with #7175.

Here's a pattern with the changes of #7175 (click images to view in full size):

Here's how the same pattern looks without the changes, i.e. in master: