Unnecessary extra horizontal space added when adding accidentals or dots

• May 20, 2019 - 21:53
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

Adding an accidental or dot to a note increases the horizontal spacing between ALL the notes of the given measure. Horizontal space is added even if there was enough space to begin with to accommodate the accidental/dot. Other added elements might also trigger this issue, but I haven't noticed this with anything other than accidentals and dots yet. This tends to create uneven spacing throughout a score and ultimately detracts from the quality of engraving.

A workaround is adjusting layout stretch, but this is very cumbersome.

This might be related to the issue of accidentals not tucking under/over preceding notes.
#285591: Accidentals no longer tuck under/over previous notes

The attached file contains a several examples of this issue.

Attachment Size
Horizontal_spacing_issues.mscz 23.82 KB

Comments

• May 20, 2019 - 22:56
Priority ⇒ P2 - Medium

The issues are kind of related indeed. I've thought about how it might be possible to deal with this but come up empty. The way things work is we figure out the minimum space need for each note, and hence for each measure, and use that information to divide up whatever extra space after deciding how many measures can fit. What we would really need to do is have two different sets of values, one for the amount of space each note would need if it didn't have accidentals or dots, and then the amount it actually needs. When assigning the extra space, we'd decide how much space each note should get based on the value without accidental or dot, but then only actually give it the amount the exceeds the the difference between the two values.

And the difference between those values is related to the idea of accidentals tucking under - right now, we include that in the overall width of the note unconditionally (as if we were enclosing the notes in a box that wide), but really we should consider it to be just another component of its shape (so it only sticks out where it needs to). As I mention in my notes to that issue and the accompanying PR, this is actually easy and works well - except that unfortunately we don't at that time have the information we need on the stem direction and length of the previous note, so we can't really be sure if it will tuck or not. Still, if we managed two different shapes - one with the accidental & dot, one without - then we would have access to the different widths. Being able to include or exclude the fingering and articulation shapes would also be useful for various reasons.

So anyhow, I see this as doable but would require some fairly major surgery.

Meanwhile, a possible partial fix would be to allow unchecking autoplace on the accidental and dot to exclude it from the shape completely. This would allow it to tuck and also to not require extra space. Then you could uncheck it in the places where you can see that you can get away with it. Still a little bit of work, but less so than adjsuting stretch, and it's a simple switch rather than needing to eyeball just how much stretch. In my PR for the tucking issue, I included code to include it as a shape component but not to determine the total width, but what we'd need here is something different - to ignore it completely.

Even though it's not ideal, it does at least provide an easier way to get the desired result than the current method.

Reply

• May 21, 2019 - 20:44

Thank you for the prompt reply, Marc. The possible partial fix you describe would indeed be welcome as an interim solution until the issue is fixed.

I understand why this will not be a quick fix. But it will definitely be worth the wait, because getting the spacing algorithm right will be a huge jump forward towards getting out-of-the-box good quality engraving.

Reply

• Jan 15, 2020 - 18:51

Another source of spacing-inconsistency spotted... It seems that the presence of longer notes causes shorter notes in the same measure to be spaced more tightly. In measures with short notes only the spacing is wider. This happens with or without accidentals/dots/etc. Notes should be spaced consistently within a system.
pic

Attachment Size
16ths_spacing.png 7.26 KB

Reply

• Jun 2, 2020 - 23:49

The fix for #305487: Invisible accidentals take space means that for accidentals at least, you can recover the space by disabling autoplace for them. It will be up to you to make sure this doesn't result in actual collisions. But it should pretty much be the case that if there aren't, disabling autoplace will produce more "correct" spacing. Testing of that theory will be welcome. The fix will be nightlies imminently, and in the beta I assume is coming soon as well.

Reply

• Jun 10, 2020 - 19:41

I've just got around to trying this out and it does indeed produce better spacing. But the biggest benefit is that it allows easy tucking of accidentals! :D One can disable autoplace for all accidentals, and then selectively enable them where there are collisions (BTW I see "=" doesn't toggle autoplace anymore by default, so I defined the shortcut in preferences). There are of course still spacing issues, but its all been detailed in the other thread.

Reply

• Jun 10, 2020 - 19:50

Thanks for confirming! So yes, an improvement, but still work to be done.

But "=" should still work, we didn't (knowingly) change that. Are you sure you didn't have shortcuts left over from an older development build? Does it fix if you revert to factory settings? If not, what OS, and what keyboard layout?

Reply

• Sep 1, 2020 - 18:28

Interesting idea! You can, a bit indirectly. First, select all accidentals (right-click one, Select / All Similar Elements) and disable autoplace. Then, select just the accidentals on the first beat (right-click one, Select / More / Same beat) and re-enable autoplace.

Reply

Fix version
4.0.0