Re: pre-process-music

[Jean Abou Samra]

Le 07/02/2022 à 21:18, David Kastrup a écrit :
> The obvious thing would be to do process-music like we do
> process-acknowledged: translators should be robust against multiple
> calls; and whenever new events are announced to some translator, it gets
> another round of process-music to deal with it.
>
> If we have some translator that creates chord events from single note
> events, for example, it will have to amend its output after receiving
> any chord input.  That's sort of a processing complexity nightmare but
> avoids the "we still need more phases" escalation.
>
> A different approach would be to allow some sort of dependency
> declaration, having translators declare what kind of event they may
> produce and consume and then establish a partial order of calling the
> process-music hooks of translators such that events of some type will
> only be consumed after no events of such type can still be produced.
>
> Indeed, we already know which types a translator may consume (that's
> what its set of listeners tells us), so we'd only need to declare what
> types it may emit.


These sound interesting, but would force communication of this
kind to happen via events. Setting whichBar as the result of
repeats is not really something one would expect to happen via an
event in the current design where events are rather the result of
user input than internal processing. The translators currently
creating stream events are Footnote_engraver, Beat_performer, and
who else? I can't think of any other. Context properties are more
convenient for internal data for a number of reasons: you can
persist them between time steps, unset them, and you can also
set them in acknowledgers.

I don't see that this would help with naturalization either.
Am I missing something there?