Hey Han Wen,
I'm responding to your e-mail backwards, with answers to the technical parts
first followed by answers to the broader questions you raise.
> Can you try a minimal implementation first? For example,
>
> * Have a stem property that determines the end of the stem. Currently, we have
>
> y2 = Staff_symbol_referencer::get_position (lh);
>
The problem with this is that the stem's direction needs to be known by other
grobs before the print function is called (before line breaking, even). This
could result in the scenario where the stem has the correct terminus but the
direction is based on whatever the original fictive note position was, leading
to stems that don't go the way one would expect them to go given their terminal
point w/ the glissando.
> * Have a mechanism for glissando engraver to ignore note-heads. Maybe
> a boolean property: #'glissando-note
>
This would be necessary - it is part of the current patch.
> Then, in your .ly file you do the following
>
> * Have an engraver (by preference written in Scheme) that hooks up the
> glissandi with the stems.
>
> * Create normal beamed 16th notes with #'glissando-note on their note-heads.
>
> * Hook a callback on that, that looks at the glissando's slope and the
> stem's X position to determine where the stem starts printing
>
> * Make the noteheads very small and invisible.
>
This was what I originally did, but the crucial issue that arises is that of
stem direction. Left to its own devices, Lily will pick the direction of
whatever original arbitrary pitch was chosen, which may be nowhere near where
the glissando actually falls. Even if a typesetter does her best to estimate
this meetup point, it cannot be guaranteed, forcing the typesetter to manually
set the direction of any problematic stems (and re-set the direction of the
length of the glissando changes because of activity in other staves & changes
to the horizontal spacing).
>
> Honestly, I cannot allow this patch in its current design. I don't see
> a reason for an obscure feature to be touching code of note-spacing,
> stem-tremolo, stem, beam etc.
>
You say that this is obscure, but this is a staple feature of innumerable
contemporary scores. I encourage you to read through works for strings written
by Helmut Lachenmann, Chaya Czernowin, Karlheinz Stockhausen, Mark Applebaum,
Roger Reynolds, and Iannis Xenakis, just for starters. You will find this
notation all over their music. This is only obscure to a person if
contemporary music is obscure to that person.
The goal is not to change note-spacing, stem-tremolos, stems, or beams, but
rather to find intelligent exceptions to their default mechanisms that
accommodate these stems.
> If we add patches like this for every composer's favorite avant-garde
> notation, the large parts of the lilypond codebase will shortly become
> a tangle of hard to understand dependencies;
I agree. In order to make the distinction between people's pet projects in
notation land (which I do on the side, outside of my lilypond development
efforts - check out my graphical notation stuff, for example, which I would
never want to include in LilyPond) and essential advancements in contemporary
musical writing and typesetting, I would encourage you to do the survey of the
above literature. After having done so, you would be empirically obliged to
acknowledge that what I'm proposing is a favorite of almost everybody.
> code for uncommon
> notation constructs should only be added if their implementation is
> separate, modular and generic.
Early music particularities find their way into the heart of the code, as do
those having to do with feathered beams (which I'm glad you added to LilyPond
(and which are as obscure as (if not more than) glissando stems in the
contemporary repertoire)), both of which only apply to a certain swath of
music. I think there is nothing wrong with hardcoding something into the guts
of LilyPond, with ample comments, if it allows LilyPond to perform better for
an important aspect of musical engraving. Lest one stand in opposition to
several Pulitzer Prize winning pieces and many-a Guggenheim fellow, glissando
stems are unambiguously important.
Making LilyPond modular is a good idea (I'm all for porting as much to scheme
as possible), and separate comes with modular, but I do not see any way to do
it here outside of what I've already done (most of the work is done in one
callback linked up to glissando-stem). As for generic, this seems to be a
generic approach - using a Stem (generic) to serve multiple functions instead
of creating a new grob that code dups a fair bit of its functionality.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
