lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GSoC 2020: Shape-note notehead encoding


From: Owen Lamb
Subject: GSoC 2020: Shape-note notehead encoding
Date: Mon, 20 Jul 2020 18:36:56 -0700

Hi all,

LilyPond's catalog of shape-note noteheads is unique because it contains
three full sets of noteheads--Aikin (default), Funk, and Walker. Even if
some noteheads are similar between the three sets, they are
deliberately defined separately and have slightly different looks.* SMuFL
has no provision for this: it defines only one set of shape-note noteheads
for all three styles.

My current plan is to define the Aikin noteheads as described in the SMuFL
specs, while the other two sets will be stylistic alternates with "Funk" or
"Walker" appended to their SMuFL names. When LilyPond needs one of the
latter styles, it can try to look for these alternate glyphs first, and, if
they are not found, resort to the base glyphs SMuFL defines.

The real issue is how other programs are going to read Emmentaler's full
Funk and Walker sets. They will expect e.g. noteShapeKeystoneBlack, a
Walker-only glyph, to be found somewhere in the font, but at this point
only noteShapeKeystoneBlackWalker (u2doWalker) has been defined.

One solution is to give our versions of such glyphs a secondary Unicode
codepoint where SMuFL expects it. However, it would look off compared to
the other glyphs, which would automatically be taken from our Aikin set.

Another solution is to describe Walker and Funk as style sets. This will
allow other programs to throw an error when, e.g. noteShapeKeystoneBlack
isn't found in the font, notifying the user that something's wrong. If the
correct styleset is used, the program will correctly display every notehead
in that style. This would probably require documentation so that Emmentaler
users know that the alternate styles are there in the first place.

A third solution is to request that the Funk and Walter systems be encoded
in SMuFL separately from the main set. But of course that's a tall order,
and on top of that we'd force Emmentaler users to wait until their program
of choice updates to the new version of SMuFL, if it ever does.

I'm leaning toward the second option, but I'm open to suggestions. Out of
these three (or any others you can think of), what do you all think would
work the best?

Thanks,
Owen

* (para. 1) With the exception that Walker has no "so", using Funk's
instead.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]