System distance unequal when system heights differ
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.5868, revision: 38f81d1
See attached score. various adjustments have been made to fit as much music and lyrics on the page as possible. But there is an obvious problem: too much space under the first system. (Note: There is a hidden vocal staff at the top of the first system.)
| Attachment | Size |
|---|---|
| system_distance_issue.mscz | 33.39 KB |
Fix version
3.1.0
Comments
I think there is indeed a problem in calculating the system distance. And it's not just the first system. In my score, the first 2 systems have 2 hidden staves, and they have lots more space underneath than the 3rd system with just 1 hidden staff. Adjusting "Min. system distance" seems to affect the first 2 systems here, but not the 3rd.
Adjusting both Min. and Max system distance could make it look better. But since these settings are affecting ALL the pages, adjustment is limited.
OS: macOS 10.13.6, MuseScore version 3.0.4.21117, revision: cda4080
Actually, while the spacing is indeed odd in the original score, I don't think the problem is what it appears to be at first. The extra space is not "forced" to be there, it's a matter of the extra space due to "max system distance" for some reason all going there. Reduce the max to 5sp and you will see the space go away. Furthermore, the uneven spacing isn't even due to the invisible staff, at least not directly - it's just a matter of this system being shorter than the others, I think. Try turning "Hide empty staves" off but then adding some fixed spacer to close the gaps between the staves down to nothing, and you'll find the exact same unequal spacing.
So, what seems to be happening is that after applying the min system distance and fitting the appropriate number of systems on the page, the algorithm that then looks at the max system distance and tries to distribute it among the systems is doing something you may wish it didn't - it is aiming for each system to take the same amount of space on the page, perhaps in an effort to help them line up from page to page. Probably there exist some situations where that might be desirable, but I agree it looks bad on this score. Worth bringing up in the forum to see if a consensus develops on the tradeoffs here.
Workaround is to use spacers where desired to even out the spacing. BTW, for some reason a staff spacer down is not working on this score, but it does on others in current development (master aka 3.1) builds. Not sure why.
I reported this problem in https://musescore.org/en/node/287990 because I wan't sure there was a bug report already. Page 4 of that score shows the problem of unequal spacing between systems. On the 2, 3, & 4th systems, the top and bottom staves are visible in the systems and there is nothing that would add the extra space between systems 1 & 2.
I agree with Marc's assessment that the max distance is being applied to the first system break and the min system distance to the others.
I had looked at this enough to be pretty sure we are indeed doing this on purpose. Assuming we agree it's not a good idea, I don't think it would be hard to change.
Doing this is a terrible idea, it should be fixed.
Werner made this change explicitly here: https://github.com/musescore/MuseScore/commit/b4eef5d4d3dd2b7f911cc27e6…
As per his comment in the source, the goal was to produce "most equally spaced systems" - so with, say, three systems on each page, you can more reliably count on the second system being at the same vertical position on each page even if the actual heights of the systems vary due to hidden staves, autoplace, etc.
In MuseScore 2, whatever space we had leftover to use in filling page, we allocated equally to all of the system gaps. The result is, all gaps are the same size. In MuseScore 3, we allocate space proportionally, with the shorter systems getting more space. The result, all distances end up being the same size (measured from top staff of one system to the top of the next), or at least as close to that goal as we can get before using up all the leftover space.
I can see the value of the MuseScore 3 approach sometimes but not always. I could envision this being controlled by an option, but for now, I'm experimenting with a different approach: a "bicameral" one with both fixed and proportional components. That is, some of the available space I distribute equally to the gaps as in 2.3.2, the rest I use to pad the shorter systems as in 3.0. The idea being to avoid the worst of the inequalities in gap sizes while also avoiding the worst of the inequalities in the system distances. Not sure I'll come up with something that works well enough in general to be worth submitting as a PR, but there's no harm in trying.
Meh, I only liked the results when I set it to favor the equal gaps to the point where it wasn't even worth doing the two passes. So, I have submitted a PR essentially reverting the change that led to the current behavior:
https://github.com/musescore/MuseScore/pull/4949
Acknowledging that there may be situations where the current behavior really is desirable, I left the code in place (with my modifications to allow control over how much of the space we allocate to each component of the algorithm) but disabled the portion that was making the gaps unequal in an effort to make the overall distances consistent. I would still support bringing it back with appropriate style option(s) to control the behavior, if someone wanted to do that.
Fixed in branch master, commit 00c872e645
fix #285467: unequal system distances
Fixed in branch master, commit 29cb896614
_Merge pull request #4949 from MarcSabatella/285467-system-distance
fix #285467: unequal system distances_
So it turns out this code aiming to equalize system distances was doing something useful, along with the counter-productive things it was doing. The useful thing was equalizing the distance between systems whose basic height was the same. So, if a page consists only of systems with exactly two staves, it's not a bad thing that the distance between them all is the same even if they have uneven skylines. The problem really only has to do with cases where heights of the systems differ - some systems having one staff, others two, or some three, others four, etc.
It turns out the code that responsible for this is also what enabled system spacers to work as expected, where they didn't start adding space until you actually reached the top line of the next system. Same with notes or other markings far below the staff. My fixing the issue in this thread for 3.1 has caused this aspect of spacing (spacers and markings far below the staff) to seem less predictable, and I want to see if I can get the old behavior back in terms of how spacers and markings far below the staff work, without returning us to part of the 3.0.5 we don't like.
I'm commenting here to help me sort out my thoughts while I work on a solution, and see if anyone else has noticed anything they'd like to let know about.
See #289693: [Regression] Spacers start adding space between systems too soon. I now believe that the original purpose of the code that was producing this effect (the unequal distance distances in this thread) was never intended to do so. That is, instead of equalizing the distance from top of one system to top of the next even though their heights may be different, the intent was simply to equalize the distance from bottom of one system to top of the next. Thus keeping equal spacing where possible for systems of the same height. And all that I should have needed to do to achieve this was subtract the system height in a couple of key places during those calculations. Well, better late than never.
Automatically closed -- issue fixed for 2 weeks with no activity.