lilypond-devel
[Top][All Lists]
Advanced

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

Re: Draft: Extended mensural notation support


From: David Kastrup
Subject: Re: Draft: Extended mensural notation support
Date: Mon, 23 Feb 2015 21:07:07 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Lukas Pietsch <address@hidden> writes:

> 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.

Sounds really good.

-- 
David Kastrup



reply via email to

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