Tuplet brackets should reliably not follow kneed beams.

Tuplet brackets should reliably not follow kneed beams.

Previously they could follow a beam if Beam::is_knee had not been called on it yet.

This affects input/regression/tuplet-number-kneed-beam-horizontal-fit.ly,
and the following:
{
  \override TupletBracket.bracket-visibility = ##t
  \times 1/2 { c8 c''' c c''' }
}

Is it safe to call Beam::is_knee in Tuplet_bracket::calc_position_and_height?

[david.nalesnik, 2014-04-05 13:25:05]

https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number...
File input/regression/tuplet-number-kneed-beam-horizontal-fit.ly (right):

https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number...
input/regression/tuplet-number-kneed-beam-horizontal-fit.ly:10: 
Don't you mean only the second tuplet number should be below the noteheads and
not between the stems?

Maybe this has to do with the double warning that is issued because
Tuplet_number::knee-position_against_beam is called twice.  Ugh.  Maybe I should
just scrap the error altogether.  I'm not sure if it accomplishes anything
worthwhile.

[Devon Schudy, 2014-04-07 03:06:07]

David Nalesnik wrote:
>
https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number...
> input/regression/tuplet-number-kneed-beam-horizontal-fit.ly:10:
> Don't you mean only the second tuplet number should be below the
> noteheads and not between the stems?

I didn't, but I should have. :) I was confused by its behavior with
\override TupletBracket.bracket-visibility = ##t, where both brackets
follow the beams and shouldn't.

> Maybe I should just scrap the error altogether.

Yes, because it doesn't indicate anything suspicious. Tuplet numbers
don't need to go close to the beams; that's just one possible place to
put them, and it's OK if they won't fit there.

[Devon Schudy, 2014-04-07 03:18:41]

Fix inaccurate description of test result.

[Devon Schudy, 2014-04-07 04:16:52]

Fix inaccurate test description.

[dak, 2014-04-07 07:33:22]

Devon Schudy <dschudy@gmail.com> writes:

> David Nalesnik wrote:
>>
https://codereview.appspot.com/84730043/diff/1/input/regression/tuplet-number...
>> input/regression/tuplet-number-kneed-beam-horizontal-fit.ly:10:
>> Don't you mean only the second tuplet number should be below the
>> noteheads and not between the stems?
>
> I didn't, but I should have. :) I was confused by its behavior with
> \override TupletBracket.bracket-visibility = ##t, where both brackets
> follow the beams and shouldn't.
>
>> Maybe I should just scrap the error altogether.
>
> Yes, because it doesn't indicate anything suspicious. Tuplet numbers
> don't need to go close to the beams; that's just one possible place to
> put them, and it's OK if they won't fit there.

When using the following test code with the latest patch (I think), it
would appear that TupletBracket directions are ignored with invisible
brackets.  Is this intentional?

[david.nalesnik, 2014-04-07 12:49:59]

On Mon, Apr 7, 2014 at 2:32 AM, David Kastrup <dak@gnu.org> wrote:

>
>
> When using the following test code with the latest patch (I think), it
> would appear that TupletBracket directions are ignored with invisible
> brackets.  Is this intentional?
>
>
Yes, this was intentional.  If the number is to be put next to the beam,
the side of the beam it should be on is generally fixed by good practice.
 (I took the rules from Gould.)

You can get the number position to be derived from the bracket (and to flip
around with changing bracket direction) with the line
 \override TupletNumber.knee-to-beam = ##f

--David

[david.nalesnik, 2014-04-07 12:58:37]

On 2014/04/07 04:16:52, Devon Schudy wrote:
> Fix inaccurate test description.

LGTM.