home tune search software learn abc discuss about blog Starbound/LOTRO contact  

  [abc standard: home | current | route-map | updating | proposals]

Writing /home/cwalshaw/chris/wiki_docs/data/cache/6/6bd9b807fd1bf9a12993747c0a263a5b.metadata failed

Scopes of Items in Multi-Voice Tunes

Any item (i.e. field, decoration, annotation, bar line, voice parameter etc.) found in the body of an abc tune, and not being a capital W: field, belongs to one well-defined voice. If it has a meaning "from here on …" (e.g. an I: or L: field), it ceases to apply at the next V: field, but resumes its validity at the next V: of its own voice, unless/until revoked in the same voice.

Revoking is done by a directive of equal type and keyword/letter, but different value. The previous value is always overridden, never added to etc. Some kinds of item also override the values of different types/keywords, as mentioned in their definition.

Three scopes will be defined: control, staff-related, and voice-related. By default, an item has no effect on other voices than the one in which it is found. We call it of "voice-related type", or simply voice-related. All types of other scope are listed in the sequel explicitely. Whenever new relevant items are introduced to the standard, the lists will be updated.

It is worth mentioning that fields of any scope can be used in the tune (or file) header. They are considered as if they were added at the beginning of each voice of the tune.

Items affecting all voices simultaneously

Control types [CT, for reference]

The following types of item (decorations, fields, etc.; list see below) are defined as control types, an item of such a type is called a control item. These items apply to all voices simultaneously at the given position in (metric) time.

  1. all sorts of repeat sign
  2. all volta signs [1 etc.
  3. the "decorations" !segno! !coda! !D.S.! !D.C.! !dacoda! !dacapo! !fine!
  4. annotations prefixed ~, to appear above the top staff of the system [NEW, please discuss]
  5. fields Q:, T:, and P:
  6. the following I: fields:
    1. I:score and I:staves
    2. I:concert-score [TODO]
    3. I:synch, see below [NEW]
    4. … [TODO]

Other than some may expect, M:, K:, non-repeat bar lines, and fermatas are not control types; they may differ between staves. For the notions of synchronity and metric position, only note values are relevant, not bars etc. Software must play events of equal position simultaneously, resp. display them on the same vertical line.

Control voice [CV]
  1. The voice for which the first V: is encountered is called the control voice of the piece. (This need not coincide with the one found first in an "I:score" directive. If there is no V: at all, the single voice is the control voice.)
  2. Any control item of a piece must be present in its control voice, so that software and human readers can see them in their intended succession.
  3. A control item found in a non-control voice that does not match an equal item in the control voice at the same metric position (i.e. to be "played" simultaneously), is considered a non-fatal error; software must not obey it and should issue a severe error message.
  4. Exception: Any control item occurring at a place where all voices have arrived at the same metric position (for example at the very beginning of the body), will be tacitly moved to the control voice. Thus we legalize a tradition that treats T: and P: fields as if they were outside all voices.
  5. To ensure such points of synchronity, a directive [I:synch voice-id rest-letter] can be used, only allowed in the control voice, which causes the non-control voice of the given id to be filled with the given type of rests (z, x, or Z), up to the current position of the control voice. Bar lines and M: fields for the missing part will be assumed copied from the control voice. (In the typical use case, the filled-in part will actually be excluded from display.) Example: "[V:new_voice][V:control][I:synch new_voice x][V:new_voice]" starts an additional voice at the current position of the control voice. [NEW]
  6. For good legibility and check of consistency, users should copy control items to all other voices at the same metric position.
    • If they fail to do this, and in a non-control voice a control item is missing, whose position there is bridged by a single note or rest, software must issue an error message. (Users must split such a note or rest in two, at the desired position, tying the notes.)
  7. If the control voice is currently excluded from the score, the control items in it must still be obeyed.
  8. Global bar numbering always refers to the control voice.

Items concerning a staff shared by more than one voice

The following types of items are defined as staff-related types, an item of such a type is called a staff-related item:

  1. all types of bar line that are not control types
  2. M: fields
  3. the key signature part of a K: field (whereas voice parameters have scopes of their own)
  4. the voice parameter "staffline="
  5. all clef keywords, including the voice parameter "middle="
  6. annotations prefixed +, to appear above the staff [NEW, please discuss]
  7. annotations prefixed -, to appear below the staff [NEW, please discuss]
  8. all annotations, decorations, or lyrics found in passages where [I:annotations_staffwise true], [I: decorations_staffwise true], resp. [I:lyrics_staffwise true] is in force. [I:…_staffwise false] returns to the default treatment. [NEW]
  9. the following I: fields:
    • I:…_staffwise
    • [TODO]
Master voice of a staff [MV]
  1. If several voices share a staff, the one whose V: declaration comes first is called the master voice. (This need not coincide with the one found first in the "I:score" directive.)
  2. Staff-related items in a non-master voice are perfectly legal (since the user may want to change the staff assignment later), but must be ignored by the software.
  3. If in a non-master voice a staff-related item is missing, and its position there is bridged by a single note or rest, software must issue an error message. (Users must split such a note/rest in two, notes being tied.)
  4. Clef keywords are formally strictly staff-related, but allow an alternative administration for shared staves. If a clef is imposed, notes must be adjusted to represent the original intended sound. See 4.6 for details.
  5. Whenever the key signature to be displayed (i.e. possibly after transposition) in a non-master voice differs from the one of the master voice, software must reproduce the effective accidentals at the notes, following the current rules, so that the intended sound remains unchanged. Example: if the master voice has "[K:C]", but the sharing voice has "[K:D]|CDC=F|=C", it will normally be displayed as if it were "[K:C]|^CDCF|C". Note that the last note does not get a "courtesy accidental", whereas any redundant accidental encountered will result in the corresponding "courtesy".
  6. Transposition will not be unified when a staff is shared; it is the user's responsibility to avoid confusion. In all other respects, the axiom is: Changing parentheses in an I:score statement will never change the intended sound of any note, as perceived by the reader of the sheet music.

Proposer's comments

My name is Alexander Scheutzow. Suggestions for improvements are welcome in the thread http://tech.groups.yahoo.com/group/abcusers/message/8246 - my user name there is scheutzow4cond. Thank you.

In this appendix, I would like to collect my own comments, errata, answers to questions, and announcements for the next version. It will be the only part of the text that will be edited, if possible by appending only. Any comments by readers, or separate proposals, are welcome, but will be particularly valuable if they take account of the various problems I try to solve with my proposal. So please take your time to study it/them thoroughly. Thanks.

I have not included any chapter numbering yet, please refer to any of the above chapters by the abbreviation given in brackets. The list items should be bullets, but for better reference, I used numbers.

New items

The whole scope concept is new for standard abc. Here a list of new items that my be discussed individually:

  • CT4 - new prefix for annotations, additional to ^ and _
  • CT6 - I:concert-score
  • CT6, CV7 - I:synch voice-id rest-letter
  • SRT6, 7 - new prefices for annotations, additional to ^ and _
  • SRT8 - New mechanism to exclude non-master annotations, lyrics etc.
  • MV5, 6 - added for clarity. I wonder which existing software follows MV5, or at least issues a fatal error message. [NEW in this version 3!]
abc/standard/v2.1/proposals/multi-voice_scope/v3.txt · Last modified: 2012/08/15 17:50 by alexmidicond
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki