[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
- \fine, pre-process-in-final-translation-timestep & co., Jean Abou Samra, 2022/07/04
- Re: \fine, pre-process-in-final-translation-timestep & co.,
Dan Eble <=
- Re: \fine, pre-process-in-final-translation-timestep & co., Jean Abou Samra, 2022/07/08
- Re: \fine, pre-process-in-final-translation-timestep & co., Dan Eble, 2022/07/09
- Re: \fine, pre-process-in-final-translation-timestep & co., Jean Abou Samra, 2022/07/09
- Re: \fine, pre-process-in-final-translation-timestep & co., Dan Eble, 2022/07/09
- Re: \fine, pre-process-in-final-translation-timestep & co., Jean Abou Samra, 2022/07/09
- Re: \fine, pre-process-in-final-translation-timestep & co., Dan Eble, 2022/07/09