Not stupid questions at all.
> 1. When going through the source files, I find that the MIDI uses a kind
> of extended Translator_group interface called Performer_group. What are the
> main differences between the two, and which one would be more suitable for
> generalizing?
>
Translator_group is the parent class. Currently it is not possible to
directly instantiate a Translator_group, and the codebase widely assumes
that MIDI and graphical typesetting are the only possible output formats.
> 2. Would a new output format defined the way you suggest require writing
> new performers/translators that are tailored for xml/mnx - or could the old
> ones be reused somehow? Could the new performers/translators be done in
> scheme in line with the format definition?
>
It would require writing a suite of new translators that listen to music
events and assemble them into XML structures piece by piece, which would
then be collated by the Score_translator and output at the end of
compilation. It might be that some of these translators could be
repurposable between XML output formats. As an aside, MuseScore also uses
an XML file format, and output from LilyPond to MuseScore format even for a
subset of music events would potentially enable command-line generation of
MUCH higher quality audio playback. That is something I've thought about
trying to tackle at some point, which is why I've thought a bit about this
already.
> 3. How would a scheme definition of a format look like? In general, how
> would this kind of definition differ from the c++ midi stream and walker?
>
Several parts to this. Firstly, a Translator_group needs a
Score_translator, and this is another class that would need to be
generalized. Second, an output type needs an Output_def, like \layout{} or
\midi{}. Third, backend output logic to actually turn the data structure
assembled by the Score_translator into file output.
I should say that it's totally doable to build a functionally equivalent
version of all this without touching LilyPond's internals, but it involves
somewhat awkward workarounds. You can see an example of such workarounds
here https://github.com/shevvek/ly-navigation-tables. IMO it would be very
beneficial to do the infrastructure work first and allow for properly
extensible output formats.
At some point I'd be happy to spend some time talking about the code in
more detail, but I'm only just recovering from a serious illness, and
slowly dipping back into LilyPond stuff.
