Spacing for center-aligned chords not honored until second layout
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MS 3.2.3.
- Open the attached score.
- Select the second chord symbol and change the Horizontal align to Center (for example).
- Now perform another action in the score.
Result: There is an unexpected system re-layout. But this should have occured automatically after step 2.
| Attachment | Size |
|---|---|
| chord_symbol_alignment.mscz | 5.37 KB |
Fix version
3.5.0
Comments
Deleted.
The score does not re-layout either if chord symbols are copied:
Result: The chord symbols are pasted as expected but overlap the barlines. The user has to force a re-layout of the system to correct it.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.3.0.8605, revision: c94866a
IMV, critical because layout changes are lost when you save and reopen the score.
Result: The corrected layout is lost.
I can confirm these layout glitches. But to be clear: no information is lost, it's just a layout glitch where something that doesn't appear entirely correct at first. All information is present, it just takes an extra layout before it takes effect.
The issue is that the partial layout done in layout1() does not account for alignment, nor is accounted for in ChorRest::shape() where we figure the spacing. So only after the first full layout do we get a good bbox. The trick will be fixing that without breaking something else involving chord symbol spacing / layout.
There appears to be a workaround which re-lays out the whole score at once: Go to Style > Chord symbols, change "Maximum barline distance", then return it to the starting value. The changes, however, are lost when the score is closed.
Yes, I seem to encountering this.
I had been scratching my head after publishing/saving a score, convinced that I had made manual adjustments.
A fix would be ideal ASAP (in my opinion), as it represents a false premise for the score.
Is solved as side effect of https://github.com/musescore/MuseScore/pull/5876 which is meant a solution of #293785: Chord symbols jump when user goes into edit mode and #302590: Inconsistent alignment of chord name above fretboard.
Fixed in branch master, commit 9946fb7c42
_Fix #293785: Fix #302590: Fix #294890 Chord symbols jump when user goes into edit mode
This commit resolves two issues:
Fix #302590 - Inconsistent alignment of chord name above fretboard
Fix #293785 - Chord symbols jump when user goes into edit mode
Fix #294890 - Spacing for center-aligned chords not honored until second layout
When looking into #293785 it was found that placement of Harmonies above a FretDiagram
was not consistent.
o) Align::HCENTER aligns the horizontal centers of bot Harmony and FretDiagram.
o) Align::RIGHT aligns the right edge of the Harmony roughly to the centrer of the FretDiagram.
o) Align::LEFT aligns the left edge of the Harmony to the left edge of the FretDiagram.
So every alignment uses it own reference. This has been corrected first.
The root cause of #302590 was the difference of bounding box between NORMAL and EDIT mode.
And this was caused because of the different formating between NORMAL and EDIT. In EDIT mode
the horizontal alignment was using both different algorithm and reference. Also the height
of the bounding box where different in EDIT and NORMAL mode
To solve this the bounding box while in EDIT mode
1) is aligned exactly are in NORMAL mode
2) has the same height in both EDIT and NORMAL mode._
Fixed in branch master, commit 9946fb7c42
_Fix #293785: Fix #302590: Fix #294890 Chord symbols jump when user goes into edit mode
This commit resolves two issues:
Fix #302590 - Inconsistent alignment of chord name above fretboard
Fix #293785 - Chord symbols jump when user goes into edit mode
Fix #294890 - Spacing for center-aligned chords not honored until second layout
When looking into #293785 it was found that placement of Harmonies above a FretDiagram
was not consistent.
o) Align::HCENTER aligns the horizontal centers of bot Harmony and FretDiagram.
o) Align::RIGHT aligns the right edge of the Harmony roughly to the centrer of the FretDiagram.
o) Align::LEFT aligns the left edge of the Harmony to the left edge of the FretDiagram.
So every alignment uses it own reference. This has been corrected first.
The root cause of #302590 was the difference of bounding box between NORMAL and EDIT mode.
And this was caused because of the different formating between NORMAL and EDIT. In EDIT mode
the horizontal alignment was using both different algorithm and reference. Also the height
of the bounding box where different in EDIT and NORMAL mode
To solve this the bounding box while in EDIT mode
1) is aligned exactly are in NORMAL mode
2) has the same height in both EDIT and NORMAL mode._
Fixed in branch master, commit 45fd0fae63
_Merge pull request #5876 from njvdberg/issue-293785-jumping-harmonies
Fix #293785: Fix #302590: Fix #294890: Chord symbols jump when user goes into edit…_
Automatically closed -- issue fixed for 2 weeks with no activity.