lilypond-devel
[Top][All Lists]
Advanced

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

Re: \fine, pre-process-in-final-translation-timestep & co.


From: Dan Eble
Subject: Re: \fine, pre-process-in-final-translation-timestep & co.
Date: Mon, 4 Jul 2022 20:03:40 -0400

On Jul 4, 2022, at 17:12, Jean Abou Samra <jean@abou-samra.fr> wrote:
> 
> |                                         | pre-listeners <- RENAMING
> |                                         |
> | pre-process-music               =>      | pre-process-music
> |                                         |
> |                                         | post-listeners  <- NEW STEP

Do you envision having the framework record events as they are dispatched to 
pre-listeners and then replay them to dispatch them to post-listeners?

Would you expect events to be dispatched to post-listeners in the same global 
order as the pre-listeners? in no specified order? something in between?

Would you allow an engraver to register both a pre-listener and post-listener 
method for the same event type?

How would you expect something like Dynamic_engraver to work?  It currently 
listens for span_dynamic events, but acts differently depending on the event's 
span-direction property.  From the rest of your message, I gather that you 
would want it to hear the end event with a pre-listener and the start event 
with a post-listener.

```
void
Dynamic_engraver::listen_span_dynamic (Stream_event *ev)
{
  Direction d = from_scm<Direction> (get_property (ev, "span-direction"));
  assign_event_once (accepted_spanevents_drul_[d], ev);
}
```

> Same for acknowledgers, lots of accumulating in vectors and clearing
> those vectors can be eliminated.

I'm not contradicting this, but I would want to verify it before designing 
around it.

> My understanding so far is that you need to exclude some events
> in engravers because \fine, like overrides, can come at
> any time during the "listeners" phase. If an engraver has
> already recorded the event in its listener, it needs to
> "unrecord" it somehow.

There are many engravers that work this way.

There are also engravers that create grobs when they "acknowledge" other grobs 
(e.g. Hyphen_engraver).

There are also engravers that create grobs when a context property is set (e.g. 
Mark_engraver).

> That could become very natural in the model above: if you
> saw \fine (doing that in a pre-listener), just don't run
> any post-listeners.

Don't focus too closely on \fine.  Engraving in the final timestep should be 
orderly whether it is caused by \fine or the natural end of the input.  You're 
just more likely to get into interesting situations by something sane like

    … \fine c1\< …

than by something crazy like

    … c1*0\<

> Jump straight to post-process-music.
> post-listeners and post-process-music are assumed to contain
> everything that creates grobs from events.

Where should a hypothetical pedagogical spanner over the final barline be 
started?  I guess it would be in post-process-music by necessity.

> When
> post-process-music creates grobs from events, those events
> are assumed to have been recorded in post-listeners.

I'm not sure what conclusions to draw from this.
—
Dan




reply via email to

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