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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
