On 7/5/22 02:03, Dan Eble wrote:
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?
Yes.
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?
The order of listeners is already unspecified, so that
shouldn't matter much, although it would probably be easier
to think about if the order were the same.
Would you allow an engraver to register both a pre-listener and post-listener
method for the same event type?
Yes. For example, it would be possible to have a pre-listener
to set forbidBreak and a post-listener to create a grob.
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);
}
```
Interesting, that gives me food for thought.
I have actually long been thinking we ought to have separate listeners
for the start and the end event in the case of span events, like we
have end acknowledgers for spanners.
Without that, the easiest would be
(pre-listeners
((span-dynamic-event engraver event)
(when (eqv? LEFT (ly:event-property event 'span-direction))
...)))
(post-listeners
((span-dynamic-event engraver event)
(when (eqv? RIGHT (ly:event-property event 'span-direction))
...)))
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.
A quick scan suggests
Accidental_engraver
Axis_group_engraver
Dynamic_align_engraver
Fingering_column_engraver
New_fingering_engraver
Trill_spanner_engraver
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).
Engraver of the former type don't need changes in connection
with \fine, do they?
I guess Mark_engraver would be fixed by using post-listeners in
Mark_tracking_translator. Well, for wha it's worth, the expected
behavior is not clear.
{
c'1
\fine
\mark \default %% Not expected to be printed
c'1
}
vs.
{
c'1
\mark \markup \musicglyph "scripts.ufermata" %% Expected
\fine
c'1
}
(which emphasizes the need for something else than \mark for
markups once again ...)
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\<
I actually disagree. For me, an ideal design engraves
{ ... \fine c1\< } just fine, but warns upon seeing
{ ... c1*0\< } because that sounds like a mistake and
a diagnostic is helpful.
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.
Ah, you caught me there.
I have to think about this one some more. Right now, I don't have
anything better than a pre-listener recording the event like in the
current model.
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.
Neither am I, but it is the only idea I could propose.
Jean