Staff miscentered vertically when set to 1 line musescore 2.0
1. Create new score in musescore 2.0 RC (I'm testing on windows revision c68b108).
2. Right click on staff, click properties, and change number of lines from 5 to 1.
The clef if displayed is misaligned vertically, and seems centered on where bottom line of staff would have been. If set show barline at start of single staff, then the barline at start of staff appears centered on where the line above the center staff would have been. If I make a new time signature (in example 3/4) for next measure, it is centered on where bottom line of staff would have been (just like the clefs position). I know clefs don't make sense for a single line staffs, but the expected behavior when making pitchless charts is that all staff elements be centered vertically along the single line.
(I was curious what it thinks the pitch single line corresponds to if I make a note B in the example, it is appears two lines below the single lined staff, so it seems musescore is internally treating that single line as the top F line in treble).
If I decide to then revert back to 5 lines, I see barlines are now extended above and below the staff by two lines. Expected behavior after reverting back to 5 lines would be that barlines begin on top line and end on bottom line.
| Attachment | Size |
|---|---|
| test_staff_misaligned_one-line.png | 9.5 KB |
| test_misaligned_single-line-staff.mscz | 6.78 KB |
| test_staff_misaligned_revert-back-to-5-lines.png | 12.26 KB |
Comments
Update: When I look at the file after uploading to musescore.com, I see time signatures are now correctly aligned (so maybe this was fixed in another release). However, the barline at start of staff is still misaligned.
(Also I was going to suggest the single line should default as center B line of treble. If I create rhtyhm only charts, I would naturally start by writing rhythms on center B line, and would expect that center B line to remain the single line when switch to 1-line staff.)
Some of these glitches fix themselves on reload - the time signature one, for example. But the clef apparently does not. I think somewhere in the coee we must be assuming that one-line staves are only for percussion, so the percussion clef is the only one that places itself correctly (and it's only available if it is in fact a drum staff).
So, setting this up as a drum staff is one workaround. The fact that it is expected that these be drum staves is also why the one line is internally treated as the top line - so any custom drum set definitions you make can work logically, where "0" always means the top staff regarldess of it there are 1, 3, 5, or 13 lines.
aha. Understood. Using drum staves is a workaround for rhythmic chord symbol charts. (I retract my suggestion of setting middle line as B, as that would probably mess with the custom drum set definitions.)
I'm confirming that time signature alignment glitch seems to fix itself upon reload (I'm now using nightly windows). Although if then add new time signatures after reload, the newly added time signatures are still misaligned.
But I'm also confirming that when I create a new score starting with only percussion and a single line and edit page style to have barline at start of staff, that that first barline is still misaligned vertically. Also as before when I revert to 5 lines, all bar lines are now extended above and below the staff by two lines.
See also #53686: mismatch between 1.x and 2.0 when reducing staff to 1-line. Auto-centering of clef and key signatures seems like a good idea to me.
Fix for the time signature issue is here: https://github.com/musescore/MuseScore/pull/1934
The barline issue seems harder. Not just the initial barline has an issue. try this:
1) create score, snare drum + bass drum
Result: most barlines span -4 to 4 - two spaces above and below the staff line - which is fine, but initial barline appears about 1sp higher (both the top and bottom of the initial barline are too high).
3) save
4) reload
Result: most barlines are now about 1sp shorter than they were before; span is now -2 to 4. Initial barline is still too high. Maybe by that same amount, for a related reason?
The fact that the barline span changes on reload is due to this sanity check:
https://github.com/musescore/MuseScore/blob/master/libmscore/scorefile…
Here we are arbitrarily resetting the "from" to -2, not sure why. Maybe a confusion between the interpretation of the value: a *line* value of -4 equates to a *sp* value is -2. Maybe we are using the wrong units here? Not sure what we are really trying to accomplish here.
EDIT: MIN_BARLINE_SPAN_FROMTO is used when editing the barline, to prevent you from extending barlines to far above/below staff, and it *is* supposed to be just 1sp above/below the staff according to the code here:
https://github.com/musescore/MuseScore/blob/master/libmscore/barline.cp…
So I think the sanity check in scorefile maybe just needs to make an exception for 1-line staves, which are explicitly allowed (and default) to extend 2sp above/below.
Layout of the initial barline I still don't understand, but since I'm now 2/3 of the way there on this issue, I guess I'll keep looking.
Here's another interesting couple of symptom, caused by a similar problems eslewhere:
1) new score for snare drum & drum set (in that order)
2) extend barline through the staves
Result: top of barline shortens - instead of spanning from 2sp above snare drum staff, it is now even with staff
3) click a barline
Result: the barline shortens at the bottom - instead of spanning to bottom of drum set staff, it stops half way down the staff.
These are other places where we are not calculating the min/max spans correctly. My PR also includes fixes for these, but I am listing the steps to reproduce the problem for reference.
All my fixes thus far are merged.
Remaining is the issue with the system initial barline, which is still offset 1sp if the top staff of a system is a 1-line staff. See also #53856: 2.0 First barline offset when using "staff spacer up" icon if top stave hidden, which might turn out to be related. Or at least, involve the same piece of code that lays out the system initial barline.
Indeed, same root cause for both bugs, same fix applies:
https://github.com/musescore/MuseScore/pull/1937
This PR fixes the remaining issues I have seen in handling of 1-line staves, so I will consider this issue closed if/when this PR is merged. There is still #53686: mismatch between 1.x and 2.0 when reducing staff to 1-line, which at this point is just about the difference betwene 1.3 and 2.0 in the interpretation of what the one line actually is (1.3 treated it as middle line, 2.0 as top line). So scores imported from 1.3 that used 1-line pitched staves may still see differences. But the (known) issues due to mishandling fo the 1-line staff in general are all fixed at this point.
PR merged for 2.0 branch and master.
Automatically closed -- issue fixed for 2 weeks with no activity.