Improve positioning of tuplet numbers for kneed beams.

Improve positioning of tuplet numbers for kneed beams.

In the past LilyPond always placed tuplet numbers according to the
position of a bracket, though this bracket may or may not have actually
been drawn.  This system led at times to tuplet numbers which appeared
stranded when there was a kneed beam and no visible bracket.

This patch positions the tuplet number independently of brackets and
close to the beam when the the bracket is not drawn, the beam is kneed, and
there is an appropriate beam segment to place the number against.

The side of the beam on which the number is placed is chosen by principles
derived from Gould.  The number is centered horizontally on the beam.

Collision detection is also introduced.  The number will be offset
horizontally if it is too close to an adjoining note column.  All shifts
preserve the number's vertical distance from the beam.  If the number is
too large to fit in the available horizontal space (between note columns
to either side), we use the old bracket-based positioning system.  In the
event of a collision with an accidental, the tuplet number is moved
vertically, away from the beam.

The older behavior is always available through an override of the property
`knee-to-beam' which is introduced by this patch, and set by default to true.

This patch also adds a header file, `tuplet-number.hh', and provides
a regression test, `tuplet-numbers-kneed-beams.ly'.

[janek, 2014-02-06 21:44:26]

Why are there so few test cases in the regtests?  I saw that you have loads of
*excellent* examples, and i think that at least half of them is worth being
added - don't be shy about it!

best,
Janek

[david.nalesnik, 2014-02-08 21:45:33]

On 2014/02/06 21:44:26, janek wrote:
> Why are there so few test cases in the regtests?  I saw that you have loads of
> *excellent* examples, and i think that at least half of them is worth being
> added - don't be shy about it!

Here's five more :)

[janek, 2014-02-09 21:23:29]

this ROCKS!

What about "more than 1 tuplet per beam group" and "nested tuplets"?  My head
explodes every time i see these examples!

best,
Janek

[david.nalesnik, 2014-02-09 22:43:34]

On 2014/02/09 21:23:29, janek wrote:
> this ROCKS!

:)

> 
> What about "more than 1 tuplet per beam group" and "nested tuplets"?  My head
> explodes every time i see these examples!

The "more than 1 tuplet per beam group" is actually covered by the French
beaming example.

I could include the nested tuplet stuff, but would you have any objection to
adding it later, after this patch is through?  This is getting *huge*!

[janek, 2014-02-09 22:48:41]

2014-02-09 23:43 GMT+01:00  <david.nalesnik@gmail.com>:
> The "more than 1 tuplet per beam group" is actually covered by the
> French beaming example.

ok.  sorry for not looking carefully enough (too hasty...)

> I could include the nested tuplet stuff, but would you have any
> objection to adding it later, after this patch is through?  This is
> getting *huge*!

sure, no problem!

best,
j