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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/lilypond-user >
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
