Juergen Reuter wrote:
I tried a similar approach long time ago around 1.9.x, but I failed,
since I would have needed to duplicate much code around the note head
engraver (e.g. handling of articulation scripts, ...). However, lily
has changed a lot since then; hence, it may be worth trying again.
I doubt that you used this approach. If you give the note heads (or
Note_columns) X-parents they are not put on the new PaperColumns. If you
attach scripts to note-heads (which is done by default, IIRC) with
grob::set_parent(), then the scripts are always over the heads,
whereever they are moved.
For engravers, code reuse through shared super classes has always had
bad results. So, derive the engraver directly from the Engraver class.
Well, the original idea was to have not only a vaticana engraver, but
also a medicea engraver, a gothic neumes (hufnagel) engraver, maybe even
an adiastematic neumes engraver, etc. In that case, the amount of code
reuse would have been rather tremendously.
"would have been" is an example of the YAGNI principle of programming.
Code reuse is something you demonstrate by folding down common cases,
thereby diminishing complexity. If you do it beforehand, the glue to
achieve it mostly takes up more space than the reuse saves.
Please notice the idea of stacked abstraction layers. Gregorian chant
notation exists in a plethora of notational styles. If you write down
the same piece once in Vaticana style and once in gothic neumes, the
non-professional reader possibly would not even recognize that it is the
same piece of music. However, the syntax was designed to be the same
for all common notational styles, such that you e.g. can switch between
them by just adding/removing a proper engraver to/from the voice context
(though this has not been proven so far since the gothic neumes engraver
has not yet been implemented). This goal is achieved by internally
breaking down complex neumes into primitive ones, e.g. porrectus into
flexa+pes, or epiphonus into pes+deminutum. The intention is to share
this approach between all Gregorian chant notation flavours. The shared
super classes reflect this intention of hierarchical abstraction.
I'm not saying that different chant notations are unrelated. I'm just
saying that implementation inheritance is not the way to write
engravers. Breaking down ligatures in primitives does not necessitate
C++ class inheritance.
What about the spacing *between* ligature items? Even with packed and
raggedright options, lily's spacing engine heavily depends on note
durations, while neumes per se do not have any fixed duration.
If you put all neumes on a single X-axis group, they are spaced with
fixed distances. Spacing separate neumes/ligatures is a different issue,
but it would be a fairly local problem, architecturally. Let's work on
one problem at a time.
This requires far more work, afaics. Btw., interaction between lyrics
and breath marks is also required for correct aligning of directive
signs like versus, responsio, etc. Maybe the stanza number engraver can
be generalized to handle such things; conceptually, stanza numbers are
strongly related.
The stanza engraver just puts numbers next to lyric syllables, so I
doubt that it would the right place to start.
Punctum-mora stacking: Punctum-mora (dots) should stack nicely.
Right. This task is similar to the accidental engraving: you have to
collect all dots and put them behind the ligature aligned in a column.
For mensural music, however, you often find the dots printed above the
ligature. So, in general, you should be able to easily switch between
these two modes plus the conventional mode of dot engraving.
This sounds suspiciously similar to aligning dots after note heads.
What's the difference.
Accidental engraving: Should act as mentioned in the TODO in
coherent-ligature-engraver.cc.
I tried to write an according patch two months ago, but unfortunately I
failed. I guess the main problem is that my code can deliver the
accidentals in a bunch only after the ligature has finished, while lily
seems to require the accidentals to be announced much earlier. I also
had to duplicate some amount of private data structures and code of the
accidentals related engravers...
You can create an LigatureAccidentalPositioning item, at the same time
as the ligature, and then fill that with the appropriate accidentals.
If the positioning item is an X-axis group, it should work.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
