Chord symbol alignment incorrectly forces alignment between above & below chords and across staves

• Jun 15, 2020 - 00:19
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project
MuseScore

The chord symbol alignment feature should serve to align chords above or below a single staff/system. Unfortunately it makes no distinction between above/below placement. This means you cannot have align both chord symbols and RNA on the same staff, as the feature will force everything above or everything below. Worse, it also works across all staves, so a chord that is displaced above one staff will force chords on other staves higher.

To reproduce the first aspect:

1) score for one instrument
2) enter chord symbols and RNA
3) increase the maximum shift above to 2

Result: chord symbols are flipped below (if you use maximum shift below, the RNA is flipped above). Example chord-align-placement demonstrates this.

To reproduce the second aspect:

1) score for two instruments
2) increase maximum shift above to 10
3) enter chord symbols on both staves
4) enter a note far above one staff

Result: the chord symbols on the other staff are affected as well.

Examples attached.

Attachment Size
chord-align-placement.mscz 2.73 KB
chord-align-staff.mscz 3.94 KB

Comments

• Jun 15, 2020 - 12:30
Reported version 3.4 ⇒ 3.x-dev

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.12238, revision: a3e23d6

Bug confirmed in this build (Shift above/below is a new feature in Style > Chord symbols).

Reply

• Jun 15, 2020 - 18:35

Algorithm now collects chord symbols, fret diagrams and RNA symbols per staff and will run the algorithm per staff. Also, placement above and below were handled as separated cases but they used the same variable for finding the highest symbol, regardless whether it was placed above or below the staff. Now dedicated variables are used.

Reply

• Jun 16, 2020 - 08:03

If that setting really is (intended) for lyrics only, it is at the wrong spot (and at least one user, plus myself, already stumbled over that).
If not, but just currently used only for lyrics, this change here is where it might (or should) get used too

Reply

• Jun 16, 2020 - 16:16

The alignment setting originally applied only to lyrics because those were the only things we aligned. Now we also align pedal lines and maybe some others. It is worth considering whether this option should be honored for all alignable types.

Reply

• Jun 21, 2020 - 12:13
Status PR created ⇒ fixed

Fixed in branch 3.x, commit 9f9d404598

_Fix #306750 - Chord symbol alignment incorrectly forces alignment between above & below chords and across staves
Fix #306751 - Chord symbol alignment changes default position without reason

Resolves https://musescore.org/en/node/306750
Resolves https://musescore.org/en/node/306751

Extended the algorithm so it aligns chord symbols, fret diagrams or RNA symbols per staff
by collecting the symbols per staff and run the alignment for every staff. When looking
for the reference for the alignment, the algorithm now handles placement above and below
the staff as two different cases. This solves #306750.

Removed an extra offset which was not required anymore but was a left-over of an earlier
version of the algorithm. This solves #306751._

Reply

• Jun 29, 2020 - 20:24

A potential issue depending on how one organizes things: use of alternate chord symbols. We allow users to attach multiple chord symbols to the same segment/track, and this is most often used to provide substitute harmonization. Sometimes people do this and just rely on autoplace to move the substitute chord symbols above the main ones. Or, they may use the "Chord Symbol (Alternate)" text style which does this for them. EIther way, results can be rather unpredictable and surprising when using the alignment option. It actually works OK if you don't give too large an offset. Otherwise, those alternate chord symbols will force everything up to their level.

Not sure what makes sense here. One possibility would be to simply ignore the alternate chord symbols. That could be done explicitly looking at the text style, or just ignoring all but the first chord symbol found for a given segment/track/place (have to consider placement, so we get the separate alignment of chord symbols and RNA at least).

Ideally unchecking autoplace from the alternates would do the trick but currently does not.

Reply

• Jul 1, 2020 - 19:24

it will be difficult to recognize alternate chord symbols, since the use the the "Chord Symbol (Alternate)" text style is not mandatory. And as a matter of fact, any text style can be used so using a text style for recognition can be tricky.

Using the lowest (if placement is "Above") or highest (if placement is "Below") placed chord symbol for alignment and maintain the same offset for the other chord symbols might be a more solid solution.

Reply

• Jul 10, 2020 - 10:29

PR #6321 is an enhancement of the alignment algorithm. It can handle multiple chord symbols/fretboard at one segment, it ignores invisible elements as a reference for alignment (although invisible elements will be aligned).
Also elements without autoplace will be ignored.
Chord symbols moved by the user are not used as a reference for alignment but will be moved if the segment contains a chord symbol which has to be aligned. In this case the user moved chord symbol will be moved too but remain the relative position with respect to the reference element. User moved fretboards will always be ignored since fretboards don't have a styled offset.

Reply

Fix version
3.5.0