lilypond-devel
[Top][All Lists]
Advanced

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

Re: recent beaming change?


From: Trevor Daniels
Subject: Re: recent beaming change?
Date: Sun, 26 Apr 2009 15:31:39 +0100


Patrick McCarty wrote Re: recent beaming change?


On Sat, Apr 25, 2009 at 8:31 AM, Andrew Hawryluk <address@hidden> wrote:
My latest LilyPond build (2.13.1, 24 Apr 2009) produces different
beaming than my last build.

e.g. {c''8 c'' c'' c''}
used to produce |_|_|_|
and now it gives me |_| |_|

Was this intentional?

Yes, this was changed recently. The reasons are listed here:

http://lists.gnu.org/archive/html/bug-lilypond/2009-03/msg00126.html

I don't know if the plans to revise the auto-beaming code (being
discussed by Carl, Trevor, and Neil) will address this issue.
Clearly, it would be better to allow for this "special case", since

|_|_|_|

is much more common than

|_| |_|

Oops.  I should elaborate a little more about this.

The first beaming pattern used to be the default in certain cases
(e.g. 4/4 time on beats 1 and 3), and this beaming pattern can still
be used by modifying beatLength, as Trevor described.

But it is reasonable to expect users to use "\set beatLength =
#(ly:make-moment 1 2)" if they want the first beaming pattern, which
is more common?

I can only repeat what I said in the thread referenced above, namely
that the new default permits the correct beaming of

\relative c'' {
a16 a a8 a a
a8 a16 a a8 a
a8 a a16 a a8
a8 a a a16 a  % beaming is different
}

Also, it seems easier to set beatLength to go from 2 to 4 beamed
quavers than to revert auto-beaming rules if you wanted 2 rather
than 4 beamed quavers.  Lily can't do both by default, and I think
the new behaviour makes the better compromise.  I tried to reduce
the number of auto-beaming rules to minimise the need to revert
them.  But I'm quite happy to change the beaming rules back if a
majority of users prefer the old default.

That said, Carl is still hoping to unify the behaviour which would
make overrides to the beaming behaviour far more rational.

Trevor





reply via email to

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