Accidentals no longer tuck under/over previous notes

• Mar 8, 2019 - 17:58
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

This is not a regression from 2.3.2 but it is a regression from where 3.0 was until shortly before release. This picture tells the story nicely:

segment-overlap-2.png

There is no good reason for the space between before the accidental - it could be tucked under the previous note. It would have looked this way in 2.x, but this was actually one of the first major improvements implemented for 3.0 and was indeed one of the main reasons for moving to the "shape" system instead of the old spaceLw/space/Rw system of calculating segment distances.

Unfortunately, this broke when we added support for the old spaceLw/spaceRw in the form of addHorizontalSpacing(). This was needed in order to restore correct spacing for glissandi, and it also re-fixed the space allocation for ties. But now, we need to update the spaceLw/spaceRw calculations to not include the things that are already part of the chordrest shape. I'm on it. With any luck, this will be one of those fixes where simply removing some chunks of old code will make things work better.

See also https://musescore.org/en/node/281024#comment-897040

Comments

• Mar 8, 2019 - 22:26

So close, but it's actually a bit more complicated, and I've run into a problem I don't see a good solution for. This was already a problem before https://github.com/musescore/MuseScore/commit/6e5de1926c80b3c616cfcb303…, which was when addHorizontalSpacing() was introduced, and I suspect this never actually worked.

But the approach I am taking is promising enough I went ahead and created a PR as a work in progress:

https://github.com/musescore/MuseScore/pull/4784

In the description, I discuss what works and what does not. Maybe someone else can see a solution that I don't.

Reply

• Dec 11, 2019 - 16:16

So far I still don't see a totally automatic solution, but in the PR I propose a reasonable alternative: making it so disabling autoplace on an accidental (or dot, or other symbol attached to a note) will cause it to be ignored in the note spacing calculation. This will effectively allow it to tuck under other notes, and have the side benefit of making a quick workaround for the issue that accidentals can widen measures unnecessarily (if they would already have been stretched enough to not need additional space for the accidentals). It would be up to the user tnot to disable autoplace for accidentals that do need the space, though.

Reply

• Feb 5, 2020 - 20:35

Any chance that this PR might get released? Its been quite some time since its been created. Although the solution at present isn't fully automatic, it would still make life a lot easier for those wanting to tuck accidentals.

Reply

• Mar 21, 2020 - 21:49

It seems like implementing tucking would probably neccesitate some complex changes to the code. So if such big effort is going to be made, its probably worth considering whether to also tuck anything else than accidentals. So here are a few thoughts and observations quickly thrown together...

It's probably worth tucking augmentation dots. Dorico tucks them. Here's what it looks like done in MuseScore (without tucking the 16ths would be spaced unevenly):

dots_tucking.PNG

Tucking stuff underneath note-flags/hooks. In specific crazy-tight situations this might be useful. Here's what it might look like in MuseScore:

tucking_under_flags.PNG

Dorico also tucks stuff underneath flags (and also under/above noteheads):

dorico_tucking.png

Lilypond also tucks notes underneath/over other notes:

lilypond_tucking_notes.png

However, for me its completely counterintuitive to do this. A note's horizontal position on a score corresponds to its position in time, so why would one cram two notes played one after the other into overlapping horizontal positions? I also asked about note-tucking on Music Engraving Tips some time ago and the consensus was also that its a bad thing to do:

https://www.facebook.com/groups/musicengravingtips/permalink/2196711670…

Attachment Size
tucking_under_flags.PNG 14.04 KB
dorico_tucking.png 16.53 KB
dots_tucking.PNG 7.18 KB
lilypond_tucking_notes.png 109.81 KB

Reply

• Mar 21, 2020 - 23:02

The good news is, if we can do it for accidentals, we can do it for just about anything. My tentative PR shows it's actually done pretty easily, the only problem is beamed notes and the fact that we don't know until too late what the stem direction will be. If we can solve that problem, then we should be good for accidentals, dots, and other symbols attached to notes. In principle we could even overlap notes, but I agree, bad idea. Luckily that would require a couple of other changes to make happen, so no danger of it happening by accident, really.

Reply

• Jul 2, 2020 - 19:53

I understand the reason why this couldn't be fixed yet is that stem-directions aren't known until long after accidental-layout, and the reason for that is the beam-placement algorithm? If the beaming-algorithm is going to be rewritten (I've read that is a possibility), then perhaps this presents an opportunity to also get a way to know stem directions in time for accidental-layout. Just putting the thought out there.

Reply

• Jul 2, 2020 - 20:47

One way or another, this is something we want to look at for sure. Not sure that merely changing the beam angle algorithm itself is going to change anything, though, that happens when it happens, we'd just be changing the specifics of how ther angle is chosen. The issue at hand has more to do with when we decided on stem directions. So it's a somewhat bigger picture decisionchange

Reply

• Sep 14, 2021 - 14:07

To be clear: that code starts to solve the problem and provides a proof of concept, but it isn't usable yet, as it creates worse problems (collisions) that we would need to solve first. I temporarily hacked around it by making it active only if you disable autoplace, but we need s real solution. That involve a more significant rewrite of the code determining stem direction which in turn probably requires a more significant rewrite of the beaming code.

Reply

Fix version
4.0.0