On 30 nov. 2012, at 07:25, k-ohara5...@oco.net wrote:
> 'finger-chords.ly' is still in disagreement with its texidoc (therefore
> failing). You could adjust that regtest in light of the new defaults,
> of course.
>
> Better might be to make Fingering.add-stem-support = #only-if-beamed
> the new default. That is in better agreement with common practice.
> Regtests come out just as good. (Les-neréides.ly can remove a couple
> "tweaks", which seems to be how somebody was keeping score.) Then users
> will less often want to override add-stem-support, and when they do it
> will be to the simpler ##f or ##t
>
>>> The while(dirty) loop runs 2366 times for the last chord in
>>> 'fingering-collision.ly' but that's an extreme case.
>>>
>> I'm not proud of this...
>
> It is at least comprehensible; while the code it replaced was utterly
> baffling. I simplified the loop
> <http://codereview.appspot.com/6854121/>
>
I'm OK w/ the simplification, but I'd like it in box-quarantine if possible.
I'd like to separate the shifting algorithm from the class. This is part of an
effort, in general, to simplify and clarify the distinction between positioning
algorithms and classes that use these algorithms (this is what I was doing w/
interval-minefield.cc as well). Eventually, box-quarantine will be used for
the ScriptColumn grob.
> You should at least put the filenames back to what they were, and adjust
> any tests or documentation or snippets using add-stem support, before
> pushing.
>
> I started to test with real music. The usual Chopin test case
> <http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1776>
> has a badly broken cross-staff beam in measure 27. I don't yet see the
> cause.
>
Ugh...this is a really nasty cyclic dependency. In the old algorithm, when Y
side positioning was done, X extents weren't necessary because we just assumed
that things had infinite X extents. Now with the skylines, both X and Y
extents are necessary to build the skylines. The cyclic dependency is with
beam directions. The triggering chain is something to the effect of:
1) note_head_x_shift
2) stem direction
3) beam direction
4) pure y coordinates of stems to figure out auto knees
5) pure internal minimum translations via align interface
6) lots of pure heights in the axis group interface
7) pure heights of fingerings depend on new skyline side positioning algorithm
8) this algorithm needs the width of a note_head whose stem is attached to the
same beam in (3) above, so note_head_x_shift
9) stem direction of the stem attached to that note
10) beam direction
The dependency seems breakable, but it'll require some mental gymnastics to
figure out how. I'm on it.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
