lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning o


From: lilypond
Subject: Re: [Lilypond-auto] Issue 3831 in lilypond: Patch: Improve positioning of tuplet numbers for kneed beams.
Date: Thu, 30 Jan 2014 14:37:58 +0000


Comment #4 on issue 3831 by address@hidden: Patch: Improve positioning of tuplet numbers for kneed beams.
http://code.google.com/p/lilypond/issues/detail?id=3831

I've provided a regtest to show the changes in operation, but I'm attaching an extensive test file to show in detail what the patch does.

This produces workable results, though I've reached a stage with this that I'm unsure how to proceed. There is a rudimentary collision detection system in place here, though it is limited by the fact that X-offset and Y-offset are considered separately.

Ideally, to detect a collision, both X and Y position are needed. Right now, I consider collisions with note columns as an approximation of stem/ledger lines/noteheads, because I don't have the number's Y when I calculate the horizontal shift. This can move the number in cases where there's a possibility it might tuck under a notehead.

How do I resolve this? I do query the X-position of the number when calculating Y-offset, but to also ask for the number's Y-coordinate when calculating X-offsets (for collision detection) seems like a recipe for disaster, at least overly optimistic. Ought X- and Y- offset be calculated together? Is there precedent/need for this?

I have not completely split the positioning of "unbracketed" tuplet numbers from the bracket-based method. Possibly that is something that needs doing at some point. The system which uses the bracket (whether visible or not) produces good results in ordinary single-staff tuplets, and to get positioning along the beam in cross-staff non-kneed beams, you just need to override TupletBracket.direction. (Now THAT'S confusing to anyone who doesn't know that there's always a bracket, invisible or no.)

Possibly there would need to be a split even here if tuplet number quanting is ever going to be implemented.

Attachments:
        kneed-tuplets-test.ly  12.5 KB

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

[Prev in Thread] Current Thread [Next in Thread]