ScoreSVG

A Web-Based Music Editor for Creating Scores in SVG

Keywords: SVG, Music Notation, Music Editing, Java 2D Graphics, XSLT, Guido, XML

Dr. Geoffrey Bays
M.S. student, Computer Science
Georgia State University
P.O. Box 3994
Atlanta
GA
USA
geoffbays@operamail.com

Biography

Geoffrey Bays is a Master's student in Computer Science at Georgia State University.

Dr. Ying Zhu
Assistant Professor, Computer Science
Georgia State University
P.O. Box 3994
Atlanta
GA
USA
yzhu@cs.gsu.edu


Abstract


ScoreSVG is a project designed to produce a non-proprietary output format for music score notation using the W3C’s SVG standard. Large, complex proprietary music editors such as Sibelius, and Finale require the purchase of expensive software, and output to formats such as PDF, PS, and TeX that require further specialized software to display. SVG, in contrast, is viewable easily in Internet Explorer with a plugin from Adobe, in the new Opera 8.0 browser which supports TinySVG, and hopefully in Mozilla in the near future. Score SVG aims to enable the user to create small scores and will be especially useful for music theory examples and interactive test questions .

The three-part software architecture of ScoreSVG has a WYSIWYG Java score editor using Java 2D objects on the front end, GuidoXML in the middle, and an XSL transform on the backend to output an SVG file. The Java front end provides x and y coordinates for all musical elements makingthe backend XSL transform much easier to implement. GuidoXML is based on the Guido music notation format, and preserves al the semantic meanings of the score for further analysis.The Saxon 8.4 XSL processor is used to create the final SVG output using the backend stylesheet.

Score SVG will be configured as a web-based application using the new Java Web Start technology, which allows a Java application to read and write files on a client system.


Table of Contents


1. Introduction
     1.1 Rationale for ScoreSVG: The Current State of Music Editors
     1.2 Music XML Formats
     1.3 Guido Music Notation and guidoXML
2. Design and Implementation Issues of ScoreSVG
     2.1 ScoreSVG: Three-tiered Design
     2.2 Adaptation of guidoXML
     2.3 Embedding of Musical Fonts in ScoreSVG
3. ScoreSVG: Current Implementation and Future Plans
     3.1 Features and Capabilities of the Java Front End
     3.2 Processing of Java Input Using XSLT to Create an SVG Output File
     3.3 Future Development Plans for ScoreSVG
Bibliography

1. Introduction

1.1 Rationale for ScoreSVG: The Current State of Music Editors

As any student of music knows, the primary music score editors, Finale and Sibelius, while full-featured and capable of delivering print-ready scores, are large, complex and expensive software packages. Output of these programs is to a proprietary file format, or PostScript, or now to MusicXML format. (See next section). Web-viewable scores are rare, but do now exist. Recently, Sibelius has implemented Scorch, which allows web viewing and playing of Sibelius music files and capella, a German company, has implemented html output of music scores. Both of these commercial editors are fairly expensive. Other attempts at making music scores viewable on the web are difficult to find.

A perusal of Acadia University's website on music notation software at http://ace.acadiau.ca/score/others.htm reveals a large number of specialized music editors for musical niches such as guitar tablature, early music notation and Braille music. Brahms software at brahms.sourceforge.net even has a piano roll music editor in it! LilyPond is the most notable open source music editor, outputting to .ly files and PostScript. [8] Results from LilyPond are very aesthetically satisfying, as the development team has worked hard to achieve an engraver's quality score. Output to html is achieved by specifying image tags to PostScript images, a process automated by the command-line tool, lilypond-book.

What appears to be missing from the extensive list of editors is an inexpensive or free editor that is general purpose, outputs to a non-proprietary file format, and allows for easy web viewing. ScoreSVG was conceived to fill this apparent gap in music editors, and to provide a starting place for further musical researches and transformations made possible by XML and SVG.

1.2 Music XML Formats

A music XML format was deemed necessary for ScoreSVG to record and preserve the semantic meaning of the music score for possible analysis, transformation or some additional parsing. Without this XML at its center, ScoreSVG would just be a transformation of graphics from one format to another. As with music editors, there are multifarious music XML formats. No less than 17 music XML formats can be found at http://xml.coverpages.org/xmlMusic.html , and there are many more as well. [9] The most widely used of these formats, indeed the only one to have achieved any widespread use, is the MusicXML format from Recordare. [14] It is very complete, and is now used as a translation agent for Finale and Sibelius, with other third party software hooking up to LilyPond as well. Unfortunately, it is extremely verbose and therefore only machine readable. SMDL from the ISO/IEC group in 1995 was based on SGML, vastly complex, and seems not to have been used by anyone. ABC is a text-based non-XML format, but not altogether complete and missed the XML development explosion. Other music XML projects, such as 4ML and MusiXML, seem to be isolated efforts, as was the project that caught the author's attention: Guido music notation format.[12] The only known attempt to convert music XML to SVG lies in Laura O'Shea's 2003 paper for the SVGOpen2003, MusicML2SVG. She presents an incomplete attempt to convert MusicXML to SVG using XSLT, but the author encounters difficulties with fonts and positioning of musical elements. These are the same difficulties that will be discussed below. [13]

1.3 Guido Music Notation and guidoXML

Guido music notation, found at http://www.informatik.tu-darmstadt.de/AFS/GUIDO/ is a non-XML text-based music notation system that is truly compact and human-readable as well as fairly complete for Western music notation. [5] It was developed by a team of faculty and students at the Technical University of Darmstadt (TUD), and continues to be worked on up to the present. This system is remarkably compact and complete, designed to be written by humans , not machines. A parser and viewer for Guido music notation, the Guido NoteServer was created and runs as a Java applet from the Guido web site. [6] It outputs to .gif and EPS formats. To use it , of course, one must learn Guido.

When the XML explosion occurred , a group of students at TUD developed a guidoXML format that retained the original system's compactness and completeness and combined this with a guido2xml parser and an xml2guido parser, both written in C++. A subset of guidoXML based on the DTD developed at TUD was used for ScoreSVG, a subset that will become more complete as more features are implemented in the future. See appendix 1 for the guidoXML subset used in ScoreSVG. The guidoXML subset was amended to include some additional attributes to facilitate processing by the XSL stylesheet, notably x and y coordinates for most XML elements. Changes made to guidoXML will be discussed further in section II. Nonetheless, the guidoXML provides a compact vehicle for the semantic meanings of any score created.

2. Design and Implementation Issues of ScoreSVG

2.1 ScoreSVG: Three-tiered Design

Although initial work on ScoreSVG was done on the XSL stylesheet that transforms the guidoXML to SVG, a three-tired architecture was planned from the outset. A WYSIWYG editor on the front end that allows for easy layout of a score, XML in the middle for semantics, and an XSL stylesheet for SVG output on the backend. The Saxon 8.0 XSLT processor from Michael Kay [15] would parse the XSL stylesheet and output the score to an SVG file. Figure 1 shows the overall architecture of ScoreSVG. Several options for transforming the guidoXML to SVG were considered, including imperative languages Python and Java, but XSL is very efficient at generating a transform with its declarative style if the number of decisions and calculations is kept to a minimum. Keeping those calculations to a minimum resulted in some changes to the guidoXML tag set.

ScoreSVGArch.gif

Figure 1: ScoreSVG Architecture

2.2 Adaptation of guidoXML

guidoXML was never designed with XSLT in mind. It relies solely on attributes for element data, which is alright, but the <stemsup/ > and <stemsdown/> tags are empty, and precede the notes they are to modify. Note elements are siblings of the stems elements.Thus only the position of the stems tags determines their effect on subsequent notes. This is an implementation headache with XSLT, because the transforms follow a functional programming model that disallows side-effect variables that could store positional data on the elements. Though the note stems can be realized correctly using elaborate XPath 2.0 and XSLT 2.0 features, this effort was clearly a matter of swimming against the current, and therefore a stems attribute was added to each note element. In addition, determining the x coordinates of the musical elements was deemed unreasonable for XSLT. A complex algorithm written in an imperative language was sketched, but x and y coordinates were easily added to the original guidoXML format enabling XSLT to be used. If desired, a simple XSL stylesheet removing x, y, and stems attributes could produce original guidoXML. Example 1 provides a small sample of guidoXML and Example 2 shows the modified guidoXML used by ScoreSVG. In guidoXML, <guido> is the topmost element. It has a single child element, <segment>. A segment can have many sequences, each sequence being a line of music occurring in the same time frame. Thus a score for two violins would contain two sequences, and a Bach fugue in four voices would have four sequences.

	 
	<guido>
      <segment>
        <sequence>
         <clef s = "f"/>
         <staff i = "1"/>
         <key i = "-3"/>
         <meter s = "4/4"/>
         <stemsdown/>
         <note name = "f" octave = "0" duration = "1/8" accidentals = "flat"/>
         <note name = "g" octave = "0" duration = "1/4" />
         <note name = "d" octave = "1" duration = "1/8" accidentals = "sharp"/>
         <stemsup/>
         <note name = "e" octave = "-1" duration = "2/4"/>
         <bar/>
         <rest duration = "1/8"/>
         <note name = "b" octave = "0" duration = "3/8" accidentals = "natural"/>
         <rest duration = "1/4"/>
         <note name = "c" octave = "-1" duration = "1/4" accidentals = "natural"/>
         <bar/>
         <rest duration = "4/4"/>
         <doublebar/>
       </sequence>
     </segment>
    </guido>
          
	

Example 1: Original guidoXML

	 
	<guido>
   <segment>
      <sequence>
         <clef s = "f" x="100" y="100"/>
         <staff i = "1" x="100" y="100"/>
         <key i = "-3" x="100" y="100"/> 
         <meter s = "4/4" x="235" y="100"/>
         <stemsdown/>
         <note name = "f" octave = "0" duration = "1/8" accidentals = "flat" stem="down" x="312 y="120"/>
         <note name = "g" octave = "0" duration = "1/4" stem="down" x="364" y="110"  />
         <note name="d" octave ="1" duration = "1/8" accidentals = "sharp" stem="down" x="421" y="70"/>
         <stemsup/>
         <note name = "e" octave = "-1" duration = "1/2" stem="up" x="470" y="200"/>
         <bar x="502" y="100"/>
         <rest duration = "1/8" x="514" y="125"/>
         <note name="b" octave="0" duration="3/8" accidentals = "natural" stem="up" x="577" y="160"/>
         <rest duration = "1/4" x="623" y="126"/>
         <note name="c" octave = "-1" duration = "1/4" accidentals ="natural" stem="up" x="660" y="220"/>
         <bar x="692" y="100"/>
         <rest duration = "4/4" x="744" y="120"/>
         <doublebar x="850" y="100"/>
       </sequence>
     </segment>
</guido>
	
	

Example 2: Modified guidoXML

2.3 Embedding of Musical Fonts in ScoreSVG

One of the initial difficulties in implementing ScoreSVG lay in the manner in which to produce the musical graphics on the front end in Java and on the backend in SVG. Musical fonts, whether Adobe's Sonata font or the Maestro font used in ScoreSVG are always symbol encoded fonts, and somewhat difficult to render in Java. The Maestro font, an older version of the font used in Coda Music's famous Finale score editor, is a True Type font complete with Unicode mapping for each glyph. Theoretically, this can be embedded in a Java application using the static createFont() method as shown below for Java 1.4.2 . In Java 1.5 (JDK 5.0) the second parameter for the createFont() method is the file name, making the whole process more streamlined. The code below in example 3 must be placed in a try block to catch an IOException and a FileFormatException.

     
	   FileInputStream fin = new FileInputStream("C:\\ScoreSVG\\Fonts\\MAESTRO_.TTF");
       DataInputStream din = new DataInputStream(fin);
       musicFont2 = Font.createFont(Font.PLAIN,din);
	   musicFont = musicFont2.deriveFont((float)size);   // size is an int variable
	

Example 3: Java 1.4.2 code to create an embedded font

The difficulty lay in knowing what the character encodings for the Maestro font were. Symbol encoded fonts such as WingDings, WebDings and Maestro have glyph mappings that go from around hexadecimal F020 to F0FB. FontCreator 5.0 from HighLogic [7] is a most useful program that shows the character mappings for True Type fonts, and allows one to create or edit fonts. With the hexadecimal Unicode values, any Maestro character can be shown in a Java application using the Unicode escape sequence, e.g. char c = '\uF026' . This will reveal a treble clef.

On the backend of ScoreSVG, the challenge was to find a way to display the musical font glyphs in SVG with complete path information. PhotoImpact from Ulead [11] exports files to SVG. More specifically, once a text object has been converted to a path object it can be exported in SVG form with all the necessary path data in very small file size. Once the Maestro glyphs have been retrieved in this manner they can be resized and positioned easily using basic SVG features. [1]

3. ScoreSVG: Current Implementation and Future Plans

3.1 Features and Capabilities of the Java Front End

Currently, ScoreSVG supports basic musical elements for simple scores. Note values supported are: whole notes, half notes, quarter notes, eighth notes and sixteenth notes with their dotted versions as well. Treble and bass clefs are supported, as are all standard key signatures and meters. Rests from whole rests down to sixteenth rests with dots are implemented, with the user being able to position the rests exactly. Beamed notes and chords are not supported yet, but should be forthcoming shortly. MouseListener and MouseMotionListener event handlers in Java enable notes, rests and accidentals to be dragged to new locations and deleted by double clicking. The dot, sharp, and natural buttons related to the notes and rests toggle on and off, with a changed background color when toggled on.

The layout of the main ScoreSVG GUI was designed to be simple and to provide the user access to commonly used features without resorting to drop-down menus. Thus the current basic features are all accessible from buttons. A screen shot of the ScoreSVG front end displaying a portion of a Bach chorale is shown in Figure 2 below:

screenGif3.gif

Figure 2: ScoreSVG Main GUI

3.2 Processing of Java Input Using XSLT to Create an SVG Output File

Once the user has input all of the musical elements, the FINISH button activates all subsequent processing. First, all musical element objects in the program's memory deliver their XML data through their toString() method and this is written to a file. Then, ScoreSVG makes a system call and runs the Saxon XSLT processor which takes the XML file and a XSL stylesheet file as command line input. The resulting output file in SVG is viewable in Internet Explorer with the Adobe SVG plugin and in the Batik SVG viewer from the Apache Foundation. Figure 3 below shows the SVG output of the modified guidoXML in Listing 2. The source code of the SVG output file includes all the paths of the embedded fonts, plus many lines similar to: <svg:use xlink:href="#quarternoteup" x="660" y="220" transform="scale(3.0)/> The staff lines, barlines, whole rests, half rests, dots, and ledger lines were drawn "from scratch" in SVG because it was easy to do and because placement of these elements was guaranteed to be exact, unlike the Maestro-extracted paths which required a little maneuvering to get into the correct position.

The new Opera 8.0 browser supports SVG-Tiny, which would seem to include all necessary SVG features for ScoreSVG, but more study is required to figure out how to get the SVG output files to display in Opera. The files seem to require some modification.

svgOutput.gif

Figure 3: SVG Ouput of Example 2 XML

3.3 Future Development Plans for ScoreSVG

First in line for additions to ScoreSVG are chords and beamed notes. The Maestro font has useful glyphs for this purpose, but guidoXML may have to be amended again. Notes in chords and beamed groups would function much better as child elements of the chord and beamset tags; then the position of an XML tag is not the sole purpose of its existence. Next, adding expressive marks such as slurs, staccatos, fermatas, crescendos, diminuendos, ritardandos and accents would be most gratifying. None of these should prove difficult to implement, but an overhaul of the main GUI to add either extra buttons or drop down menus will probably be necessary. Making the SVG output file interactive with added JavaScript would be another interesting line of development, especially since this feature would not be possible in any other format. Musical quizzes could be designed where the user would have to rearrange notes to form proper voice leading or chord resolution. The notes could be moved around and the SVG file returned for grading. Another useful feature will be printing the score directly from the Java front end for when a printed score is needed. The ability to import data into the Java front end from a Java object file would also be a useful feature. This would allow for score storage independent of the SVG output, and be fairly easy to implement. Formulating the SVG output so that it is viewable in Opera 8 will be yet another satisfying feature to be added in the near future. Finally, ScoreSVG will be placed on the Web using the new Java Web Start technology, which allows applications to read and write files on the client-side system.

Bibliography

[1] Kurt Cagle, SVG Programming: The Graphical Web, Apress, New York,N.Y. 2002
[2] Michael Kay, XSLT 2.0 Third Edition, Wiley Publishing, Indianapolis, 2004
[3] Sal Mangano, XSLT Cookbook, O'Reilly media, Sebastopol, CA 2003
[4] H. Merten, S. Simon, A. Berndt, Guido to XML: Einbettung des Guido Formats in ein XML konformes Modell, Technishe Universitat Darmstadt, 2001.
[5] http://www.informatik.tu-darmstadt.de/AFS/GUIDO/ // Guido Homepage
[6] http://www.noteserver.org/noteserver.html //Guido NoteServer
[7] http://www.high-logic.com/fcp.html // FontCreator 5.0
[8] http://lilypond.org/web/ // LilyPond Music Editor
[9] http://xml.coverpages.org/xmlMusic.html // Music XML formats
[10] http://ace.acadiau.ca/score/others.htm //Acadia University: music score editors
[11] http://www.ulead.com/ // home of PhotoImpact
[12] http://www.musicmarkup.info/scope/markuplanguages.html#4ML // more music XML
[13] Laura O'Shea, Stirring XML: Visualizations in SVG No. 2: MusicML2SVG, Proceedings,SVGOpen2003 Conference, 2003 http://www.svgopen.org/2003/papers/StirringXml-VisualisationsInSVG/#S2.
[14] http://www.recordare.com/ // Recordare, home of MusicXML
[15] http://saxon.sourceforge.net //Home of the Saxon XSLT

XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.