Under the terms of the agreement, MakeMusic is purchasing the MusicXML™ open format and Dolet® software technology, including copyrights, source code, and trademarks. MakeMusic also announced that the founder of Recordare and inventor of MusicXML, Michael Good, will be joining MakeMusic as the Director of Digital Sheet Music.

A few people, myself included, were both excited for Recordare/Good but were also wondering what this means for the future of MusicXML in terms of remaining open so here's the scoop – posted on November 2, 2011 – from Michael Good himself on the MusicXML discussion list:

 … MusicXML will remain an open format. MusicXML will continue to be licensed under the same open, royalty-free terms it has today. MusicXML's value comes from being an open format that anybody can freely use in their products and services. That will not change. Community development of future versions of the MusicXML format will not change. What will change is that MusicXML will now be supported with a larger company with more resources. There are exciting possibilities ahead!

Personally, I'm not worried.

In terms of XML approaches to music encoding, there's MusicXML and then there's everything else. Mr. Good's known all along that building relationships that ensure software support is a key to success for the format. He's even been kind to the little guys: emailing me and commenting on this blog in regard to some of my work with MusicXML for digital libraries.

So congratulations to Michael Good and MusicXML. I'm looking forward to hearing the next movement.

MXMLiszt is a web-based delivery and search/retrieval environment for MusicXML files and their manifestations.

The documentation and source-code download links are available here.

Here's the changelog:

0.9.2
- included Bach and Schubert MusicXML files from MusicSQL project (http://musicsql.googlecode.com/).
    - For the Bach, cleaned up diacritics (in titles only) and changed "Soprano", etc. to "Soprano", etc.
        - diacritics are still messed up in lyrics. I'm too lazy to fix them. :]
    - For the Schubert, changed "Part_1" through "Part_4" to "Violin 1", "Violin 2", "Viola", and "Cello".
    - original files available here:

http://musicsql.googlecode.com/files/Bach_SATB-1.0.zip

http://musicsql.googlecode.com/files/Schubert_quartets-1.0.zip

- adjusted <hr> rules in style.css to accomodate Internet Explorer 9
    - Removed "optimized for Firefox" in welcome.php since MXMLiszt now works well in IE, Firefox, Chrome, Safari, and Opera (see below).
- fixed generateIndex.php so the <img> tag now closes in this line:
        echo nl2br('<img src="png/' . $filenamePlain . '.pre.png" />'); //line #12
    - This was the only reason the Index view wasn't working in Opera.
        - Opera was the only browser that caught this error. :]
- made "Results" header for search results an <h2>, just as with the MIR results header.
- added two modules: startWatch.php and stopWatch.php to reduce coding redundancy in regard to reporting the time it takes for actions to finish.
- changed mxml2mods.xsl to output the MODS namespace.
    - adjusted mods.xsl, loadMODSasDC.php, and XQuery syntax as needed.
    - Sample XQueries using a namespace prefix:

        This is a Faust query example:
                    declare namespace mods = "http://www.loc.gov/mods/v3";
                    for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS/mods:mods
                    let $x1 := $x//mods:subTitle
                    return $x1

        This is a Dante example:
                    declare namespace mods = "http://www.loc.gov/mods/v3";
                    for $x in doc("../concat/concatMODS.xml")/hyperMODS/hypoMODS
                    let $x1 := $x/mods:mods
                    where $x1//mods:subTitle contains text "You"
                    return data($x/@file)

- simplified some of the built in MODS related XQueries (same functionality, just less wordy).
- changed order of MODS search drop down terms on Search page.
- changed <i> and <b> to <em> and <strong>, respectively.
- replaced "pop1", etc. with better-named CSS variables like stickyNote and IndexPopup, etc. in style.css.
- added a streamed comment in each module with a one or two sentence description of what it does.
- added .htaccess file.
    - to hide root folder.
    - to make the "/~foo.xml" forward (with masking) to:"transmuteMXML.php$fname=musicXML/foo.xml".
        - adjusted mxml2mods.xsl accordingly.
    - to hide directory icons.
    - to use fancy indexing.
- changed displayMODS.php to display MODS files via an <iframe> only as a fallback if PHP XSL processing not available on server.
_______________________________________________________________________
0.9.1
- created mods.css file to display MODS on a transparent background.
- changed displayMODS.php to display MODS files via an <iframe>.
    - The previous version was using the mods.xsl stylesheet to parse the MODS element values in real-time.
_______________________________________________________________________
0.9.0
- this was the first version - that worked!

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/

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.

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 …

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?

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?