Re: SPONSORSHIP OFFER: centering a context between two other contexts (followup)

[Andrew Hawryluk]

On Fri, Jun 27, 2008 at 3:19 PM, Kieren MacMillan
<address@hidden> wrote:
> Hey all,
>
> After thinking about it a bit, it seems to me that the current (*wicked
> awesome*, BTW) skyline coding could come to the rescue here...  =)
>
> IMO, the ultimate algorithm for a piano-with-centered-dynamics situation
> might be as follows:
>
> 1. At any given point requiring a dynamic/hairpin, the grob-box containing
> the dynamic/hairpin is inserted between the skylines of the two surrounding
> Staff contexts.
>
> 2a. If this insertion can be done without the dynamic/hairpin box touching
> either skyline, the two Staff contexts remain unaffected.
> 2b. If the dynamic/hairpin grob-box touches either skyline, the lower Staff
> context is pushed down until the grob-box no longer (or just barely) touches
> the skylines.
> [In other words, this context would be "super-skylined" or "flatline-able",
> with a minimum height of 0 where a Staff context has a minimum height of 4.]
>
> 3a. The dynamic/hairpin grob-box #'padding would be user-settable.
> 3b. There would also be a setting (default = ##f) which would force all
> dynamic grob-boxes within a single system to be aligned on the same vertical
> axis.
>
> How difficult (read: expen$ive) would it be to add such a feature?
>
> Thanks,
> Kieren.
>
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>

That would be very exciting, and a big step forward for keyboard music
in LilyPond. Almost as big as the new (2.11) vertical layout routine
that allows for cross-staff beams without fixed staff distances.

To keep the discussion moving, I think I can simplify your description
slightly. The ultimate Aligned Dynamics Engraver as described above
would need to handle two cases:

Case A, baseline aligned dynamics:
This almost works properly with the piano template but could use some
improvements with its skyline and with its note-column alignment
before it's really ready to go. It produces a row of dynamic marks
that are then placed between the staves by the skyline algorithm.

Case B, vertical centering between skylines on a mark-by mark basis:
The only change here is that the routine will require the lower
skyline from the RH staff and the upper skyline from the LH staff.
Within the horizontal space of each dynamic grob, it must find the
distance between the center line of the RH staff and lowest point on
the RH staff, and the distance between the center line of the LH staff
and the highest point on the LH staff. If we call those distances Y_RH
and Y_LH (both positive), then that grob must be shifted upward from
the baseline by Y_shift:
  Y_shift = (Y_LH - Y_RH)/2

This will produce a row of dynamic marks that are shifted above and
below the baseline. The existing vertical placement logic will then
align them correctly and spread the staves the correct amount.

I don't know how hard that would be, but I think it would be worth it.

Andrew