On Fri, Jun 27, 2008 at 3:19 PM, Kieren MacMillan <[EMAIL PROTECTED]> 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 > lilypond-user@gnu.org > 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
