Chord with accidental and offset downstem note too close to barline
Windows 7, GIT commit: ef4c692
1) load attached file (from vtest)
2) look at first chord of second measure, bottom staff
Result: chord is too close to barline. It's using barline-to-accidental distance, which would be fine but there is also a notehead at just about the same horizontal position as the accidental.
Here is how I think it should look:
Well, maybe that's actually too much space, but it's in the ballpark. Here on the other hand is the actual result:
I am pretty sure I see how to fix it. In the following loop:
https://github.com/musescore/MuseScore/blob/master/libmscore/measure.cp…
Instead of just looking for an accidental and then stopping, we should look for the minimum accidental X position, and also the minimum notehead X position (be sure to add in chord()->x() too). Then when we decide whether to use ST_barAccidentalDistance or ST_barNoteDistance, we check those minimum X values and be sure we add the correct amount of extra leading space to clear both accidental and notehead by the appropriate amounts.
I'm confused because there is almost identical code here as well:
https://github.com/musescore/MuseScore/blob/master/libmscore/layout.cpp…
and I'm not sure how these relate. So I'll leave this alone for now to see if someone else wants to look at this first.
| Attachment | Size |
|---|---|
| accidental-1.mscz | 1.67 KB |
| accidental-1-ref.png | 10.57 KB |
| accidental-1-1.png | 10.47 KB |
Comments
I got curious and started looking further. It looks like the code in layout.cpp (computeMidWidth) is calculating how much space the measure needs, but the code in measure.cpp (layoutX) is doing the actual layout of elements. So the correct thing to do is to make the modification in both places.
With that assumption, I've gone ahead and made the change as I proposed above. Here is the code:
https://github.com/MarcSabatella/MuseScore/compare/25341-bar-distance
It seems to work, but I wouldn't mind confirmation that my understanding of the relationship between these two sections of code is correct.
I would like to fix #25342: too much space after time signature if first chord has accidental as well, and because these two fixes will share code, my plan is to submit just one PR for both, although with two separate commits.
Well, I'm afraid we are in a rather subjective area here. Between the examples you quote, I surely prefer the second (which, if I understand correctly, you qualify as wrong) to the first, which has way too much space between the bar line and the first chord in measure 2.
Do you think example 2 is going against some of the score style values? Assuming the LH chord in measure 2 had no G, the current position wold be correct, I think. The fact that the flipped G note head is inserted in the 'spare space' generated by the presence of the accidental seems to me a plus not an error.
But this is just my reaction when looking at the images, there is no 'rule' behind it.
Thanks,
M.
P.S.: the only 'rule' I can think of is the old, rather extreme, position of some engravers that bar lines should not generate ANY extra space. Not everybody agreed and it seems to have fall out of fashion, but it has some value...
Yes, the first example I posted did actually have too much space. It was what I had lying around, generated by an old build using default settings. As it happens, it was too far away because of a bug that was fixed a week or two ago that caused too much space to be allocated on the *top* staff because of the multiple voices. The chord on the bottom staff just came along for the ride. So the one bug caused there to be too much space; now a different bug causes there to be too little.
The issue is actually pretty simple and not really that subjective. The "rule" that MuseScore should be following here is, the leftmost notehead of a chord must be a minimum of 1.0sp from the left barline, as per the style settings. If a chord has accidentals, they are allowed to use up some of that 1.0sp, so the chord doesn't have to move too much further away from the left barline. But under no circumstances should adding an accidental to a chord ever move the chord itself *closer* to the left barline.
And that is what was happening here. Without the accidental, this chord was placed 1.0sp from the barline. But once the accidental was added, MuseScore thought it could get away with putting the accidental close to the barline, assuming this was just going to use up some of the 1.0sp between the barline and the leftmost notehead. But the reality is, because the accidental overlaps the notehead, the whole chord ended up too close to the barline.
The actual correct result should have the leftmost notehead always no less than 1.0sp from the barline. Here's how I think it should look, with and without the accidental (this is generated by my current code):
Now, the idea that the mirrored note should *also* be allowed to use up some of the 1.0sp margin is intriguing, but not a rule MuseScore follows at all, accidental or not. As I mentioned and show above, without the accidental, MuseScore would have placed that chord such that there was 1.0sp from the barline to the leftmost notehead - the mirrored one.
It would of course be possible to modify the rule to allow mirror notes to use up some of that 1.0sp, but then we'd need a new parameter that defined how much space there should be between the barline and the leftmost mirrored note. That's a separate feature request, I think. I just want to fix the bug that caused adding an accidental to move this chord closer to the barline than it would otherwise be allowed.
PR: https://github.com/musescore/MuseScore/pull/834
OK, thanks for the explanation and sorry for the noise: I didn't understand from the first post that MS was actually moving a note head with accidental closer than a note head without, but simply that the result in your second example was too close (which, per se, is not, at least without a an example of no accidental to compare to).
Thanks,
M.
My fault for having settled for posting the closest thing I had lying around rather than constructing an better example.
Now I just need to figure out why my tests are failing.
Tests are working now.
Fixed in edbeaeccde
Automatically closed -- issue fixed for 2 weeks with no activity.