Re: Issue 3560: Completion_heads_engraver with \scaleDurations (issue 14268043)

[k-ohara5a5a]

On 2013/11/01 20:20:35, dak wrote:
> On 2013/10/26 06:37:13, Keith wrote:
> > The simplicity is just lovely.

> Always hard to tell sarcasm from enthusiasm.

This patch does simplify things -- especially in comparison to the
version that changed behavior based on scale-factors being integral
multiples of things.  Only history makes things complicated.


https://codereview.appspot.com/14268043/diff/9001/ly/engraver-init.ly#newcode637
> > ly/engraver-init.ly:637: completionFactor = #ly:duration-scale
> > We do need to keep issue 1532 fixed, since several people depend on
and expect
> > that behavior.
> >
> > %% Historically, completion_heads_engraver has split integer-scaled
> > %% notes into notes with no scaling   c1*3  ==>  {c1~ c1~ c1~}
> >   completionFactor = #
> >   (lambda (dur)
> >     (let ((scale (ly:duration-scale dur)))
> >          (if (integer? scale)
> >               1
> >               scale)))

> Now that does not change that having to crank out some anonymous
> lambda function for some common behavior is a bad idea.  At least the
> previous default behavior should be available as a stock function, and
> one can conceivably teach convert-ly to continue providing the old
> inconsistent behavior via an appropriate assignment whenever one of
> the completion engravers is being used.  Please remember that this old
> behavior is _also_ not what "people" expected, or we would not be
> having this issue.

The function above provides the old behavior.

You could make the C-code fall-back to the consistent behavior if
someone un-defines 'completionFactor'
 factor_ = robust_scm2rational("completionFactor", note_dur.factor());
Then I'll update the docs patch at
http://codereview.appspot.com/14633043
so the known-issue just says "Historically, blah blah...  \unset
completionFactor removes this inconsistency."

https://codereview.appspot.com/14268043/