You can replace fragments of the musical text, by clicking on the green dots and selecting another variant.

In some cases, one source is different from all others, while all other sources agree. In other cases, some sources agree on one variant, and other sources agree on another. In the little pop-up variant selector window, you can see which source(s) a variant comes from (Figure 3-4).

Evaluation

With this application you can select an arbitrary combination of variants, effectively creating your own ‘edition’ or a customized ‘view’ of the piece. It is an extremely powerful feature compared to printed music.

Unfortunately, allowing an arbitrary combination of sources brings us to new challenges. When a semantically closely related set of differences is encoded by a number of differences in the MEI (e.g. a two-syllable word difference in lyrics is represented by two differences in MEI) it makes no sense to choose an arbitrary combination of sources. For this reason meiView currently doesn’t show differences in lyrics and it only displays local variants. That is, differences that don’t span across barlines, or if they do, they are split into multiple differences. You can check out an example of this at page 3 measure 3-4. Note that the ties don’t generally cause problems, because in more simple cases they can be encoded as a single element, therefore the difference only concerns the measure containing that element, see for instance page 1 measure 3. Fortunately, there are plans to overcome this problem by allowing the music editors to specify which combination of variants are possible and limit user options accordingly.

This project has demonstrated some of the potential of the MEI format to musicians and music scholars. According to the feedback from the participants at the École Thématique in Tours, there’s great interest in taking MEI-to-VexFlow and meiView even further. The application will be integrated into the Digital Du Chemin platform.

Acknowledgements

I feel lucky for having been able to participate in this project, which was made possible by the Google Summer of Code program and Maryland Institute for Technology in the Humanities at theUniversity of Maryland. Also, I would like to thank my project mentor Raffaele Viglianti who provided fantastic support, and David Lee from University of Glasgow (UK) for providing me with the musical material.

 

 

 

MEI provides two ways of describing where a line begins and where it ends. The most straightforward way is to specify that a crescendo, for instance, ‘starts at note one in measure two and ends at note two in measure two’, as in the example below:

On the other hand there are instances when the line doesn’t exactly correspond to the start of notes. For these cases MEI allows the encoder to specify two points in time expressed as beats. For example the diminuendo in the second bar of the Ravel example (Figure 1) starts roughly on the third beat, hence one can describe it as a ‘diminuendo starting at beat three and ending at beat “five”—that is at the very end of the measure’. Or indeed, in the fourth measure the crescendo ‘starts at beat one and ends at beat three’.

I’ve made MEI to VexFlow capable of dealing with such encodings, in other words, it is now possible to display lines that are described with beats in the MEI file. Although, VexFlow is only capable of drawing lines that start and end with a note, so my solution was to find the closest notes of two given beats and to draw the lines as if they were attached to such notes. This is a very important step towards more advanced support for these objects. In the future it will be possible to render the lines between the correct locations by calculating offsets from the closest notes.

 

 

Several other features have been introduced. Now it’s possible to display changing time signature, meter or clef. For instance, in the harp part of the Sonata for Flute Viola and Harp by Debussy all three occur at once:

 

 

System breaks are also now supported (Figure 4), and staff connectors are now rendered on the left of each system. Different staff connectors are supported in order to render different symbols connecting different groups of staves (for example, a brace for the piano right left hand, or a bracket for a group of instruments in an orchestral score).

 

 

 

These are important steps towards the usability of the scores in real-life use cases such as performance or practice.

For more information about the project, visit our project page and to see MEI to VexFlow in action (scores rendered directly in your browser) try out the demo page!

In our next milestone we are turning our attention towards variant handling. Historical musical pieces make their way to us through multiple documents and it often happens that multiple sources introduce differences and variants in the music. We are designing a sample web application that will be able to display 15–16^th century music and provide a dynamic mechanism for the user to select which variant they want to see.

To achieve this, we are adding new parsing interface to MEI to VexFlow in order to expose the set of variants encoded in the input file. A web application will be able to display this information to the user and allow them to make their choices before rendering, and to see multiple variants at the same time.