LH Guitar Fingering creates too much space before itself, when directly after a barline
Reported version
3.2
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.3.0.7722, revision: cc654b1
Open the attached score.
- Click on the first note in voice 1 of measure 4.
- Add a Natural accidental from the toolbar.
Expected result: Space from barline to note stays the same?
Actual result: The note moves closer to the barline. This seems to happen when there is a fingering symbol in a different voice at the same position.
| Attachment | Size |
|---|---|
| accidental_spacing_issue.mscz | 10.88 KB |
Comments
Accidentals are supposed to change the distance to first note; there are separate style settings for this. But it's not implemented as consistently as it should be, and it's true that content in other voices or others staves can confuse things. The behavior in this case seems correct as far as what happens with the accidental - it's correctly honoring the barline to accidental distance. The issue is the note is too far away with the fingering. We really could ignore it since it's below the staff and thus doesn't collide with the barline, except it still will if barlines were extended to a staff below. But maybe we treat notes with fingering as if they had accidentals and use the smaller distance in that case.
Typo?
Guitar scores feature a lot of LH fingering symbols so it's a significant bug. Could this be fixed for the next update?
It's not so much a bug as an opportunity for improvement, but it deserves further discussion on the forum first. Feel free to start a thread to collect input on my proposal to treat notes with fingering as if they had accidentals in terns of which distance from barline setting to use.
I suppose another option is to simply not reserve (as much) space for notes with fingering at the beginning of a measure - subtract off the the barline-to-note distance, essentially.
Deleted. See subsequent post.
Well, I don't get the same result as you (default settings, and examples created from scratch)
MuseScore 2.3.2 (not good, the LH fingerings 1, and 3, are too close to the barline)
MuseScore 3.2.3 (as expected here: anyway, you can customize)
Oops, my mistake: I was using customised settings.
IMV, it would be good to keep the barline to fingering distance the same, regardless of the accidental: E.g.
![spacing_before.png]( "spacing_before.png")
![spacing_before_with_accidental.png]( "spacing_before_with_accidental.png")
Right, 2x did not consider fingerings at all, so the default result often overlapped the barline. This was indeed bad, and the current defaults are much better.
Right now, for notes with fingerings, we continue to use the regular "note left margin" or "barline to accidental distance", and the latter is smaller by default. This is deliberate as it is the right results for notes without fingerings (probably 95% of all notes across all scores for all users). But for the special case of notes with LH guitar fingering, it's true that the presence of the accidental is not what is relevant. We should perhaps actually ignore that and use the regular "note left margin" setting in those cases. Or, conversely, always use the note to accidental distance for notes with LH guitar fingering. Then the results would be more consistent, because you are right that the presence of the accidental shouldn't be relevant.
But consider, it wouldn't be all notes with fingerings, only notes with LH guitar fingerings, and then also, not even all of those, only those where you hadn't manually moved the fingering elsewhere. So I'm not sure how viable this is really. A better algorithm might be something like, calculate the distance from the left edge to "shape" for the chord to the left edge of the leftmost note itself, and then subtract that amount from the barline left margin if it's at least as much as the barline to accidental distance. Or something like that. But I'm not sure all that information is readily available, the layout algorithms were not necessarily designed to work that way.
So I'm not saying there is nothing that can be done, but I am saying the defaults aren't that bad, so this really is "minor", and right now, without input from people on the forum who might also be affected any such change to the layout algorithms and might also have some insight as to solutions, I can't see any viable way forward right now, so I would not be getting your hopes up about seeing changes here on short notice.