Chord Symbols: allow option to ensure uniform vertical alignment

+1.

In fact, such an implementation look straight forward:

The algorithm just looks for the highest chord and aligns all chords on a system with that highest chord.
However, if there are a few high notes, they might push other chords too high up. For that reason I introduced a style parameter which limits how far a chord can be pushed up. The example above shows the result with a maximum shift of 3.5sp (1sp is the space between the lines of the staff, or roughly one note head).
If the pushing is limited to 3.0sp the result will be:

Now all notes up to the B in the 3rd measure should be push up more then 3.0sp which is too much. Now the algorithm looks for a new highest note, which happens to be that B, and aligns all remaining chords with this, new , highest, chord.
If the limit is reduced even more, to 1.0sp the result will be:

Not the best result but is shows how the algorithm works.
When the limit is set to 0.0sp, the default, we get the original situation where no alignment is done at all. In general it is best to uses a slightly larger value for the limit or just zero.

For now only chords are aligned, I'm extending the algorithm to align fretboard diagram too. And some polishing is required but I showing these results so far for some feed back.

Thanks for looking at this, I like where it is going! FWIW, it bothers me less for chord symbols than it does for Roman numeral analysis. RNA is implemented as a Harmony object just like chord symbols are, so probably whatever you are doing will work for RNA automatically, but you might want to check that (Add / Text / Roman Numeral Analysis). Only thing to be careful of is that RNA defaults to below the staff instead of above, but chord symbols can also be placed below, so be sure your code doesn't literally work only for pushing things up.

RNA worked out of the box (okay, after changing the box a little so it handles placement below the staff but that was on the list anyhow):

There is still an issue of alignment of fretboard diagram, these elements show an interesting behavior when changing the position. Also the new positions have to be added to the skyline.

Yes, the algorithm works per system. One very high placed chord in one system will effect that system only.

https://github.com/musescore/MuseScore/pull/6060

I'm far from an expert on notation standards, but I'm surprised to read that simply lining up all the harmony symbols in a system, regardless of their individual vertical distances from their corresponding note(s), wouldn't be the most desirable layout.

I just checked Gould's Behind Bars, but I couldn't find anything on this.

Do Sibelius et al. also implement a similar maximum vertical shift when aligning harmony symbols?

I agree, aligning is the most desirable layout. And as a matter of fact, all albums I have the chord symbols aligned.
The reason of setting the default to 0.0sp (meaning: No alignment) is just compatibility. This might be important if this PR makes it to 3.5. If it appears not before 4.0 I don't see any reason to change the default to a higher value. But existing scores still remain unchanged even in 4.0. Users have to explicitly change the parameter in the scores.

I was asking why it is implemented as a “maximum vertical shift” numeric setting instead of a simple on/off toggle. It seems cumbersome for the user to have to set the “maximum vertical shift” to some arbitrary large value (5 sp? 10 sp? 100 sp?) just to make sure that all cases in the score, present and future, are correctly handled.

I like it very much to have it implemented as a maximum instead of a single off/on.
Will be quite suitable for the the type of scores I use.
Now the UI could show a triple radio:
Align chords:
[ ] Yes
[ ] No
[ ] Up to max: [...] sp
Behind the scene the yes option could set the max to 100sp

It is implemented as a "Maximum vertical shift" to prevent one single note will cause all chords shifted too far up, making it unreadable. In my books I saw a few examples. But I'm a woodwind player so chord symbols are more or less alien to me, any feedback from real users is welcome.
On the other hand, to align all chords, you need a larger value indeed but it isn't that arbitrary as it looks like. 1.0sp is one ledger line, that gives one a good idea what a good maximum would be.

A kind of user interface as proposed by @frfrancha seems to me a good alternative.

I agree the max setting is a great way to go. Most people would not want a single outlier to force all chord up, and yet that doesn't mean the other chords should try to align amongst themselves, either. To some extent the same could possibly be accomplished by disabling autoplace for the outlier - I assume (?) the remaining chords would still align, but I don't want to have to disable autolace and thus position my outliers manually, I just want good things to happen.

I don't really see the need to complicate things further with a separate "yes" button. Nowhere else that I can think of do we do anything like this, but plenty of places where we simply allow arbitrarily large (or small / negative) values to essentially give the same result. For example, there is no "always increase system distance to fill the page' - you just set max system distance high enough. There is no never or always fill last system, just 100 or 0 values for fill threshold. Elements that still have autopalce enabled can be allowed to collide with other elements by setting appropriately small min distance, and so on. Putting an extra setting there just invites the question, what does this do that simply increasing the max doesn't, creating unnecessary confusion and UI clutter.

Unless we figured out some clever new UI element we used consistently in all the places where there comes up, which is certainly possible. But I don't think now is the time to try to solve that.

Marc wrote: Nowhere else that I can think of do we do anything like this, but plenty of places where we simply allow arbitrarily large (or small / negative) values to essentially give the same result.

So currently MuseScore tends to ask to enter large values to achieve a "always" result instead of an explicit additional 'Always' (or 'Yes') choice.
I wonder what is the most user friendly solution.
A - Adding that "always" or "yes" solution to all these choices
B - Keeping them like they are, but offer 'Always/yes' option for chord align
C - Keeping them like they are, and use the same (=without yes/always) for chord align

In my personal view (but of course that's subjective) [A] is a lot more user friendly.

I agree there are friendlier options, but adding a bunch more buttons to an already cluttered UI isn't necessarily always a good idea. I'd rather consider where there is a better answer that doesn't increase confusion or clutter, And since the same type of change would be needed many other places in the UI, and we are already looking at pretty substantive change to how settings are made (to the Inspector and style dialogs) for 4.0, to me that's the more natural time to consider bigger picture issues like that. For now, I think it better to keep this control consistent and uncluttered.

Fixed in branch 3.x, commit ae6eb164cf

_Fix #281759 - Chord Symbols: allow option to ensure uniform vertical alignment

Implements an algorithm for vertical alignment of chord symbol or fretboards._

Fixed in branch 3.x, commit 3419430c05

_Merge pull request #6060 from njvdberg/issue-281759-vertical-alignment

Fix #281759 - Chord Symbols: allow option to ensure uniform vertical …_

This feature can be used via a new style parameter. You can find this parameter on the Chord Symbols page for the Style Editor. To open this form, use the menu option File -> Style and select Chord Symbols in the left hand column. There you see the options Maximum shift above and Maximum shift below. These parameters control how much the software can shift the chords up (if placed Above) or down (if placed Below). If you choose these parameters "large enough" (3 - 3.5sp) all chord symbols will be aligned. With smaller numbers, the chord symbols can be aligned in two or more rows because there is one chord symbol too high and not all chords can move enough to be aligned. This can be helpful to prevent one single chord symbol causes all other symbols to placed very high. See here for some examples.

And the change is part of the 3.5 beta which was released today.

I'm using with my Roman numeral analysis, thanks for implementing this!

I would say that we should consider enabling some amount of it by default, say 2-3 sp worth. My thinking is, it could be good if notes up to two or three ledger lines above/below the staff did not move chord symbols out of alignment by default. However, existing scores that used manual adjustments to achieve this won't look right. Still, I might recommend the change in the Jazz templates at least, so new scores using these have it by default.

Having a default other than 0.0 would be useful indeed. Maybe we can do this in 4.0 especially if MuseScore 4.0 will have a new version of the score file. In that case it easy to keep older score unchanged.
But I haven't thought of changing templates could do the job to. I prepare a PR for this.

With (PR #6216](https://github.com/musescore/MuseScore/pull/6216) the templates Jazz Lead Sheet, Big Band and Jazz Combo will set the alignment parameters to 3.0sp.

Automatically closed -- issue fixed for 2 weeks with no activity.