Jean Abou Samra <j...@abou-samra.fr> writes: > To fill this hole, I am musing about adding a new translator slot > called pre-process-music. The principle should be clear from the > name: pre-process-music is called on all translators after all > listeners, and before all process-music slots. It can be used for > operation that needs all events heard but should happen before grob > creation. No equivalent can be sensibly provided for > acknowledgers since it remains possible in process-acknowledged > to create grobs, thus starting new acknowledge cycles, > so there is no logical grouping of the grobs seen in the > same acknowledge cycle. > > Thoughts on the principle? Other ideas?
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. -- David Kastrup
