[Top][All Lists]

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

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

From: David Kastrup
Subject: Re: \override Beam #'consistent-slope = ##t should be default
Date: Sat, 22 Oct 2011 11:55:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

"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

reply via email to

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