fix #299644: add support for fret diagram rotation

[jthistle]

resolves https://musescore.org/en/node/299644

This is what it looks like:

(rotated, rotated, normal, rotated with fret number)

Other changes in this PR:

• a new property, ORIENTATION has been added. This can be either HORIZONTAL or VERTICAL.
• cross and circle markers (above the diagram) have been made to look nicer, using a pen to draw them rather than using a font with the letters 'X' and 'O'
• layout has been modified so that the diagrams are actually centred over the notehead/rest they are above, rather than using a hacky method that didn't change with the number of strings
• a missing method for reading a CHANGE_METHOD type property

[Jojo-Schmitz]

What about rotating into the other direction, for left handed players?

HORIZONTAL_270 and HORIZONTAL_90 maybe, or HORIZONTAL and HORIZONTAL_LEFTHANDED?

[jthistle]

damn, I hadn't thought of that... has that ever been requested?

[Jojo-Schmitz]

Not sure, but I believe so. But even if not, I see it coming

Edit: yes it has, see https://musescore.org/en/node/136436

[lasconic]

Maybe it's an opportunity to use smufl glyphs and so make the markers configurable via the score fonts instead of hard coding the drawing with primitives? See https://www.smufl.org/version/latest/range/chordDiagrams/

[Jojo-Schmitz]

Those seem to be too restrictive, like "Fingered fret (filled circle)" won't allow for fingering inside the dots and no barré and the fret diagrams have only 3-6 strings. The symbols for "Open string (O)" and "String not played (X)" might work though.

[jthistle]

It's definitely an idea... could you explain the benefit of it over drawing, though? Because it wouldn't exactly be easy to implement.

[Harmoniker1]

@jthistle Rebase needed

[anatoly-os]

@jthistle ping :)

[jthistle]

ah yes, will do

[anatoly-os]

@jthistle ping :)

[jthistle]

sorry sorry!

[jthistle]

@anatoly-os just building now - I'll push once I'm sure it's still working correctly.

[jthistle]

@anatoly-os rebased

[jthistle]

vtests should be fixed now

edit: or not

[AntonioBL]

@jthistle : for what concerns vtests, both PR vtests and ref vtests are now generated "on the fly", so that the vtests for one PR are always compared to the vtests of the parent branch (some sort of "differential" check).
If a PR introduces changes (even for the better, as in this case), the vtests will fail (I couldn't find a way for an "allowed failure" in github actions, which are used to do the vtests, or automatically post a comment in the PR). So a vtest "failure" is not necessarily a real failure; it just asks to carefully check what has changed, so that no regressions are introduced.
No need to change local refs or vtest scripts (unless you are adding a new vtest).

In this case, the difference is that "X" and "O" symbols in the fret diagram are a little bigger, for a better readability.