lilypond-devel
[Top][All Lists]
Advanced

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

Re: PATCH -- Dashed Slurs


From: Carl D. Sorensen
Subject: Re: PATCH -- Dashed Slurs
Date: Fri, 17 Apr 2009 13:20:07 -0600



On 4/17/09 1:05 PM, "Neil Puttock" <address@hidden> wrote:

 
> Carl, these are brilliant; they look wonderful.

Thanks for the compliment.
> 
> I'm just looking through the patch at the moment, so I'll post
> comments (mainly trivial things) at Rietveld.  I can't really comment
> on the implementation itself, since the only thing I know about bezier
> sandwiches is that they produce nice slurs and ties in LilyPond. :)

Great.  I'll look forward to seeing your comments.  This is my first big
patch that involves the C++ side of LilyPond.  I started to implement it
in Scheme, and then realized that it would be way better to add the
methods to the Bezier class in C++.  So I did it, and got it to work, but I
have *no* idea what kinds of standards or best practices I may have broken.
> 
> The main thing I'm concerned about is the situation with the current
> style.  I've only tested the patch briefly, but it seems you can't
> revert to constant-thickness curves.  Could we not keep 'dash-fraction
> and 'dash-period for users who don't want variable thickness?  This
> would obviate the need for a convert rule: any user wanting fancy
> slurs or ties would set 'dash-definition, which would override 'dash-*
> settings.

Does anybody *want* constant-thickness slurs or ties?  I thought that
variable thickness was clearly better.  I think that keeping inferior output
to avoid conversion problems is not a good decision.  I'd rather force the
user to make a simple manual change and get the benefit of the improved
layout.  It better presents the quality of LilyPond.  If we allow inferior
layout to hang around, it will be something that people can use to impugn
LilyPond.

Of course, if there is a reason that users *want* constant-thickness slurs
or ties, I could resurrect Lookup::dashed-slur as fixed-thickness-slur.  And
we could define a property \useFixedThicknessDashedSlurs that would allow
the old interface to apply.  But I think that's a lot of messiness for
something I don't think anybody wants.

Also, I think that there will be few (if any) users who will need to make
this syntax change.  The default way of getting dashed slurs and dotted
slurs continues to work as it did before, with no change in the input syntax
required.

Thanks,

Carl






reply via email to

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