Nonstandard (possibly insufficient number or incorrect placement of) augmentation dots for certain chords
GIT commit: 3c7a69d
It appears that Musescore sometimes omits the augmentation dot for a specific note within a multi-note chord (a four-note chord in the example screenshot), placing only three of the dots. It's possible that the fourth augmentation dot is placed by MuseScore in the same position as the dot for another note and is therefore not visible as an separate marking, or that MuseScore is using a different notation standard or set of rules.
Some notation standards or rules suggest moving one or more augmentation dots up or down to an adjacent space to accommodate the same number of dots as are present in a chord. Of course, if two or more voices are notated on the same staff at the same position in time, and both voices include chords with augmentation dots, and both voices are very close to each other in their vertical alignment, it may not be possible to adequately display the full number of augmentation dots required or suggested by the chords.
Compare chords and augmentation dots of first and second measures of screenshot "augmentation-dot-anomaly2.png. Score attached; anomaly exemplified at measures 76-77.
Thank you.
Example PNG screenshot attached.
| Attachment | Size |
|---|---|
| augmentation-dot-anomaly.png | 39.81 KB |
| Abstract_1.mscz | 46.85 KB |
Comments
Can you also attache a sample score?
Compare chords with augmentation dots it first measure of attached screenshot with the chords and dots in the subsequent measure of same score (second measure in attached screenshot).
(First comment of discussion edited to include this information and the additional screenshot, as well as the requested .mscz file)
Sample score attached (I apologize for the oversight). The anomaly is easiest to find in the last grand staff of the piano score, measures 76-80, and it is measures 76-77 that were captured for the screenshots of previous comments.
Thank you.
(Edit: First comment of discussion has been edited to include an attached .mscz score file from which the sample screenshots were extracted.)
It's not a bug.
Open Inspector (F8) - > select eg measures 76 to 79 -> clic on "Notes" (Select) at the bottom Inspector panel -> Dot position ("Note" section): clic on "Bottom" (instead the Auto default)
Result: 1Abstract_1.mscz
And welcome aboard :)
Well, it should work with automatic, if it does not, it is a bug. You just found a workaround, in my opinion
.
Indeed, our algorithm is kind of simplistic and while it handles a lot of cases well, it isn't that hard to fool it.
Well, it's a feature/possibility in Inspector, right? So, where is the bug?
In measure 4 (that was the first place I saw this) the E defaults (auto) to the dot position bottom while the C defaults to dot position top. This isn't a bug? Both notes are in the same voice, same stem direction and both on lines. Why do we expect them to have different dot positions?
Thank you to cadiz1, mike320, Jojo-Schmitz and of course Marc Sabatella for your comments and workaround.
In looking more closely at the score (the .mscz file attached to the original post), I have noticed perhaps 6-7 other cases of augmented notes in which the dots seem to be placed a little unusually, or overlaying another dot. I've corrected all of these individual cases using the Inspector (thank you, cadiz1 for the suggestion).
Thank you Marc and the developers for such a wonderful application and community.
The rule we follow is something like this: notes on spaces get dots in the space, lines get their dots above the line for voice 1, below for voice 2. But we also check to see if the next/previous note in the chord would conflict, and if so, we adjust. So we can handle *some* cases where the simple rule would result in conflict. But if the adjustment we make causes *another* conflcit, we don't detect that. And indeed, the rules for how to handle complex chords could get messy pretty quick.
Looking at the specific case of measure 4 from Abstract_1.mscz, we put the A and F dots in the corresponding space. For the E, we first think about putting it above as we normally would, but we see that would conflict with the F, so instead we put it below. This would absolutely be the right thing to do if it weren't for the C. What we *should* do is then check again to see if there are further conflicts, and then keep adjusting until there are none.
To my mind, this is somewhere between a bug and a feature request - it's a place where our automatic collision avoidance doesn't go far enough. So it's doing what it is deigned to - not a bug exactly - but the design could clearly be improved.
So the algorithm is working from the bottom up one note at a time. When it looks at the C it thinks that since the next note is an E there can be no conflict. Then it looks at the E and thinks it will conflict with the F and places it below to avoid that conflict without regard to where the C put it's dot. I understand now.
If I'm correct in this the simple fix is to work from the top of the chord down since the default is to put the dot above. It will then only have collisions when there is an ugly chord with notes sharing lines and/or spaces.
Isn't this a duplicate of #45576: Tie on same side of staff/ledger line as augmentation dot = collision?
In reply to Isn't this a duplicate of … by Jojo-Schmitz
I think this is different. It is a collision between augmentation dots in a chord rather than augmentation dots with something else like a tie or slur. Here is another example (Using 3.5 RC) with a collision between dots on notes in different voices leading to the "loss" of a dot.
3 years ago I explained why most of these dots are on top of each other and the fix should be rather straight forward, start calculating the dots on the top note rather than the bottom note in voice 1 (probably with some minor changes to the code inside the loop) and you won't get collisions. This seems a cheap fix to improve engraving capabilities. For voice 2 I think you should continue to calculate from the bottom up unless I'm missing something.
There is a workaround if you manually place the dots in the inspector.
@SteveBlower , I think the website ate your attachments due to problems the day you uploaded them.
In reply to 3 years ago I explained why… by mike320
I re-added the eaten attachments.
Came up again in #329619: Bad heuristics for augmentation dots in chords with consecutive seconds
In reply to Came up again in #329619:… by Jojo-Schmitz
Relates to #311175: [EPIC] Engraving issues and suggestions