[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Odd interaction between ly:grob-property and hairpin

From: Jean Abou Samra
Subject: Re: Odd interaction between ly:grob-property and hairpin
Date: Thu, 10 Feb 2022 23:28:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0

Le 10/02/2022 à 22:57, David Kastrup a écrit :
Jean Abou Samra <jean@abou-samra.fr> writes:

Le 10/02/2022 à 15:42, Simon Albrecht a écrit :
Hi Aaron,

thanks a lot for the help! I knew that these pure vs. impure issues
exist, but I’ve never been able to wrap my head around them and this
is the first time I ever needed to account for them in practice.

Looking at Extending Manual section 2.8, it seems that Y-offset is
likely to be affected, so that makes sense.

What I don’t quite get is the meaning of the ‘begin’ and ‘end’
parameters in ly:grob-pure-property, but as long as 0 0 works, I’m
good ;) (and it’s not a topic for the bug list)

Best, Simon

Sorry, I just received this message now so my previous reply didn't
account for it (yes, list messages are taking 5 hours to reach
recipients sometimes, this was discussed recently on lilypond-user).

So, to answer your question, start and end are column ranks.
The meaning of the question (ly:grob-pure-property grob start end)
is "What will this grob property approximately on the broken
piece if this spanner is broken between start and end?"
Not the way I understand things.  The question is "What will this grob
property be in a line that starts in column `start` and ends in column
`end`.  That spanners consist of broken pieces is a different
complication not specifically related to start/end.

What would be the difference exactly? I don't understand what
you mean.

(for items they should be ignored).
I don't see that.  Even items may have different properties depending on
start/end.  For example, accidental rules should be taking them into
account (but don't currently) since accidentals on notes tied over bars
get repeated after a line break (and then don't need another

I was not talking the ideal design (which I happened to be exactly
working on while receiving this message). Rather I was talking about
the current design, which is that, to my knowledge, all pure functions
ignore start and end when passed an item, and item pure heights are
actively cached independently of start and end because they are
assumed not to depend on them and this saves calculations.

Item::pure_y_extent (Grob *g, vsize start, vsize end)
  if (cached_pure_height_valid_)
    return cached_pure_height_ + pure_relative_y_coordinate (g, start, end);
  /* Note: cached_pure_height_ does not notice if start changes, implicitly
     assuming that Items' pure_heights do not depend on 'start' or 'end'.

  cache_pure_height (Grob::pure_y_extent (this, start, end));
  return cached_pure_height_ + pure_relative_y_coordinate (g, start, end);

They are used in VerticalAxisGroup pure calculations, to estimate how
tall a staff will be between two certain points in order to score page
breaking configurations.
Yes, that's more like it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]