lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6


From: dak
Subject: Re: Issue 2584 (redo 1967): please make partcombine merge slurs (issue 6294047)
Date: Fri, 08 Jun 2012 08:24:55 +0000

Reviewers: Keith,

Message:
On 2012/06/08 08:02:02, Keith wrote:
Works good for me.

You might consider three commits
revert b986b3
fix 1967 and 1884 thoroughly
let c(_(^( e) engrave a double slur, bzw phrasing slur

Oh, 1884 was also on the loose?  I have two commits here, the first
being the revert, the second everything else.  The double slur logic is
not really separate from the rest: it is a consequence of dealing with
all cases.  Designing an artificial second commit with different
behavior would require writing the logic more or less from scratch and
making a decision under which circumstances which directions are to
survive.  How to merge an undirected and a directed slur?  If you
actually check, and keep the directed slur, then it seems awkward to
drop one of conflicting directed slurs.  If you don't check and just
keep the first of several slurs, this looks like a defect artificially
left in place for a single commit.

Keeping two slurs around in the case of _(^( is not as much a planned
feature than a consequence of trying to get consistent behavior for
multiple slur starts.  If you have a combination of - _ ^ on the _same_
event (for example, by doing -\tweak ... ^\tweak ... _ ...), the last
explicit direction to be applied to the event (so usually the first in
sequence) wins.

The problem with applying this logic also here is that "last" is rather
ill-defined with regard to parallel events.  Creating a second commit
means having to make decisions and write logic implementing a choice I
consciously avoided having to make.

In contrast, the separate commit reverting the original "fix" is a
no-brainer, and indeed that is what my feature branch looks like at the
moment.

Description:
Issue 2584 (redo 1967): please make partcombine merge slurs

The partcombiner does not really bother about keeping the number of
generated start and end slur events matched, so this attempts to cope
by implementing the following behavior:

a) multiple slur starts on the same moment are not an error but the
   same as one.
b) multiple slur ends on the same moment are not an error but the same
   as one.
a2) there will be a slur with direction UP if there is at least one
   such start event, and there will be a slur with direction DOWN if
   there is at least one such end event.  This might imply a double
   slur, but for ending it, a single slur end is sufficient.

Consequently, a^(_( c)) (the second closing paren not required, just
added for prettiness) will add a double slur.

Revert "Allow multiple identical slurs (issue 1967)"

This reverts commit b986b38f14195f31e26b0a929c8ac23a8ecfc204.

Conflicts:

        lily/slur-engraver.cc

Please review this at http://codereview.appspot.com/6294047/

Affected files:
  M input/regression/phrasing-slur-multiple.ly
  M input/regression/slur-multiple.ly
  M lily/phrasing-slur-engraver.cc
  M lily/slur-engraver.cc





reply via email to

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