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/

This is my final semester at the School of Library and Information Studies at the University of Alabama.

For my final credits, I’ll be researching the digital encoding of symbolic music representation (SMR), i.e. "sheet music", its background, and the benefits it offers over simply thinking of SMR as an image – all within the context of libraries, including avenues of web-based delivery, preservation and metadata, and search and retrieval technologies. My research will be directed by Dr. Steven MacCall.

In addition to a paper addressing these issues, I’m required to deliver what is essentially a "demo" of a MusicXML web-based delivery system that could serve to demonstrate to librarians the possibilities that arise with the usage of XML-encoded musical information.

I’ll be blogging along this semester as part of a modular approach to constructing the paper. Currently, I’m plugging away at the demo which utilizes open-source server-side music applications.

The first idea behind the demo is that one could "drop" MusicXML documents on their server and – via automation – PDF, audio, and preliminary Dublin Core metadata are generated. So far, I’ve got all that covered but I need to polish the output and I really need to comment-up my PHP code as I’m even forgetting at times what I’ve done and why. I’ll be sharing the code as well as the XSL transformations that are used to generate the Dublin Core metadata from the MusicXML documents.

As time allows, I’ll try and add some cool features. For example, this week I implemented libmusicxml so that the user can generate a PDF of a musical score in a different key than the original. I’m guessing this is the same way that the Wikifonia site offers this transposition option. I’ll have to ask them to make sure.

The second idea behind the demo is to implement a search/retrieval mechanism using XQuery. This will prove the biggest challenge as I don’t know XQuery well, but I have some excellent sources on querying MusicXML documents from which I can learn. Implementing XQuery on the site has – for the most part – already been dealt with in terms of scripting. In other words, the hard, hard work is done in terms of the demo, but I’m not quite there yet …

ps: Unfortunately, the server-side software required to run the demo can’t be added to a free server like the one I use for this blog. But while I can’t host the demo, I will at the end of the semester offer it as a download-able package so that one can run it on their personal computer as server.

This blog post is part of a semester-long investigation into digital encoding of symbolic music representation (SMR), its context in libraries, web-based delivery, preservation and metadata, and search and retrieval technologies.

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 …

Earlier today,  I posted about my first experience with XQuery. I’d mentioned that I wanted to get my feet wet before I started trying to run queries on MusicXML documents.

Well, I’m an incredibly impatient person.

I couldn’t wait to take a couple of simple queries for a test run, especially after reading the following paper from the 2008 International Conference on Music Information Retrieval hosted by ISMIR, the International Society for Music Information Retrieval:  

Using XQuery on MusicXML Databases for Musicological Analysis
Joachim Ganseman, Paul Scheunders and Wim D’haes

Now, I’ve known for a while the tests have been done using XQuery on MusicXML documents, but this paper was getting at something that’s been on my mind for a long time now: the day we can have digital libraries of sheet music, not as image files, but as encoded documents, allowing musicians and the like to have the same online ability to query music in the way that users of prose and literary documents now take for granted.

Anyway, on to my first XQuery and MusicXML experience …

For testing, I used a very silly little ditty I wrote called "MusicXML: I Heart Thee".

Here are its various manifestations:

• MusicXML

• JPEG

• MP3

The first query demonstrated in the paper (see page 3) is one to count the total notes in a digital library, in this case the Wikifonia collection of MusicXML docs.

I couldn’t get it to work as written even after I adjusted the query to work on my test document. This is likely due to my own ignorance, but in the end it was a good thing because it forced me to write my own, simpler queries.

I’m using the Saxon query processor as described in my earlier post.

1. This query (in red) counts all the notes in my piece:

<ul>
{
for $i in doc("i_heart_thee.xml")/score-partwise
let $j :=count($i/part/measure/note)
return $j
}
</ul>

A line-by-line translation:

Open an unordered list.

Open the query syntax with the "{" character.

Let there be a variable called "i" that will start at the root element, <score-partwise>, of the document "i_heart_thee.xml".

Let there be a variable, "j", that executes the Count function on "i" for the <note> element which is a child of <measure> and a grandchild of <part>.

Print the value of "j".

Close the query syntax with the "}" character.

Close the unordered list.

2. This query (in red) counts all the notes in the vocal part (there are 3 parts altogether: voice, guitar, bass):

<ul>
{
for $i in doc("i_heart_thee.xml")/score-partwise
let $j :=count($i/part[@id='P1']/measure/note)
return $j
}
</ul>

A line-by-line translation:

Open an unordered list.

Open the query syntax with the "{" character.

Let there be a variable called "i" that will start at the root element, <score-partwise>, of the document "i_heart_thee.xml".

Let there be a variable, "j", that executes the Count function on "i" for the <note> element which is a child of <measure> and a grandchild of <part>, where the "ID" attribute of <part> is = to "P1". This is the vocal part of the score.

Print the value of "j".

Close the query syntax with the "}" character.

Close the unordered list.

If you run the first query you get the result "137" as in 137 notes, including rests – even the hidden rests in measures 1,5, and 9 that exist because both voices in the guitar part have rests, though it only displays as one rest each time on the image version of the score.

If you run the second query, you get 43 notes including rests and the tied notes.

I’m sure there are ways to subtract rests and tied notes, but I have to start somewhere, right?

A few months ago, my department head had encouraged us to learn about XML stylesheets and XSLT transformations. After picking at it here and there, I finally had my breakthrough with it this weekend. Of course, were I more patient, I could have gotten paid to do this at work tomorrow.

As usual, the majority of the work is in finding examples and explanations that speak to me. This thread was particularly helpful.

One of the biggest breakthroughs – as embarrassing as it is to admit – was my realization that one needed an XSLT processor to actually create a new XML document based on the instructions provided in the stylesheet.

I’ve been experimenting with both the Saxon and Microsoft processors. Rather than run them from the Windows command prompt, I’ve been using the command line interface in the jEdit text editor. There’s a built in XSLT processor plug-in with jEdit, but I couldn’t get it to work, hence the use of the afformentioned methods.

If I understand corrently, one of the uses of this will be to take XML data about audio files generated from the JSTOR/Harvard Object Validation Environment (JHOVE) and map the pertinent information to another schema/XML document. That’s a bit out of my league right now, but a modest start is yet a start.

I’ll also be interested in using transformations to make customized XML documents from MusicXML sources and Zotero exports. Admittedly, I have no real ideas as to what I’d need to do this for, but I simply have a hankering to think of related projects. Maybe pulling the lyrics out of a MusicXML document into a TEI verse document?