MuseData work directory file structure
The standardized file structure for storing MuseData files for manipulation and processing in Dmuse is described below (or at least in an initial draft).
The work directory
A MuseData work directory is essentially defined by the existence of a sub-directory called stage2 which contains the primary symbolic data for a work.
The parent directory
A work directory can have any name, and usually describes the work in some way such as an opus/number or a BWV number.
Top-level files/directories with the work directory
- stage2 == directory for storing the primary symbolic musical data in the MuseData stage2 format
- stage1 == directory for storing the preliminary version of symbolic musical data as entered from a MIDI keyboard before notational aspects are incorporated. Typically this directory is deleted after stage2 files have been created, since stage1 files are a subset of the content in a stage2 file.
- distrib == directory for storing data conversions of MuseData into other formats.
- outputs == directory for storing graphical music layout files which are created from stage2 files. Two variants of files are stored in this directory: i-files and page files.
- editions == directory for storing CFT files which are created from page files
- info == directory for storing bibliographic and other textual data describing the work.
The stage2 directory contains additional sub-directories, one for each movement of the work. Typically these sub-directory names are numbers starting at 01 for movement 1, and so on. For example, if the work has four movements, there should be four sub-directories: 01, 02, 03 and 04.
More complicated works may have alternate methods of describing the movements, such as Handel's Messiah:
1-01 1-06b 1-12 1-18 1-22c 2-06 2-14a 2-16c-a 2-20a 3-06a 1-02 1-06c 1-13 1-19 1-23 2-07 2-14b 2-16c-b 2-20b 3-06b 1-03 1-06d 1-14a 1-20a 2-01 2-08 2-14c 2-16d 2-21 3-06c 1-03add 1-07 1-14b 1-20b 2-02a 2-09 2-14d 2-16e 3-01 3-07 1-04 1-08 1-15 1-21a 2-02b 2-10 2-15 2-17a 3-02 3-08 1-05 1-09 1-16a 1-21b 2-03 2-11 2-16a 2-17b 3-03 3-09 1-05b 1-10 1-16b 1-22a 2-04 2-12 2-16b-a 2-18 3-04 3-10 1-06a 1-11 1-17 1-22b 2-05 2-13 2-16b-b 2-19 3-05
In this case each directory is starts with the Part number, followed by the movement within that Part, and then possible sub-section letters. Ultimately the directory structure is arbirary but each movement's data should be in a separate sub-directory.
The files with each movement directory contain the MuseData information for a single part (or possibly multiple parts if they share the same staff). Part files are numbered starting at 01 for the top part in the system, 02 for the next part, and so on. A lower-case letter may appear before the part number which indicate a particular end-purpose for the part. For example, if a file starts with a p character, then it is a MuseData file intended for generating parts.
The stage1 directory structure is similar to that of stage2. Multiple data files within each movement directory may actually represent a single part file once the data is processed into a stage2 file. This is because each stage1 part file can only contain one time signature.
The distrib directory is used to store data conversions (and printed music) generated from Stage2 data.
The info directory is used to store textual information about the work which is necessary in particular for automatic processing. There are currently three standardized sub-directories in the info directory:
- humdrum == this sub-directory contains files which are used to create Humdrum conversion of the stage2 MuseData files.
- footer == this sub-directory contains files used to create footer on printed version of the work.
- website == this sub-directory contains two files called alias.txt and parts.txt which are used to generate content on the http://www.musedata.org website.
The info/website directory contains two standardized files:
- alias.txt this file contains a list of aliases for work directories to allow for shorter web addresses for works. The aliases acts as pointers to the real location of the work directory. This is useful, since the actual location of a work directory can change, but a consistent web address is desired.
For example, Beethoven's first symphony is stored in the MuseData archive directory: beet/bh/sym/no1. This work directory translates into a web address of: http://www.musedata.org/encodings/beet/bh/sym/no1 . If the alias.txt file contains the line beethoven/sym-1, then an additional web address will be enabled (provided that certain scripts are run on the webserver): http://www.musedata.org/beethoven/sym-1 . If the location of the work moves in the MuseData archive (such as to beethoven/bh/sym/no1, then the alias.txt file can be reprocessed to update the location of http://www.musedata.org/beethoven/sym-1 .
- parts.txt this file contains a list of the part names associated with each part file and described the preferred ordering of the parts when they are listed on the website. For example, for Beethoven's symphony no. 1, the part.txt file looks like this:
# This is a list of the parts (or possible parts) in the order in # which they should be displayed (or combined into a single file), # and their full names. the first column is the abbreviation used in # files/directories (no spaces allowed, and the second column is the # expanded name (spaces allowed). @START: PARTLIST @PART: fl_1 Flute 1 @PART: fl_2 Flute 2 @PART: ob_1 Oboe 1 @PART: ob_2 Oboe 2 @PART: cl_1 Clarinet 1 in C @PART: tcl_1 Clarinet 1 in B-flat @PART: cl_2 Clarinet 2 in C @PART: tcl_2 Clarinet 2 in B-flat @PART: fag_1 Bassoon 1 @PART: fag_2 Bassoon 2 @PART: cor_1 Horn 1 in C @PART: tcor_1 Horn 1 in F @PART: cor_2 Horn 2 in C @PART: tcor_2 Horn 2 in F @PART: timp Timpani @PART: tr_1 Trumpet 1 @PART: tr_2 Trumpet 2 @PART: vln1 Violin 1 @PART: vln2 Violin 2 @PART: vla Viola @PART: vc Cello @PART: cb Bass @END: PARTLIST
In the above example, the clarinet parts are given in the original C pitch, as well as in the more commonly available B-flat versions.