- The user will be able to change a predefined set of notation parameters.
- A score will be just as easy to edit in a new notation as in traditional notation.
- New notations will be easy to save, load, share and switch out.
- There will be a simple unified GUI for editing, saving and loading of notations.
1. The user will be able to change a predefined set of notation parameters.
In the first iteration of my project, I aim to provide the following notation parameters:
- Note positions: how a note gets mapped to a vertical line position, based on pitch, tonal pitch class, and clef.
- Noteheads: which Notehead group to display for a given note. For now, I am using only the Noteheads available immediately in the MuseScore code. In the long run, I wish to provide more, possibly by allowing more SMuFL set of note heads: http://www.smufl.org/version/latest/range/noteheads/
- Staff Lines: the number of lines, their relative positions, and their coloration (solid, dotted, etc.)
- Inner Ledgers: the placement of ledger lines within the extrema of a staff
- Accidentals, Key Signatures, and Clefs: how to display these symbols (if at all)
For now, the types of notations I plan on supporting are really just variations on the traditional staff. Even with just the above parameters, the user can construct plenty of interesting schemes. Nearly every notation proposed on musicnotation.org is possible. The following three examples demonstrate some of the parameters in use.
Here is a snippet of music in its traditional form:
This first example demonstrates alternative staff lines, inner ledgers, shaped notes, and absent-accidentals.
This second example shows more spaced-out note positions and absent-accidentals.
2. A score will be just as easy to edit in new notations as in traditional notation.
The visual presentation is not the only thing that needs to change for successful use of new notations. MuseScore’s editing tools also have to be kept in sync with the new rules. Otherwise, the user might enter a note on the fifth line (in the traditional location of “D”) and MuseScore would erroneously interpret the new note as a D and place it somewhere other than the fifth line.
3. New notations will be easy to save, load, share and switch out.
The user would be able to save and load notations in special files. During regular use of MuseScore, these files would be dynamically loaded so that the user could freely switch between notations. MuseScore will remember which notation the user last chose when it starts up again (and if the notation file is corrupted, traditional notation would be used instead. Finally, traditional notation will not require any special file. It will always be available.
4. There will be a simple, unified GUI for editing, saving and loading notations.
In other words, the user would only have to visit a single dialog box to perform all notation actions.
Possible Additional Features:
- Allow for more semantic-based notations such as Sacred Harp.
- Provide an option to automatically delete page breaks and spacers when a score is loaded. In some cases, alternative notations may require extra or less space and may end up breaking the original user-specified formatting. So, if the user wishes to view many scores without manually resolving spacing issues, they could just set this option and scores will be loaded in a default, pre-formatted manner. However, unlike the other features, this would modify the score data. This modified data would only be saved if the user wishes to save.
- Allow different notations for different staves. This would allow notations to be compared right next to each other.