Re: musicxml2ly

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 25. November 2008 schrieb Martin Tarenskeen:
> I will not describe in detail here what the results were. Some examples
> showed good results, some showed really obvious typestting errors, some
> examples exited with error messages when processed by Lilypond. Everyone
> who is interested can try it for himself
>
> I don't expect all the examples from recordare to be rendered perfectly
> with the very next devel. version of Lilypond.
>
> But I do think the example collection from the Recordare website
> provides an interesting set of benchmarks for the development team to
> test both musicxml2ly and lilypond. 

Well, yes and no. 

- -) First, these example files are examples to hightlight what MusicXML can 
do, 
so they use quite some involved features. From musicxml.org: "They are 
deliberately chosen to be more difficult, and make use of more MusicXML 
features [...]"

- -) Second, I was/am using those examples, but currently I'm trying to fix 
some 
more basic issues with real-life scores.

- -) Third, Recordare claims copyright on the typesetting of those MusicXML 
files, so we can't simply copy them into our build tree for testing purposes 
(Michael Good, the author of the MusicXML spec wrote me last year that if I 
ask them and tell them on which website the files would be placed, they would 
grant us permission, but due to the open source nature of LilyPond, I doubt 
that we can really fulfill this. I simply don't want to copy anything into 
the source tree which cannot be freely copied and published/uploaded 
somewhere else).

- -) Fourth, the MusicXML format in many ways was created according to how 
Finale handles things (Michael Good and Recordare, who wrote the MusicXML 
DTDs and invented the format, are also the guys who implemented the Finale 
Dolet plugin for MusicXML, which was actually at first their only MusicXML 
implementation, so of course Finale heavily influenced the way MusicXML does 
things), while LilyPond does many things differently. For example, in 
MusicXML, all text markups and all dynamic marks are attached to the staff, 
while in LilyPond they are attached to a note. As you can imagine, it's not 
easy to find a proper note to attach them to when importing a MusicXML file 
to the LilyPond format. Even worse, one has to decide to either assign those 
markups and dynamics to only one voice present in the staff (with the 
consequence that you will not be able to split multiple voices into multiple 
staves later on without losing the dynamics for the second voice) or to 
assign them to both voices and live with the duplication that you currently 
see.


> To find bugs and/or chances for 
> improving and finetuning Lilypond and musicxml2ly.

See my informal list of things I noticed:
http://wiki.kainhofer.com/musicxml2ly

Also, I am working on a really full test suite for MusicXML (there are 
absolutely no test cases and no representative test suite available from 
Recordare). It can be found in our source code in the 
input/regression/musicxml/ directory and its output is also available in our 
documentation:
http://kainhofer.com/~lilypond/input/regression/musicxml/collated-files.html

I regularly add new test cases as I implement stuff in musicxml2ly or fix 
bugs.


> As a a comparison I also tried the examples with the new Finale Notepad
> 2009. I hate to admit it but: At this moment Finale Notepad does a
> better MusicXML rendering job than Lily.

Well, you better rephrase it: "Currently, Finale does a better job at 
importing an MusicXML file that it created itself than Lilypond".
This is actually to be expected. Of course, Finale should be better at 
importing its own files than lilypond!

However, Finale also has its issues and not-supported MusicXML features (e.g. 
figured bass, real mid-measure bar lines, etc. Those are supported in 
musicxml2ly, though ;-) ), but since those example files were created with 
Finale, of course they only show those features that Finale supports 
perfectly ;-) 

Also notice that those examples are also not perfect: Some features displayed 
in the .pdf files are actually not exported to the MusicXML file by finale, 
so the PDFs are misleading. And there are some other issues too: For example, 
to print a tick as a bar line, they printed an "|" text markup and manually 
positioned it over the staff. This is definitely not the correct MusicXML way 
to print such a bar line...

Also, if you try to import the 02a-Notations-MusicXML.xml file from my test 
suite to Finale, you'll see that finale completely messes up determining 
approproate positions for the articulations. Finale handles its own MusicXML 
files almost perfectly, but for others it also has its issues.

Cheers,
Reinhold

- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJLAF0TqjEwhXvPN0RAkEQAKC7nJsi+941GATUZBhk3ENYpEjZLQCffwRC
wM3kQocuPFaHcdRt6OuWC6s=
=Vqda
-----END PGP SIGNATURE-----