Re: \override Beam #'consistent-slope = ##t should be default

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Oct 21, 2011, at 6:15 PM, David Kastrup wrote:
>
>> 
>> commit 1d9a73b13ee576d28c0f41f5b243f2ebb1ff9fcf
>> Author: Mike Solomon <address@hidden>
>> Date:   Fri Oct 21 09:03:43 2011 +0200
>> 
>>    Implements consistent beam slopes across line breaks.
>> 
>> says
>> 
>>    To turn on this feature, use \override Beam #'consistent-slope = ##t.
>> 
>> I think that is a mistake: unbroken beams naturally have consistent
>> slope.  So when breaking a beam across lines, Lilypond already gets to
>> play with stem lengths to make the broken output strictly better than
>> the unbroken output was.
>> 
>> The best output might conceivingly be achieved by very slightly relaxing
>> slope consistency.  As long as we have no button for that, not relaxing
>> it is a much saner visual choice than totally discarding it.
>> 
>> I would not even offer a settable property for this as long as the only
>> options are on and off.
>> 
>
>
> Compile beam-feather-breaking.ly in input/regression with and without
> this property - I think that the visual output changes enough to merit
> the on/off existing in LilyPond, no?

Apart from breaking the documentation, this patch does not really reach
the finishing line.  First, the property actually is called
consistent-broken-slope.  Second, it is quite obvious from the output
that it does _not_ merely keep the slope consistent, but additionally
the vertical position.

Of course, this _does_ change the quality of the output.  The vertical
positions of the broken beams should be kept together with a light
spring at most.

If the vertical positions are tied together rigidly, the user gets the
choice between two suboptimal extremes: detrimental overconsistency, or
total non-consistency.

Picking the detrimental overconsistency only makes sense if by chance
the beam slopes would be similar anyway.  Which is the case in
beam-feather-breaking.ly.  But it should not be the task of the user to
determine this and flip a switch accordingly.

-- 
David Kastrup