lilypond-auto
[Top][All Lists]
Advanced

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

Re: [Lilypond-auto] Issue 3560 in lilypond: Completion_heads_engraver wi


From: lilypond
Subject: Re: [Lilypond-auto] Issue 3560 in lilypond: Completion_heads_engraver with \scaleDurations
Date: Sun, 13 Oct 2013 11:07:52 +0000

Updates:
        Owner: address@hidden

Comment #34 on issue 3560 by address@hidden: Completion_heads_engraver with \scaleDurations
http://code.google.com/p/lilypond/issues/detail?id=3560#c34

there are actually four commits:

commit 1: Create exact-rational? predicate

commit 2: Create completionFactorUnit

commit 3: Change regtests for completion engravers for illustrating issue 3560
(and using completionFactorUnit)

commit 4: Issue 3560: make use of completionFactorUnit in completion engravers

factor out chopping into a base class Completion_engraver_base

Both the Completion_heads_engraver and Completion_rest_engraver have
to make the decision whether to interpret a scale factor on a note
either as actually scaling the note duration itself (similar to
\times/\tuplet) or as a means of specifying an inconvenient length,
like a full bar note in 5/8 time or a multi-measure note (or,
actually, combination of all these).  The completion engravers need to
make an actual decision here.

The previously employed heuristic was that integer scale factors were
interpreted as a multi-measure note while other rational scale
factors implied an actual scaling of the note value.  In the first
case, any durations produced by the completion engravers received a
scale factor of 1, in the second, they inherited the original scale
factor.  The visual note duration needed for filling the measure
depended on the chosen scale factor.

This heuristic led to surprises like issue 1772: the behavior of
issue 1772 was triggered by scale factors like *3/2 but not by *3/1.
Now the heuristic has been dropped, so either scale factor will lead
to the observed behavior.

Since both behaviours are required (see issue 1532), introduce
a means to control the decision explicitly, defaulting to the
existing behaviour.  The device chosen in this patch is
completionFactorUnit.

http://codereview.appspot.com/14640043

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

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