Staff spacer up pushes staff away at a distance
This is a very longstanding issue, that I believe has always been present in MuseScore 2. The issue is simple:
While the staff spacer down only starts to push away a staff below when it is extended until it reaches that staff, the staff spacer up immediately adds a lot of space while still much shorter than the distance between the staves.
The problem is beautifully demonstrated in two scores attached to https://musescore.org/en/node/99661:
https://musescore.org/sites/musescore.org/files/99661.mscz (staff spacer down, correct)
https://musescore.org/sites/musescore.org/files/Example_17.mscz (staff spacer up, incorrect)
I suggest playing with the staff spacer up in the second score to get a sense of how this bug works.
Hopefully fixing this would not present a major compatibility problem.
Comments
This does work as expected between systems (i.e. the top staff of one system to the bottom staff of th system above, but not from a staff to the staff above, here the extra distance it obeys seems to be the staff distance (gradually change that to 0 to see the effect)
Yes, the extra distance is the staff distance, and I believe this is currently by design: the spacer is defined to take into consideration the space allocated below the upper staff. Eg, either the staff distance or system distance specified in the style settings, although I think in the latter case it depends somehow on both the min & max). If we changed the behavior of the spacer up to not take that existing space into consideration, scores depending on the current behavior would break, so this type of change could only be made at a time when we are planning on making incompatible changes (and hopefully adding code to automatically adjust older scores).
My sense is that the way this works is going to change anyhow probably incompatibly so - if/when Werner's new layout code goes into effect, so this could perhaps be revisited then.
If it's by design, then why does the staff spacer down behave in what I would say is a more expected fashion?
I don't have a good answer, since I didn't implement these originally. But I have done some work on them, so I understand a little about them. Think of staff distance as being like an invisible cushion that is added *below* the staff - so it's part of the underside of the staff. This isn't totally accurate - there is more to the story than this - but it's basically why the spacers work differently. The staff spacer up bumps into that invisible cushion. It would presumably have been possibly to acocunt for that and make it work more like the staff spacer down, but for whatever reason, it wasn't.
BTW, I set the stauts to "needs info" not because the current situation isn't clear, but because I don't know if there are plans to change this as part of the new layout. It could just as easily be set to "by design "postponed", I guess, or "by design" if that's really how it will stay. I think that's not really my call. But it doesn't make sense to me to leave it on "active" since it *isn't* really a bug currently as far as I know.
I've hardly even heard rumors about a new layout system at an unknown stage of development. Is this the sort of thing that gets discussed on IRC? I'm really interested to know what's in the works.
It's mentioned on IRC some, yes. So far I have only seen screenshots; I haven't tried the code yet. But there is a branch for it on GitHub ("newlayout").
Closed due to inability to reproduce. Please report, with precise steps to reproduce, in a new thread if this still troubles you in the latest version (3.4.2).
FWIW, this one I remember fixing around 3.1.
Like #289693: [Regression] Spacers start adding space between systems too soon I guess?
Actually I think #283365: Staff spacer up need to "invade" the top line of the upper staff in order to start inserting space
Which was in 3.1beta already