|home||tune search||software||learn abc||discuss||about||blog||Starbound/LOTRO||contact|
[abc standard: home | current | route-map | updating | proposals]
The notion "abc item" describes one of the following:
Each item belongs to a type (also called item type), which is one of the following:
Each type has one of the following six scopes:
The last three are collectively called stream scope.
If for any item type no scope is specified in this document, voice-related applies.
Fields of type T:, if encountered in the tune body, have grave consequences beyond typesetting. They split the code of the tune body into disjoint parts, technically called movements here (which may or may not coincide with their musical meaning). Voices, as characterized by their voice IDs, can run through several movements, affected by the separator only in one respect: Their metric positions (see next paragraph) are considered "synchronized" there, i.e. set to an equal value.
Each movement can contain its own selection of voices.
The first movement of every tune starts behind the tune header.
The metric position of an abc item is defined within a movement as the sum of the note values of single notes, chords, or rests preceding it in the current voice and movement. Bar lines, fermatas, etc. are irrelevant. (If bar/beat numbers are needed, they can only be derived from the control voice, see below. If a position within the whole tune is required, the lengths of the longest voices of the preceding movement are added.)
Two abc items are called synchronous if they belong to the same movement, and their metric positions coincide. Software must display such items on the same vertical line, resp. play them simultaneously. Repeat signs of bar-line type, volta signs, and P: fields are disregarded for these definitions.
In fact, playback software is allowed to run out of synchronousness if non-synchronous repeats are decreed at the user's responsibility - see below -, but not for other reasons such as non-synchronous fermata signs. (Any inconsistendies of repeat signs and P: fields should of course be treated as syntax errors.)
Fields of (upper-case) W: type will be collected per movement in given order, but disregarding any voice context. The W: lines will be typeset at the end of each movement.
In a movement of a multi-voice tune, the items preceding its first V: field constitute the "movement header", which is considered outside any voice. It must not contain any notes or rests. All other items are permitted, and will have the same effect as if they were copied into each voice occurring in this movement. More precisely, it has the same effect as
Typical candidates for this header are K: and M: fields.
The ranges of ordinary repeat signs do not transcend their movements. Example:
def :| % player software must only repeat the last three notes.
The "name=" attribute of a voice can be changed per movement; display software will normally print it at the beginning of each movement:
V:clr name="Clarinet in Bb"
V:clr name="Clarinet in A"
In principle, any stream-scoped item found in the body belongs to one well-defined voice (see below for a formal exception). If it has a meaning "from here on …" (e.g. an 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 an item of equal type and keyword/letter, but different value. The previous value is always overridden, never added to etc. Items of some types also override the values of different types, as mentioned in their definitions.
Stream-scoped fields can also be used in the tune (or file) header, some of them are even required there, M:, L:, and K:. They are considered as if they were added at the beginning of each voice of the tune, following its first V: field, but logically preceding any voice parameters in it (which simply means that these voice parameters may be able to override the header specifications).
Note that movement limits (T: fields) do not bar any of these mechanisms in any way. In particular, if a voice ID was already used in the previous movement, it would be a mistake to assume that anything was reset from the tune header.
In the following paragraphs, we use an ordering of the voices occuring in a movement, called "order of declaration". It is determined by the first occurrence in the movement of a V: field of the respecive voice.
(Note that a voice ID may have occured before its declaration, not only in other movements, but also e.g. in an "I:score" directive, where the ordering has a different significance and can therefore not be used for the purposes of this chapter.)
The following types are defined as control types (short for "metric-position-related types"); items of such a type, called control items, apply to all voices simultaneously at the given metric position:
Other than some may expect, M:, K:, repeat signs (see below), bar lines, and fermatas are not control types; they are allowed to differ between staves resp. voices, though they rarely will.
Control items are not allowed everywhere in the code. The main reason for this is to detect mistyped or miscalculated code; a welcome side effect is that reading becomes slightly easier for humans and software. Therefore, a control item found at a disallowed point is considered a non-fatal error; software must not obey it and should issue a severe error message.
A text position in the abc code between two abc items is called an "in synch" point, if all voices that occur anywhere in the current movement have accumulated the same note lengths. In other words, if for each such voice a note were inserted here, their metric positions would be equal. Every movement header is "in synch", by definition.
Control items are always allowed at in-synch points. This is the preferred place for lengthy fields (non-inlined), or for items that mark a new section of the tune. This conforms to a tradition that treats P: and some I: fields as if they were outside all voices, like T:.
For example, the following usage, occasionally found in legacy, is still correct:
P:1 % movement header
V:flute % the control voice
P:2 % formally in the non-control voice "whistle", but in synch
% (if a K: field appeared here, it would only apply to "whistle", other than a movement header) I:score (flute whistle) % formally in the non-control voice "whistle", but in synch
An example using a type which is normally inlined:
The following types of items are defined as staff-related types, an item of such a type is called a staff-related item:
(Note that 8va (ottava) fields are voice-related, see 4.6.)
The regulations about staff-related items are designed for the following goal: Users should be enabled to prepare a score for various printouts of distinct dispositions of voices onto staves, within reasonable limits. Ideally, for each of these printouts, it suffices to adapt the I:score/staves directives, including any parentheses for staff-sharing.
Of course, the idea of the master voice is that its staff-related items are respected.
The guiding principle for voices sharing staves is: If the user changes parentheses in an I:score statement, and nothing else in a tune, this must not change the intended sound of any note, as perceived by the viewer of the sheet music.
Voices that share a staff should have matching key signatures and bar lines. Clefs need not match; if a clef is imposed on a non-master voice, software must adjust the displayed notes to represent the original intended sound. See 4.6 for details.
If display software encounters two voices sharing a staff that do not match in staff-related matters other than clefs, it may perform the following adjustments (accompanied by a warning message saying that other software may not):
Whenever software it is unable to fulfill any of these rules in a particular case, it must issue a well-worded fatal error message, never display incorrect sheets. Differing key signatures must not be considered an error if there is no actual note to adjust, e.g. for the typical voice consisting only of chord symbols and invisible rests.
In contrast, software must not try to unify transposition when a staff is shared. Transposition is never staff-related; discrepancies in this respect are not necessarily errors. For example, in classical scores a double bass voice may share its staff with a 'cello voice at different octaves. As with "clefs with invisible 8 markings", it is always the user's responsibility to clarify the meaning to the viewer of the sheet music.
Items of the following types are formally staff-related, but normally required to be precisely synchronized in all voices:
The header-only instruction "I:repeats_synchronized" causes software to check whether this is true, and to issue a helpful fatal error message otherwise. Software is also encouraged to offer a user-triggered mode or function to perform these checks on any abc code.
Volta signs and the decoarations mentioned will normally be displayed not on each staff of a score, but only once above the score, as with genuine control items, if they are synchronous in all voices. [TODO: in large scores, anything "above the score" is sometimes repeated above each group of staves.] Otherwise, display software may represent them either on each staff or summarize those that are equal. (Playback software must of course act per voice, whatever sense that may make to the user.)
Fermata signs are not pseudo control items, since they may appear slightly asynchronously in a polyphonic context.
My name is Alexander Scheutzow, I am a professional software architect and developer, also the author of the abc tool MidiZyx2abc and of the more widely known MIDI software MidiCond ( http://www.midicond.de/ ).
Suggestions for improvements are welcome in the forum http://tech.groups.yahoo.com/group/abcusers/ - 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.
The whole scope concept is new for standard abc. Here a list of new items that my be discussed individually:
It would be possible, and compatible to abc 2.1., to make T: an ordinary control type, like P:. This document would be somewhat shorter, as were its previous versions.
The charm of movements is the new selection of voices, without worrying about formally filling them with rests for the preceding movements. A special synchronizing directive is not needed any more.
The idea of using T: fields for movement separators is somewhat arbitrary, in particular since Jef often uses it without an actual "title" string. But it can be accepted as de-facto legacy.
Because each movement can have its own set of voices, so there may not exist a single voice that occurs in all movements, let alone one that qualifies for the role everywhere.
That is in fact the idea. When this document describes what software must do, it is just a rhetorical device to explain what an abc item means, and what usage is safe (even if it may not be mainstream usage).
Well, we could, as does the abc standard document 2.1, but it is much better if the document
Most standards written by humans, including MusicXML, actually fail this goal, and so will this one, but the closer we get, the more will our work be useful and respected, and the more effort will be invested by programmers.
We may want to add features in the future, which may rely on a particular style of abc coding. Users will be glad if we describe such a style as "orthodox", so that new features are most likely to work properly on otherwise unchanged code. A typical example is the concert score. Also, conversion tools from and to formats of slightly differing philosophies may have difficulties if our notions are unnecessarily vague.
An equally important reason is the logical consistency of the standard. Present and future regulations should be as self-evident as possible, or at least easy to understand and memorize correctly and completely. Thus, it is much better to say "T: starts a new movement" than just "At a T: field, software must resynchronize all voices". The notion "movement" is defined technically, so that users are free to map their own needs to it. (Actually, a more neutral wording such as "part of code" would be preferable, if it could not be confused with the P: mechanism.)
Because of legacy usage. In future versions, we may have more flexible mechanisms for tempi and everything related to repeating. These will probably use fresh keywords in I: syntax, since a natural extension of the current Q: and P: syntax is hard to imagine.