Two Grace Notes Disable Vertical Chord Alignment (Maximum Shift Above)

• Jul 17, 2020 - 05:14
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

In a score, set Style > Chord Symbols > Maximum Shift Above to 7.

On a note that is numerous ledger lines above the staff that has a chord symbol, add two grace notes.

Observe that the chord symbol starts to ignore any sort of placement rules and collides with the note.

Attachment Size
Malaligned Chord.mscz 7.86 KB
MuseScore Bugs.png 27.73 KB

Comments

• Jul 17, 2020 - 19:36

I am 90% sure this will turn out to have the same root cause as #307946: Chord Symbols > Maximum Shift Above is weird if measure has rhythm slashes and rests. We know selecting a rest will force a chord symbol to be laid out all by itself, without triggering the alignment code (or, for that matter, a whole lot of other things). I think we'll discover the grace note beaming code does the same thing. The problem isn't with the alignment code, or for that matter with he rest selection code or grace note beaming code. It's that laying out a chord symbol all by itself changes its position. We had things structured so this wouldn't happen - a special subset of the layout code that could be called without it resetting position, but a change to a different chord-symbol-jumping issue seems to have broken that.

Reply

• Jul 28, 2020 - 09:19
Status PR created ⇒ fixed

Fixed in branch 3.x, commit 084770c4cd

_Fix #307946 Fix #307945 - Strange behavior with chord alignment.

Harmony::calculateBoundingRect() no longer sets the new position of the Harmony but returns it.
Harmony::layout1() ignores the the position while Harmony::layout() will use to set the position of the
Harmony._

Reply

Fix version
3.5.0