Re: Inconsistent tuplet-number-kneed-beam-horizontal-fit.ly results?

[Devon Schudy]

David Nalesnik wrote:
> I wonder if what you're seeing related to an issue with
> the tuplet number code for which I just submitted a patch.  (It fixes a
> problem with faulty recognition of kneed beams in connection with overrides
> of Beam.positions.)

The patch doesn't change this.

Making the brackets visible reveals that this is actually a problem
with tuplet brackets, not tuplet numbers. Simple test case:

{
  \override TupletBracket.bracket-visibility = ##t
  \times 1/2 { c8 c''' c c''' }
}

The bracket is close to the beam, where it intersects some stems,
instead of staying above the noteheads. This isn't new -- it happens
even in 2.17.24.

The problem is in Tuplet_bracket::calc_position_and_height, which
isn't supposed to follow kneed beams. It identifies them by looking up
the beam's knee property, which isn't set yet, so it thinks the beam
isn't kneed and is safe to follow. (If regtests do some layout
operations in unpredictable order, the knee property could sometimes
already be set, which would explain the regtest inconsistency.)

Other routines that care about knees use Beam::is_knee instead, which
sets the property if it isn't defined. Is it safe (wrt the rules about
pure and impure properties) to call Beam::is_knee here too?

By the way, while playing with this, I noticed that tuplet brackets
turn inside out when the label is longer than the bracket:

\times 999/1000 { c8 d }

(This might be what the "TODO: this will fail for very short (shorter
than the flare) brackets" comment on Tuplet_bracket::make_bracket is
about.) This could plausibly happen with
tuplet-number::fraction-with-notes, so maybe it's worth a bug report.