Re: Draft: Extended mensural notation support

[Lukas Pietsch]

David Kastrup <dak <at> gnu.org> writes:

> You state "The notation samples, which include numerous highly uncommon
> and idiosyncratic forms, will be encoded in the corpus in an XML-based
> format".  If the forms are highly uncommon and idiosyncratic, can they
> be described by an XML-based expressions that are _not_ highly uncommon
> and idiosyncratic?
> 
> For me the most important question arising is not as much whether we
> should merge your support for a particular set of uncommon and
> idiosyncratic notation, but rather what kind of support we would need in
> LilyPond such that this and other forms of uncommon and idiosyncratic
> notations can be supported _without_ recompilation of LilyPond.
> 
> Do you have an idea how LilyPond could be generally better for such
> tasks out of the box?
> 

Indeed, I quite agree it's a matter of how best to make the basic Lilypond
system most efficiently extendable. I'd like to think of what I'm proposing
as a thing with two layers. 

There is a set of core functional extensions that will just enhance the
coverage of standard features of mensural notation: an improved glyph set
for mainstream white notation, support for mainstream black notation, a
consistent and user-friendly set of commands for such things as
perfect/imperfect meters, rests, coloration and so on. This will be standard
stuff and useful for all users of mensural notation. 99% of it will be
implemented either in Metafont or in a Scheme stylesheet, which a user will
be able to simply "include" (just as they now "include gregorian.ly" to get
quadratic notation). There are only a very few small patches to the C++ code
that will be needed to support this, and they should be easy enough to merge
into the standard distribution without affecting anything else.

The second layer is a general support mechanism that provides an
infrastructure for adding further, user-defined features such as additional
alternative glyph sets, non-standard note shapes and so on. Think of it as
similar to the way "shape notes" are implemented now: a standard extension
mechanism that allows users to define their own new sets of noteheads on the
fly. The idiosyncratic features required by the TML project will be
implemented as one such set of user-defined extensions. The standard
distribution merely needs to provide the general functional infrastructure
for it. That, too, can be done entirely in Scheme; no further changes in the
C++ codebase are needed for it beyond those mentioned above. 

Best
Lukas