On Mon, Jul 4, 2011 at 11:10 PM, David Nalesnik<address@hidden> wrote:
Hello, all --
Greetings,
First of all, I hope that I'm asking this question on the appropriate list!
Since you're demonstrating a regression, I'm forwarding your message
to our bug- list.
I'm trying to simplify the workaround relating to tuplet-number
position on kneed beams
http://lsr.dsi.unimi.it/LSR/Snippet?id=646
and I'm running into an unexpected problem.
My reasoning is that, since the tuplet number is positioned according
to the bracket, a logical first (certainly hacky!) step is to move the
(invisible) bracket to the beam by setting the 'positions property of
the bracket to that of the beam. Then, the position of the number
could be refined according to its height, the thickness of the beam,
etc.
This works as planned, except that in 2.14.1, the staves are pushed
apart dramatically. \override Beam #'collision-voice-only has no
effect on the problem. Manually setting Beam #'positions can be used
to fix the problem, but that is obviously inconvenient.
I've attached an .ly file with the function (stripped down to fit just
this case), and several images of the output (one is produced with
2.12.3, the other two with 2.14.1 -- one with an override of the Beam
#'positions). There doesn't appear to be any problem in 2.12.3.
Is there anything I can do to fix this problem with the function? Any
help would be greatly appreciated!
Indeed, it's a problem I've been stumbling across as well. Several new
properties have been introduced with 2.14 ("stretchability", etc.);
you may want to have a look at
http://lilypond.org/doc/v2.15/Documentation/notation/flexible-vertical-spacing-within-systems#within_002dsystem-spacing-properties
Whether the default behavior can/should be improved, is a question for
the Bug Squad :-)
Cheers,
Valentin.