gnu-music-discuss
[Top][All Lists]
Advanced

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

Re: Lily and Plainsong


From: Mats Bengtsson
Subject: Re: Lily and Plainsong
Date: Fri, 03 Aug 2001 16:35:24 +0200

I don't know much on plainsong ligatures and have somewhat limited
experience of the inner workings of Lilypond, but can't help sharing
my 5 cents.

> > Following on the same vein. I felt that to do something as common in
> > this type of music as a half-height bar needed more native support than
> > having to set and reset the bar-size property every time. 
> 
> That's fine, but please do not call it '\bar "|/2"', but, according to
> common standards, rather "\divisio minor" (which actually does not
> look like a bar with 1/2 of full size, but rather like one with 2/3 of
> full size).  By the way, according to your syntax, how would you call a
> "\divisio maxima" (I guess '\bar "|"'), "\divisio minima" (which looks
> pretty the same like a "\breathe"), and "\finalis" (I guess '\bar
> "||")?  Please also note that, in musical sense, divisiones are rests
> rather than bars.  So even if we internally (mis-)use the bar engraver
> and breathing sign engraver to avoid duplicate code, in terms of
> mudela input syntax, we really should name it differently.  And we
> should not forget that, at some point in the future, we may want to
> implement a divisio performer that inserts rests into midi files.

Isn't it easy to implement this using a macro like

divisionMinima = \notes{
  \property Staff.BarLine \override #'bar-size = ...
  \bar "|"
  \property Staff.BarLine \revert #'bar-size
}


> > My Plainsong context is just a renamed Staff context (like
> > RhythmicStaff) with the various properties (like line-count) and
> > engravers set.
> 
> Recently, there was a discussion about templates for different
> notation styles.  Maybe this could be applied for vaticana style
> typesetting rather than introducing a new context just for
> initializing some properties and engravers.  However, I still think
> that we need some ligature context to get the spacing and line
> breaking right, which requires rules other than the standard ones that
> lily currently uses for sequential music.

The idea of a template file is that it should be simple enough
that any user quickly can get an overview of it and understand
how to use it. If it contains lots of strange definitions and
settings, I wouldn't want to use it as a template.

I think it's better to encapsulate such settings in the form 
of a context than as a more or less incomprehensible template
file, if it indeed is possible to solve the problems simply by
introducing a new context. The RhythmicStaffContext is an 
excellent example of the power of the context mechanism. 
Also, don't be afraid of introducing new engravers, if necessary.
What could cause more severe problems is if you are unable to 
use the standard context \type: Engraver_group_engraver.

...
> Since the symbols "(", ")", "[", "]" are already used for beams and
> slurs, I think it is not a good idea to give them a totally different
> meaning in the context of ligatures.  This would require carefully
> restructuring lily's parser.  Even though in vaticana style ligatures,
> there are no beams or slurs, a modern composer and/or editor might
> want to use slurs nevertheless in combination with vaticana-style
> ligatures.  But you say you are also fine with any other delimiter;
> ok.  For simplicity, in the below examples I stick to your () and [].
> But you need an additional delimiter for liagtures like flexa and
> torculus.  For simplicity, let's take {}, but in practice, that would
> also have to be replaced by some other delimiter.  And you need
> delimiters for a porrectus.  Let's take <>.

One trick to extend the number of possible delimiters is to 
add a backslash: \[ \], \( \), \< \> (hmm, that one's already used).
If you're unlucky, you may have to introduce another input mode
besides the current \notes, \lyrics and \chords, that interprets
the symbols in some special way. 


   /Mats





reply via email to

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