On Mon, May 21, 2012 at 2:37 PM, Janek Warchoł
<address@hidden> wrote:
Hi David,
On Sun, May 20, 2012 at 2:42 PM, David Nalesnik
<
address@hidden> wrote:
>
> On Sun, May 20, 2012 at 2:34 AM, Janek Warchoł <
address@hidden>
> wrote:
[ ... ]
> You get different results for the second tuplet depending on whether the
> example is doubled.
random. Try repeating \music 6 times (see attached "very strange") -
1st and 3rd occurence is correct, remaining ones are wrong. Now
delete the definition of your function (which isn't used at all!) and
the 3rd occurence goes bad.
Actually, as i'm trying various combinations, i cannot reproduce
previous behavior!
And another weird example: try "manual beaming" with 2.15.38. At one
moment, deleting any of 3 manual beam definitions present changed last
tuplet from good to bad - but i cannot reproduce it anymore!
Thank you for providing the files--I too get strange results and the inconsistency is making it so I can't narrow the problem down to create some sort of meaningful bug report. I've checked these files for the problem which gave me such a headache way back when--the situation where a beam could belong to a different staff than the tuplet bracket after a staff change (I believe it was), but that has clearly been fixed (issue 1667). This fix is why you're able to run the snippet without using manual beaming.
Since i'm going to try your function on the project i'm working on
with Urs, i may have more feedback in some time.
Great! I'll keep my fingers crossed :)
I'm attaching a revised version which works with 2.15.38 which you'll want to use instead. (It won't work with 2.14.2.) It's somewhat simplified. One thing that you can do with it is change the distance of the number from the beam by overriding TupletBracket #'padding (yes, bracket--Lily positions the numbers according to where the bracket would be, so moving the invisible bracket pulls the number along with it.)
Best,
David
lsr-646-update04.ly