Re: SMuFL name mapping update, 17 December

[Owen Lamb]

Hi Jürgen,

Thank you so much! Apologies for the delayed reply.
> *noteheads.uM2, noteheads.dM2*
> IIRC, I have seen these noteheads various times in print (which does 
> not necessarily mean that they are an agreed standard), though I can 
> not immediately find an example to show.  If I remember correctly, 
> e.g. publisher "Möseler Verlag" once published the work "Geborn ist 
> uns Immanuel" from Michael Praetorius in its "Lose Blätter" collection 
> with exactly these noteheads.  I think the idea of these noteheads is 
> that their shape was derived from mensural longa, representing the 
> value of 4 whole notes in transcription to modern notation, but 
> typographically they are used with stem up or down just like modern 
> quarter notes.  However, just because a single publisher uses these 
> notes this way does not necessarily imply that this is widely accepted 
> practice.
> I agree that the stem should be drawn by the C++ code, just like for 
> quarter notes, rather than incorporating it into the font.  However, I 
> guess, since these notes are used extremely seldom, it was not 
> considered worth or desirable to make the rather complex C++ stem 
> drawing code even more complex only for adding these exotic noteheads, 
> but go the much simpler way to add separate glyphs (i.e. kind of dirty 
> hack to save much trouble with the C++ code, at least back then...).
I can't find the edition you're talking about. After a cursory glance at 
the Möseler Verlag editions I found on IMSLP, the longas seem to always 
be square, or else two breves tied over a barline. Would you happen to 
know where I can find their "Lose Blätter" online?

I got a copy of Gould for Christmas, and she doesn't even mention the 
longa. Seems like we've gotten away with setting the standard ourselves, 
if Wikipedia is any indication. At any rate, seems like it's a matter 
for later.

> *scripts.lcomma*
> No, this is not primarily a chant thing.  It already existed before 
> chant implementation of virgula, see commit 
> 8e300d9598c6f54cb18d8bc8cd0458fa1028d8b9 in the LilyPond repository.

That makes things easy, then!

> *scripts.rvarcomma*
> rvarcomma was added specifically for Gregorian Chant.  Maybe it is 
> also useful in contemporary notation, but I do not actually know.

I haven't seen any examples in contemporary notation, so I think I'll 
just file it under chant and call it a day. If someone wants to use it 
in modern notation, certainly nothing will stop them.

> *scripts.lvarcomma*
> lvarcomma was added for reasons of consistency / orthogonality with 
> lcomma (e.g. think of (future) automatic transcription etc.), but I do 
> not know of any specific use in Gregorian Chant.  Probably, it is unused.

Hmm. It would be misleading to leave it the chant section if it's not 
actually attested in chant literature. But where else would it go? I'll 
call it chant for now...

Perhaps what we need is for the documentation to include short 
descriptions of every glyph... but that's a-whole-nother issue. I'll put 
it on the to-do-someday list.

> *noteheads.smedicaea.rvirga, noteheads.smedicaea.virga*
> This is still somewhat in the state "work in progress" (forever?).  
> Have a look at: 
> https://de.wikipedia.org/wiki/Datei:IN.Nos.autem.gloriari.Editio.Medicaea.1890.Pustet.png
> Medicaea has somewhat different engraving rules than Vaticana.  As of 
> now, there is no MedicaeaLigatureEngraver.  When having implemented
> such an engraver, probably there will be no more need for a virga and 
> rvirga, but this is actually not for sure as of now.  Maybe we should
> get rid of these glyphs, but then people will not even be able to 
> typeset something similar as the Medicaea ligature engraver would do.  
> However, my guess is that there is not anyone trying to actually 
> typeset Medicaea with LilyPond.

In that case, I'd certainly vote against needlessly breaking what 
already works! Keeping an incomplete implementation is better than 
removing functionality altogether; I'm sure a hypothetical Medicaea 
engraver of generations hence will agree.

I'll forget calling it an alternate, but I'll keep the wordier name (. 
It will help those few people who happen to use the glyph more than it 
will inconvenience them.

> *noteheads.shufnagel.virga*

Whoo! Thank you for the context.

My only worry was that users of non-LilyPond programs would have some 
trouble using the Medicaea- and Hufnagel-style virga glyphs in other 
SMuFL-endorsing programs if they were not listed as alternates of 
Vaticana versions. But if, as you've shown, there's so much work still 
to be done (and so few programs support both SMuFL and chant anyway), 
it's probably not worth the trouble until someone commits to a 
large-scale improvement/standardization of LilyPond's own chant output. 
I'll forget the alternate idea for now, but leave the glyph names as-is.

> *custodes.**
> Yes, you are right: We use a different system, where 0 = space, 1 = 
> line, and 2 = anywhere.  I just double-checked: This is the way 
> custodes are usually engraved in all relevant Gregorian chant examples 
> that I have access to, with only a few exceptions (that look to me 
> like typographical errors rather than on purpose).  The goal of this 
> system obviously is that the "stem" of the custos always ends in the 
> middle between to staff lines.
> In contrast, mensural notation uses clefs where the 
> Middle/High/Highest or Middle/Low/Lowest system applies.  This is in 
> particular true for mensural works published by Petrucci (maybe he 
> introduced this style of typography?).  However, there is no such 
> system in Gregorian chant notation, as far as I know.  Hence, I 
> consider the six variants of a Custos in SMuFL as a bug -- at least 
> from a Gregorian chant point of view; things might slightly differ for 
> mensural notation; I would have to check that more carefully.

You're right! I just gave my (Vaticana-style) Liber Usualis a look, and 
I found the same result: space vs. line is significant; y position is 
not. As for Mensural--well, that's next on my list. I'll get there soon.

Regards,
Owen