Inconsistent/uneven horizontal spacing

• Dec 11, 2019 - 08:01

Hello, ... so MuseScore "stretches" a measure a little bit when adding an accidental or dot (and perhaps other elements?) to a note, resulting in increased space between ALL the notes of that measure, even if there was already enough space to begin with to accomodate the added element. This creates ugly inconsistent/uneven horizontal spacing throughout entire scores that requires lots of careful manual editing to sort out.

See the bug report here:
https://musescore.org/en/node/289446

It has been noted that fixing the issue where accidentals no longer tuck under/over previous notes will probably have the fortunate side effect of fixing the spacing issue also.

see here:
https://github.com/musescore/MuseScore/pull/4784#issuecomment-541352797
https://musescore.org/en/node/285591

Can you please fix this? This spacing issue is a huge obstacle to getting out-of-the-box good default layout.

A picture speaks a thousand words...

pic

pic

Attachment Size
horizontal_spacing_issue.png 26.83 KB
real_world_example_1.PNG 64.23 KB

Comments

• Dec 11, 2019 - 16:09

There are a few different things going on here, and also a few misunderstandings.

First, I didn't mean to suggest that the issue of overlapping accidentals between voices in itself fixed other spacing issues. What I had said at one time is that the particular workaround I had implemented for this - allowing you to disable autoplace for an accidental to allow it to tuck under another voice - would also work to prevent an accidental from adding space unnecessarily. So it would still be a manual process.

And that would not affect your top example at all - the space for those accidentals is necessary. Only cases where a measure was already stretched enough to not need extra space for an accidental, my change would allow you to disable autoplace for an accidental and thus not require extra space. Trying that on your top example would result in the accidentals overlapping the preceding notes, because there is not in fact enough room for them otherwise, as the other measures on the line demonstrate.

I'm still not convinced what we do in the top example is wrong, necessarily. Interesting discussion going on in in the Music Engraving Tips group on Facebook now, it seems everyone has wildly different ideas about what should happen there.

Also, manual adjustments should not be required - or advisable - to make changes to this spacing. Instead, it's just a stretch issue. In your top example, a tap or two of "{" on the measures you are perceiving as too wide, ot "}" on the ones you perceive as too narrow evens out the spacing. It's really the right way to address the perceived problem, because the effect you are seeing is a stretch issue, The spacing within the measure is consistent as it should be already, the only problem is we are making some measures wider than they actually need to be relative to others once we get around to stretching them to fill the system.

Reply

• Dec 11, 2019 - 17:53

Thank you for the clarifications regarding accidental-tucking, Marc.

I disagree with most of what you say about the top-example (the one with only the treble clefs). Just look at the manually fixed version. All the 8th notes are near perfectly equally spaced and there are no collisions/overlap between accidentals and preceding notes, proving that they don't need extra space in this case.

I'm very convinced that the way MuseScore does this is wrong. My post on Music Engraving tips was to invite other Musescorers to chime in here if they also felt this is a problem. I actually do adjust stretch with "{" and "}" to fix problematic measures this way. I consider this a manual edit, because its something I have to do after MuseScore has finished its default layout.

Reply

• Dec 11, 2019 - 19:06

You misunderstand what I am saying about the top example. The space for the accidentals themselves is absolutely necessary, in that if there were no accidentals, each measure would only be as wide as the first, and there is not room for the accidental there. So space needed to be added for the accidental. The only debate is over whether space should have been added elsewhere in the measure. MuseScore does so not out of any specific attempt to force the spacing to be equal (I misstated that on MET) but more as a by-product of how the stretching works. Which is why reducing the stretch fixes it.

And yes, reducing a stretch is a form of manual adjustment. I just wanted to be sure you weren't laboriously fiddling with leading space or offsets on a note-by-note basis, because that shouldn't be needed.

Reply

• Dec 13, 2019 - 02:13

I have to agree with you, necessary spaces (which means without them the accidentals will overlap something) are necessary but those unnecessary are just unnecessary. Additional spaces don't help at all in both the cases where 1) there's no accidentals at all; 2) the accidentals fit in already provided spaces.

Reply

• Dec 13, 2019 - 05:22

There's some very interesting discussion of the topic in Music Engraving Tips on Facebook.

It seems one way or another, we need to calculate and record some additional information about each measure when first collecting it - some way of representing a "nominal" minimum width for the measure, the width it would require if not for the accidentals. Or, conversely, the amount of space required by the accidentals.

In principle, the nominal width doesn't require any complex layout calculations, it's a direct function of the number of notes and their values. After all, it isn't even just about accidentals, but also things like dots, seconds, arpeggios, falls, etc.

If we had that information, then during the stretch phase, we could compare the nominal minimum width against the actual minimum width that we currently calculate (this does account for accidentals etc). Each measure's share of the extra space to be distributed (ExtraSpace as per the MET discussion; "rest" is the actual variable holding this value in Score::collectSystem() where the stretching happens) would be reduced according to the difference between actual and nominal minimum widths.

At least, I think that would be one way forward.

Reply

Do you still have an unanswered question? Please log in first to post your question.