New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fingering layout #4591
fingering layout #4591
Conversation
The broken tests are kind of to be expected as a side effect of how I implemented the algorithm, making use of the placement property. I could update the references, but frankly, I'd rather update the writing of Fingering elements to skip writing this property, because it is not actually needed (it is generated automatically). Hmm, I was thinking that would mean creating an override for Fingering::writeProperties, but actually, maybe I can avoid that by forcing this property to always be "styled" (it is not exposed in the UI). Anyhow, one way or another I will fix. |
FWIW, I updated the references. That way if we ever do decide to expose the placement property for fingering, the tests won't break again. |
Updated to incorporate some excellent feedback from cadiz1 and geetar in the issue report https://musescore.org/en/node/280807 Speaking of issue reports, there's actually a whole bunch of them that are addressed by this, enough that it was not convenient to list them all in the commit message. When (!) this PR gets merged, I am happy to close issues manually. |
c775bde
to
66a3645
Compare
In anticipation of needing to close issues manually once this is merged, here's a list of issues addressed here: https://musescore.org/en/node/280807 (as per commit message) |
libmscore/chord.cpp
Outdated
} | ||
} | ||
for (Fingering* f : alignNote) { | ||
if (f->autoplace()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this needed if you already checked the elements earlier for autoplace? Or does autoplace have a side effect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Harmless, but I can remove this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(fixed)
6006860
to
bf677b4
Compare
Build failure doesn't seem to be my fault, AppVeyor may be full? |
Force a new build and it should work |
bf677b4
to
8942ed8
Compare
There are quite a few issues involving fingering layout. Some are design limitations, some are bugs inherited from 2.3.2, some are some regressions. This PR tries to address them all as well as possible.
Some of the issues fixed:
No doubt there is still room for improvement even with my fixes, but I think mostly it will be about small tweaks - quibbling over exactly how far from the notehead the fingering is, etc. I'd like to see this merged and let people like cadiz1 and geetar have at it to provide more feedback.
One limitation I know we will probably want to revisit is the vertical alignment and spacing of LH guitar fingering in chords. With the possibility of tightly-spaced chords (including seconds), plus accidentals, it's going to be next to impossible to come up with perfect layout by default in all cases. My algorithm here does pretty well for many chords but will still have collisions in some cases. That's probably unavoidable, hopefully people find my approach avoids the need for manual adjustments in many cases and provides a good starting point in the rest.
Here's a sample: