|
From: | Urs Liska |
Subject: | Re: OMG - performance issue with Scheme engraver |
Date: | Wed, 11 Jul 2018 09:08:13 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
Am 10.07.2018 um 19:48 schrieb Urs
Liska:
It's obviously not: while it reliably reduces processing time to what it should be it equally reliably misses all annotations except on the very first timestep. What my engraver now does is:
The last behaviour is necessary because process-aknowledged is called multiple times and only in a later call the annotations are actually attached to the grobs I really don't see why this does not work. If the annotation is on the first note of the score it gets caught, otherwise it's overlooked. But debug printing indicates that in the process-acknowledged invocations all the required grobs are present in the all-grobs list. I have now done yet another experiment: process annotations in the stop-translation-timestep clause, assuming that *then* all the tweaks must have finally arrived at the grobs. This *seems* to work properly, and expectedly it further reduces the number of times the all-grobs list is iterated (i.e. exactly once per timestep. From what I have now come to understand about the process this actually seems like the right place to process the annotations. However, there's one more thing I'd like to ask about: Processing the annotation involves setting the grob's 'color property. In the engraver tutorial it is stated that in this timestep one can *read* properties, "possibly" set context properties based on them but that one must not create new grobs. So it is not explicitly forbidden to set grob properties but the language is pretty discouraging in that respect. OTOH I don't see how setting a property like 'color might cause conflicts, especially not the types of cleanup conflicts with other engravers. Any opinions on the last question? Thanks
|
[Prev in Thread] | Current Thread | [Next in Thread] |