Re: Adds glissando stems to Lilypond. (issue4661061)

[address@hidden]

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