lilypond-devel
[Top][All Lists]
Advanced

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

Re: Lily and Plainsong


From: Juergen Reuter
Subject: Re: Lily and Plainsong
Date: Wed, 8 Aug 2001 10:33:27 +0200 (MEST)

Mark Hindley wrote:
> I have spent the weekend trying out your syntax. I actually found it
> less confusing than I had feared.

I am glad to hear that. :-)

> Of course you are right that the different neumes do not have a
> strict implication of different durations. I suppose that to use
> nominal durations as an underlying encoding will just store up
> problems in the future (? midi performance). Might it be worth
> having the neume duration as a crotchet rather than a breve which
> will remove for the need for a\breve at the beginning?

Actually, I assumed that the surrounding context (e.g. "\context
ligature { ... }") automatically selects the correct duration and, at
the end of the context, resets the duration to the value that was last
seen before the start of the context.  (This is yet another reason why
you need some enclosing syntactical construct.)  In other words, I do
not care that much about the concrete nominal duration, as long as it
is the same for all neumes.

Why do you think that midi performance will become a problem when
using nominal durations?  The duration of neumes is context sensitive,
anyway.  For example, it is (at least in Germany) common practice to
lengthen the neume that *precedes* a quilisma.  Neumes at the end of a
phrase are also often lengthened.  Strophicus neumes are usually
joined into a single note event when performed.  So, the midi
implementation must consider neighbouring neumes anyway.

> When you talk of needing a new context for ligatures, do you mean a
> context as in \context Voice or as in \notes{}, \lyrics{} etc?

When I first tried to write some experimental code around 1.3.80
(which, of course, is obsolete now), I recognized that lily's grace
context was very similar to what I was looking for: it gives you an
enclosed area that lily's spacing engine treats as a unit; and lily
did not try to put a line break within a grace context.  And other
than a single molecule, it still allowed you to individually address
notes within the context in a similar way as outside of the context.
Hence, I originally thought of slightly modifying the grace context to
get a ligature context.  However, Han-Wen recently pointed out that
there were many severe issues with the grace context; so it might be
worth to look for alternatives.  In any case, we should have a look at
lily's implementation of grace notes, since this is a somewhat related
topic.

> It has occurred to me that we could actually make do with only 2
> ligature syntaxes. One that requests a porrectus and one for all
> the other paired neumes, the code working out what to print based on
> which note was higher and the note types. Is this quest for
> simplicity going too far? It is certainly common to other parts of
> lily where the `knowledge' is embedded in the code rather than
> expecting the user necessarily to supply it.
>
> eg
>
> g \ligature b                           Podatus
> b \ligature a                           Flexa
> g \ligature \plica b                    Epiphonus
> \virga b \ligature \plica a             Cephalicus
> \virga b \porrectus a \ligature b       Porrectus
>
> This cold even do a Torculus as I don't believe that g \ligature a
> \ligature g could be anything else. (Have I missed something here?)

I think we will get into trouble with this approach.  E.g., what about
scandicus?  There are two forms:

c \pes d \flexa e
c \flexa d \pes e

Anyway, a pes/podatus is definitely a different ligature than a flexa
-- typographically and musicological.  I think we should not try to
merge them into a single type.

> If you also allow a shorthand (say + and =) for the 2 request types
> then I think the syntaxt gets quite compact and easily usable.

Regarding Mats' suggestion to use \<, \>, \(, \), \[, \], \{ and \}, I
could imagine to use \~ rather than \porrectus, in analogy to lily's
~-syntax for ties (remember, a porrectus always connects exactly two
noteheads like a tie).  Similarly, for stacking notes in a
pes/podatus, we could use \^ in analogy to lily's ^-syntax.  I start
liking your idea to use parenthesized syntax for flexa ligatures,
e.g. "\[ c d c \]" instead of "c \flexa d \flexa c".  Actually, I
would prefer a slightly different form like "\flexa { c d c }" or
"\- { c d c }".

As for epiphonus and cephalicus, I still would prefer to denote them
differently.  Especially cephalicus is definitely not a pes/podatus
with just altered note heads: the first (main) note is the one with
the *upper* pitch, while the plica is the one with the lower pitch; in
a pes/podatus, the first note is the one with the *lower* pitch.  I
think, the implementation also would suffer from mangling these
different ligature types into the same piece of code.  But maybe, we
can find some smart abbreviation for "\cephalicus" and "\epiphonus"
(e.g. "\," for cephalicus and "\`" for epiphonus).

Another difference between your approach and mine is the scope of note
head requests.  Your approach is analogous to lily's note duration
scheme: if a note is specified without explicit note head shape, the
shape of the preceding note is used once again.  My approach is to
always use a punctum note head shape, unless the user explicitly
requests something different.  The rationale for my approach is that
most note heads are punctum heads, with often only a single virga or
quilisma in between.  So, the idea of my approach is just to save the
extra "return to punctum note head shape" request.  On the other hand,
in the case of a series of two or three subpunctum note heads, your
approach saves additional subpunctum requests.  To find out which
approach is the more comfortable one, one probably has to type in a
fair amount of ligatures.  So, currently I am in favour of my own
approach, but I might be convinced to become in favour of yours.

For syntactically making a difference between ligatures and note head
requests, I also might be convinced to follow your approach to put the
request after the pitch, even if this makes the implementation
(minimally) more complex (i.e. hacking a few lines of c++ rather than
just writing 4 single-line macros in e.g. init.ly).  Currently, I feel
uncertain about this issue.

Summarizing the above discussion, the update for the ligature table of
my last mail would look like this:

Name                    updated syntax
----                    --------------

Punctum                 c

Virga                   \virga c

Bivirga                 \virga c \virga c

Punctum inclinatum      \subpunctum c

Podatus vel Pes         g \^ b

Clivis vel Flexa        \flexa { \virga b g }

Epiphonus               g \` b

Cephalicus              b \, g

Scandicus               \flexa { g \^ b c }
                        \flexa { g a \^ c }

Salicus                 g b \^ c

Climacus                \virga c \subpunctum b \subpunctum g

Torculus                \flexa { c e c }

Porrectus               \virga e \~ c \^ e

Torculus resupinus      \flexa { c d \~ c \^ d }

Porrectus flexus        \flexa { \virga e \~ c e c }

Pes subpunctis          c \^ e \subpunctum d \subpunctum c

...

                        \flexa { e  f \~ d e c }

Notes:

As you can guess from the scandicus and torculus resupinus example, I
implicitly assume that any "\^" or "\~" overrides any surrounding
"\flexa {}".  Otherwise, one would have to write e.g.:

Scandicus               g \^ \flexa { b c }
                        \flexa { g a } \^ c

which looks a little bit nasty, since the note heads that make up the
pes (g \^ b, respctively a \^ c) are musicologically and graphically
more closely tied than the appended flexa (c, respectively g).

However, I am not at all sure yet about all implications of such a
rule for overriding ligature types; so I will reserve to myself to
change my mind and revert my vote back to the "c \flexa d \flexa c"
style syntax.

> Have you actually started any of the implementation yet?

Quite a long time ago I sent several bugfix patches that made ledger
lines, bar lines and note head positioning working on 4-line staves.
Besides general custos support, so far I contributed the metafont
characters (noteheads, accidentals, clefs, custos).  Other than that,
I have some totally obsolete and incomplete code of around 1.3.80 that
I did not send in as a patch and which you can safely ignore.  So, as
for the aspects we are just discussing, I have not implemented
anything worth mentioning yet.

As I already told, my original plan was to complete the mensural stuff
(enhanced note head shapes, flags, rests) before starting with
vaticana ligatures; but this may still take a couple of weeks
(currently, I am waiting for the note heads patch to make it into the
next release, so that I can merge and update ancient-font.ly and some
other things without requiring yet another merge).

> My quilisma looks much the same, although it is a little flatter

Probably, I should eventually have a look at yours, but currently I
have still the mensural stuff to work on.

> Hope you had a good weekend away.

Thanks, yes, indeed!  (I was canoeing; only the weather could have
been a little bit less rainy...) :-)

Greetings,
            Juergen




reply via email to

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