blog.humaneguitarist.org

From the latest edition (issue #18) of the Lilypond Report:

Conference sightings!

(by Valentin Villenave)

Reinhold appeared at the Linux Audio Conference in Utrecht / Netherlands, presenting two papers:

• R. Kainhofer: A MusicXML Test Suite and a Discussion of Issues in MusicXML
• R. Kainhofer: OrchestralLily: A Package for Professional Music Publishing with LilyPond and LaTeX

Kainhofer wrote the musicxml2ly Python script that comes bundled with Lilypond.

This morning I read the first paper:

R. Kainhofer: A MusicXML Test Suite and a Discussion of Issues in MusicXML 2.0, Proceedings of the LAC 2010 Conference, Utrecht, 2010.

It was great. Although I would really need to known MusicXML 2.0 from memory to pick up on everything, the paper discusses some tests regarding MusicXML 2.0 and discusses some of its current limitations and the effect on import/export from other notation applications. He also discusses how  some of the format’s ambiguities create problems in trying to convert MusicXML to Lilypond.

Anyone who’s worked with MusicXML and several GUI notation apps probably knows that there are some rendering inconsistencies across different GUI music notation apps and it was good to get a better idea of the reasons behind this.

Also of interest was, from what I can gather, the limitations that the original DTD for MusicXML has imposed on MusicXML 2.0 which using an XSD schema – as backwards compatibility with earlier incarnations of MusicXML is desired. That is to say limitations of the DTD are inherited by the XSD.

Kainhofer offers some suggestions regarding any upcoming incarnations of MusicXML to deal with some of the aformentioned rendering problems as well as programmatic difficulties that arise in the occasional cases where MusicXML isn’t as explicit as it perhaps could be.

Far from a landslide of criticism however, Kainhofer concludes with this:

MusicXML is a very useful format for the extremely hard and complex task of music notation exchange. As the OSF specication has already shown, one can expect that future versions of MusicXML will clarify, solve or at least soften most of the issues we discuss here.

ps: OSF refers to the Open Score Format: http://openscoreformat.sourceforge.net/

One of the nice things about an emerging standard, namely MusicXML, having a command center (Recordare LLC) is having a central place to learn about what’s new.

On Friday, I was looking at Recordare’s page of MusicXML related software for software that worked from the command line and noticed something new and really interesting: MusicSQL.

According the the Goodle Code page that hosts this project, MusicSQL is:

a system for conducting complex searches of symbolic music databases. The database can import and export MusicXML files. In the current version searches are constructed using a command line interface or through simple Python scripting tools.

Basically, at least as I understand it, MusicSQL is a Python program that sits on top of a MySQL database – now I really hope Oracle doesn’t kill MySQL if it buys Sun.

I was so excited to get MusicSQL working that I didn’t notate all the little problems I had along the way. The documentation for MusicSQL is very good and is written for Windows, Mac, and Linux (Ubuntu) users. But I’m inconceivably impatient, so I just mowed through the installation with little care for remembering what I was doing.

I do remember that I had to install Python 2.5, whereas I already have Python 2.6 installed – now I have both. I put/installed all the dependencies in my Python 2.5 directory just to compartmentalized everything – the exception being MySQL, which I installed wherever the default is.

So far, I only ran the first query in the documentation that uses "scientific" musical notation in the form Nx, where "N" is the alphabetical note name, say C, and "x" is an integer that denotes what octave the note is a member of. In other words, a C-Major scale would be "Cx Dx Ex Fx Gx Ax Bx Cx+1", something like "C5 D5 … B5 C6", etc. You can place an integer before the note name to denote its duration.

Running the query from the command line, I was really happy with the speed and the output of MusicSQL for the test query.

One problem I did have, though, is I kept getting errors for another great feature of MusicSQL. Basically, after you run your query, you can see a PDF of the results (i.e. the music excerpt pertaining to the query results). The PDF is made by Lilypond, a text-based notation software that produces – in my opinion – the absolute best looking engraving out there, that’s why I use it (and yes, it’s free).

Now Lilypond doesn’t natively read MusicXML, it uses its own encoding. So MusicSQL takes advantage of a Python script that comes with the Lilypond install called "xml2ly" that converts MusicXML to Lilypond format. I left a message on the project forum for MusicSQL, so I’m hoping I can figure out what I need to do to get the Lilypond outout of the query results to work. At any rate, I do wonder how effective it can be since the conversion from MusicXML to Lilypond can sometimes get ugly.

I wonder if an alternative solution is to use the command line options for the MuseScore notation software to generate a PDF of the query results. Musescore can also convert MusicXML to other graphics formats (PNG) and even audio (WAV, FLAC, OGG), so theoretically it could be leveraged to make audio files for the corresponding query results.

At any rate, I’m really looking forward to the future developments of MusicSQL.

And as for using MuseScore’s command line in conjunction with MusicXML and how it can add value to a web collection of MusicXML docs – there will be more to that later …