The SCORE music notation program

SCORE, designed by Leland Smith (SCORE 1992a, 1992b, Smith 1997), is an exceptionally well-documented commercial notation program, especially

con-cerning the contents of internal data structures and operational logic. The SCORE system is implemented for IBM PC compatible computers running the MS-DOS operating system. SCORE is based on an earlier program for main-frame computers, called MSS (Smith 1972). Hereafter, SCORE, written in all capital letters, refers to the SCORE program as a distinction from the general musical term “score” or from a class “Score” (with an initial capital letter) as described in Chapter 7.

As its data representation system, SCORE uses a database approach similar to that of Music V. Whereas the database of Music V consists of sound synthesis parameters, SCORE’s database consists of music notation parameters.

SCORE is written in the FORTRAN programming language. The limited data structure capabilities of early FORTRAN languages are reflected in SCORE’s data representation and behavior. Due to the lack of user-definable data structures in FORTRAN 66 and 77, SCORE stores most of its data in arrays of floating point numbers. Text strings are stored separately from the floating point arrays. Parameters are accessed through their position (i.e., index) in an array. As in Music V, parameter fields are named P1, P2, etc. according to their index number.

As in Music V, SCORE’s data representation system can be described as a simple database where data is stored in records, with each containing a set of fields. In a record, the first field, named P1, is a “code” number. Individual code numbers are given to notes, rests, clefs, staves, time and key signatures, etc.

Some closely related symbols are given a shared code. For example, slurs, ties, tuplet brackets and endings share a common code number. The second, third and fourth fields are common to all record types. The second field, named P2, is the number of the staff associated with the symbol. Fields P3 and P4 contain the horizontal and vertical coordinates of the symbol, usually relative to the associ-ated staff’s location on the score. Other fields contain parameters specific to the type of record.

SCORE supports a text-based input language for entering notation from the computer terminal or from a file. The graphical layout may be adjusted manually by editing the numeric values of the record-based data storage format. SCORE also has a set of commands for automatically adjusting the spacing of notes, height of stems, length of beams etc.

Internally, each SCORE record is stored in an array of floating point num-bers. Even the record types are internally stored as numnum-bers. Lyrics and other text symbols are an exception to this principle.

Below is a representation for the note example presented in Figure 3-1 as a SCORE Parameter List File (SCORE 1992b: 225). Each SCORE symbol is printed on a separate line. Above the parameter list is a line that lists names of

the parameter fields from P1 to P9. The symbol code number is stored in P1 fol-lowed by a staff number, horizontal and vertical (if needed) coordinates, in P2, P3, and P4, respectively. Coordinates are expressed in staff steps and are relative to the position and size of the staff that the symbols are printed on. Coordinates may use the decimal part of the floating point number to reach higher resolution than that of a staff step. Fields P5 through P9 contain parameters specific to the individual code numbers.

P1 P2 P3 P4 P5 P6 P7 p8 P9

8. 1.0 .000 .00 .00 70.00

3. 1.0 1.500

18. 1.0 8.999 .00 3.00 4.00

1. 1.0 16.499 1.00 10.00 .00 1.0000

1. 1.0 26.678 3.00 10.00 .00 1.0000

1. 1.0 36.857 5.00 10.00 .00 1.0000

14. 1.0 47.456 1.00

1. 1.0 50.788 1.00 10.00 1.00 3.0000 .00 10.00

14. 1.0 70.000 1.00

The example contains dedicated records for one staff (code 8), a clef (code 3), a time signature (code 18), four notes (code 1), and two barlines (code 14).

SCORE’s coordinates are expressed in staff steps.

In SCORE parameter list files, parameter field values are printed for each code, up to the last field having a nonzero value. Zero values are printed as

“.00”.

Below is a list of the code numbers used in SCORE version 3. The code numbers range from 1 to 18 with the exception of number 13 which is not used in SCORE version 3. Leland Smith marked code number 13 as “reserved”

(Smith 1997: 257).

1. Notes 2. Rests 3. Clefs

4. Lines and hairpins

5. Slurs, ties, tuplet brackets, and endings 6. Beams and tremolandi

7. Trills, ottavas, and pedal marks 8. Staves

9. Symbol library

10. Numbers (rehearsal letters) 11. User symbol library 12. Special shapes 13. (“reserved”)

14. Barlines, braces, and brackets 15. Importing postscript programs 16. Text

17. Key signature 18. Time signature

Note items have 17 parameter fields, or 13 in addition to fields P1 through P4, which have similar meaning in all codes. Fields P5 through P17 are used for specifying values for parameters such as stem direction, type of accidental and displacement (P5), note head type (P6), rhythmic duration of a note (P7), stem length (P8), number of augmentation dots and flags (P9), etc. In the above exam-ple, the P5 value of “10.” means “Up stem/No accidental” (SCORE 1992b: 9).

P6 of 1.000 (in the first three notes) means rhythmic duration of a quarter note and 3.000 (in the last note) means three times the duration of a quarter note (i.e., the duration of a dotted half note). The P8 value “.00” in the last note means

“Normal stem length” (ibid: 15) and the P9 value “10.” means “Single dotted note”.

Rest records have 15 parameter fields. Clefs have 7 parameter fields. In the latter, for example, P5 is used to specify a clef type from nine different choices.

In the example, the P5 value 0 indicates a treble clef.

The graphical approach of SCORE has advantages and disadvantages. For example, SCORE permits the moving or reshaping of most symbols indepen-dently of each other. Any individual note head may be resized or moved with great precision both horizontally and vertically. Changing the position or size of one symbol does not move or resize the other symbols in the score unless a spe-cific formatting command is entered by the user. On the other hand, the level of

automation is low – even most features stated in the SCORE manual as “auto-matic” must be executed manually by entering a dedicated command.

In SCORE, a note is equivalent to a graphical note symbol including a note head, a stem, augmentation dots, and various modifiers including accidentals and articulations. As a representation, SCORE is explicit in respect to graphical aspects of music engraving. All symbols in SCORE are explicitly positioned on a two-dimensional coordinate system. Logical and performance data is repre-sented either implicitly by graphical symbols or stored as parameters of graphi-cal symbols.

Many editing operations, however, leave the score in a graphically distorted state. For instance, stems may, as a result of a transposition operation, become separated from their respective note heads. During an engraving process, the score must be occasionally fixed with manually typed commands that check the relationships between musical symbols and adjust the layout accordingly. Nev-ertheless, SCORE has a rich set of features and is suitable for professional-qual-ity music engraving. It has thus been used by many music publishers (Smith 1997: 252). In particular, SCORE’s record-based internal structure is thoroughly documented, which makes it a suitable subject for study.

SCORE is partly inconsistent. Many complex or rarely needed layout situa-tions are encoded differently from simple or commonly used ones. This is partly due to the long development process from MSS through several versions of SCORE itself. SCORE’s inconsistencies are also partly caused by the primitive data structure capabilities of the FORTRAN programming language.