2.0 grace note spaced too wide on ledger lines

• Apr 2, 2015 - 20:05
Type
Functional
Severity
S5 - Suggestion
Status
active
Project

As per the picture, grace notes are too widely spaced when on ledger lines, whereas those on regular lines space correctly. Windows 8.1, 2.0 6e47f74.

gn01.png

Attachment Size
gn01.png 12.54 KB

Comments

What's your criteria for saying that's too wide? We need to allocate space for the ledger lines, and they are not normally supposed to touch, so we include a minimal amount of padding. The ledger lines themselves also seem to be shortened correctly.

I guess we could have additional parameters to control the ledger line size for grace notes - making them shorter than you'd expect just scaling down a normal grace note. Or make the minimum space between ledger lines smaller - but there really isn't much room to play with there.

What did you have in mind?

Spacing and vertical alignment is my criteria. Considering this passage is mirrored in both hands, it seems wrong to not see the grace notes starting at the same physical place. Seems to me scaling the ledger lines to be short enough for the smaller noteheads is the way to go.

I would say that the case of trying to align the grace notes between the hands is an unusal spaceial case, and that *normally*, you do want the ledger lines not to collide. As I mentioned, the ledger *are* already scaled. Arguably, they could be downsized *more* than the noteheads themselves - as I suggested, a separate command to say how much they should shrink *in addition to* the scale that already happens. But they still wouldn't align - not without breaking engraving rules. In general, it *is* important that grace notes on ledger lines get more space than grace notes not on ledger lines.

If you wish to make the grace notes align between staves, it would be better to add additional otherwise unnecessary space to the grace notes *without* ledger lines.

Yes, here is look like they artificially added extra space to the grace notes on the lower staff. They mighthave also artificially compressed the spacing of the grace notes on the top staff a bit. But I would note they also appear to have shorter ledger lines even for normal notes, so there's something you might consider doing as well if you prefer that look (see Style / General / Notes).

cadiz1: yes, the code to make grace notes on ledger lines space correctly was added relatively recently. I forgot when, but apparently after May 19, because the result you show there that is the incorrect spacing I was fixing, as per Gould "Behind Bars".

I think this needs to be revived in discussion. Gould, "Behind the Bars" is one idea of what a score should look like. You have decided to make this your standard for notation layout, but the picture in the original post simply looks wrong. Just as all notes on beat 2 line up in a system, all of the grace notes attached to the same note should line up also. I don't own "Behind the bars," but I can't imagine that anyone would consider a layout that does not line up all notes played at the same time to be proper. Is there not some accommodation for ledger lines that are shorter for grace notes?

Severity S4 - Minor S5 - Suggestion

I'd say it looks wrong in this specific case because a) the staves are adjacent, b) they are for the same instrument, and c) the passage is essentially identical in both staves. But in other cases - say, two descending grace notes into an oboe part, three ascending grace notes into a viola part half way down the page - there would be no specific reason to try to align them. On the contrary, the correct notation is to allow the grace notes in one part to overlap ordinary notes in another part if the other part doesn't have grace notes. Also consider a case where the grace notes in one part require accidentals but these are not required in another part.

Thus, the general rule - not just from Gould, but common practice in general - but is to align grace notes on one staff or in one instrument but not otherwise. MuseScore doesn't attempt to do the special-casing it would take to differentiate these situations. Someday we certainly could consider it. So I'm leaving this open as a feature request.