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

[Jean Abou Samra]

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