[Top][All Lists]

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

Re: [Lilypond-auto] Issue 2584 in lilypond: please make partcombine merg

From: lilypond
Subject: Re: [Lilypond-auto] Issue 2584 in lilypond: please make partcombine merge slurs
Date: Sun, 03 Jun 2012 09:11:38 +0000

Comment #7 on issue 2584 by address@hidden: please make partcombine merge slurs

The description of the patch states that the partcombiner can produce the following kind of patterns:
{ c(( d)) } or { c(( d) } or { c( d)) }
I have a hard time swallowing that we should consider all that valid input without the need of a warning. In particular, if
{ c(( d) }
is supposed to be valid, and
{ c(( f) e) }
is also supposed to be valid, then there is no way whatsoever to guess whether
{ c(( f))( e) }
is supposed to be reduced to
{ c( f)( e) }
{ c(( f)( e)) }

So I think that this _can't_ reliably be fixed in the slur engraver alone. Instead we need to make the partcombiner produce sane patterns given sane input. The patterns that currently come out of it _can't_ be interpreted without ambiguity.

The slur engraver current has to work with garbage-in from the partcombiner, and it has changed the cases where it produces garbage-out. Since the partcombiner never produced anything but garbage, I have a hard time picturing this as a regression. It is just that we now deal differently with a problem that is impossible to solve given the unchanged output of the partcombiner.

reply via email to

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