|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.
A tune without any T: in its body will be considered to consist of a single movement.
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.
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.
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, or of a stream-scoped item belonging to the voice that had been current prior to the T: field. (Users are recommended to redeclare the voice in such a case, unless only one voice exists.)
% it is preferable, but not strictly necessary, to redeclare "V:melody" here
def|] % this belongs to "melody", which thus becomes the first ("master") voice of this movement
V:harmony % "harmony" becomes the second voice of this movement in order of declaration
(Note that a voice ID may have occured before, 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:, non-repeat bar lines, and fermatas are not control types; they may differ between staves resp. voices. (Note that fermata signs come with notes or rests, not necessarily exactly at the metric position to be dilated, and differing from voice to voice.)
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. The beginning of the body or of a movement (after the T: item) is always "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 % no voice, but in synch
V:flute % the control voice
P:2 % formally in the non-control voice "whistle", but in synch
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:
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.
The first consequence is: If a clef is imposed, 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 do not match in some other staff-related matters, 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.
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.
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:
Note that I have dropped the "I:synch" of previous versions completely, for simplicity.
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 master role.
That is in fact the idea. When this document describes what software must do, the purpose is only 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 way of coding. Users will be glad if we describe a style of coding 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.)