
If you have a single song that is not part of a collection, you will usually put the title of the song in the element, and not use either the or elements. Similarly, we use the element for the title of the individual song. We use the to identify that “Mut” is the 22nd song in the cycle – it is not restricted to use for movements in a symphony. If you have all the movements in a work represented, you can use the element to link to the MusicXML opus file that in turn contains links to all the movements in the work. numbers than opus numbers, so that is what we use in the element the contains the name of the larger work. Schubert’s works are more commonly referred to via D. The element is used to identify the larger work of which this movement is a part. In MusicXML, individual movements are usually represented as separate files. Only the part-list is required, all other elements are optional. You see that this score header has all five of the possible top-level elements in the score header: the, ,, and. Here is a sample score header for that work:īased on Breitkopf & Härtel edition of 1895 It also contains the, which lists all the parts or instruments in a musical score.Īs an example, take our MusicXML encoding of “Mut,” the 22nd song from Franz Schubert’s song cycle Winterreise. The score header contains some basic metadata about a musical score, such as the title and composer. If the example in the preceding “Hello World” section gave you enough information, you may want to skip ahead to the next section that starts describing music data. We will now look at the score header in more detail. The score header may contain the following elements: This contains the actual music in the score, including zero or more of the following elements: In either case, the lower-level elements are filled with a group of elements referred to as music data. The document reverses the ordering of and elements. A document contains one or more elements, and each element contains one or more elements. The only difference between the two formats is the way that the and elements are arranged. Top-Level ElementsĮach of the top-level formats contains a group of elements called the score header, followed by the musical data. If all else is equal, that would be the format of choice for your application.

In practice, most of today's MusicXML applications use the format. Let the program reading the MusicXML convert it if necessary. When your application writes to MusicXML, simply write to whichever format best meets your needs. If it is neither of the two top-level document types, you do not have a MusicXML score, and can return an appropriate error message. If so, apply the appropriate XSLT stylesheet to create a new MusicXML document in your preferred format, and then proceed. If not, check to see if it is the other MusicXML root element. If it is your root element, just proceed. Īn application reading MusicXML can choose which format is primary, and check for that document type. The parttime.xsl stylesheet converts from to, while the timepart.xsl stylesheet converts from to. MusicXML provides two XSLT stylesheets to convert back and forth between the two document types. Having two different structures does not work well if there is no automatic way to switch between them. The measure is primary, and musical parts are contained within each measure.

For a timewise document, the root element is. The musical part is primary, and measures are contained within each part. For a partwise document, the root element is. This is why MusicXML has two different score formats, each with its own root element. David Huron, a music cognition specialist and the inventor of Humdrum, advised us to make sure we could represent music both ways, and be able to switch between them easily. The answer is different for every music application. How do we reconcile this? Should the horizontal organization of musical parts be primary, or should the vertical organization of musical measures? XML represents data in a hierarchy, but musical scores are more like a lattice. It has multiple parts, one per player, and multiple measures. Say we have a piece of music for two or more people to play. The Structure of MusicXML Files Adapting Musical Scores to a Hierarchy
