Re: Some audicious hand-engraved slurs compared to LilyPond

[Mike Solomon]

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

Cheers,
MS