A Formal Grammar for Describing Music

Adam Tee

Feb 15, 2001

Contents

1  Introduction to Music Programs File Formats
    1.1  Performance Based Formats
        1.1.1  Standard MIDI File (SMF) Format
        1.1.2  Expressive MIDI
    1.2  Notation Based Formats
        1.2.1  Common Music Notation CMN
        1.2.2  DARMS
        1.2.3  SCORE 
        1.2.4  Lilypond
        1.2.5  Guido
    1.3  Analysis Based Formats
        1.3.1  Humdrum and Kern
    1.4  Independent Formats
        1.4.1  Notation Interchange File Format (NIFF)
        1.4.2  MuseData
        1.4.3  Standard Music Description Language (SMDL)
        1.4.4  Music Markup Language MML
2  The Grammar
3  Representation of the Grammar as File Format
    3.1  Introduction
    3.2  Revised Design
    3.3  Reference Implementation

Abstract

With the plethora of music programs available, it is difficult to get one which provides all the functions one requires. For example, if one wants to typeset music it is likely that one will choose a typesetting package. However, if one wanted to both typeset and analyse music, one is hard pressed to find a package that performs both these tasks.

The file formats and specification of these programs does not allow for this, so conversions between the various file formats is required. One is proposing that one possible solution to this problem is to define music as a formal grammar. Then implement this in a file format which contains both the positional information, required for displaying, and the information for the analysis of the work.

1  Introduction to Music Programs File Formats

There are four distinct areas that file formats are used. These are Performance based, Notation Based, Analysis Based and finally a combination of the first two. In this section one will look at a variety of file formats that appear in the above categories. This is for comparison in later section with the proposed format. All encoding examples are of the following Bach chorale.

Figure 1: Bach Encoding Example

1.1  Performance Based Formats

1.1.1  Standard MIDI File (SMF) Format

As most people know, MIDI stands for Musical System Digital Interface. This format is one of the few program/platform independent formats that is currently used. It is a binary format that encodes performance details as opposed to musical details. This format is again based upon the Electronic Arts IFF format[5], in concept anyway. A Standard Midi File, as described by [2], has the following format and layout features.

Format Features   There are three formats: 0, 1, and 2. Format 0 is for monophonic music, i.e. one track. Format 1 is for polyphonic music and is the most widely used format. Format 2 deals with tracks that are temporally independent.

Layout Features   All the formats have the same layout. Each file is split into chunks and there are two types of chunk: First, the header chunk which contains an ASCII identifier, Header Length, Format, the Number of Tracks and other defining features for aspects of the file. The second chunk is the track chunk, this contains an ASCII header, Track Length and Track Events. There are three types of Track Event: Midi Events, Meta Events and System Exclusive (SysEx) Events.

Midi events are control events which control; things like note on/off, instrument changes etc. Meta events contain information which is not represented in the midi or sysex events. Finally, the System Exclusive message contains information for midi instruments that control other features.

The following example shows a ASCII representation of two tracks of a four track midi file. 2

ASCII Representation of MIDI file
Chunk Type: MThd
Header Length: 6
Midi Format type: 1
Number of Tracks: 4
Ticks Per Quarter Note: 96

Header Information 
Key Signature: 0
Time Signature: 4 4
Ticks Per Quarter Note: 96
Number of 32nds per Quarter Note: 8

1  Note on  F4  65  0  01:04:00  72
1  Note off F4  65  48 01:04:48  72
1  Note on  G4  67  0  01:04:48  72
1  Note off G4  67  48 01:04:96  72
1  Note on  A4  69  0  02:01:00  72
1  Note off A4  69  96 02:01:96  72
1  Note on  Bb4 70  0  02:02:00  72
1  Note off Bb4 70  96 02:02:96  72
1  Note on  C5  72  0  02:03:00  72
1  Note off C5  72  96 02:03:96  72
1  Note on  C5  72  0  02:04:00  72
1  Note off C5  72  96 02:04:96  72
1  Note on  D5  74  0  03:01:00  72
1  Note off D5  74  96 03:01:96  72
1  Note on  E5  76  0  03:02:00  72
1  Note off E5  76  96 03:02:96  72
1  Note on  F5  77  0  03:03:00  72
1  Note off F5  77  96 03:03:96  72
1  Note on  F4  65  0  03:04:00  72
1  Note off F4  65  48 03:04:48  72
1  Note on  G4  67  0  03:04:48  72
1  Note off G4  67  48 03:04:96  72
1  Note on  A4  69  0  04:01:00  72
1  Note off A4  69  96 04:01:96  72
1  Note on  Bb4 70  0  04:02:00  72
1  Note off Bb4 70  96 04:02:96  72
1  Note on  C5  72  0  04:03:00  72
1  Note off C5  72  96 04:03:96  72
1  Note on  C5  72  0  04:04:00  72
1  Note off C5  72  96 04:04:96  72
1  Note on  Bb4 70  0  05:02:00  72
1  Note off Bb4 70  96 05:02:96  72
1  Note on  A4  69  0  05:01:00  72
1  Note off A4  69  96 05:01:96  72
1  Note on  G4  67  0  05:03:00  72
1  Note off G4  67  96 05:03:96  72

2  Note on  C4  60  0  01:04:00  72
2  Note off C4  60  96 01:04:96  72
2  Note on  F4  65  0  02:01:00  72
2  Note off F4  65  96 02:01:96  72
2  Note on  E4  64  0  02:02:00  72
2  Note off E4  64  96 02:02:96  72
2  Note on  F4  65  0  02:03:00  72
2  Note off F4  65  96 02:03:96  72
2  Note on  A4  69  0  02:04:00  72
2  Note off A4  69  96 02:04:96  72
2  Note on  Bb4 70  0  03:01:00  72
2  Note off Bb4 70  48 03:01:48  72
2  Note on  A4  69  0  03:01:48  72
2  Note off A4  69  48 03:01:96  72
2  Note on  G4  67  0  03:02:00  72
2  Note off G4  67  96 03:02:96  72
2  Note on  A4  69  0  03:03:00  72
2  Note off A4  69  96 03:03:96  72
2  Note on  C4  72  0  03:04:00  72
2  Note off C4  72  96 03:04:96  72
2  Note on  F4  65  0  04:01:00  72
2  Note off F4  65  96 04:01:96  72
2  Note on  G4  67  0  04:02:00  72
2  Note off G4  67 192 04:03:96  72
2  Note on  F4  65  0  04:04:00  72
2  Note off F4  65 144 05:01:48  72
2  Note on  E4  64  0  05:01:48  72
2  Note off E4  64  48 05:01:96  72
2  Note on  F4  65  0  05:02:00  72
2  Note off F4  65  96 05:02:96  72
2  Note on  E4  64  0  05:03:00  72
2  Note off E4  64  96 05:03:96  72     

This demonstrates that there is a large amount of data required to encode a small number of bars of music.

1.1.2  Expressive MIDI

This is an extension of the SMF format. It allows the encoding of all musical symbols which cannot be encoded in normal midi files[7]. This is so that a page-description can be gathered. It allows this by using a System Exclusive message to encode the data. The following shows a sample message.
        0xF0            start of sysex message
        0x7D            expEvent message (non-commercial value)
        <Data Bytes>    Symbol data (at least 2 Bytes)
        0xF7            end sysex message

Each symbol is encoded from a look-up table. There are three tables for the symbols which are split into two distinct groups. Isolated and Extensible, the difference being, extensible symbols appear across a number of events. The way in which the symbols are encoded is as follows:

  Data Byte1  0XXYYYYY  XX - table number YYYYY - Option Flags
  Data Byte2  0ZZZZZZZ  ZZZZZZZ - Symbol Number


The following example shows a sample ASCII representation of an expMidi file. Again it shows only the first two tracks. 2
ASCII Representation of Expressive MIDI 
file

Chunk Type: MThd
Header Length: 6
Midi Format type: 1
Number of Tracks: 4
Ticks Per Quarter Note: 96

Header Information 
Key Signature: 0
Time Signature: 4 4
Ticks Per Quarter Note: 96
Number of 32nds per Quarter Note: 8

1  Note on  F4  65  0  01:04:00  72
1  <Begin expEvent>    01:04:00
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0
   Beam_Code
   <End expEvent>
1  Note off F4  65  48 01:04:48  72
1  Note on  G4  67  0  01:04:48  72
1  <Begin expEvent>    01:04:48
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1
   Beam_Code
   <End expEvent>
1  Note off G4  67  48 01:04:96  72
1  Note on  A4  69  0  02:01:00  72
1  Note off A4  69  96 02:01:96  72
1  Note on  Bb4 70  0  02:02:00  72
1  Note off Bb4 70  96 02:02:96  72
1  Note on  C5  72  0  02:03:00  72
1  Note off C5  72  96 02:03:96  72
1  Note on  C5  72  0  02:04:00  72
1  Note off C5  72  96 02:04:96  72
1  Note on  D5  74  0  03:01:00  72
1  Note off D5  74  96 03:01:96  72
1  Note on  E5  76  0  03:02:00  72
1  Note off E5  76  96 03:02:96  72
1  Note on  F5  77  0  03:03:00  72
1  <Begin expEvent>    03:03:00
   CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0
   Fermata_Code
   <End expEvent>
1  Note off F5  77  96 03:03:96  72
1  Note on  F4  65  0  03:04:00  72
1  <Begin expEvent>    03:04:00
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0
   Beam_Code
   <End expEvent>
1  Note off F4  65  48 03:04:48  72
1  Note on  G4  67  0  03:04:48  72
1  <Begin expEvent>    03:04:48
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1
   Beam_Code
   <End expEvent>
1  Note off G4  67  48 03:04:96  72
1  Note on  A4  69  0  04:01:00  72
1  Note off A4  69  96 04:01:96  72
1  Note on  Bb4 70  0  04:02:00  72
1  Note off Bb4 70  96 04:02:96  72
1  Note on  C5  72  0  04:03:00  72
1  Note off C5  72  96 04:03:96  72
1  Note on  C5  72  0  04:04:00  72
1  Note off C5  72  96 04:04:96  72
1  Note on  Bb4 70  0  05:02:00  72
1  Note off Bb4 70  96 05:02:96  72
1  Note on  A4  69  0  05:01:00  72
1  Note off A4  69  96 05:01:96  72
1  Note on  G4  67  0  05:03:00  72
1  <Begin expEvent>    05:03:00
   CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0
   Fermata_Code
   <End expEvent>
1  Note off G4  67  96 05:03:96  72

2  Note on  C4  60  0  01:04:00  72
2  Note off C4  60  96 01:04:96  72
2  Note on  F4  65  0  02:01:00  72
2  Note off F4  65  96 02:01:96  72
2  Note on  E4  64  0  02:02:00  72
2  Note off E4  64  96 02:02:96  72
2  Note on  F4  65  0  02:03:00  72
2  Note off F4  65  96 02:03:96  72
2  Note on  A4  69  0  02:04:00  72
2  Note off A4  69  96 02:04:96  72
2  Note on  Bb4 70  0  03:01:00  72
2  <Begin expEvent>    03:01:00
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=0
   Beam_Code
   <End expEvent>
2  Note off Bb4 70  48 03:01:48  72
2  Note on  A4  69  0  03:01:48  72
2  <Begin expEvent>    03:01:48
   CodeTbl=0 Y1=0 Y2=0 Y3=0 Y4=0 Y5=1
   Beam_Code
   <End expEvent>
2  Note off A4  69  48 03:01:96  72
2  Note on  G4  67  0  03:02:00  72
2  Note off G4  67  96 03:02:96  72
2  Note on  A4  69  0  03:03:00  72
2  <Begin expEvent>    03:03:00
   CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0
   Fermata_Code
   <End expEvent>
2  Note off A4  69  96 03:03:96  72
2  Note on  C4  72  0  03:04:00  72
2  Note off C4  72  96 03:04:96  72
2  Note on  F4  65  0  04:01:00  72
2  Note off F4  65  96 04:01:96  72
2  Note on  G4  67  0  04:02:00  72
2  <Begin expEvent>    04:02:00
   CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0
   Tie_Code
   <End expEvent>
2  Note off G4  67  96 04:02:96  72
2  Note on  G4  67  0  04:03:00  72
2  <Begin expEvent>    04:03:00
   CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=1
   Tie_Code
   <End expEvent>
2  Note off G4  67  96 04:03:96  72
2  Note on  F4  65  0  04:04:00  72
2  <Begin expEvent>    04:04:00
   CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0
   Tie_Code
   <End expEvent>
2  Note off F4  65  96 04:04:96  72
2  Note on  F4  65  0  05:01:00  72
2  <Begin expEvent>    05:01:00
   CodeTbl=0 Y1=1 Y2=0 Y3=0 Y4=0 Y5=0
   Tie_Code
   <End expEvent>
2  Note off F4  65  48 05:01:48  72
2  Note on  E4  64  0  05:01:48  72
2  Note off E4  64  48 05:01:96  72
2  Note on  F4  65  0  05:02:00  72
2  Note off F4  65  96 05:02:96  72
2  Note on  E4  64  0  05:03:00  72
2  <Begin expEvent>    05:03:00
   CodeTbl=0 Y1=0 Y2=0 Y3=1 Y4=0 Y5=0
   Fermata_Code
   <End expEvent>
2  Note off E4  64  96 05:03:96  72     

1.2  Notation Based Formats

1.2.1  Common Music Notation CMN

This is the name of the program, as well as the name of the file format, that typesets music[28,29]. It is primarily aimed at composers. It is written in LISP with the input being a large LISP function. For this reason, the format is very verbose. In this, one means long words are used to represent symbols as opposed to a combination of control and single characters. Two more features are that it is hierarchical and it is ASCII based.

The following example shows how the file is laid-out.

;;; -*- syntax: common-lisp; package:cmn; base: 10; mode: lisp -*-
(cmn (size 20)
  (system brace
    (setf s1 (staff treble (key f-major) (meter 4 4)
     (f4 e stem-up) (g4 e stem-up) bar
     (a4 q stem-up) (b4 q stem-up) (c5 q stem-up) (c5 q stem-up) bar
     (d5 q stem-up) (e5 q stem-up) (f5 q fermata stem-up)
       (f4 e stem-up) (g4 e stem-up) bar
     (a4 q stem-up) (b4 q stem-up) (c5 q stem-up) (c5 q stem-up) bar
     (b4 q stem-up) (a4 q stem-up) (g4 q fermata stem-up)))
    (staff (tied-to s1) (c4 q stem-down) bar
     (f4 q stem-down) (e4 q stem-down) (f4 q stem-down) 
       (a4 q stem-down) bar
     (b4 e stem-down) (a4 e stem-down) (g4 q stem-down)
       (a4 q stem-down) (c4 q stem-down) bar
     (f4 q stem-down) (g4 q stem-down begin-tie) (g4 q stem-down end-tie)
       (f4 q stem-down begin-tie) bar
     (f4 e stem-down end-tie) (e4 e stem-down) (f4 q stem-down)
       (e4 q stem-down))
    (setf s2 (staff bass (key f-major) (meter 4 4)
     (a3 e stem-up) (b3 e stem-up) bar
     (c4 q stem-up) (b3 q stem-up) (a3 e stem-up) (c4 e stem-up)
       (f4 q stem-up) bar
     (f4 q stem-up) (c4 q stem-up) (c4 q stem-up) (a3 q stem-up) bar
     (d4 q stem-up) (d4 q stem-up) (c4 e stem-up) (b3 e stem-up)
       (a3 q stem-up) bar
     (b3 q stem-up) (c4 q stem-up) (c4 q stem-up))
    (staff (tied-to s2) (f3 q stem-down) bar
     (f3 q stem-down) (g3 q stem-down) (a3 q stem-down)
       (f3 q stem-down) bar
     (b3 q stem-down) (c4 q stem-down) (f3 q stem-down 
       upside-down-fermata) (f3 e stem-down) ( e3 e stem-down) bar
     (d3 q stem-down) (c3 e stem-down) (b2 e stem-down)
       (a2 q stem-down) (d3 q stem-down) bar
     (g2 q stem-down) (a2 e stem-down) (b2 e stem-down)
       (c3 q stem-down upside-down-fermata))))    

There are features that rigorously specify positional information. Also, storage becomes a problem because of the file size. This is possibly the easiest format to read because of the amount of description used.

1.2.2  DARMS

This file format is the oldest for describing music, it was initially designed in 1963 by Bauer-Mengelberg[3]. It has two main features[30] other than the one mentioned above. The first is that it
...illustrates the orientation of the print-oriented code extremely well.
and second is that it
...offers a paradigm that is rarely presented in the other codes...All files stored in DARMS can be converted to an unambiguous `canonical' version.

It is an Alphanumeric format. There have been variants developed, these are discussed later. It is widely used by scholars in both typesetting and analytical applications. The internals of the format are such that every object is described completely and all positional information in explicit. Pitches are defined using a `vertical space code', which represents the line on the stave that the note is1.

One draw back in the format, in the `vertical space code', is that enharmonic notation is ambiguous even when there is a key signature. The actual note is not explicitly known.

The first DARMS variant one will look at is Note-Processor Dialect DARMS. This describes the actual musical symbols as they appear on the page. This uses a combination of key-codes and alphanumeric characters to represent the symbols. This is used for typesetting purposes. These include Brinkman DARMS[4] and Erickson[9] (Canonical) DARMS but the basics are the same throughout all the variants.

The following example shows one possible encoding technique. The file layout is free-format, easing data-entry but creating many possibilities for problems to occur in the interpretation of the code. 2

!I1 !G, !G, !F, !F
K Begin Soprano Part $
!K1- !M4:4 2EU( 3U) /
4QU 5U 6U 6U /
7QU 8U 9U?109 2EU( 3U) /
4QU 5U 6U 6U /
5QU 4U 3U?109 !-50

K Begin Alto Part $
!K1- !M4:4 -1QD /
2QD 1D 2D 4D /
5ED( 4D) 3QD 4D?110 -1D /
2QD 3DJ1 3DJ2 2DJ1 /
2E(J2 1D) 2QD 1D?110 !-50

K Begin Tenor Part $ 
!K1- !M4:4 9EU( 10U) /
11QU 10U 9EU( 11U) 14QU /
14QU 11U 11U?109 9U /
12QU 12U 11EU( 10U) 9QU /
10QU 11U 11U?110 !-50

K Begin Bass Part $
!K1- !M4:4 7QD /
10QD 8D 9D 7D /
10QD QQD 7D?110 7ED( 6D) /
5QD 4ED( 3D) 2QD 5D /
1QD 2ED( 3D) 4QD?110

As the example shows, some knowledge of the Mnemonics used is required to understand the format. However, it is very concise, in the amount of information stored, due to the use of these Mnemonics.

1.2.3  SCORE 

SCORE is a commercial typesetting/engraving package, which aims to produce equal quality printed output to that of engraving[19]. There are two output file formats available to the user. The first is plain binary and the second is ASCII text. The file format has been derived from the MUSIC V 's file format. One will focus on the ASCII format for this discussion. Contained in the file is all the information to do with the positioning, type of musical object that is to be placed on the page. This also includes an optional offset for particular features, this is so that no collisions occur when the objects appear on the page. However, the main problem with this format is that the data is represented numerically. Thus meaning that one has to have extensive knowledge of the object key to be able to decipher the file. It also means that it is difficult to edit outside the program's environment. There is no example no example given for this due to the nature of the contents of the file. To give an accurate example the SCORE program is required.

1.2.4  Lilypond

Lilypond as mentioned previously is a typesetting program[23]. With this program one is concerned only with the input file format, as the output produced is in LATEX. The file is laid out differently compared to the other formats discussed in that it is a bottom-up design. The first item that appears in the file is the Header. All the files to be included are added. Then each Part is, in turn described. The penultimate section is the grouping of the like parts. The final section is the grouping of all the parts in a system and paper definitions. The syntax of the file is as follows each note is represented as it's note name, then it has an octave specification followed by a duration. A rest is denoted by a r. Then all the other symbols are entered by using their names but having a \ at the front of the name.

2

%Lilypond Sample file
\header{
filename = "bach.ly";
title = "O Ewigeit, du Donnerwort";
tagline = "";
}

\version "1.2.0";
\include "paper11.ly";
global =\notes {
	\key f;
	\time 4/4;	
	\skip4*3;
}
sop = \notes \relative c' {
	\clef "violin";
	\global
	
	\context Staff <
	
	\context Voice = uVoice {
	


	\stemup
	f8 g |
	a4 bes c c |
	d e f-\fermata f,8 g |
	a4 bes c c | 
	bes a g-\fermata \bar "||";
	}
	\context Voice = dVoice {
	\stemdown
	c,4 | 
	f e f a | 
	bes8 a g4 a c, |
	f g~ g f~ |
	f8 e f4 e 
	}

	>
}

bass = \notes {
	\clef "bass";
	\global
	
	\context Staff <
	\context Voice = tenor {	
	\stemup
	a8 bes |
	c'4 bes a8 c' f'4 |
	f' c' c' a |
	d' d' c'8 bes a4 |
	bes c c' \bar "||";
	}
	
	\context Voice = Bass {
	\stemdown
	f4 |
	f g a f |
	bes, c f-\fermata f8 e |
	d4 c8 bes, a,4 d |
	g a,8 bes, c4-\fermata
	}
	>
}

\score {
	\notes \context PianoStaff <
	\sop
	\bass
	>
	\paper{indent=0.0\cm; }
}

1.2.5  Guido

Guido[17,15] is an ASCII based notation format. It is focused on musical information.The format has three different hierarchies. The first is Basic Guido, this deals with the low-level representation notation. The second, Advanced Guido[16], deals with the formatting issues and thirdly, Extended Guido, which introduces features not found in Western Notation. Being a human-readable format guido has some similar properties with CMN in that it is descriptive in it's encoding technique.

Basic Guido as mentioned above deals with the basic notation issues, like duration, slurs etc. Whereas Advanced Guido takes this a step further and adds the extra information that is required when typesetting music.

The following example demonstrates the Basic Guido in use. 2

{ 
[ \staff<1>
\clef<"g2"> \key<"F"> \meter<"4/4">
\stemsUp
_*3/4 f1/8 g |
a1/4 b& c2 c |
d e \fermata(f) f1/8 g | 
a1/4 b& c2 c |
b&1 a \fermata(g) |
],
[ \staff<1>  \key<"F"> \meter<"4/4">
\stemsDown
_*3/4 c1/4 |
f e f a |
b&/8 a g1/4 a c |
f \tie(g g) \tie(f | f1/8) e f1/4 e
],
[ \staff<2> 
\clef<"bass"> \stemsUp \key<"F"> \meter<"4/4">
_*3/4 a0*1/8 b&0*1/8 |
c0*1/4 b&0*1/4 a0*1/8 c1*1/8 f1*1/4 |
f c c a0*1/4 |
d1*1/4 d c1*1/8 b&0*1/8 a0*1/4 |
b& c0 c1*1/4],
[ \staff<2> \stemsDown \key<"F"> \meter<"4/4">
_*3/4 f0*1/4 |
f d a f |
b&-1*1/4 c0*1/4 \fermata(f) f0*1/8 e |
d/4 c/8 b&-1*1/8 a-1/4 d0*1/4 |
g a-1*1/8 b&  \fermata(c0*1/4)]
}

Figure
Figure 2: Guido Encoding Example

Figure 2, above, demostrates the typesetting done by the Guido Note Server[26]. This demonstrates the need for the additional information used in Advanced Guido.

1.3  Analysis Based Formats

1.3.1  Humdrum and Kern

Humdrum is an analysis toolkit which uses ASCII text to encode musical works [32,18]. The files are laid out in a concurrent style. This, one assumes is to make the parsing of the file easier as concurrent events appear on the same line. The way in which the musical objects are encoded, is completely different from SCORE . Notes are represented by letters as opposed to numbers. Again, the user needs to be familiar with the syntax to use this because the octave specification is not numerical, instead a combination of symbols are used. 2
!!Humdrum Sample file
!!Title
**kern		**kern		**kern		**kern
*staff4		*staff3		*staff2		*staff1
*clefF4		*clefF4		*clefG2		*clefG2
*k[b-]		*k[b-]		*key[b-]	*k[b-]
*M4/4		*M4/4		*M4/4		*M4/4
4F		8A		4c		8f
.		8B		.		8g
=1		=1		=1		=1
4F		4c		4f		4a
4G		4B		4e		4b
4A		8A		4f		4cc
.		8c		.		.
4F		4f		4a		4cc
=2		=2		=2		=2
4B		4f		8b		4dd
.		.		8a		.
4c		4c		4g		4ee
4F		4c		4a		4ff
8F		4A		4c		8f
8E		.		.		8g
=3		=3		=3		=3
4D		4d		4f		4a
8CC		4d		[4g		4b
8BB		.		.		.
4AA		8c		4g]		4cc
.		8B		.		.
4D		4A		[4F		4cc
=4		=4		=4		=4
4GG		4B		8F]		4b
.		.		8e		.
8AA		4c		4f		4a
8BB		.		.		.
4C		4c		4e		4g
==		==		==		==	


1.4  Independent Formats

1.4.1  Notation Interchange File Format (NIFF)

The NIFF file format[13,12] is modelled upon the features of the SCORE file format. It was designed using the rule of Microsoft's Resource Interchange File Format (RIFF)[25] structure. It is also platform independent to a certain extent, the only difference between platforms being the way that an integer byte (8bit value) is ordered2. If RIFF is found then it is in Intel byte order, if RIFX is found it is in Motorola byte order. It is a binary format, with some of the data being stored as a combination of ASCII and Hexadecimal codes.

Each file is hierarchically structured having two sections : the first is a setup section which contains part definitions, default parameters and header information. The second section, the data section, contains the musical symbols in a page-ordered format. This means that the data, musical symbols, are stored as they would appear. There is a special case where all the symbols are placed in one system on an indefinitely wide page. Each part has it's own staff. This case is known as `simulated part ordering'. No example is given because the data is stored as hexadecimal numbers.

1.4.2  MuseData

This format is designed for data entry and storage purposes[14]. It has a parametric layout and has the advantage of being software-neutral3. It is another ASCII based format. There are other points which make this is a bad format to use. The first is that conversion to other formats is required to process the data in the file. Secondly, it is not intended to represent a score fully. Finally, there is only one part of the score encoded per file. Thus large orchestral scores require a large number of files. The format uses Mnemonics to represent the musical symbols. Due to it's parametric format it gives columns for each attribute/option. There are 80 columns which contain the data for the note or rest being represented. The columns are split as follows: For note records columns 1-4 contain pitch information, columns 6-9 contain duration information, then columns 13-80 contain graphic and interpretive information.

The following example represents a simple encoding in the format, the columns are not strictly observed, but it does demonstrate the encoding technique.

2

29/10/1999 A Tee
WK#: ?  MV#: ?
?
Chorale
?
Soprano
1  0
Group memberships: sound, score
sound: part 1 of 4
score: part 1 of 4
$  k:-1	  Q:8   T:4/4   C:4  		
F4   4   e   u   [
G4   4   e   u   ]
measure 1
A4   8   q   u   
Bf4  8   q   u
C5   8   q   u
C5   8   q   u
measure 2
D5   8   q   u
E5   8   q   u
F5   8   q   u       F
F4   4   e   u   [   
G4   4   e   u   ]
measure 3
A4   8   q   u
Bf4  8   q   u
C5   8   q   u
C5   8   q   u
measure 4
Bf4  8   q   u
A4   8   q   u
G4   8   q   u       F

29/10/1999 A Tee
WK#: ?  MV#: ?
?
Chorale
?
Alto
1  0
Group memberships: sound, score
sound: part 2 of 4
score: part 2 of 4
$  k:-1	  Q:8   T:4/4   C:4
C4   8   q   d   
measure 1
F4   8   q   d
E4   8   q   d
F4   8   q   d
A4   8   q   d
measure 2
Bf4  4   e   d
A4   4   e   d
G4   8   q   d
A4   8   q   d
C4   8   q   d
measure 3
F4   8   q   d
G4   8-  q   d   -
G4   8   q   d
F4   8-  q   d   -
measure 4
F4   4   e   d   [
E4   4   e   d   ]
F4   8   q   d
E4   8   q   d       F

29/10/1999 A Tee
WK#: ?  MV#: ?
?
Chorale
?
Tenor
1  0
Group memberships: sound, score
sound: part 3 of 4
score: part 3 of 4
$  k:-1	  Q:8   T:4/4   C:22
A3   4   e   u   [
Bf3  4   e   u   ]
measure 1
C4   8   q   u
Bf3  8   q   u
A3   4   e   u   [
C4   4   e   u   ]
F4   8   q   u
measure 2
F4   8   q   u
C4   8   q   u  
C4   8   q   u       E 
A3   8   q   u
measure 3
D4   8   q   u
D4   8   q   u
C4   4   e   u   [
Bf3  4   e   u   ]
A3   8   q   u
measure 4
Bf3  8   q   u
C4   8   q   u
C4   8   q   u       E

29/10/1999 A Tee
WK#: ?  MV#: ?
?
Chorale
?
Bass
1  0
Group memberships: sound, score
sound: part 4 of 4
score: part 4 of 4
$  k:-1	  Q:8   T:4/4   C:22
F3   8   q   d
measure 1
F3   8   q   d
G3   8   q   d
A3   8   q   d
F3   8   q   d
measure 2
Bf3  8   q   d
C4   8   q   d
F3   8   q   d       E
F3   4   e   d   [   
E3   4   e   d   ]
measure 3
D3   8   q   d
C3   4   e   d   [
Bf2  4   e   d   ]
A2   8   q   d
D3   8   q   d
measure 4
G2   8   q   d
A2   4   e   d   [
Bf2  4   e   d   ]
C3   8   q   d       E

1.4.3  Standard Music Description Language (SMDL)

This is a derivative of HyTime (HyperMedia/Time-based Structuring Language)[1] which is a derivative of SGML (Standard Generalized Markup Language)[10]. Before one introduces this format, a note should be made that some knowledge of the formats mentioned above (SGML, HyTime) is an advantage in understanding SMDL[31,22] fully.

There are four main domains which can be represented in the file. The first is the Logical domain or cantus, this is where all the basic musical data is stored. This domain can be split into threads/voices, each having their own instrument assigned. The second domain is the Visual domain, this is where the display information is stored. The type of notehead, for example, might appear here. The third domain is the Gestural domain, this stores performance information such as the real-time duration of the musical data. The final domain is the Analytic domain which stores any analysis or bibliographic information about the work.

There are five details, about the logical domain, that are important. The first is that pitch can be specified in three different ways, as a specific frequency, as a function of a reference frequency or be defined in a look-up table, gamut. Second is the duration, this can be specified as either a real-time value or as a virtual-time4. Thirdly, articulation and ornamentation are not represented fully, mainly because of the number of possibilities. These are clarified in the Visual and Gestural domains. Dynamics are represented in the same fashion as articulation and ornamentation markings. Finally, the timbre can be set by splitting the cantus into threads/voices, each having its own instrument label.

<!DOCTYPE work SYSTEM "smdl.dtd" [
<?HyTime VERSION "ISO/IEC 10744:1992" HYQCNT=32>
<?HyTime MODULE base
   desctxt dvlist lextype refctl>
<?HyTime MODULE measure
   axismdu dimref fcsmdu HyFunk HyOp markfun>
<?HyTime MODULE sched
   grpdex>
<?HyTime MODULE rend
   modify patch profun project>
<!NOTATION virtime PUBLIC -- virtual time--
   "+//ISO/IEC 10744//NOTATION Virtual Time Unit//EN">
<!ENTITY tactvtu "80640">
<!ENTITY % e.canti "Chorale">
<!ENTITY % av.wxdm "4294967295">
<!ENTITY % av.wxfm "`SIsecond 1 1000'">
<!ENTITY % av.wxbg "msec">
<!ENTITY % av.wxgh "`1 1'">
<!ENTITY % av.wxpg "`1 1'">

<!ENTITY % av.cxdm "4294967295">
<!ENTITY % av.cxfm "`virtime 1 1'">
<!ENTITY % av.cxbg "vtu">
<!ENTITY % av.cxgh "`1 1'">
<!ENTITY % av.cxpg "`1 &tactvtu;">

<!ENTITY % e.rsrc "strestem|chordgam|pitchgam|mudef">
<!ENTITY % e.music "note|chord|rest">
<!ENTITY % m.ceg "(%e.music; | ceg)+">
<!ENTITY % m.np "(gampitch|freqspec)">
<!ENTITY % e.intji "arbintvl">
<!ENTITY % e.bib "title|author|date|issuer|descript|copr|status|role|numclass">
<!ENTITY % d.bib "<!ELEMENT (%e.bib;) - o (#PCDATA)>"> %d.bib;
<!ENTITY % m.bib "(%e.bib; | theme)*">
<!ENTITY % a.theme "">
]>

<work>
<bibdata>
  <title>O Ewigkeit, du Donnerwort
<author>J.S.Bach
<descript>Choral music
</bibdata>

<workfcs>
<workschd>
 <workseg>
  <bibdata>
    <title>O Ewigkeit, du Donnerwort
  </bibdata>

<pitchgam id=pitchgm0
gamutdes="conventional  12-tone equal temperament"
highstep=11
octratio=2 1
>
<genfreq>
<gamstep>9</gamstep>
<freqspec><hertz>440</hertz></freqspec>
</genfreq>
<namestep><pitchdef><pitchnm>c</pitchnm><gamstep>0</gamstep></pitchdef></namestep>     
<namestep><pitchdef><pitchnm>d</pitchnm><gamstep>2</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>e</pitchnm><gamstep>4</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>f</pitchnm><gamstep>5</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>g</pitchnm><gamstep>7</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>a</pitchnm><gamstep>9</gamstep></pitchdef></namestep>
<namestep><pitchdef><pitchnm>b</pitchnm><gamstep>11</gamstep></pitchdef></namestep>
</pitchgam>

<fictagam id=1flat idref=pitchgm0>
<pitchnm>b</pitchnm><fictadj>-1</fictadj>
</fictagam>

<notedurs HyTime=desctab id mydurs>
<durname HyTime=desctxt>t</durname>
<durval HyTime=descdef><marklist>&tactvtu;</marklist></durval>
<durname HyTime=desctxt>t4</durname>
<durval HyTime=descdef><marklist>
   <HyOp opname=div>
     <marklist desctab=mydurs desctxt=t>
     <marklist>4
   </HyOp>
</durval>
</notedurs>

<ce HyTime=event exspec=myextlist2>
<extlist HyTime=extlist id=myextlist2>
  <marklist HyTime=marklist desctxt="t4" desctab=mydurs>
</ce>
<ce HyTime=event exspec=myextlist>
<extlist HyTime=extlist id=myextlist>
  <dimref HyTime=dimref elemref=dur1231 selcomp=last>
  <marklist HyTime=marklist desctxt="t4" desctab=mydurs>
</extlist>
</ce>

<strestem id=simptrip pointcnt=4>
<pointnum>1</pointnum>
<stresval><strestxt>downbeat</strestxt></stresval>
<strestem id=simplesub pointcnt=2>
   <pointnum>1</pointnum>
</strestem>
</strestem>

<stresuse id=tsig1 idr=simptrip strespt=4>

<O Ewigkeit, du Donnerwort>
<thread id=thd1 nominst="soprano">
</thread>
<thread id=thd2 nominst="alto">
</thread>
<thread id=thd3 nominst="tenor">
</thread>
<thread id=thd4 nominst="bass">
</thread>

2
<baton id=bat1>
</baton>

<start thd1>
  <ceg id=sopline>
  <note>t2 0 f
  <note>t2 0 g
  <note>t  0 a
  <note>t  0 b
  <note>t  1 c
  <note>t  1 c
  <note>t  1 d
  <note>t  1 e
  <note>t  1 f
  <note>t2 0 f
  <note>t2 0 g
  <note>t  0 a
  <note>t  0 b
  <note>t  1 c
  <note>t  1 c
  <note>t  0 b
  <note>t  0 a
  <note>t  0 g
  </ceg>
<end thd1>

<start thd2>
  <ceg id=altoline>
  <note>t  0 c
  <note>t  0 f 
  <note>t  0 e
  <note>t  0 f
  <note>t  0 a
  <note>t2 0 b
  <note>t2 0 a
  <note>t  0 g
  <note>t  0 a
  <note>t  0 c
  <note>t  0 f
  <note>2t 0 g
  <note>1.5t  0 f
  <note>t2 0 f
  <note>t2 0 e
  <note>t  0 f 
  <note>t  0 e
  </ceg>
<end thd2>

<start thd3>
  <ceg id=tenorline>
  <note>t2  -1 a
  <note>t2  -1 b
  <note>t    0 c
  <note>t   -1 b
  <note>t2  -1 a
  <note>t2   0 c
  <note>t    0 f
  <note>t    0 f 
  <note>t    0 c
  <note>t    0 c
  <note>t   -1 a
  <note>t    0 d
  <note>t    0 d
  <note>t2   0 c
  <note>t2  -1 b
  <note>t   -1 a
  <note>t   -1 b
  <note>t    0 c 
  <note>t    0 c
  </ceg>
<end thd3>

<start thd4>
  <ceg id=bassline>
  <note>t  -1 f
  <note>t  -1 f
  <note>t  -1 g
  <note>t  -1 a
  <note>t  -1 f
  <note>t  -1 b
  <note>t   0 c
  <note>t  -1 f
  <note>t2 -1 f
  <note>t2 -1 e
  <note>t  -1 d
  <note>t2 -1 c
  <note>t2 -2 b
  <note>t  -2 a
  <note>t  -1 d
  <note>t  -2 g
  <note>t2 -2 a
  <note>t2 -2 b
  <note>t  -1 c
  </ceg>
<end thd4>

From the example it is clear that there are two distinct sections to the file. The first is the Document Type Definitions (DTD's). Then all the data entries. SMDL has the advantage over other formats because it can be used with music that is encoded using the majority of formats available today. However, being a document style format it is very verbose, both in the amount of data needed and it's layout.

1.4.4  Music Markup Language MML

MML[33] is only in its discussion stage at present and has no parser to test the syntax. This is another subset of SGML but focussing upon the XML approach to document definition. It aims to be deliverable in the following formats text, block bars/piano roll (as seen in sequencers), Western music notation and by midi device. The format will not go into the amount of detail to represent a score fully. It has a modular design so that only the modules of relevance are used when marking a score up.

<mml>
<head>
<title>O Ewigeit, du DonnerWort</title>
</head>

<song>
<div clef="G" octave="4" note="4" key="Fmaj">
<upbeat>[C:4 F:8]G:8 </upbeat>
<bar 1>[F A] [E Bf] [F 5C] [A 5C] </bar>
<bar 2>[Bf:8 5D]A:8 [G 5E] [A 5F] [C F:8]G:8 </bar>
<bar 3>[F A] [G Bf] [G 5C] [F 5C] </bar>
<bar 4>[F:8 Bf]E:8 [F A] [E G]</bar>
</div>
<div clef="F" octave="3" note="4" key="Fmaj">
<upbeat>[F A:8]Bf:8 </upbeat>
<bar 1>[F 4C] [G Bf] [A A:8]4C:8 [F 4F]</bar>
<bar 2>[2Bf 4F] [C 4C] [F 4C] [F:8 A]E:8</bar>
<bar 3>[D 4D] [C:8 4D]2Bf:8 [2A 4C:8]Bf:8 [D A]</bar>
<bar 4>[G Bf] [2A:8 C]2Bf:8 [C 4C]</bar>
</div>
</song>
</mml>    

2  The Grammar

The fact that music can be treated like a language meant that a grammatical approach could be made in the designing of a representation. There are various different types of grammar which can be used[6]. The type of grammar that was chosen was a Phrase-Structure Grammar[6,27]. The formal grammar, shown below, represents the musical score by laying out each individual musical object in a hierarchical format. The top-level aspect of a musical score is the system this can then have a number of staff groups attached to it forming the basics of a score.


Grace Notes still have to be finalised as there are many different contexts where they can be applied and have different meanings.

3  Representation of the Grammar as File Format

3.1  Introduction

We have shown in the previous section that there are a great number of different file formats available for use in music programs. The majority have their origins from the file formats used by the early music programs, in-particular MUSIC V [32]. The programs, that use formats derived from these programs, are the typesetting or audio generation. The main reason behind this is the parametric syntax used within the files. This means that the files have a formalised structure, making them easy to decipher when being read by the user outside of the program's environment. An example of this is SCORE 's ASCII format.

The analysis programs also use a parametric file format in a sense. However, there is a different style of layout in the file. The layout is dependent on the program. Some programs layout the file so that each part appears sequentially, others layout the file so that concurrent events, over all parts, appear on the same line. Two examples of this are Lilypond , although a typesetting package, and, of the latter, Humdrum.

3.2  Revised Design

The revised design has removed all the identifiers (i.e. MusicalObject etc..) and replaced some of them with single characters, with the exception of the System, StaffGroup and StaffSpec. These last three items have beginnings and ends so they will be represented by a pair of characters e.g. curly braces ( { } ), in the case of a System, Square brackets ( [ ] ) in the case of the StaffGroup and brackets ( () )for a StaffSpec. Rests will be represented by the letter r as opposed to Rest(....).
This has an effect on the file in two ways. The first is that it makes the file easier to read and secondly it reduces the files size dramatically. 2
{ brace [
( 5 0 0 
1 1 0,0 G
1 1 5,0 Fmaj
1 1 10,0 4/4
1 4 0,0 f 4 up 0 right 1/2 
1 4 0,0 c 4 down 0 null 1
1 4.5 0,0 g 4 up 0 left 1/2
2 1 -10,0 simple_line
2 1 0,0 a 4 up 0 null 1
2 1 0,0 f 4 down 0 null 1
2 2 0,0 bb 4 up 0 null 1
2 2 0,0 e 4 down 0 null 1
2 3 0,0 c 5 up 0 null 1
2 3 0,0 f 4 down 0 null 1
2 4 0,0 c 5 up 0 null 1
2 4 0,0 a 4 down 0 null 1
3 1 -10,0 simple_line
3 1 0,0 d 5 up 0 null 1
3 1 0,0 bb 4 down 0 right 1/2
3 1.5 0,0 a 4 down 0 left 1/2
3 2 0,0 e 5 up 0 null 1
3 2 0,0 g 4 down 0 null 1
3 3 0,0 f 5 up fermata 0,15 null 1
3 3 0,0 a 4 down 0 null 1
3 4 0,0 f 4 up 0 right 1/2
3 4 0,0 c 4 down 0 null 1
3 4.5 0,0 g 4 up 0 left 1/2
4 1 -10,0 simple_line
4 1 0,0 a 4 up 0 null 1
4 1 0,0 f 4 down 0 null 1
4 2 0,0 bb 4 up 0 null 1
4 2 0,0 g 4 down tie 0,-5 null 1
4 3 0,0 c 5 up 0 null 1
4 3 0,0 g 4 down null 1
4 4 0,0 c 5 up 0 null 1
4 4 0,0 f 4 down tie 0,-5 0 null 1
5 1 -10,0 simple_line
5 1 0,0 bb 4 up 0 null 1
5 1 0,0 f 4 down 0 right 1/2
5 1.5 0,0 e 4 down 0 left 1/2
5 2 0,0 a 4 up 0 null 1
5 2 0,0 f 4 down 0 null 1
5 3 0,0 g 4 up fermata 0,15 null 1
5 3 0,0 e 4 down 0 null 1
)

( 5 0 0
1 1 0,0 F
1 1 5,0 Fmaj
1 1 10,0 4/4    
1 4 0,0 a 3 up 0 right 1/2
1 4 0,0 f 3 down 0 null 1
1 4.5 0,0 bb 3 up 0 left 1/2
2 1 -10,0 simple_line
2 1 0,0 c 4 up 0 null 1
2 1 0,0 f 3 down 0 null 1
2 2 0,0 bb 3 up 0 null 1
2 2 0,0 g 3 down 0 null 1
2 3 0,0 a 3 up 0 right 1/2
2 3 0,0 a 3 down 0 null 1
2 3.5 0,0 c 4 up 0 left 1/2
2 4 0,0 f 4 up 0 null 1
2 4 0,0 f 3 down 0 null 1
3 1 -10,0 simple_line
3 1 0,0 f 4 up 0 null 1
3 1 0,0 bb 3 down 0 null 1
3 2 0,0 c 4 up 0 null 1
3 2 0,0 c 4 down 0 null 1
3 3 0,0 c 4 up 0 null 1
3 3 0,0 f 3 down fermata 0,-15 null 1
3 4 0,0 a 3 up 0 null 1
3 4 0,0 f 3 down 0 right 1/2
3 4.5 0,0 e 3 down 0 left 1/2
4 1 0,0 simple_line
4 1 0,0 d 4 up 0 null 1
4 1 0,0 d 3 down 0 null 1
4 2 0,0 d 4 up 0 null 1
4 2 0,0 c 3 down 0 right 1/2
4 2.5 0,0 bb 2 down 0 left 1/2
4 3 0,0 c 4 up 0 right 1/2
4 3 0,0 a 2 down 0 null 1
4 3.5 0,0 bb 3 up 0 left 1/2
4 4 0,0 a 3 up 0 null 1
4 4 0,0 d 3 down 0 null 1
5 1 -10,0 simple_line
5 1 0,0 bb 3 up 0 null 1
5 1 0,0 g 2 down 0 null 1
5 2 0,0 c 4 up 0 null 1
5 2 0,0 a 2 down 0 right 1/2
5 2.5 0,0 bb 2 down 0 left 1/2
5 3 0,0 c 4 up 0 null 1
5 3 0,0 c 3 down fermata 0,-15 null 1
)]}

3.3  Reference Implementation

To test the syntax of the file format a reference parser has been implemented. This has been implemented using the Lex(Flex) and Yacc(Bison) tools[21,24,8]. The grammar was translated into a Yacc compatible grammar, see Appendix A. The grammar required some syntactic alterations due to the way Yacc interprets a grammar specification. The lexical analyser has been implemented as a stateful lexer. The descion to do this was made because some of the lexical elements have a different meaning when they appear in different parts of the file. There are six states in the lexical analyser. These are the initial state, system state, staffgroup state,staff state, musicalobject state and note state.

References

[1]
? Hypermedia/time-based structuring langauge: Iso/iec 10744. Technical report, American National Standards Institute, 1986.

[2]
? The standard midi file format specification. Technical report, Midi Manufacturers Association, 1988.

[3]
S Bauer-Mengelberg. Musicology and the Computer, chapter The Ford-Columbia Input Language, pages 53-56. New York: City University of New York, 1970.

[4]
A R Brinkman. Representing scores for computer analysis. Journal of Music Theory, 30:225-275, 1986.

[5]
Bob Burns, R. J. Mical, Jerry Morrison, Greg Riker Steve Shaw, and Barry Walsh. "EA IFF 85" Standard for Interchange Format Files. Technical report, Electronic Arts, 1985.

[6]
N Chomsky. Handbook of Mathematical Psychology, chapter Formal Properties of Grammars. Wiley, 1963.

[7]
David Cooper, Kia-Chuan Ng, and Roger Boyle. Beyond Midi: The Handbook of Musical Codes, chapter 4: Midi Extensions for Musical Notation: Expressive Midi. MIT Press, 1997.

[8]
C Donnelly and R Stallman. Bison Manual.

[9]
R Erickson. DARMS - A Reference Manual, 1976.

[10]
C Goldfarb. The SGML Handbook. Clarendon Press / Oxford University Press, 1990.

[11]
J S Gourlay. A language for music printing. Communications of the ACM, 29(5):388-401, 1986.

[12]
C Grande. Beyond Midi: The Handbook of Musical Codes, chapter 31: The Notation Interchange File Format: A Windows-Compliant Format. MIT Press, 1997.

[13]
C Grande and A Bekin. The development of the notation interchange file format. Computer Music Journal, 20(4):33-43, 1996.

[14]
W B Hewlett. Beyond Midi: The Handbook of Musical Codes, chapter 27: MuseData: Multipurpose Representation. MIT Press, 1997.

[15]
H H Hoos and K A Hamel. The guido music notation format version 1 specification part 1: Basic guido. Technical report, Technische Universität Darmstadt, 1997.

[16]
H H Hoos, K A Hamel, and K Renz. Using advanced guido as a notation interchange format. In ICMC Proceedings 1999, 1999.

[17]
H H Hoos, K A Hamel, K Renz, and J Kilian. The guido notation format: A novel approach for adequately representing score-level music. In ICMC Proceedings 1998, 1998.

[18]
D Huron. Humdrum :A User's Guide.

[19]
D Huron. Beyond Midi: The Handbook of Musical Codes, chapter 26: Humdrum and Kern, pages 375-401. MIT Press, 1997.

[20]
A Kornstädt. Score-to-humdrum: An environment for computer-assisted musicologiacl analysis. Computing in Musicology, 10, 1995/6.

[21]
J R Levine, T Mason, and D Brown. Lex & Yacc. O'Reilly, 1995.

[22]
S Mounce. Standard music description lanaguage : Iso dis 10743. Technical report, ?, 1995/6.

[23]
Han-Wen Nienhuys and Jan Nieuwenhuizen. Lilypond tutorial/reference manual, October 1999.

[24]
V Paxson. Flex Manual.

[25]
Redmond. Microsoft Windows Multimedia Programmer's Reference. Microsoft Press, 1991.

[26]
Kai Renz. The guido noteserver. Web. Web based GUIDO format GIF/EPS typesetter.

[27]
C Roads. Grammars as representations for music. Computer Music Journal, 3(1):48-55, 1979.

[28]
B Schottstaedt. Common Music Notation Manual.

[29]
B Schottstaedt. Beyond Midi: The Handbook of Musical Codes, chapter 16: Common Music Notation. MIT Press, 1997.

[30]
E Selfridge-Field. Beyond Midi: The Handbook of Musical Codes, chapter 11: DARMS, its Dialects, and Its Uses. MIT Press, 1997.

[31]
D Sloane and S R Newcomb. Beyond Midi: The Handbook of Musical Codes, chapter 30: HyTime and Standard Music Description Language: A Document-Description Approach. MIT Press, 1997.

[32]
L Smith. Beyond Midi: The Handbook of Musical Codes, chapter 19: SCORE, pages 252-280. MIT Press, 1997.

[33]
Jacques Steyn. Music markup language. HTML. URL http://is.up.ac.za/mml/.


Footnotes:

1 1is the lowest line on the stave and 9 is the highest line on the stave

2Intel uses Little Endian Encoding, lowest byte first and other Architectures use Big Endian encoding Most significant byte first

3The format is not associated with any current music program

4All virtual-time units are related to one another and only become real values when converted in the Gestural domain


File translated from TEX by TTH, version 2.88.
On 15 Feb 2001, 11:22.