On Tue, Mar 26, 2019 at 6:07 AM Andrew Bernard <[email protected]> wrote: > > 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?
\once \alterBroken ... > > 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
