Re: Dynamics offset suddenly changes

[Andrew Bernard]

Hi All,

Thanks to Aaron's wonderful hairpin colouring function I have been able to really focus in on the hairpin behaviour.

I found the issue with my score. I am somewhat dumbstruck by this. There is a call as follows at one and only point point in the score:

\alterBroken Y-offset #'(0 4) Hairpin

This makes the misalignment problem arise at quite a few places, but 80-90 pages later.

I have recollection from somewhere that using alterBroken can have some downsides, but I do not know what.

However, would this not be classified as a bug?

Andrew

On Tue, 26 Mar 2019 at 13:13, Aaron Hill <address@hidden> wrote:

Sorry, Andrew.  I've been buried in work for my choir.  Allow me to try
to address the questions/comments in a single mail to catch up.

====

On 2019-03-25 5:04 pm, Andrew Bernard wrote:
> The pink arrow lines - how does lilypond work out this distance? It
> seems
> to be that that is jumping around. Can you help me understand that?

The pink lines are hard-coded as part of my demonstration of using a
specific value for minimum-space.  It was meant only to visually depict
the offset, as it can be hard to count staff spaces outside the staff
itself.

What I could have done was this:

%%%%
   %% Overlay reference lines.
   \override Hairpin.stencil =
     #(grob-transformer 'stencil (lambda (grob orig)
       (let* ((p (ly:grob-object grob 'axis-group-parent-Y))
              (y (ly:grob-property p 'minimum-space)))
         (grob-interpret-markup grob #{
           \markup \with-dimensions-from \stencil $orig \overlay {
             \with-color #(rgb-color 0.4 0.7 1.0)
             \path #0.2 #'((moveto -8 0) (lineto 8 0))
             \with-color #(rgb-color 1.0 0.4 0.7)
             \path #0.2 #`((moveto 0 0) (lineto 0 ,y)
               (moveto -2 ,y) (lineto 2 ,y)
               (moveto -1 ,(- y 1.5)) (lineto 0 ,y)
               (lineto 1 ,(- y 1.5)))
             \stencil $orig } #}))))
%%%%

NOTE: I omitted the \once so this will draw on all Hairpins.  As such, I
shortened the blue line.

Here this is only just for visualizing minimum-space, but it does not
account for all of the possible factors that affect vertical
positioning.  Again note that in my other example, I zeroed out several
of the padding properties to make things work.

====

On 2019-03-25 4:42 pm, Andrew Bernard wrote:
> Hi Aaron,
>
> Thank you for looking into this. As mentioned in my original post, I am
> not
> using a Dynamics context as this New Complexity score is very, very
> complex
> rhythmically, and it would tale a month to go back and figure out all
> the
> spacer rests to use a dynamics context. I'd rather not do that, but I
> can
> see where this is going.

As I showed in my prior email, you do not technically need to do
anything a second time.  You should be able to instanciate your music
twice: once for the \Staff and a second time for \Dynamics.  It should
only then be a matter of \omitting any dynamics-related grobs from the
Staff.  Of course, this tactic may not work depending on how "dirty"
your music variables are.  If they are pretty clean and just represent
pitches and durations with dynamics attached, it should work as I
showed.

For cases when the music is muddled with things that the \Dynamics
context is not by default ignoring, it would fall to the task of using
map-some-music and a suitable procedure for extracting only the elements
you want.  Basically, I agree that you should not have to do extra work.
  You have already indicated the dynamics you want and when.  The tactic
now is to leverage the power of the computer to split out the things you
want in \Dynamics apart from the things you want on the \Staff.

Unfortunately, I am running a bit out of time to dig into this further. 
And it could very well have already come up before, so I'd encourage a
thorough search through the archives and the LSR.

> This was all fine until the score reached a certain number of pages. I
> suppose I can go chopping pages out to see what may be going on there.
> I
> tried 2.19.82 and 2.19.83, so I don't think there is an issue with the
> version.
>
> I mention again that this started happening as the score grew large,
> making
> me think there is some kind of memory management issue lurking around.
> I am
> completely unable to prove this.

I would expect memory bugs to result in crashes rather than simple and
consistent misalignment of elements.  But stranger things have happened.

You may have another strategy here.  You mention that problems happen at
scale, so would it make sense to break up the piece into smaller
sections that each independently render as expected?  It is not elegant
for sure; but if the approach unblocks you, I would say elegance should
not matter.


-- Aaron Hill

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user