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

[address@hidden]

On Oct 22, 2011, at 11:55 AM, David Kastrup wrote:

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

This is true.

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

I see you raising two issues here:

1) Automating when broken slopes are kept consistent.  I agree that it'd be 
great if LilyPond could decide when this'll happen with respect to certain 
parameters, but I'm not sure what those parameters would be.  Based on my 
experience in the contemporary literature (I'm thinking of the 2nd Boulez 
Sonata), consistent slopes is always the case.  I think LilyPond's old output 
was not as much an aesthetic choice as a lack of an implemented feature.  Thus, 
I would be for getting rid of the property and making it the default, but I'd 
need more evidence showing that the default comes up nowhere in the literature.
2) As for the light spring, I think you're right (the Bartok 2nd string quartet 
on IMSLP, for example, has light differences between the cut points in broken 
beams), but I also think that:
 a)  The extreme that consistent-broken-slopes brings is closer to that which 
is found in the literature.
 b)  It will be easier to code the subtleties that are in the literature now 
that this feature is implemented.

Cheers,
MS

> -- 
> David Kastrup
> 
> 
> _______________________________________________
> bug-lilypond mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-lilypond