Re: Lilypond crash related to tuplets

[Thomas Morley]

Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill
<address@hidden>:
>
> On 2019-03-23 6:46 am, Andrew Bernard wrote:
> > What calls calc_x_offset for Tuplet Number?
>
> This likely may be coming from Scheme.  If you look at the Internals
> reference, you will see that the X-offset property for TupletNumber is
> by default set to ly:tuplet-number::calc-x-offset.
>
> That means that if you were to call (ly:grob-property grob 'X-offset)
> against a TupletNumber, it will end up consulting the specified
> procedure which is in this case implemented in C++.
>
> > Any assistance would be greatly appreciated. My string quartet is going
> > nowhere but I am learning a lot about debugging lilypond.
>
> Are you able to share your .ly that exhibits this behavior?  Without a
> failing case on my side, I am left to only guess what might be
> triggering the behavior.

I'd like to second.

> That said, I have found a few things in the
> code that *could* be problematic.
>
> For instance, would you try adding this to your project:
>
> %%%%
>    \override TupletBracket.X-positions = #(lambda (grob)
>      (let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
>        (if (> (car xpos) (cdr xpos))
>          (format #t "\nwarning: Inverted X-positions ~a" xpos))

We have `ordered-cons´ for:

>        (cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr xpos)))))
> %%%%
>
> This will emit a warning when it detects that the calculated X-positions
> are inverted, but it also patches the issue by making the interval
> valid.
>
> -- Aaron Hill

It's worth checking LigatureBracket as well, they share the same
procedures for stencil/X-offset.
HorizontalBracket probably too (same procedure for
`connect-to-neighbor´), although this is unlikely to trigger the
problem, imho.

Cheers,
  Harm