lilypond-devel
[Top][All Lists]
Advanced

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

Re: Some audicious hand-engraved slurs compared to LilyPond


From: David Kastrup
Subject: Re: Some audicious hand-engraved slurs compared to LilyPond
Date: Tue, 03 Dec 2013 16:32:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Mike Solomon <address@hidden> writes:

> On Dec 3, 2013, at 4:51 PM, David Kastrup <address@hidden> wrote:
>
>> Mike Solomon <address@hidden> writes:
>> 
>>> On Dec 3, 2013, at 4:19 PM, David Kastrup <address@hidden> wrote:
>>> 
>>>> David Nalesnik <address@hidden> writes:
>>>> 
>>>> 
>>>> So I wanted to share the slurs, and then LilyPond surprised me with
>>>> awful tuplet numbers.
>>> 
>>> I’m guessing that there are a few things stopping the number from
>>> lining up nicely, but the most glaring one is line 526 of
>>> lily/tuplet-bracket.cc, which specifies that tuplet brackets should
>>> not follow kneed beams.
>> 
>> I find the version cranked out when setting
>> TupletBracket.bracket-visibility to ##t quite defensible.
>> 
>> I don't find it defensible that tuplet brackets interfere with tuplet
>> number placement when there are no actual tuplet brackets being typeset.
>
> The logic inside LilyPond is that tuplet numbers should always occupy
> the same position, irrespective of the presence of a tuplet bracket.

I don't think that rule makes any sense since tuplet brackets never
alternate between being present and absent in comparable circumstances.
So there is no way the reader could notice whether they would "occupy
the same position".

> When tuplet brackets are not visible, a phantom one is calculated that
> tuplet numbers are positioned off of.
>
> The EP snippet you’ve found is a good example of a case where this
> rule breaks down.

What makes this case here fabulously bad is that the phantom tuplet
bracket anchors to the beam on its left and to a notehead on its right.

> My gut feeling is that tuplet numbers for kneed beams should follow
> the beam if the bracket is not visible and if there is no collision
> between a stem and the tuplet number.  Perhaps this is generalizable
> to a bigger class of tuplet numbers, but that’s what comes to mind for
> now.
>
> To get placement of the tuplet number like the EP snippet, one can do
> \override TupletBracket.direction = #UP.  This results in ugly slurs
> and a collision between the septuplet figure and the B-flat…belch…

This is a backend case where LilyPond falls flat on its face _after_
understanding properly what is wanted from it.

-- 
David Kastrup



reply via email to

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