WolfgangDrescher / lassus-geistliche-psalmen

Digital edition of «Geistliche Psalmen mit dreyen Stimmen» by Orlandus and Rudolphus Lassus. Encoded in Humdrum (Kern).
https://lassus.mh-freiburg.de
3 stars 1 forks source link

Terminal long notes #4

Open craigsapp opened 2 years ago

craigsapp commented 2 years ago

Here is some extra info for the terminal long RDF marker:

!!!RDF**kern: l = long note in original notation

That description is OK, but usually I use:

!!!RDF**kern: l = terminal long

And I usually reserve it for ends of pieces, as well as medial cadences where they are also used.

The main advantage of this is to allow the last note of the composition to look similar to the original edition, but in the modern score. In mensural music the different parts may end at different times, so the "terminal long" is functioning as a fermata on the last note (so everyone holds their last note until all parts get to the end).

I encode the duration of the last note to be one measure (typically the duration of a breve, as you are doing) — since this note is more of a fermata rather than a real long. (You are doing the same as I do). If the last note does not start at the end of the breve cycle (measure), then I only give it the duration to fill in the rest of the measure.

A feature I added a few months ago is to allow for "terminal maxima" by doubling the ll marker:

Screen Shot 2022-03-05 at 10 12 41 PM Screen Shot 2022-03-05 at 10 13 09 PM Screen Shot 2022-03-05 at 10 14 29 PM Screen Shot 2022-03-05 at 10 14 36 PM

So if you want a very diplomatic encoding, you can differentiate easily using this system. I find no rhyme or reason to which is used, and I find in the demo volume example given at the bottom of the IIIF bounding box issue that there can be a terminal long in one part and a terminal maxima in the other part (but clearly they are supposed to have the same duration). And there are cases in the same volume where a terminal long is used rather than a maxima just because there are too many notes on the last line of music (so just to save space).

Here are terminal long and maximas from your source edition:

Screen Shot 2022-03-05 at 10 05 31 PM Screen Shot 2022-03-05 at 10 06 09 PM
WolfgangDrescher commented 2 years ago

Is it intended that the stem of the maxima is always down?

https://verovio.humdrum.org/?github=WolfgangDrescher/lassus-geistliche-psalmen/kern/01-beatus-vir.krn https://verovio.humdrum.org/?github=WolfgangDrescher/lassus-geistliche-psalmen/kern/02-quare-fremuerunt-gentes.krn

=28 =28 =28 =28 =28 =28
0cll    ten.    0ell    ten.    0gll    ten.
==  ==  ==  ==  ==  ==
*-  *-  *-  *-  *-  *-

Sure I can make it manually, but I'm not sure if this behavior is expected:

=28 =28 =28 =28 =28 =28
0cll    ten.    0ell    ten.    0gll/   ten.
==  ==  ==  ==  ==  ==
*-  *-  *-  *-  *-  *-

Funnily enough, with my source, the note stems usually go up on the middle line, but not with the maxima at the end of the piece.

craigsapp commented 2 years ago

I think that is a behavior of verovio (and I think I was contemplating calculating the stem direction automaticaly in the Humdrum-to-MEI converter, and I may have an issue about this on verovio -- I think I made an issue for long note stem directions, but maximas were probably not considered at the time since JRP and TiMP do not have a lot of maximas).

One way to make it somewhat automatic would be to use the autostem tool:

!!!filter: autostem

(this would be added not to the score, but in the Javascript code that is about to send the score to verovio).

WolfgangDrescher commented 2 years ago

I found https://github.com/humdrum-tools/verovio-humdrum-viewer/issues/637. Is this already merged? I wanted to check what the problem could be with the stems but I cannot find it in version-3.9.0.

WolfgangDrescher commented 2 years ago

Related: https://github.com/rism-digital/verovio/issues/1511

WolfgangDrescher commented 1 year ago

I opened https://github.com/rism-digital/verovio/issues/3193 to address problems with the stem direction for maxima.