Grace notes moving to other side of trill note

[craigsapp]

In this example Humdrum data (D. Scarlatti sonata in C major, Longo 1, measure 4):

https://verovio.humdrum.org/?file=scarlatti/sonatas/L001K514.krn&k=ey#mh4

The two grace notes after the trilled note are being placed before the trill note in the MuseScore rendering of the output MusicXML file:

They are also beamed with a single beam and there is a slash on the beamed group rather than two beams and no slash. This is a fine point, with further discussion needed: The Humdrum text for these notes:

Notice that there is one pair of L/J for the beam. So it is a reasonable assumption to add a single beam for these note. However I am using a lazy beaming encoding here, which instead uses one (or more) L/J to define the beam, and the number of beams is controlled by the durations given with the grace notes. I should fix this in the data since I prefer to not do lazy beaming in the encoding, but I do utilize it for automated processing of the data. Lazy beaming is more analogous to how MEI encodes beams (which is used in the process of rendering on VHV through verovio).

The best algorithm for parsing grace notes would be:

(1) If there are rhythms associated with grace notes, assume a lazy beaming encoding method. (2) otherwise if there are no rhythms, then assume exact beaming is specified (which in this case should be LL/JJ for two beam bars).

Point (2) cannot be used for single-note grace notes, since there are no beams to precisely specify the visual aspect of the note, so that is why I given priority to explicit rhythms when rendering grace notes (currently I do not render using method (1), but I should add that to the Humdrum-to-MEI converter).

The slash is technically correct, since it usually means an unaccented grace note or note(s) in this case. Slashes on beamed grace notes is more of a 20th-century style, but this music is from the 18th century (and the reference editions is from the very early 20th-century). The slash originates from the second beam of a single-note grace note (i.e. an eighth note with a slash through it was meant as a stylized 16th note).

For comparison, here is a scan of the reference edition (type alt-p or option-p in MacOS in VHV to view a scan of the original music.

[gregchapman-dev]

Thanks for this very detailed issue report! For the record, I attempt to do the same support of lazy beaming that humlib does, so it's more likely this is a bug in grace note handling. And of course, my trill support is missing something critical, if the first two notes of the three are being displayed as grace notes, instead of the last two notes of the three.

[craigsapp]

Here is a short example showing the ordering behavior:

Verovio rendering of Humdrum (rendering as expected):

MuseScore rendering of MusicXML conversion:

In measures 1 and 2, the grace notes are reversed in order and place before the last note of the measure (the presence of the trill does not alter the behavior).

I measure 3, the grace notes are converted in the correct order. So I would presume that the bug is related to trying to insert grace notes at the end of a measure, or trying to insert grace notes when there is no following non-grace note.

Measures 4 and 5 demonstrate that the behavior affects both beamed and unbeamed grace notes.

Humdrum test data:

**kern
=1
1f
16qgLL
16qa-JJ
=2
1bt
8qccL
8qddJ
=3
2ffT
16qeeL
16qggJ
2aa
=
1d
16qe
=3
2g
8qe
2f
=
*-

[gregchapman-dev]

I have pushed a fix for getting the right number of flags/beams (commit 843d5121efc2562ab6173b7690f421bb6e298dd4).

I have filed an issue with MuseScore about eighth-note grace notes at the end of a measure being rendered at the beginning of the measure (in reversed order): https://musescore.org/en/node/323052

Amusingly, getting the number of flags/beams right causes the MuseScore bug to happen less often, since it only happens for eighth-note grace notes.