Re: Export from LilyPond to MusicXML (Thomas Morley)

[Jan-Peter Voigt]

> Am 08.10.2021 um 12:04 schrieb David Kastrup <dak@gnu.org>:
> 
> Jan-Peter Voigt <jp.voigt@gmx.de> writes:
> 
>> Hi all,
>> 
>> probably what I am writing now is not new to most of you. About a year
>> ago there was a discussion regarding the license of Lilypond, triggered
>> by Urs' question about the future of OLL. Again and again the
>> documentation was referred to, which says that Lilypond is a compiler
>> that translates the source code into a PDF. For God's sake, I don't want
>> to discuss the licensing consequences again, but I want to point out
>> that this representation is not exactly complete. In fact, each source
>> file is translated into a Lilypond internal executable, the execution of
>> which then generates the PDF.
> 
> Uh, no?  Calling LilyPond's internal representation of music an
> "executable" is nonsensical since it does not imply any actions but is a
> structural representation of music.
Ok, my designation as internal executable is certainly not a good picture.
My point is that this process is not a pure translation language A to language 
B.
Whatsoever, this is not the topic I want to discuss.
> There never is any linear
> representation being "executed", and source files are interpreted rather
> than compiled, with no file-level representation ever being explicit.
Well at least a (Scheme) Engraver can be used to instruct that a note head be
painted red if it is the third moment in the measure. Alternatively, this 
information
can be given to each affected notehead via override. The source file is 
interpreted,
as you write, and not compiled, as written in the documentation.
(https://lilypond.org/windows.html, https://lilypond.org/macos-x.html, 
https://lilypond.org/unix.html: "Compiling a file")
> That's not an academic difference since it is a non-trivial question
> just what the structure of a MusicXML file is supposed to represent from
> a given LilyPond input file.
Yes, that is essentially what I wanted to say.

Jan-Peter