Chord symbols won't overlap barline
Windows 7, GIT commit: 6c5b016
1) new score, 4/4
2) Ctrl+K to enter chords: "C" Gbmaj7#11
Result: the measure is alloted a ton of extra space to allow the Gbma7#11 (which is on beat 4) to fit within the measure rather than allowing it to extend over into the next measure. I understand there were implementation-related reasons for this - see http://comments.gmane.org/gmane.comp.multimedia.musescore.devel/18. But I think we need to find a solution. A chord on the last beat (or half beat) of a measure as an anticipation of the downbeat is pretty common in jazz, and it shouldn't require the measure to be spaced so wide. Only if there is another chord on the downbeat should the space be required.
Comments
Here's a couple of images showing why this is a problem:
Expected result:
Actual result:
I generated the "expected" result by setting the new-for-2.0 "Minimum chord spacing" style parameter to -10sp, thus effectively disabling the new automatic chord spacing. But that's overkill. I want chord to avoid each other; I just don't want them to go out of their way to avoid barlines.
Based on what I know of the implementation - which is based on measure-at-a-time spacing - a cheap fix might be to ignore the last chord of the measure *unless* the next measure has a chord in the first chordrest segment (ie, do a lookahead). It's a kludge, and will be easy to find cases where it won't work as expected, but it should be an improvement. Ideally, we'd also continue to consider the last chord if the measure is the last measure of a system, but I'm not sure that's known yet.
Because of the way the layout code is structured - essentially duplicated but with differences in Score::computeMinWidth() and Measure::layoutX() - it turns out to be next to impossible to do anything across measure boundaries. At least not with significant re-architecture, and this isn't worth it right now.
So I have a non-ideal fix in place: instead of extending the measure to fit the entire last chord, I allocate only enough room for half of it. So in cases like the above, the chord symbol will straddle the barline. So *if* there is a chord at or near the beginning of the next measure, there may be conflict. I am hoping this doesn't happen often - often the reason for at the very end of a measure is to be an anticipation of the next measure, so there will be no conflict. I have also changed the behavior of chord symbol manual positioning to have a more logical (to me, anyhow) effect on spacing.
It's still not ideal - in most cases, there should be no need to allocate any extra space at all for the chord - and I suspect in some case the user may wish to resort to disabling the automatic spacing entirely. I may add a checkbox to the harmony properties (accessed from the Inspector) to exempt individual chords from the auto-spacing.
Just thinking aloud here in case others wish to weigh in.
Here, BTW, is my branch:
https://github.com/MarcSabatella/MuseScore/compare/25278-chord-symbol-s…
My current thinking is that I will add a new chord style parameter, "maximum distance to barline", to control the amount of space to allocate at the end of the measure. With a default setting of, say, 2sp, chords will mostly be allowed to overhang the barline, but you can add more space for individual chords by adding extra trailing space to the segment. Conversely, if you up the setting to say 10sp, then you'll get the current behavior (measure extended to make room for the chord).
I have implemented what I described above. There is a new general style parameter on the chord symbol tab: "Maximum barline distance". This controls how much of the last chord in a measure will be contained within the measure. The default is 3sp, which pushes the barline out just a little bit in the example I used above., The chord is allowed to overlap the barline after the first 3sp:
If there had been a chord at the beginning of the next measure, by default they would overlap, just as they did in 1.3. You can prevent this for all such chords by setting "Maximum barline distance" to a sufficiently high value, forcing the entire chord to be contained within the measure. The result will be like my "actual result" I posted previously.
But I think this is an area where people will be better off sorting out how they want to do things on a case-by-case basis, using extra leading/trailing space and/or manual positioning. Not only is it technically difficult to accurately detect the overlap between measures before it is too late, but also, it is by no means clear what the "right" adjustment would be.
Here's the PR:
https://github.com/musescore/MuseScore/pull/870
Fixed in 2185d1c6be
Automatically closed -- issue fixed for 2 weeks with no activity.
Hi Marc, I just got around to trying out 2.0 beta1, and found a problem with this change. As you mentioned in your email to me, there is the possibility of a chord overlapping a chord in the following bar. I've attached a score that shows this in bars 9 and 10.
Did you have any ideas for solving this? It seems to me that there are two possible approaches:
1. Look ahead to the next bar for a possible chord symbol. This could be complicated, as you probably don't yet know whether the next bar will even be on the same line.
2. Store somewhere the amount of space by which the chord has overlapped the following bar. Then when processing the first chord symbol in the next bar (which might not be on the first beat), use that saved value to calculate the amount of collision overlap, and add that amount of space to the spread from the beginning of the bar to the current point. this is probably a better approach.
My dev environment is way out of date at the moment, so I can't look at it directly.
OK, I've looked at the PR and can see that you have some code in there to handle carry-over spacing, but it is #if-ed out. I guess there was a problem getting that aspect working.
I think I actually tried both of the approaches you mention and both proved problematic, although to be honest I forget the details. It wasn't seeming like there was a way to really it working - layout is really one-measure-at-a-time at a pretty fundamental level. Instead, I chose to go with the style parameter as described in response #5 above. But feel free to take another look!
One hopefully good thing that came of this - I tweaked how things work in terms of manual adjustments to chords. The results aren't always exactly what one might expect - because expectation can vary by situation - but I am reasonably satisfied with what happens if you move the last chord of the first measure to the left to avoid overlapping the first chord in the next measure (same if you move the latter chord to the right). At least, more satisfied than I was before.
It occurs to me that if it's too hard to do this spacing automatically, it could be worth it to add a property to chord symbols that defeat the automatic spacing. Actually, lyrics could use the same property (see below). This would be per element, set via Inspector. Then you could turn the Style setting I added (maximum barline distance) up, to allow MuseScore to pad measures to prevent chord symbols from overlapping barlines, but defeat it for individual chords that you *want* to overlap the barline.
As I mentioned the same property could be useful for lyrics; see #33246: Hyphenated melisma requires too much space and the discussion on the PR https://github.com/musescore/MuseScore/pull/1330.