Hi devs,
this question may seem somewhat far-fetched and maybe even
out-of-the-blue, but it actually has a concrete context (if you don't
know what I mean you may ask me off-list).
Consider the scenario that I have a specific XML format where a number
of external formats can be converted to (e.g. MusicXML, MEI, Abjad). I
want to enable LilyPond to engrave from that format directly, without
going the way of converting to LilyPond *input language* first. This
seems possible by converting the XML representation to something that
can be fed to LilyPond's engraving engine through
(make-sequential-music) or something similar that may be developed. The
process would be two-fold:
* process the music to become LilyPond music expressions
* build a LilyPond file with the score structure that uses these music
expressions
The first task consists of converting XML data to LilyPond music
expressions in Scheme. For this we can see two routes, and what I'm
asking for is opinions on the implications of these routes:
A)
* Convert XML to Scheme expressions and write them out (to a file or a
pipe)
Note: The given XML format is already handled through Python, so
that should be used here as well
* Feed the result into LilyPond through the -e command line option
B)
* Read the XML to Scheme-XML using the sxml module (from Guile 2)
* Use Scheme to convert that S-XML to LilyPond music expressions
AFAICS A) has two major advantages:
- we don't need sxml
- the hard stuff can be developed and maintained in Python, which means:
more potential developers
B) also has its advantages:
- we don't need to care about serializing Scheme expressions, i.e. we
don't need to think about writing Scheme syntax
- we don't need a separate intermediate representation
- maybe this may prove more robust against syntax changes (?)
I would probably try to implement this as an external library and *not*
to squeeze it into LilyPond itself.
The original motivation is to let LilyPond engrave scores encoded in
MEI, but due to the nature of our intermediate XML format (and related
tools) this would automatically give us the possibility to engrave from
a number of other formats, e.g. MusicXML.
Once this works it should be rather straightforward to implement a
proper file converter by letting LilyPond itself write out its music
through \displayLilyMusic or something derived from that.
This would make import from e.g. MusicXML much more robust than our
current tools because the converter doesn't have to deal with the
(changing) LilyPond syntax at all.
I'd be happy about any opinions and hints
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
