-----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: [EMAIL PROTECTED], 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----- _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
