[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SMuFL name mapping update, 17 December
From: |
Owen Lamb |
Subject: |
Re: SMuFL name mapping update, 17 December |
Date: |
Mon, 31 Jan 2022 23:40:05 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: SMuFL name mapping update, 17 December,
Owen Lamb <=