Aaron Hill <address@hidden> writes:
On 2019-03-06 4:15 am, N. Andrew Walsh wrote:
Hi Aaron,
here's another example that causes the error:
\version "2.19.82"
\relative c'' {
\time 4/16
gis'32[ e c a \repeat tremolo 8 { fis64] }
}
Again, it seems related to collisions between beams and tremolo
glyphs. But
here, the 32nd-notes should force the bottom beam low enough that
there's
room for them, yet for whatever reason it fails anyway.
It doesn't force the beam low enough. That is because your sequence
of notes prefers a stem-down beaming which means that the final note
will have the shortest stem length. If you manually switch to stem-up
(i.e. use "^[") then it works fine because there is enough length.
Sticking with stem-down behavior, you would have to raise the F# up
minimally to the high D:
%%%%
\version "2.19.82"
\relative c'' { gis'32_[ e c a d8:64] }
%%%%
This will fail on any note in between.
Well, we have a failed assertion error. Failed assertions mean that
there is a condition that the programmer does not expect possible to
occur in a score and that makes it likely internal data is corrupted to
a degree where continuing would be unsafe.
Since you can come up with a description of what causes this problem to
occur, it should be possible to devise and implement a safe strategy
for
the program to continue.
This would take one of three options:
a) output is as good as can be reasonably expected given the input ->
just do it
b) output is bad, to be expected given the input -> do it, give a
warning
c) output is bad, not to be expected by the user given the input ->
do it, give a warning or possibly a programming error
d) output is likely bad, we don't know how the condition came about but
can continue safely -> do it, give a programming error
Something like that.