Re: Lilypond crash related to tuplets

[Aaron Hill]

On 2019-03-23 5:46 pm, Andrew Bernard wrote:
> Hi Aaron,
>
> I know it would be great to see my code, but the quartet is 11,000 
> lines
> long and that's only half, and my library of which I use everything is
> 13,000 lines of code (for all the New Complexity stuff). I would never
> expect anybody to go through it, let alone set it all up for compiling.
>
> I am unable to extract an MWE from the score that proves it. However, 
> being
> clued in to a possible issue around tuplets, I found the issue by trial 
> and
> error rather than gdb. Here it is: calling tupletFullLengthNote = ##t
> causes the crash. This is definite. But it only occurs in my reasonably
> large score. I am unable to stimulate this in a simple example.
>
> Does knowing that combined with the gdb backtrace help pinpoint this?

Yes.  The issue is as I mentioned in my pathological example.

You may be able to counteract the effects by reducing break-overshoot 
and/or full-length-padding:

%%%%
%% Here are the defaults.
% \override TupletBracket.break-overshoot = #'(-0.5 . 0)
% \override TupletBracket.full-length-padding = #1

\override TupletBracket.break-overshoot = #'(-0.25 . 0)
\override TupletBracket.full-length-padding = #0.5
%%%%

Alternately, you could patch the behavior by correcting the invalid 
intervals when they show up:

%%%%
\override TupletBracket.X-positions = #(lambda (grob)
  (let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
    (if (> (car xpos) (cdr xpos))
      (let ((mid (/ (+ (car xpos) (cdr xpos)) 2)))
        (format #t "\nwarning: Fixing invalid X-positions ~a" xpos)
        (cons mid mid))
      xpos)))
%%%%

This variant of my prior procedure opts to use the artificial "center" 
of the invalid interval as the result.

-- Aaron Hill