[notation issue] clef getting vertical displacement after changing number of staff lines

[Vykoiazon]

Describe the bug the clef does not stay in the middle of the staff anymore if the number of staff lines changes (so y coordinate needs to be manually corrected)

To Reproduce

1. add a clef
2. change the number of staff lines
3. see the start of the next page

Expected behavior the clef should appear to stay in the middle of the staff (even if the removed lines were from the bottom of the 5 line staff)

Screenshots

Platform information windows

[oktophonie]

It looks like MuseScore starts from the position of the top line of a 5-line stave (y=0), and then proceeds downwards until we have as many lines as specified: Time signatures are centered, rests are moved to hang from the middle line (rounding up), brackets and barlines are adjusted to match the height of the stave, etc.

Percussion clefs (and TAB) evidently have special handling to also centre on the stave: But treble/bass clefs do not, and I'd argue that it doesn't really make sense to do so, because what do they even mean on a non-5-line stave?

We could change this so that staves instead grow out from the middle line by default, but I worry about what other systems this might upset, since all the geometry works on the basis of this. Nevertheless, if a stave changes number of lines mid-system it would make sense for them to remain 'vertically centered', i.e. going from 5 lines to 1 would look like this:

I'd propose achieving this by adding a y-offset to the stave properties, i.e. this one-line staff would have an offset of 2sp (or 4 scale steps). Any items that are to be centered on the stave (barlines, brackets, time signatures) should also follow this offset.

(We should also address the discrepancy between the full-height bracket/barline on a 1-line stave compared with those of a 2/3/4-line stave which match the stave height. Obviously we can't match the height of a 1-line stave, as they would disappear, but we must be able to specify a minimum height for barlines, brackets and braces in sp.)

[Vykoiazon]

In musescore 3, changing number of staff lines also affected the multibar rest number placement to be too far up or down.

[oktophonie]

Indeed so. The relevant seting (Style > Rests > Vertical position of number) measures from the top stave line, and when we go down to one stave line it continues to do so, not taking into account the height of the H-bar:

A quick fix would be to measure from the top of the stave, or the top of the whole H-bar (including the vertical strokes), whichever is higher:

[Fonixary]

Not just using rests. I want to use this single-line output to my chord harmonica lines with hybrid rythm and single note notation. Waiting for update! I just checked the old issue ticket that said this problem found in 2015 from 1.x to 2.0 version. I can't use baritone clef and that's STILL INCORRECT centering, mention to the "flat", very funny position.

[MarcSabatella]

The workaround meanwhile is to use a staff type change from the Layout palette, which then allows you to set a "Step offset" that effectively defines which line of the standard the current line(s) should apply to. A step offset of -4 does the job here. It's given in line rather than sp units because it affects playback too, and rhythmic slash notation - it's really changing the logical line used, not just vertical offset. Note there is a separate "offset" setting that handles the position of the line itself, to create examples like the one shown previously where the staff changes from 5 to 1 lines mid-system and remains centered.

While this stuff is pretty well baked into the internals, a better design could certainly be created to simplify how it is presented to the user.

And however it is presented, these settings should obviously be included in staff/part properties too and not just in the staff type change element. They are, I think, the only settings from staff type change not exposed in staff/part properties.