[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lilypond crash related to tuplets

From: Aaron Hill
Subject: Re: Lilypond crash related to tuplets
Date: Sat, 23 Mar 2019 18:01:28 -0700
User-agent: Roundcube Webmail/1.3.8

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))

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

-- Aaron Hill

reply via email to

[Prev in Thread] Current Thread [Next in Thread]