[Top][All Lists]

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

Re: Distance of a grob from its reference point

From: Aaron Hill
Subject: Re: Distance of a grob from its reference point
Date: Tue, 14 Jan 2020 12:07:54 -0800
User-agent: Roundcube Webmail/1.3.8

On 2020-01-14 7:16 am, Kieren MacMillan wrote:
My mind was a little blown by the result of changing that to

    \override $grob-path .before-line-breaking = #proc

Doing so made it *deeply* and *immediately* clear that, despite being
a serious power-user of Lilypond for almost twenty years, I know
almost nothing of how it actually works.

You and me both. I am still trying to understand what is happening, but just querying for relative coordinates is enough to cause problems with the bracket's extents as well as the Beam of all things. I suspect that since ly:grob-relative-coordinate caches information behind the scenes, that calling it during before-line-breaking is possibly not well-supported.

Here is a hopefully minimal example for filing an issue:

\version "2.19.83"

  % Break things by calling ly:grob-relative-coordinate.
  \override Staff.OttavaBracket.before-line-breaking
    = #(lambda (grob)
         (ly:grob-relative-coordinate grob
           (ly:grob-parent grob Y) Y))

  % Highlighting the beam only for clarity.
  \override Beam.color = #red

  \ottava #1 g''8 8 4

Hence the ability to offset (e.g.) an OttavaBracket precisely X staff
spaces while still [re-]engaging the spacing engine is neither an
unreasonable request, nor something that Lilypond could (or even
should!) try to manage automagically.

I suppose my sticking point is the need to be so precise with positioning. I am not connected to the world of modern notation, but I cannot envision any musical meaning for the exact vertical position of an OttavaBracket. Rather, an engraver should simply desire it positioned so the performer is able to notice it without distraction. If it sits too close to other elements, then additional padding may be necessary. And vice versa, perhaps the bracket needs to sit very snuggly in some cases to look right.

Ultimately, if an appropriate tool exists but is broken in some way, it is best to fix that tool than invent a new one. Moving an offending bracket as mentioned above *should* be doable with Y-offset or any one of the various padding properties. That said, I have noticed that slur-padding seems to have no effect on OttavaBrackets. That is either yet another bug or just a figment of my misunderstanding.

-- Aaron Hill

reply via email to

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