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 <lilyp...@hillvisions.com> 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
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
