Jean Abou Samra <j...@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
