op71_no02: Rhythms for last measure

[bel28kent]

How would you (@craigsapp) encode the rhythms in the last measure? I know that I cannot have "2.5" because of the decimal, but I am not sure what else to put.

Here is the kern.

Here is the error message; it is finding an error with both the "5" and the "2.5."

Here is the reference score.

[craigsapp]

There are two rhythm errors: (1) The quintuplet dotted eighth note should be 10.B- instead of 5B-, and (2) the quintuplet quarter note should be 5c instead of 2.5c.

Rhythms cannot have decimal points in them, so 2.5 is invalid for that reason (there is an extension to **recip that could deal with such fractional cases, such as 3%2 which is a triplet whole note (2/3rds of a whole note).

It would be useful to include the Humdrum text for the examples instead of only graphic images of the data (and/or a link to the data in VHV).

Here is what I get:

View in VHV

**kern  **kern
*clefF4 *clefG2
4r  4r
4r  4r
*   *^
!   !LO:TX:a:t=lento    !
4GG# 4D 4c  (4ee    20eeLL
.   .   20cc
.   .   20a
.   .   20f#
.   .   20eJJ
*   *v  *v
=   =
*^  *
*   *^  *
*   *   *^  *
*   *   *   *^  *
*   *   *   *   *^  *
*   *Xtuplet    *Xtuplet    *Xtuplet    *Xtuplet    *Xtuplet    *
20e-LL\ N[>4e-/ 20ryy   10ryy   10.ryy  5ryy    2.f# 2.cc 2.ffni;)
20c .   N[>5c/  .   .   .   .
20B-    .   .   N[>10.B-/   .   .   .
20F#    .   .   .   N[10F#  .   .
[<20DDJJ    .   .   .   .   20DD/   .
*v  *v  *v  *v  *v  *v  *
2DD] 2F#N] 2B-N] 2cN] 2e-N];    .
==  ==
!!!RDF**kern: i = editorial accidental, paren
!!!RDF**kern: > = above
!!!RDF**kern: < = below
!!!RDF**kern: N = linked

I had to use the link marker to connect the tie endpoints to each other (either from the tuplets or the spine splits. In theory these should not be necessary (the link marker N needs to go immediately in front of the tie markers).

The B-flat note heads are separated since they have different durations. This is not yet possible to control in Humdrum, and maybe not yet be controllable in MEI/verovio to merge the two noteheads. This is related to issue https://github.com/rism-digital/verovio/issues/1569

I merge all of the subspines at once. The way you do it is safer (I would have to check if my merging does not cause problems when simplifying the spine merges back into a single primary spine).

[bel28kent]

Hey Craig - thanks for the response. I will include links to the data in the future.

Can you comment on how the !!!RDF**kern: N = linked impacts using the command-line tools? I.e., if I were to use it for ties between different voices/subspines—which is ubiquitous in Scriabin's music—would an analysis with something like the beat command still be accurate? If so, then this method would solve a lot of other complicated problems that I have been encountering in the corpus. Currently, the ties across different voices are represented through doubled notes and added subspines that are not in the original notation. It would also simplify subspine assignment.

[bel28kent]

@craigsapp Can you follow up on this question about linked ties? If the solution will work, then I should start planning how to make the necessary edits to the corpus. If not, then I will need to pursue other solutions.

Can you comment on how the !!!RDF**kern: N = linked impacts using the command-line tools? I.e., if I were to use it for ties between different voices/subspines—which is ubiquitous in Scriabin's music—would an analysis with something like the beat command still be accurate? If so, then this method would solve a lot of other complicated problems that I have been encountering in the corpus. Currently, the ties across different voices are represented through doubled notes and added subspines that are not in the original notation. It would also simplify subspine assignment.

[craigsapp]

I figured out the problem that was making the linked ties necessary: The spines needed to be terminated in my encoding for the ties to be processed correctly. Adding spine terminators allows the ties to be regular:

View in VHV.

You are using what I call "disjunct" ties by using [[. Ideally the terminator for disjunct ties is ]] (and middle of a disjunct tie is __). These are used when the two tied notes are not adjacent to each other (these happen often in some Beethoven piano sonatas for example):

View in VHV.

In the first measure, regular ties are used. But the tie endings cannot find a matching note immediately after and before the notes with the tie starts/ends. When this happens the ties are highlighted in red to indicate a data error. To indicate that this is not an error, the slur endings characters are doubled. Note that the C5 slur can be encoded with [/], so it is not necessary to use the character doubling for that tie (better not to use disjunct ties unless they are needed).

The linked ties are for more complicated cases where automatic identification of the pairings of the endpoints are too difficult to process automatically. These should be very rare: here is an example that I can think of where notes in different spines need to be tied together:

View in VHV.

Linked ties are similar to how MusicXML deals with ties by giving them numbers to match the tie ends. Cases such as NN[ or NNN[ are also possible for multiple linked ties that are active at the same time. Linked ties are sometimes needed in keyboard music for cross-staff ties (since I treat a piano part as two spines rather than one spine that splits into the top/bottom staff).

---

Another category of tie is a laissez vibrer (l.v.) which has a starting note but no ending note:

View in VHV.

The first measure has an unterminated tie, but it is treated as a data error (by the Humdrum-to-MEI converter) and displayed in red with verovio. To assert that the tie is an l.v. tie, a layout parameter is prefixed to the starting note in the spine that starts the tie: !LO:T:lv, where T means it is a tie-related layout parameter, and lv is the layout parameter to label the tie as an l.v. tie.

Currently there is no control for the length of an l.v. tie, but that can be added relatively easily when needed; otherwise, the l.v. tie goes to the next rest/note in the spine/subspine.

---

A final special case is the "hanging" tie which goes to the beginning or ending of the music (typically as part of a musical excerpt as in the Polyrhythm Project). In this case nothing special needs to be done to assert that the incomplete tie is valid:

View in VHV.

In this situation, the ties are automatically attached to the ending barline, or "time 0" at the beginning of the first measure.

[bel28kent]

Okay. Thanks for the feedback. I have tried the ties in different subspines as in the first example in some other pieces, and it works. So I will implement this going forward.

There was one complicated example with cross-staff beaming that I could not get to work though. View in VHV

I have to link the N[[32qqqb-> with the 2.b-N]] as they are in different staves; the same is true for the E5. I also have to use two [[/]] as the 32nd note Bb4 is disjunct from the first dotted half note Bb4. Note that I also had to put two __ on the 2.b-__ because the ties were rendering backwards if I only used one. The rendering is fairly accurate, except that the ties on the Bb4 and E5 are only rendering for the start and end notes. A second pair of ties should also be showing for the intervening dotted half notes.

[craigsapp]

Here are some adjustments that matches close to the original:

View in VHV.

The link signifiers (N) need to be placed on the tie-continuation notes (first half note chord). Then the N should also be added on the next chord since they had to be added to the _/__ tied notes.

What does qqq mean? I would use a single q in this case.

[bel28kent]

I added the same number of qs as the number of beams. I did this after I first converted the krn files from MusicXML because I noticed that there were multiple qs if the note was smaller than an eighth note. Here is a quick example in krn; I encoded it first in Finale and then converted with musicxml2hum.

**kern
*clefG2
*k[]
*C:
*M3/4
=1
8qc/
4c
16qqc/LL
16qqc/
16qqc/
16qqc/JJ
4c
32qqc/LLL
32qqc/
32qqc/
32qqc/JJJ
4c
==
*-

Though looking at this now, there are two qs for both the 16ths and 32nds.

[craigsapp]

Roughly speaking a single q means an acciaccatura, which is an unaccented note just before the beat, and qq is an appoggiatura or accented grace note which should be played on the beat, stealing time from the note that follows it.

Single q. notes will have a slash on the stem, and qq grace notes will not. Typically groups of grace notes beamed together are the q type (but traditionally do not have a slash through the beam, although there are modern styles that display a slash on the beam of such grace note groups).

Examples:

View in VHV.

The rhythms on grace notes are visual only, and when analyzing the score they are treated as 0 duration notes (due to the presence of the q in the token). For appoggiaturas, they typically indicate the duration to steal from the following note.

[bel28kent]

Okay. I can correct this easily using sed.

[craigsapp]

Also I have a sed-like tool in VHV called shed:

shed -ke "s/qq/q/"

View in VHV.

This will convert qq to q in all data tokens in the file (but not changing "qq" in comments or reference records, or interpretations. If you have humlib tools installed on the command-line you could do this in a directory:

for file in *.krn
do
     echo processing $file
     shed -ke "s/qqq/q/" $file > $file.temp && mv $file.temp $file
done

The -k option will only process **kern spines (ignoring "qqq" in any other spine types (so it is safer in general than plain sed, although I doubt you have "qqq" anywhere else in the files).

[bel28kent]

Tie issue now subsumed under issue for 2.1 round of edits as it is effectively a subspine issue.