[Top][All Lists]

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

Re: (scheme-)engraver in 2.20/21

From: Aaron Hill
Subject: Re: (scheme-)engraver in 2.20/21
Date: Thu, 24 Sep 2020 07:28:16 -0700
User-agent: Roundcube Webmail/1.4.2

On 2020-09-24 5:15 am, Jan-Peter Voigt wrote:
Hi Dan,

Am 24.09.20 um 13:42 schrieb Dan Eble:
On Sep 24, 2020, at 05:51, 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!

This change was intended.

thank you!
I stumbled across this looking at the edition-engraver.
Even though Aaron's objection is not entirely unjustified, I prefer this
uniform behavior. That means, the last action of "initialize" is always

The make-engraver macro does not provide a means to manually invoke the start-translation-timestep procedure from the initialize procedure. One would have to explicitly define a common procedure to be invoked in both cases:

   ((start-translation-timestep trans)
    (format #t "\nstart ~s" trans)))

%% would have to become something like...

#(lambda (context)
  (define (handle-start trans)
    (format #t "\nstart ~s" trans))
    ((initialize trans)
     (handle-start trans))
    ((start-translation-timestep trans)
     (handle-start trans))))

I doubt this is the sort of thing convert-ly could patch, so the proposed change in behavior would break user-created engravers that expect to always get a pair of (start|stop)-translation-timestep calls. As such, it makes far more sense that LilyPond automatically take care of invoking start-translation-timestep after initialize.

The argument for uniform behavior is sound, though one must be careful the behavior to which you are aligning is correct. My vote is that "starts" and "stops" must always be paired. If there were cases where "start" was not occurring, *that* is the faulty behavior to address.

-- Aaron Hill

reply via email to

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