Re: Gets vertical skylines from grob stencils (issue 5626052)

[mtsolo]

I've forgotten why I added the horizontal skyline stuff so I've taken it
out in a new version that I'll post after regtests.


http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc
File lily/axis-group-interface.cc (right):

http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode658
lily/axis-group-interface.cc:658: are avoided
On 2012/08/17 11:19:26, joeneeman wrote:
> Have you measured the costs of not having exempt?

I've decided to scrap exempt in a new version - will upload soon.

http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780
lily/axis-group-interface.cc:780: while (dirty);
On 2012/08/17 08:12:56, Keith wrote:
> I am beginning to understand the new code. Would you consider again
using
> distance() instead of the repeated calls to intersects() in the
while(dirty)
> loop ?  It might look simpler now that you've been away from the code
for a
> while.

> The Skyline::distance()s have all the information you want.  If you
are trying
> to place, by moving UP, an object with skylines 'pair' among a set of
skylines
> 'forest[j]' then the distance you need to move has several constraints

> floors[j] = padding - forest[j][UP]~distance~pair[DOWN]
> ceilings[j] = forest[j][DOWN]~distance~pair[UP]

> You know the solution will be to move an amount equal to one of the
floors[j],
> and you want to find the smallest that fits, so make
>    trials = sort (floors)
> and find the smallest among trials that satisfies
>     trials[n] > 0
> &&  for all j (trials[n] > floors[j]
>                 || trials[n] < ceilings[j] )

> Somebody might complain that this is quadratic in the number of
objects to
> place, but the problem placing N objects while looking for holes left
in earlier
> placements is a quadratic task.  But now the inner loop is simple
comparisons,
> rather than re-checking of skyline intersections and distances with
the
> while(dirty) method.

> In any case, the number N seems to be sufficiently limited in practice
(thanks
> maybe to 'exempt') based on reported score compilation times.

Hey Keith,

I am not adverse to using distance if possible - my trouble case is the
following.

AAAAAAAAA

    BBBBBBBBBBBBB

Image that object A above is placed first and LilyPond is now
considering whether it should leave B where it is or place it above A.
The distance function would dictate that it needs to be shifted above A
because its DOWN skyline is below A's UP.  However, it never intersects,
so there's no need to shift it.  This is why I'm looking for
intersections. Maybe I'm thinking of it incorrectly, though?

http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode945
lily/axis-group-interface.cc:945: feature present in
tuplet-number-outside-staff-priority.
On 2012/08/17 08:12:56, Keith wrote:
> If I remove all additions to the 'riders' array,
> 'tuplet-number-outside-staff-priority.ly' stays the same.

> I tried, but failed, to create a case where keeping track of 'riders'
helps.
>    \relative c'' {
>      \override TupletBracket #'outside-staff-priority = #1
>      \times 2/3 { a8\trill a\trill a\trill } }
> What case did you use ?

\version "2.17.0"
#(ly:set-option 'debug-skylines #t)
 \relative c'' {
   \override TupletBracket #'outside-staff-priority = #1
   \times 2/3 { a4\trill a\trill a\trill } }

If you comment out the rider business, the vertical-skylines will not be
correct for axis-group-interface. Comment it back in and they will.

http://codereview.appspot.com/5626052/