Chord symbol spacing issues

• Dec 2, 2018 - 20:48
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

We're making good progress on chord symbols, but here are some related spacing issues. Could conceivably be four separate changes need to fix, but I think it would be good to look at them together. I suspect the first is an easy fix, the second might not be fixable before release, but we'll see.

Look at the following:

chord-symbol-spacing-1-4.png

In the first measure, there is obviously way too much space allocated for the chord symbol name. I am betting that is because we are allocating the entire width of the chord symbol to the right-hand side of the note shape, even though the chord is centered. Hopefully an easy fix. Note that in the second measure, I tried left-aligning the chord symbol, and now there isn't quite enough space allocated. That's because the D is centered but the code is allocating shape for that second note with the same flaw. Left-aligning the D finally fixes it, as shown in the third measure.

That's what happens if chord symbols are attached to adjacent notes. Now let's look at what happens in the case where the notes aren't adjacent, or when there are no notes at all for one or both chords:

chord-symbol-spacing-2.png

Here, the approach of adding space to the notes fails, because we aren't checking for note collisions. In the first measure, it's because the notes aren't adjacent; in the second it is because there is no note shape at all for the second chord. So no extra space is allocated, and instead the autoplace kicks in instead, thus pushing the second chord above the first. better than nothing, I guess, but 2.x would have done the right thing, which is to space the notes to avoid the collision (it did this by doing a separate pass for chord symbol spacing as opposed to note spacing). I'm not sure these will be so easy to fix without re-implementing the two-pass approach, which I doubt actually makes sense at this point.

Comments

• Dec 3, 2018 - 14:36
Severity S3 - Major ⇒ S4 - Minor
Status fixed ⇒ active

partially fixed (first case). I would focus on the second case and postpone fixing the third one.

Reply

• Dec 3, 2018 - 16:57

I am not sure how to go about either, but at least for both of these, increasing stretch as necessary is a workaround.

BTW, my change had an interesting side effect, now long chord symbols on the first note of a measure add space before the first note - they don't overlap the barline. That's not necessarily a bad thing, but will become more of a non-issue when I change the default to left align...

Reply

• Mar 6, 2019 - 00:09

Since it has come up a couple of times lately, and I was just looking at this section of code for something else, I'm thinking about this again.
Turns out that adding to the chordrest shape is already handling collisions both between non-adjacent segments ("second case"), which I am pretty sure it wasn't when that code was added originally. I think maybe this change for lyrics caused it to start working: https://github.com/musescore/MuseScore/commit/54eab63a7f6027b183d987efe….

The one thing we're still not catching is segments with no chordrests ("third case"). But, if we add the chord symbol to the segment shape, this suddenly starts working too! This is easily done by deleting the line excluding harmony objects from being added in Segment::createShapes().

There are some glitches I'm seeing as the layout of harmony elements is still very fragile, happening as it does in different places at different times. Especially when using jazz style, where the raw bbox is very different from the formatted one. So we can't make the one-line change and call it done. But if someone wanted to work on this, it's probably not too far from working already.

BTW, this could also be our ticket to avoiding the "stair step" problem on other element types too, except we'd need to deal with them as part of the chordrest shape calculation just as we do for lyrics and chord symbols. A bigger change, but something to think about.

Reply

Fix version
3.1.0