On 12/02/2012 12:51, m...@apollinemike.com wrote: >> 2) Adding comprehensive MusicXML import and export features, together >> > with test suites for it. Requirements: ? (no idea in which language >> > this would be written), MusicXML, basic LilyPond and music notation >> > knowledge; familiarity with other scorewriters would be a nice bonus >> > (for cross-testing). The goal would be considered achieved when a >> > (previously chosen) not-so-complicated score could be imported from >> > MusicXML and exported back with no (unintentional) loss of data. >> > > I worked on this a little bit - it is totally possible and would likely weigh > in @ 500-1000 lines of Scheme. I'd recommend not worrying about placement > data and stopping at the engraver level. This is more or less the same thing > as a MIDI plus stuff like articulations, slurs, etc.. Placement data would > be doable but hard: it'd be better to just get the info from engravers first.
It is much easier to export just the music contents (in scheme, just using the output of the iterators), but that solves only part of the problem. To be able to provide solutions for composers in the professional music publishing world, layout information is essential in the MusicXML export. Currently, if you are using LilyPond, you are locked in to LilyPond. If any composer writes a piece in lilypond, it's practically impossible to find a publisher. The publishers usually only accept finished (i.e. layout done!) Finale/Sibelius/SCORE files, and probably MusicXML. But if the LilyPond users sends them the MusicXML of the finished LilyPond file, the publisher will have just the raw data and needs to do all the layout themselves again (and proably reject the files)... So, just a basic MusicMXL export functionality is not able to fulfill all the needs of the users. To be able to compete in the professional market, LilyPond also needs to export the positioning (and MusicXML is moving more and more into that direction, now also including full audio support). MusicXML 1.0 was just about the musical contents, MusicXML 2.0 added mainly layout information, and MusicXML 3.0 adds lots of audio information. Also notice that many MusicXML viewer are not able to lay out the musical contents themselves, but depend on the positioning information in the MusicXML file. My suggestion would be to implement MusicXML export with the following steps: -) Handle basic musical content export like the MIDI export (i.e. using dedicated exporter classes, derived from the translator class) -) Build the XML tree of the basic musical content, add a connection from music event to XML tag -) Let all engravers do their jost -) add ability to link each output object (basically each stencil / group of stencils) to the music cause (and thus to the XML tag in the XML tree) -) Add a XML output backend, which can then add the layout information for each output object to the XML tags This would probably be the most generic and extensible solution (although it is definitely not the easiest road). Basic export could already be implemented using some translator-derived classes collecting all interesting events. Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
