[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crash with \repeat ... \alternative and \remove "Bar_engraver" on 2.
Re: Crash with \repeat ... \alternative and \remove "Bar_engraver" on 2.17.26
Sat, 16 Nov 2013 17:29:02 -0800
On Sun, Nov 17, 2013 at 12:15:45AM +0100, David Kastrup wrote:
> What is this good for? I'm debugging on this
> <URL:http://code.google.com/p/lilypond/issues/detail?id=3663> and though
> I've gotten the crash under control, my results are not identical to the
> 2.16 results. I have a hard time deciding whether I should even care.
> Can you spell out an actual application for this that did something
> useful in 2.16? What would the output look like for such a reasonable
By itself, I don't know what it's good for, nor do I have an
example of what the minimal example's output "should" be. It's
an element that is intended to be used simultaneously with other
contexts (melodic, chordal, whatever).
I was working on a lead sheet, and looking for a way to separate
the volta structure, \time changes, rehearsal marks, etc., from
the actual notes, because the notes often repeated, but did so in
unusual parts of the arrangement. So I wanted to separate the
form from the melody.
At some point while I was working, the input file got into a
state which caused Lilypond to crash. I arrived at the minimal
example by process of elimination after I discovered that
Lilypond still crashed when the chordal and melodic staves were
commented out or removed, leaving only the \form. I then
winnowed down the \form variable's music to the smallest example
that would trigger the crash.
A larger example created just today works fine if I define a
simultaneous empty (spacers) melodic staff of a sufficient
If the crash has been resolved, I would agree that the expected
output from the minimal example is inconsequential, and it's
probably difficult to say what output is definitively correct or
incorrect, since there are no bar lines for the volta brackets to
I'm attaching a less-minimal example. Commenting out the sample
melody and using spacer rests, it appears that the crash happens
when the simultaneous music is not long enough to complete the
first ending. Hence s1*15 (and less) crashes, s1*16 (and more)
does not. Perhaps this example will suggest a more specific
"correct" output, but my feeling is that if the crash is fixed,
the issue can probably be closed.
Thank you for taking a look at this.
Description: Text Data