Re: weird error with \repeat tremolo

[Aaron Hill]

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.

Note that manually setting the beam positions does not help as this 
effects things *after* the programming error has already happened.  
Meaning, you can change the beam positions all you want, but the default 
values are the ones that matter w.r.t. the failing assertion.  Here we 
force the beam positions into an impossible case that still compiles:

%%%%
\version "2.19.82"
\relative c'' {
  \override Beam.positions = #'(-1.5 . -0.5)
  gis'32_[ e c a d8:64]
}
%%%%

This works because there was enough room for the grobs when the internal 
calculations were occurring.  Afterwards we \overrode what was computed 
to produce the overlapping grobs.

In a previous thread, I showed how Beam.beam-thickness and 
StemTremolo.beam-thickness can impact things.  Here's yet another 
property: Beam.length-fraction.  Again, examine the following which 
includes cases that would fail if the length-fraction were increased:

%%%%
\version "2.19.82"
{
  \override Beam.length-fraction = #1.081
  \relative c'' { gis'32_[ e c a d8:64] }
  \override Beam.length-fraction = #0.986
  \relative c'' { gis'32_[ e c a c8:64] }
  \override Beam.length-fraction = #0.890
  \relative c'' { gis'32_[ e c a b8:64] }
  \override Beam.length-fraction = #0.795
  \relative c'' { gis'32_[ e c a a8:64] }
  \override Beam.length-fraction = #0.711
  \relative c'' { gis'32_[ e c a g8:64] }
  \override Beam.length-fraction = #0.711
  \relative c'' { gis'32_[ e c a fis8:64] }
}
%%%%

Of course, this produces ugly results and is not a good workaround.

But I think I have found a much better workaround.  As I have been 
presuming, the issue has to do with not having enough room for the stem 
length to accommodate both the Beam and StemTremolo grobs.  We need a 
way to tell LilyPond that it can *increase* the stem length as needed.  
This is done by using Stem.details.stem-shorten with negative values.  
Consider the following:

%%%%
\version "2.19.82"
{
  \override Stem.details.stem-shorten = #'(+inf.0)
  \relative c'' { gis'32_[ e c a d8:64] }
  \override Stem.details.stem-shorten = #'(0.176)
  \relative c'' { gis'32_[ e c a c8:64] }
  \override Stem.details.stem-shorten = #'(-0.324)
  \relative c'' { gis'32_[ e c a b8:64] }
  \override Stem.details.stem-shorten = #'(-0.824)
  \relative c'' { gis'32_[ e c a a8:64] }
  \override Stem.details.stem-shorten = #'(-1.324)
  \relative c'' { gis'32_[ e c a g8:64] }
  \override Stem.details.stem-shorten = #'(-1.574)
  \relative c'' { gis'32_[ e c a fis8:64] }
}
%%%%

There is an interesting pattern that shows up.  Most of these limit 
values are exactly 0.5 away from each other, which makes a lot of sense 
when you consider that the notes are half a staff space apart.

The final result is not perfect, as we would expect a degree of 
shortening to occur on beamed notes.  But that can be trivially fixed:

%%%%
\version "2.19.82"
{
  \override Stem.details.stem-shorten = #'(-1.574)
  \override Beam.positions = #'(-3 . -5.5)
  \relative c'' { gis'32_[ e c a fis8:64] }
}
%%%%


-- Aaron Hill