Re: weird error with \repeat tremolo

[David Kastrup]

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.

-- 
David Kastrup