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

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

 

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.

By default, an item has no effect on other voices than the one in which it is found. All exceptions are listed in the sequel; whenever new relevant items are introduced to the standard, the lists will be updated.

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. … [TODO]

Other than some may expect, M:, K:, non-repeat bar lines, and fermatas are not control types; they may differ between voices. 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. (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 an 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. For good legibility and check of consistency, users should copy control items to all other voices at the same metric position.
    1. 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. [TODO: possibly introduce a new mechanism of "bridgeable types"])
  6. If the control voice is currently excluded from the score, the control items in it must still be obeyed.
  7. A directive [I:synch id restletter], only allowed in the control voice, 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 here. [NEW]
  8. Global bar numbering always follows 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 part of a K: field (voice parameters are considered separately)
  4. the voice parameter "staffline="
  5. clefs and their parameter "middle=", with a qualification described below
  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. some I: fields yet to be listed [TODO], including those [I:…_staffwise …] directives.
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. Exception: in a bar where the master voice has no notes, but other voices in that staff do have notes, the first such voice (in the order of declaration) determines the clef/middle. Use [I:otherclef false] resp. [I:otherclef true] in the master voice to modify this behaviour, true being the default [NEW].
  4. Software must interpret any change of clef induced by this mechanism to leave the sound unchanged, in particular if a +/-8 suffix is involved. (Typical example: tenor and bass of a choral piece pressed on a single staff with bass clef. Users should prefer the +/-8i variants.)
  5. 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.)

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.

The same applies to my other fundamental proposal at http://abcnotation.com/wiki/abc:standard:v2.1:proposals:clefs_voice_parameters:v1


July 24, 2012: First version. 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.

July 26: The "exception", MV 3, is somewhat contrived. The idea is: "The role of master voice with respect to clefs is given barwise (with respect to the bars in the true master voice) to the first voice that has any note in that bar. Corresponding clef changes must be induced at the beginning of the bar, if necessary." - I am now willing to drop that exception completely. Instead, users should be allowed to choose the clef for the shared staff explicitly at liberty, with a different keyword clef_shared. Thus the intended use case is best served: two voices to be switched between sharing and non-sharing simply by changing the I:score directive.

abc/standard/v2.1/proposals/multi-voice_scope/v1.txt · Last modified: 2012/07/28 15:10 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