placement of fingering text does not change when stem direction changes
If I start with a B with auto stem direction in treble clef, and then add a fingering, this is what I get:
If I then change stem direction to force up, then I get:
I don't like how that 2 is still above the note since the stem is also pointing above.
Comments
This happens because for historical reasons, the automatic positioning fingering is implemented as a user offset, and it remains fixed once calculated. You can force it recalculate via Ctrl+R however.
If we redesign fingering some day, I would be more than happy to see the automatic positioning more the way other symbols are - as defaults calculated on each layout operation rather than an offset calculated once when the element is initially placed.
In reply to This happens because for by Marc Sabatella
Force recalc seems to throw the fingering too far out:
I'm wondering now if could utililze the base class for chord text, fingering text, and lyrics text. That base class would be responsible for having the text elemens appear always below/above the outer-most note of the multi-note chord, and also avoid writing on the staff.
In reply to Force recalc seems to throw by ericfontainejazz
Ctrl+R works as expected for me. What version of MsueScore? Sample score, steps to reproduce?
In reply to Ctrl+R works as expected for by Marc Sabatella
Now here is the part where my steps diverged from you. If I ONLY have the *fingering* selected before I press Ctrl->R, then fingering position is nicely positioned. However, if I have both the fingering AND the notehead selected, then the fingering gets thrown out way too high above the staff.
I think the error can be fixed by changing the order of operations in the code. First should august the stem direction to auto. And then should change the fingering position. I'm thinking the code first adjusted the fingering position to where it should have been when the stem was pointing upwards, which later doesn't make sense when the stem is then changed to point down.
In reply to new score treble clef place by ericfontainejazz
Glitch happens on both musescore 2.0.3 release and Nightly 32c3100, both on Windows 8.1 x86-64.
In reply to This happens because for by Marc Sabatella
Marc,
All these placements problems will go away in 3.0 with auto layout, won't they?
Or do I misunderstand and autolayout is something else?
In reply to Marc, All these placements by frfancha
Not necessarily. The automtic layout improvements in the current master are rather more limited than this, and it's a long way from where we are now to being to do anything like full automatic collision avoidance.