On 2020-01-22 7:26 am, Paolo Prete wrote:
The problem is associated with:

https://lists.gnu.org/archive/html/lilypond-user/2020-01/msg00467.html

Sorry if I insist again with this: is there a fix (or work-around) for it? The function is ***very*** useful, You can really see what happens with the
discussed property, and you can really use therefore a ruler for fine
tuning .

I started to take a look at this, but got side-tracked. My work schedule is erratic at the best of days, plus I have been trying to get over a cold; so I am uncertain I will be able to dig in more deeply.

My initial impression is that accessing certain properties out of sequence can cause problems. The NR includes a brief section on unpure-pure-containers mentioning how one must be careful when accessing properties relating to Y-axis concerns. Beam in particular is called out as something to avoid touching, and I imagine that TupletBracket cares about Beam. I also know there is internal caching of computed results at various stages of processing, so perhaps an unintended side-effect of these things is that it all goes awry when the normal pattern of access is interrupted. And since much of this work is done at the C++ level, it becomes difficult for Scheme code to influence effectively.

All of my helper functions for overlaying stencils are really just hacks; they might work for some grobs and fail for others. And when things stop working, you just have to look for another hack. For instance, if messing with the stencil for TupletBracket is not working, perhaps you could use another grob to host the debug annotation. TupletNumber might be more accepting of modification, which you should be able to get via (ly:grob-object bracket-grob 'number). But be aware that you might have to do things the other way around, working from TupletNumber.after-line-breaking which would mean getting the bracket from the number: (ly:grob-object number-grob 'bracket).


-- Aaron Hill

Reply via email to