Re: Dynamics offset suddenly changes

[David Nalesnik]

On Tue, Mar 26, 2019 at 6:07 AM Andrew Bernard <address@hidden> 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 <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
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user