lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pre-process-music


From: David Kastrup
Subject: Re: pre-process-music
Date: Mon, 07 Feb 2022 21:18:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]