Re: Google Summer of Code - Ideas List, please discuss

[Reinhold Kainhofer]

On 12/02/2012 12:51, address@hidden 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, address@hidden, 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