Re: Adds glissando stems to Lilypond. (issue4661061)

[Graham Percival]

On Fri, Jul 01, 2011 at 07:17:08PM +0200, address@hidden wrote:
>    I'm responding to your e-mail backwards, with answers to the technical
>    parts first followed by answers to the broader questions you raise.

I'll briefly comment on those broader questions.

>      * Have an engraver (by preference written in Scheme) that hooks up the
>      glissandi with the stems.

This might be an ideal way forward -- not necessarily with this
specific issue, but as a general means of extending lilypond.  I
think it could be really helpful if we had a few more examples of
how to write + include such scheme engravers.

>    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.

If we want to push the ideal of custom scheme engravers (and I
don't want to assume that we _do_ want to encourage this approach,
although at the moment I can't think of any problems with it),
then perhaps we need more hooks to pass information around, to
allow "programmer" users to avoid such problems with their custom
scheme engravers.

>      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.

I'm not certain about this point -- but I mean this literally,
rather than the "understated British manner" of politely saying "I
disagree".  I am not at all certain how much hard-coding we want,
either in our current code or future code.  I think few people
would argue against a general notion that "separate, modular and
generic" code is good, but such general sayings have a habit of
breaking down when we look at specific cases.


Could we postpone this discussion for a few weeks, and tackle it
as a serious GOP proposal?  I think a good way to approach the
question is by thinking about our *current* code base -- what do
we think about the balance of "specific features vs. generic
mechanisms" in current git?  People naturally assume that if they
follow the existing practices, then a patch will be ok, but I
don't think we should assume that everybody likes the current code
base.

Cheers,
- Graham