[2.0] chord name collision with next chord

• Apr 29, 2015 - 13:02
Type
Graphical (UI)
Severity
3
Status
closed
Project
MuseScore

The layout in page mode can cause chord names which collide together for chords happening at the end of the bar. This does not happen in continuous mode as far as I can tell, and the space allocation is correct within a bar, even for chords with "large" names (e.g. Gb13sus/Ab)

I attached 2 bars from a piece I'm transcribing. chord_name_collision.mscz

Thanks for your help.

Attachment Size
chord_name_collision.mscz 9.86 KB

Comments

• Apr 29, 2015 - 14:17
Severity ⇒
Status (old) active ⇒ duplicate

See also #25278: Chord symbols won't overlap barline.

Increasing the parameter mentioned above does solve this problem. But unfortunately, it causes another - had there *not* been the DbMaj7 in the next measure, the extra space would have been allocated unnecessarily. Might not be an issue here, but see comment #1 in the aforementioned issue. Solving this more generally is hard, but something we'd like to figure out eventually.

Reply

• Apr 29, 2015 - 14:23
Severity ⇒
Status (old) duplicate ⇒ active

by "change", do you mean "increase" or "decrease"? (sorry if this sounds stupid, but all the settings in spaces in these style screens are very obscure to me...)

Reply

• Apr 29, 2015 - 14:55

Increase. The idea is, MuseScore has the ability to insert extra space before the barline to accomodate a chord symbol and keep it from overlapping the barline. If you increase that setting to infinity, you are giving MuseScore permission to put more space before the barline - to *not* let the chord overlap it. Which is what leads to the problem I mentioned - that space may well not be needed if the overlapping chord would not have bumped into anything. So the default is conservative. It works well if the main reason to have chords at the end of the measure is because the chord on beat 4 (or whatever) is simply anticipating the next measure. It works less well if you actually have four long chords per measure.

Reply

• Apr 29, 2015 - 15:17

Thanks Marc.

I checked the related report, and there are indeed 2 very different needs:

1. chords on last beat anticipating the next bar
2. chord present on the last beat, leading to another chord on the next bar (typically a 1 bar turnaround)

while overlapping on the next bar is ok for case 1 (but you still have to be careful about the last bar of the line) (and I will have to check if this is commonly done in "well known" sources such as the new real book), we really don't want that in case 2.

I would have gone for case 2 being the default, though... But I guess this is highly debatable, and there is probably no right answer. In the tune I'm working on, definitely no anticipation, so I can freely increase the max barline distance.

Reply

• Apr 29, 2015 - 17:12

One important factor in the decision to make case 1 the one we optimized for - it's easier to manually add space to correct for case 2 than the other way around. But it's unfortunate that it has to be one or the other. The way the layout algorithms are designed, all decisions are made a measure at a time, and looking into the next measure (which may or may not be on the same system) for help making the decision is not currently feasible. So it will take some rethinking to make this possible. It's definitely still on the radar though.

Reply

• Apr 30, 2015 - 08:13

@afayolle Your bug report / feature request falls under the general task of making beautiful scores easier and faster by adding a mechanism to avoid collisions. So this request will not be handled as a standalone issue and will be tackled in the way towards MuseScore 3.0. So don't expect a fix any time soon.

Reply