[MU3] improve horizontal spacing & vertical alignment +collect_artifacts #6312

MarcSabatella · 2020-07-08T17:42:44Z

This is a trial implementation of a spacing improvement that seems likely to be good.

Further explanation to follow...

MarcSabatella · 2020-07-08T17:50:44Z

The problem I am trying to solve here is that notes on one staff have an undue effect on the spacing of notes on another staff. As an extreme example, consider this:

The B's in the bottom staff are creating huge gaps between the D's in the top staff, and vice versa. That is because we are forcing the segments to be spaced by the width of a notehead + the minimum note distance style setting. That's just not needed. There is no place within those passages where adjacent segments contain adjacent notes, and even if they did, only minimum note distance would be relevant, not notehead width (because the latter would already be accounted for in the basic segment minimum distance calculation).

So, by removing the notehead width component of this calculation completely, and also tightening things up so minimum note distance only kicks in where there are adjacent segments with notes in the same voice, we get this:

Seems obviously a lot better. The question will be if it has some major drawbacks somewhere else, which I guess wouldn't surprise me. But it's definitely worth further investigation!

Jojo-Schmitz · 2020-07-09T08:40:34Z

I presume those rather large and numerous vtest differences are intended/expexted?

MarcSabatella · 2020-07-09T15:51:57Z

Well, I definitely expect differences, since I am changing layout. But I haven't gone through them one by one to see what is going on exactly. We'd of course need to do that before we could consider merging this.

The main expected effect of this is to reduce the amount of space required in passages where there are different rhythms on different staves (actually even on a single staff with multiple voices, which may or may not be a good thing, but could be changed if we decide it isn't).

In practice, this means many measures in scores with multiple staves will need less space overall. This will sometimes allow more measures on a system, but will also for sure change the relative widths of measures within a system. So for example, I see one test with two measures, one empty, the other has stuff. The original had the difference in widths between the two measures greater than with my change. That's because the measure with stuff no longer needs to be as wide as it did. This sort of thing will play out all over the place. The overall effect is that both measure widths and overall spacing will become more even.

Jojo-Schmitz · 2020-07-09T15:55:14Z

So this may result in 'implicit' system breaks at different places, right? That in turn may screw up layouts of existing scores quite badly.

MarcSabatella · 2020-07-09T15:56:14Z

BTW, relevant to the discussions about how much to bite off for 3.6: these sorts of changes are obviously unacceptable to impose on for existing scores by default. But on the other hand, since the change is completely self-contained, it's easy to provide either spacing according to a style setting. My sense is there might be a few other quick wins like this that could be collected under a single "Engraver Spacing" (I think what's what Finale called a similar improvement a number of years back) style setting. But most likely, to fix some of the more fundamental layout issues, we might need to consider just throwing out the old algorithms and accepting that again there would be differences from MuseScore 3 to 4 just as there were from 2 to 3. Nothing nearly as dramatic, though.

MarcSabatella · 2020-07-09T18:30:38Z

Yes, this can change where breaks are. In no cases should it ever result in fewer measures fitting per system, but it wouldn't be hard to come up with cases where more might.

That is the main reason why I say this would have to be turned off for existing scores if it were to be considered for 3.6 or any 3.x release. Making this behavior optional, controlled by a style setting that is off for existing scores but perhaps forced on for new ones would be the best way I can see. Really, we could even leave it off by default for new scores. Or have a program preference to control how the option defaults in new score. Or have this be a checkbox in the New Score Wizard.

This is the sort of thing I was thinking about when I mentioned recently we could really use a good strategy for handling this kind of issue in general. It came up for chord symbol playback, and I saw it possibly coming again regarding changing the default font. This would be another example.

Jojo-Schmitz · 2021-09-02T14:50:28Z

libmscore/segment.cpp

+                  // in the same voice
+                  //w = qMax(w, score()->noteHeadWidth()) + score()->styleP(Sid::minNoteDistance);
+                  if (isAdjacent)
+                        w = w + score()->styleP(Sid::minNoteDistance);


Where exactly would we need to check for an older version and enable compatibility?

I have no idea at this point. I don't know that there is a clearly laid out plan for this, but there should be, as it's likely to come up any number of other places we might want to improve default spacing for new scores without adversely affecting older ones. We waited way too long to sort that out for 3.6 with the new style defaults, hence the cascade of bugs during the last couple of weeks before and after release.

I'd really like to include it in #9000, but am not sure about its implications and whether and how to make sure to not screw up pre 3.6.3 layouts