introduction to the score guidelines #53
Conversation
| ================== | ||
|
|
||
| These guidelines are intended to ensure that the scores produced by and for the DCML are consistent and high-quality | ||
| encodings of some print or manuscript edition. Although they represent digital editions, first and foremost they |
There was a problem hiding this comment.
Do you mean "some print or other digital edition"? I don't know what "manuscript edition" means (unless you mean facsimile?).
| typesetting software MuseScore provides. For example, a ``cresc.`` performance indication must not be encoded | ||
| as a "normal" staff text: It has the semantics of a dynamic marking and is available as such in the "Lines" palette. | ||
| A large part of these guidelines is concerned with stipulating how various score elements are to be encoded. | ||
|
|
There was a problem hiding this comment.
"We should also emphasize that, unless otherwise indicated, DCML scores are produced with a 'fitness to use' mindset. While we prefer to rely on authoritative sources and scholarly editions, we do not aspire to produce Urtext scores or reference-quality material. Rather, we provide scores that are 'good enough' for the research questions that motivated their production. These are typically computational-musicology questions."
|
|
||
| A major use case for the scores is the study of tonal music in all its aspects. It has proven worthwhile to | ||
| organize the scores into units which, tonally, stand for themselves in one way or another. Three aspects play a | ||
| role when deciding into how many different files to split a musical expression: |
There was a problem hiding this comment.
"Expression"? Freudian lapsus for "music score" or "music work," perhaps? :)
| role when deciding into how many different files to split a musical expression: | ||
|
|
||
| #. **measure numbering**: it should make sense to start with 0 or 1 | ||
| #. **global key**: it should make (at least some) sense to analyze the contents under a single global tonic |
There was a problem hiding this comment.
Other things equal, if it makes sense to analyze (part of) a work under a single global tonic, that speaks in favor of storing it in a single file.
|
|
||
| Parts-of-work that are frequently separated into different files are: | ||
|
|
||
| * movements |
There was a problem hiding this comment.
- movements (e.g. of a classical sonata)
| Parts-of-work that are frequently separated into different files are: | ||
|
|
||
| * movements | ||
| * pieces within a cycle |
There was a problem hiding this comment.
(e.g. individual variations in a theme-and-variations type of work)
|
|
||
| * movements | ||
| * pieces within a cycle | ||
| * sections within a movement (e.g. "Trio") |
There was a problem hiding this comment.
(e.g. the "trio" in a minuet-and-trio movement of a classical sonata)
| For reference in case of doubt, here are a few DCML corpora that are noteworthy in some aspect: | ||
|
|
||
| * In `Corelli's Trio sonatas <https://github.com/DCMLab/corelli>`__, the division into movements can be somewhat | ||
| arbitrary and some of the files contain nothing more than a slow transition of a few bars' length. |
There was a problem hiding this comment.
- [Explain more explicitly why? E.g. tonal closures can be weak…]
| * In `Mozart's Piano sonatas <https://github.com/DCMLab/mozart_piano_sonatas/>`__, on the other hand, the two | ||
| variation movements are *not* split into separate files, leading to an alternative counting of measures (which is | ||
| also used by the Digital Mozart Edition (DME) issued at the Mozarteum Salzburg) where new variations do not restart | ||
| with measure 1 or 0. |
There was a problem hiding this comment.
[How do we justify this exception?]
No description provided.