[Top][All Lists]

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

Re: (scheme-)engraver in 2.20/21

From: Jan-Peter Voigt
Subject: Re: (scheme-)engraver in 2.20/21
Date: Thu, 24 Sep 2020 14:12:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 24.09.20 um 13:40 schrieb Aaron Hill:
> On 2020-09-24 2:51 am, Jan-Peter Voigt wrote:
>> Hi all,
>> after some other very involving projects I can now refocus on lilypond
>> :-)
>> I probably missed a change in 2.20/21. If I create a scheme-engraver the
>> "start-translation-timestep" slot is not called, if the "initialize"
>> slot has been called in this particular timestep. If this the intended
>> behaviour I appreciate it because it is consistent. The "start-trans.."
>> slot wasn't called before for instant voices, but for regular installed
>> contexts. So now I have to finish "initialize" of the engraver with
>> "start-trans..." in any case.
>> So my question is if this is intended and not likely to change?
>> Sorry, if I missed discussion about this!
>> I have a demo below, where you can see that "start-trans..." is not
>> called, if "initialize" has been called before in the same timestep.
> It would seem that initialize/finalize are primarily concerned with the
> lifetime of the context whereas (start|stop)-translation-timestep deal
> with moving from one moment to the next in music.  As such I do not see
> these things as related, so what would be the reason for initialize to
> trump start-translation-timestep?

> I am curious more about the statement that start-translation-timestep
> was not "called before for instant voices, but for regular installed
> contexts".  Do you have a MWE that demonstrates this behavior?  Running
> the code you already provided against 2.18.2 and 2.19.55 (both via
>, and 2.20.0 locally show the call to
> start-translation-timestep after initialize for all three contexts.
> -- Aaron Hill

The problem occured with the edition-engraver addressing instant voices.
When I run my example with 2.19.84 the voice-contexts created by <<...>>
miss the start-trans..-slot, but it is called for the first voice and

reply via email to

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