Re: pre-process-music

[David Kastrup]

Jean Abou Samra <jean@abou-samra.fr> writes:

> 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?

Well, there is a lot happening via grob acknowledgers which has this
sort of avalanching acknowledge_grobs phase.  Problem is that this
approach is not helpful for performers, let alone generic translators
not actually dealing with output-dependent work.

It may not be the best fit for your exact problem at hand.

-- 
David Kastrup