[Top][All Lists]

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

Re: (scheme-)engraver in 2.20/21

From: Dan Eble
Subject: Re: (scheme-)engraver in 2.20/21
Date: Thu, 24 Sep 2020 12:43:51 -0400

On Sep 24, 2020, at 10:28, Aaron Hill <> wrote:
> 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.

This could probably be done (I'm not looking at the code right now), but then 
what would it mean to start a timestep?  Starting a timestep would not be a 
pass over existing engravers, calling their start-translation-timestep methods 
with nothing in between.  When an engraver is told that the timestep is 
beginning, it might actually mean that the current timestep began a while ago 
and an unknown number of other engravers have since done some processing other 
than what's in their start-translation-timestep methods.

> 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.

I understand your point, but I don't see that that can be achieved without 
abusing the current terminology.

Changing it to work this way and renaming the methods to describe reality might 
be reasonable.

reply via email to

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