informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/music/smdl-t.ech

2964 lines
103 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

X3V1.8M/SD-7 Journal of Development
Standard Music Description Language
Part Two: Technical Description and Formal Definition
Editor: Alan D. Talbot, New England Digital Corporation
June 4, 1988
June 16, 1988
- 2 -
CONTENTS
0 Introduction 4
0.1 Purpose of the Document 4
0.2 Development Methodology 4
0.3 Editorial Conventions 5
1 Scope and Field of Application 5
1.1 Scope 5
1.2 Field of Application 6
3 References 6
4 Definitions 6
5 Notation 8
6 Structure and Content 8
7 Work 9
7.1 Work Segment 10
7.2 Work Segment Reference 11
8 Core 11
8.1 Thread 12
8.1.1 Core Event Sequence 13
8.1.2 Core Event Group 14
8.1.3 Core Events 14
8.1.3.1 Notes and Rests 14
8.1.3.2 Graced Events 15
8.1.3.3 Special Events 16
8.1.4 Core Event References 16
8.2 Time 16
8.2.1 Beat 16
8.2.2 Duration 17
8.3 Stress 17
8.3.1 Beat Number 17
8.3.2 Stresses 18
8.3.3 Meter 18
8.4 Tempo Sequence 18
8.4.1 Tempo 18
9 Gestural Domain 20
9.1 Track 21
9.1.1 Gestural Event Sequence 21
9.1.2 Gestural Event Group 21
9.1.3 Gestural Event 22
9.1.4 Gestural Event Reference 22
9.2 Click Track 22
10 Visual Domain 23
10.1 Part 23
10.1.1 Visual Event Sequence 24
10.1.2 Visual Event Group 24
10.1.3 Visual Event 24
10.1.4 Visual Event Reference 25
10.2 Space 25
11 Analytical Domain 25
11.1 Voice 26
11.1.1 Analytical Event Sequence 26
11.1.2 Analytical Event Group 27
11.1.3 Analytical Event 27
June 16, 1988
- 3 -
11.1.4 Analytical Event Reference 27
12 Bibliographic 27
12.1 Theme 28
13 Conformance 28
Annex A 30
Annex B 40
B.1 General Application 40
Annex C 42
C.1 Definitions 42
C.2 Structure 42
C.3 Segregation 42
C.4 Language 43
Annex D 44
D.1 Structure 44
D.2 Punctuation 44
Annex E 45
June 16, 1988
- 4 -
0 Introduction
This is the second part of a two part document describing the work of
ANSI X3V1.8M, the Music Information Processing Standards Committee
(MIPS). The parts are known collectively as the Journal of Develop-
ment.
"Part One: Objectives and Methodology" describes the objectives of the
project and the development methodology employed.
"Part Two: Technical Description and Formal Definition" describes the
language design itself, and provides a formal definition.
This document and the other Standing Documents comprise the output of
the committee, while the other documents and material presented at the
meetings provide the input.
NOTES
1. The Journal of Development is maintained in two parts only to
facilitate maintenance by separate individuals; the two parts
should always be read as a single document. There is much in Part
Two, for example, that may seem confusing or contentious if it is
not read in the context established by Part One.
2. This introduction appears in both parts of the Journal of
Development.
3. General information about the MIPS committee, including a guide
to participation, can be found in committee document X3V1.8M/SD-
0.
0.1 Purpose of the Document
The Journal of Development describes the status of the Standard Music
Description Language (SMDL) being developed by the Music Information
Processing Standards (MIPS) Committee. It is intended as the technical
and methodological design specification which will ultimately evolve
into a Standard.
0.2 Development Methodology
Both parts are revised by their respective editors after each meeting
of the committee. As a result, the documents never represent text
that has been agreed on in detail by the committee, but only the edi-
tors' best efforts to express the committee's ideas. Moreover, the
ideas in the journal are subject to further study and revision and do
not represent a final design.
Eventually, the design work will reach a point where all aspects of
the language have been addressed, although not necessarily finalized.
At that point, the Journal of Development will cease to be the vehicle
that expresses the current language design. Instead, the committee
will produce one or more successive "working drafts", consisting of
June 16, 1988
- 5 -
text that has been agreed to.
During the Journal of Development and working draft stages, public
comment is sought and considered, but the process is informal. When,
eventually, the committee is satisfied with a working draft, it will
recommend that X3V1.8 process the document as a "draft proposed Ameri-
can National Standard". There will then commence a formal public
review and ballot, during which all comments received will be
responded to in writing.
0.3 Editorial Conventions
Formal standards can be complex documents in which every word has both
legal and technical significance. They may also need to be translated
into other languages. For these reasons, editorial conventions have
been established to assure precision, accuracy, and clarity (albeit
often at the expense of readability by the general public). The key
principles are:
1. Precise and consistent definitions of terms.
2. Distinguishing real requirements from mere commentary, explana-
tions, and examples -- and from definitions.
3. Avoidance of redundancy. (Repetition of a requirement is nor-
mally expressed as a note, to avoid the question of which text
governs if the "repetition" is imperfect.)
Part Two of the Journal of Development observes some of the editorial
conventions of a formal standard, but not yet with the strictness and
consistency that will be required in the final document. (See Annex C
of Part 2 for details.)
1 Scope and Field of Application
This section defines the range of applicability of the Standard. It
specifies the limits of what the Standard can be expected to
represent, and what is outside the design criteria.
NOTE: In order to proceed in a timely fashion, we found it necessary
to choose a subset of all possible music for the scope of the Stan-
dard. As the design matures, we expect to expand the scope to meet any
further needs of its users.
1.1 Scope
This Standard defines a language for the representation of music
information, either alone, or in conjunction with text, graphics, or
other information needed for publishing or business purposes. The
language is known as the "Standard Music Description Language", or
"SMDL".
NOTE: The Standard Music Description Language is an SGML application
conforming to International Standard ISO 8879 -- Standard Generalized
June 16, 1988
- 6 -
Markup Language.
The SMDL is capable of representing many (but not all) genres of
music, and most (but not necessarily all) instances of works in those
genres. The primary focus is on music that can reasonably be
expressed in Standard Western Musical Notation.
NOTE: The scope as defined should encompass the vast majority of
music. It does not exclude the use of special symbols that can be
placed in the score, nor of modern notational practices. The only cri-
terion is that the music be capable of representation as notes on a
staff, regardless of whether it was actually written down that way, or
even written down at all.
The SMDL is designed for flexibility and extensibility. There are no
technical prohibitions against the use of some components without the
whole, or against the use of user-defined components in conjunction
with standardized ones. The Standard includes a conformance clause
that identifies minimum and higher levels of support in terms of
standardized language components and options for user extensions.
1.2 Field of Application
Pieces that are composed on computer devices, pieces that exist as
printed scores, pieces that are performances recorded in a manner that
permits machine transcription, and pieces that are already represented
in some language, are all within the field of application of this
Standard.
Pieces that have other sources, such as digital audio recordings, can
be associated and synchronized with pieces described in SMDL. They can
exist as elements in the same document as SMDL works, but will have
their own representation (document type definition and data content
notations).
3 References
ISO 8879, Information processing -- Text and office systems -- Stan-
dard Generalized Markup Language (SGML).
X3V1.8M/SD-6 Journal of Development -- Standard Music Description
Language -- Part One: Objectives and Methodology
4 Definitions
The following items are used in a number of places in the text but are
not explicitly defined. They are essential to the understanding of the
Standard, and many have been assigned meanings which differ from com-
mon usage.
4.1 analytical domain: The portion of a work which contains music
theoretical analyses.
4.2 analysis: A music theoretical analysis of the piece, such as a
June 16, 1988
- 7 -
Shenkerian analysis. An examination of the piece as opposed to a ren-
dition of the piece.
4.3 beat: A relative time unit that is used for measuring durations
in the core.
NOTE: It should be the "felt" beat (tactus) if known. Otherwise, it
can be chosen for convenience; for example, the smallest or most com-
mon note value in the piece (i.e., 1/4, 1/8, 1/16, etc.)
4.4 bibliographic data: Identification information used to catalog
and archive pieces of music (or any other works.)
4.5 core: The portion of a work that represents the basis of all of
the performances, scores, and analyses. The logical musical material
as opposed to the performance or score specific material.
NOTE: The core can be thought of mechanistically as the information
which is most convenient to share in common among the other domains,
and among multiple instances in the same domain. Philosophically, it
can be thought of as the information that is necessary (and in the
case of conventional Western music, sufficient) to distinguish the
piece from all others.
4.6 gestural domain: The portion of a work that represents live per-
formance data such as precise timing and dynamic fluctuation.
4.7 logical: The basic musical content of a piece of music, such as
the time values, pitch values, and basic groupings such as chords and
tuplets.
4.8 logical domain: The core.
4.9 markup minimization: The elimination of redundant verbiage in the
actual representation of a work.
NOTE: SGML has been designed to allow this to happen naturally, so it
is not necessary to consider it in the initial design of the Standard.
4.10 MIPS: Music Information Processing Standards Committee; ANSI
X3V1.8M.
4.11 performance: A particular realization of a piece, either by
mechanical means or by a musician.
4.12 piece: A musical composition.
4.13 real time unit: The basic unit of measurement of time in a work;
the smallest representable division of time.
4.14 SGML: Standard Generalized Markup Language; a text markup
language and structured design tool. SGML is an International Standard
and is fully defined and described in ISO 8879-1986.
June 16, 1988
- 8 -
4.15 SMDL: Standard Music Description Language; this Standard.
4.16 score: A printed piece of music; an edition.
4.17 tuplet: A group of notes which occur in a different time frame
than the surrounding notes; a time anomaly.
NOTE: A triplet, a quintuplet, and a duplet in compound meter are all
tuplets.
4.18 visual domain: The portion of a work which represents the score;
the music engraving information.
4.19 work: The SMDL representation of a piece.
NOTE: A work has four domains: core, gestural, visual, and analytical.
In addition, bibliographic data can be associated with the work as a
whole or with instances of any of the domains.
5 Notation
This Standard is expected to be an SGML application, and the develop-
ment is proceding using SGML as a design tool. For this reason, the
formal syntactic and structural definitions in this document are in
SGML. A brief discussion of SGML syntax and semantics can be found in
Annex D. A complete and definitive treatise on SGML is found in ISO
8879-1986.
It is intended that the text describing each element and attribute
will be a complete definition and explanation, but the formal language
of the SGML coding provides the rigorous definitions underlying the
text descriptions, and will show the mechanism behind each technique
that is presented. For this reason, excerpts of the SGML encoding have
been interspersed with the text at strategic points. It is recommended
that the reader refer to the SGML in the text and in Annex A while
reading the technical definitions.
NOTE: In the case of conflict between the SGML excerpts in the text
and the formal specification in Annex A, the SGML in Annex A will
govern.
6 Structure and Content
The Standard will be based on a hierarchical structure which describes
a piece in terms of four basic sections: the underlying musical form,
a set of performances (presumably to be reproduced by a machine), a
set of scores in the form of Standard Western Music Notation, and a
set of theoretical analyses. We feel this structure best reflects the
conceptual divisions inherent in music in light of the uses to which
the Standard will be put. These divisions may not represent the philo-
sophically most elegant approach to the expression of musical ideas,
but we feel they will they will be maximally useful. This separation
of the whole into performance and score, and the extraction of the
logical musical concepts, seems an unavoidable outcome of the way
June 16, 1988
- 9 -
music has come to be performed and notated, and has long been present
in Western music.
This hierarchical structure will be codified in terms of elements.
Elements are basic structural building blocks which provide a frame-
work and a means to relate and collect information. Each element has a
related information set consisting of attributes. These will contain
much of the actual data, as the element itself is basically a place
holder. For instance, an event is an element, and may represent a
note, in which case it will have attributes describing pitch, dura-
tion, and possibly dynamic level. Attributes can be defined by the
user as well as the designer. This allows almost unlimited flexibility
in representing unusual material that may not have been foreseen dur-
ing the design.
The representational scheme is based on the separation of the basic
musical content (pitch, rhythm, harmony, etc.) from the purely perfor-
mance oriented information (intonation, rhythmic interpretation) and
the purely score oriented information (page layout, horizontal spac-
ing, clef). This means simply that some process or machine must be
able to separate the work into one or more of these categories for
this Standard to represent it. (These divisions are discussed in
detail in the following clauses.) This is not to say that the piece
must originate in a separated form, only that it can be separated for
the purpose of encoding in the Standard. While it is possible to ima-
gine pieces which are not separable in this way, almost all works in
all genres are in fact easily separable.
7 Work
NOTE: This and the following clauses are devoted to a detailed defini-
tion of each element of the structure, and the information it con-
tains. (A description of the applications of these elements is found
in Annex B.) Some of the attributes have been defined and are
described below, but some have not yet been addressed. The assumption
is that every element will have an attribute list, containing at least
an identification mark for reference by other elements. Additional
items will be added to the attribute list as they are defined, but in
the interests of top down design, we are concentrating on the overall
structure first, leaving the myriad and obfuscating details for later.
The work is the top level of the hierarchy. The work encompasses the
entire document, and is defined as the logical musical information,
and all of the performances, scores, and analyses that stem from that
musical information. If a "piece" actually has several versions which
differ in basic ways, those versions must each be a separate work. All
of the remaining elements are contained within the work.
The source is an attribute of a work which indicates what form the
piece originated from. It distinguishes between a piece which was cap-
tured from a MIDI stream, a piece which was entered from a printed
score, and a piece which was composed and entered as logical informa-
tion.
June 16, 1988
- 10 -
The composer analysis attribute, if present, indicates an analysis
which was created by the composer.
NOTE: The intent is to label that information which is definitive as
opposed to that which represents an opinion.
The rtu base is a time reference which specifies the order of magni-
tude of the timing in the work. It specifies the number of real time
units (rtu) per second.
NOTE: The intent is to allow a wide range of pieces to be realized
with an implementation of limited precision. If 32 bits are used to
hold time values, for instance, setting rtubase to 1 will give about
100 years of time measurable to 1 second accuracy. Setting it to
1,000,000 will give about 1 hour at 1 microsecond accuracy.
<!-- 7 Work as a Whole -->
<!ELEMENT work -- Musical composition, piece, etc. --
- - (bibdata?, workseg+, analysis*) >
<!ATTLIST work source -- Origin of this representation of the work --
(core | analysis | perform | score) #REQUIRED
companal -- Composer's analysis (may include core-like
controlling factors that distinguish the work)--
IDREF #IMPLIED -- ID of analysis --
rtubase -- Real Time Units per second (0=100,000,000) --
NUMBER 10000 >
7.1 Work Segment
The work segment is a structural device for dividing the work along
major boundaries. Workseg is defined self-referentially so that
repetitions and other constructs can be easily represented.
Movements of a symphony would be placed in separate segments, as would
acts in an opera or any other divisions that affect all aspects of the
piece (i.e. all parts, all instruments, etc.) The segment will also be
used for making global changes such as key changes, time signature
changes and instrumentation changes. If the piece changes key or time
signature, that often affects every part and instrument, and indicates
a major turning point in the music. In such cases, the material before
the change should be in one segment, and the material after in
another.
One very important use of the work segment will be in cases where the
instrumentation changes. If the piece starts out with full orchestra,
and later proceeds with only strings, then two segments should be used
to separate the sections. This will greatly assist in maintaining a
useful relationship between the threads in the core, the parts in the
score, and the tracks in the performance.
Another use is to indicate the composer's intent. If the composer or
the editor wants a major division in the work, the work segment can be
used to indicate the division even though none of the above situations
June 16, 1988
- 11 -
apply.
The class is a label indicating the use of the workseg. It is coded as
a text string, not as a machine interpretable value.
The delay indicates the expected pause (if any) between the workseg
and any following workseg. It is coded as a text string, not as a
machine interpretable value.
<!-- 7.1 Work Segment -->
<!ELEMENT workseg -- Sequential segment of a work: movement, act, etc. --
O O ((workseg, (workseg | worksegr)+) |
(bibdata?, core, perform*, score*)) >
<!ATTLIST workseg id ID #IMPLIED
class -- E.g., movement, section, coda --
CDATA #IMPLIED -- don't care --
delay -- E.g., 15 minute intermission --
CDATA #IMPLIED -- don't care -- >
7.2 Work Segment Reference
The work segment reference is a structural tool to allow a work seg-
ment to reference other work segments. This provides flexibility in
creating repeats and loops, and allows analyses to refer to work seg-
ments.
<!-- 7.2 Work Segment Reference -->
<!ELEMENT worksegr -- Work segment reference --
- O EMPTY >
<!ATTLIST worksegr idr IDREF #REQUIRED -- ID of any work segment -- >
8 Core
The core is the basis for a work, and a work has one and only one
core. The core contains such information as pitch, note value, har-
monic groupings, phrasings, tuplets, etc. A piece for which a core is
not producible can not be represented, and a piece with more than one
core must be represented as more than one work. We will see, however,
that several interpretations of the same basic piece can reside in the
same work if they derive from the same core.
Let us take the example of a simple piano piece. We have a performance
captured by a MIDI sequencer, and the score from which the performance
was played. The core will contain an element for each note and rest in
the score, thus representing the logical basis of the work. A given
measure in the core may contain no notes, and the corresponding spot
in the score may say "ad lib". At that point in the performance, there
are several improvised notes. It is possible that another performance
with a different improvised section, and another score which specifi-
cally details a cadenza, might be included in this work and be based
June 16, 1988
- 12 -
on the same core.
The normalized attribute states whether the core has been normalized.
It may often be desirable that the core have a canonical (normalized)
form. That is, that there be one particular form which will always be
used for a given piece. (Note that the definition of the core does not
provide orthoganality, so there are many ways that a given piece could
be represented.) For such situations, an algorithm can be applied
which translates any arbitrary core into a given canonical form. The
user may create such an algorithm to fit the needs of the application,
or the Standard Canonical Form can be generated using the Standard
Algorithm. We plan to provide this Standard Algorithm both as a way
of providing consistency between applications and as a model for other
algorithms.
The normalization algorithm attribute states which algorithm has been
used to normalize the core. If "standard" is used, it is expected that
implementations will access the Standard Algorithm. If another algo-
rithm is used it can be identified here, and may be implementation
specific.
<!-- 8 Core -->
<!ELEMENT core -- The essential music, common to all domains --
- O (stress*, temposeq+, thread+) >
<!ATTLIST core norm -- Is core timing normalized? (7.5) --
(norm | nonnorm) nonnorm >
8.1 Thread
The thread is a sequence of musical events which lasts for the dura-
tion of the piece. It is analogous to a track in a sequencer or on a
multi-track tape deck. The purpose of the thread is to allow the core
to be sectioned into concurrent streams of notes and other events,
mostly for the sake of convenience. There is no assumption made about
how the piece will be divided into threads, but logic suggests that
parts in a score, tracks in a sequence, or voices would be the best
choices of thread allocation.
The tempo sequence attribute indicates which tempo sequence is to be
used for this thread.
The nominal instrument attribute records for posterity the instrument
that the composer had in mind (in case anybody cares.) The point is
that the gestural section, which contains the timbral information, may
be an interpretation by someone other than the composer. This will be
encoded as a text string, not as coded timbral data such as is found
in the gestural section.
June 16, 1988
- 13 -
<!-- 8.1 Thread -->
<!ELEMENT thread -- Voice-like time-ordered sequence of events --
- O (ces) >
<!ATTLIST thread id ID #IMPLIED
temposeq IDREF #IMPLIED
nominst CDATA #IMPLIED -- Nominal instrument --
-- TO DO: other attributes -- >
8.1.1 Core Event Sequence
A core event sequence is a collection of core events, other core event
sequences, and core event groups. A core event sequence groups sequen-
tial events, as in movements, measures or tuplets. These groups may be
nested to any depth and combined in any way. Each thread is made up of
a structure of core event sequences which is as complex as is neces-
sary to represent the music completely.
The time factor attribute is a fraction which describes the relation-
ship of the beat inside a given sequence and the beat surrounding (or
underneath) the sequence. Time anomalies (such as triplets) will be
represented by setting the time factor to the correct fraction. For
example, if the beat of a piece falls on the quarter note (so quarter
notes have a time value of 1) and an eighth note triplet is encoun-
tered, the triplet could be expressed as a sequence of three notes of
value 1 with a time factor of 1/3, or as a sequence of three notes of
value 1/2 with a time factor of 2/3. It may turn out to be desirable
to specify that every event sequence must contain an integral (non-
fractional) number of beats. This would not be limiting since a common
denominator can be found for any situation.
The stress id attribute is a reference to a stress pattern to use for
this sequence.
The stress beat attribute is the offset (in beats) into the stress
pattern at which the sequence starts. A common use for this would be
for an anacrusis (pick-up measure).
The ornamentation style attribute is a text string which allows the
composer or editor to record remarks on the ornamentation style of the
sequence.
NOTE: This attribute should perhaps modify stress instead.
June 16, 1988
- 14 -
<!-- 8.1.1 Core Event Sequence -->
<!ENTITY % FRAC "NUMBERS" -- fraction: numerator, denominator? (=1) -- >
<!ENTITY % m.ces "(ces|ceg|note|rest|grcevent|special|cer)*" >
<!ELEMENT ces -- Core event sequence --
O O (chordnm?, %m.ces;) >
<!ATTLIST ces id ID #IMPLIED
factor -- ces beats / sum of subelement beats --
%FRAC "1 1"
stressid -- Beat cycle dynamic stress pattern --
IDREF #IMPLIED -- Default: no change --
stressbt -- Beat # of stress pattern on which ces begins --
NUMBER 1 -- Not 1 only if anacrusis --
ornstyle -- Ornamentation style: e.g., period --
CDATA #IMPLIED -- Default: no ornamentation -- >
8.1.2 Core Event Group
The core event group is a collection of events or sequences which are
initiated simultaneously. A chord is a group which contains events
(notes). A section of a thread may well be a group containing a
sequence for each of several parallel voices. This is an alternative
to placing each voice in a separate thread.
<!-- 8.1.2 Core Event Group -->
<!ELEMENT ceg -- Core event group --
- - %m.ces; >
<!ATTLIST ceg id ID #IMPLIED
-- TO DO: other attributes -- >
8.1.3 Core Events
The core event is the basic unit of the structure. Notes and rests are
examples of core events, but other occurrences may also be represented
as events. In general an event is some occurrence or item which has a
single definable starting point in time, and a definable duration.
8.1.3.1 Notes and Rests
The note and the rest are the most common musical events. They are
very similar in that they are simple events (as opposed to compound
events like the graced event). The note has a pitch attribute which
specifies its scale tone and octave.
June 16, 1988
- 15 -
<!-- 8.1.3.1 Notes and Rests -->
<!ELEMENT (note | rest)
-- Conventionally pitched time-stamped event --
- O EMPTY >
<!ATTLIST (note | rest)
id ID #IMPLIED
%a.ctime;
-- TO DO: other attributes -- >
8.1.3.2 Graced Events
The graced event is a compound event in that it consists of a main
event ornamented by a "grace" modifier. The modifier is an event
sequence which can either precede or follow the main event, and which
will not consume time as will a normal sequence.
The preceding grace modifier is an event sequence which starts at a
given time and proceeds until finished, at which time the grace sub-
ject is started.
The grace subject is the main event. It starts after the preceding
modifier and continues until the end of its duration, or until the
start of a posterior modifier.
The posterior grace modifier starts at a given time after the main
event has started, and proceeds until finished.
The grace synchronization attribute specifies the starting time
offsets of the preceding and posterior modifiers. It is measured from
the start time of the subject, and the end time of the subject,
respectively.
<!-- 8.1.3.2 Graced Event -->
<!ELEMENT grcevent -- Graced core event --
- O ((grcpre, grcsubj) | (grcpre?, grcsubj, grcpost))>
<!ATTLIST grcevent id ID #IMPLIED >
<!ELEMENT (grcpre | grcpost)
-- Core event whose duration is not counted --
- O %m.ces; >
<!ATTLIST (grcpre | grcpost)
id ID #IMPLIED
-- Synchronization with subject:
start-time in the case of grcpre
end-time in the case of grcpref --
grcsync (lead | lag) lead >
<!ELEMENT grcsubj -- Grace sequence subject: that which is graced --
O O (note | rest | special | cer) >
June 16, 1988
- 16 -
8.1.3.3 Special Events
The special event contains user defined information about timed events
other than conventional musical occurrences. Its content (other than
starting time and duration) will be application specific.
<!-- 8.1.3.3 Special Events -->
<!ELEMENT special -- User-defined time-stamped event: content describes it --
- O (#PCDATA) >
<!ATTLIST special id ID #IMPLIED
%a.ctime;
-- TO DO: other attributes -- >
8.1.4 Core Event References
Core events are accessed through core event references. These are
pointers which allow the core to be referred to in arbitrarily complex
ways by the performance, score, and analysis sections of the piece.
This process will be explored in more depth in Theory of Use. This
structure yields a very flexible system for organizing and referring
to events.
<!-- 8.1.4 Core Event Reference -->
<!ELEMENT cer -- Reference to core event, sequence, or group --
- O EMPTY >
<!ATTLIST cer idr IDREF #REQUIRED -- ID of ces|ceg|ce --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
8.2 Time
It is in the core that the time of the piece is represented. By time
we mean the rhythmic relationship of each event to all other events.
This is not to be confused with tempo, which refers to the rate of
progress of the piece. The time model has several components which
combine to form a system which we hope will account for any situation
within the scope of the Standard.
8.2.1 Beat
All time must be measured in relation to some base which is not open
to interpretation. That base will be called the beat. The beat is
defined to be that time interval which, at any given point in the
piece, is small enough to divide without remainder into all existing
subdivisions of the sequence, excluding time anomalies. This beat will
only be assigned an absolute value in the gestural section; in the
core it is simply a common reference. If the beat changes in meaning
as the piece progresses, then the core will be sectioned into more
than one sequence. Each sequence will specify the relation of its
beat to an overall reference beat.
June 16, 1988
- 17 -
Since the beat is a relative measurement, the performance can be
linked to any time base that is appropriate. The beat can be assigned
a fixed duration, an algorithmically generated variable duration, or
be related to a live recorded click track. Similarly the score can use
any appropriate time signature for a given passage. The same piece
could, for example, be scored in 4/4 as triplets or in 12/8 as
straight eighths. Indeed, a score representation in each meter could
refer to the same core.
8.2.2 Duration
Each core event will have a music duration (note value) attribute
which is stated as a fraction of a beat. The time consumed by a core
event sequence will be the sum of the durations of its events in
beats. Accumulated time is therefore represented as the sum of dura-
tional time, necessitating the definition of events which sound
(notes), and events which do not (rests).
The model will support single events or tied events. Tied events are
strings of events which are taken together to represent one event with
a duration that is the sum of each of the individual durations. When a
note starts sounding in one event sequence and continues into the
next, the note is split into two tied events of the appropriate dura-
tion. The tie attribute indicates that the event is tied, and to which
subsequent event it is tied.
<!-- 8.2 Time -->
<!ENTITY % BEATS "%FRAC;" -- Measure of music time (fractional) -- >
<!ENTITY % a.ctime -- Core event time attributes (7.2) --
"musicdur %BEATS #CURRENT tie IDREF #IMPLIED" >
8.3 Stress
The stress element indicates how a passage is to be stressed dynami-
cally. It consists of a set of template sequences that indicate which
beats are to receive what stress. Stress can be dynamic, agogic (tempo
related), or can be related to other user specified parameters.
The beat count attribute indicates the number of beats in the template
cycle.
<!-- 8.3 Stress -->
<!ELEMENT stress -- Beat cycle definition; dynamic stress pattern --
- O (beatnum, stresses)+ >
<!ATTLIST stress id ID #IMPLIED
beatcnt NUMBER #REQUIRED -- Number of beats in cycle -->
8.3.1 Beat Number
The beat number element marks a particular beat in a stress cycle as
June 16, 1988
- 18 -
receiving stress.
<!ELEMENT beatnum -- Beat number receiving agogic or dynamic stresses --
O O (#PCDATA) >
8.3.2 Stresses
The stresses element contains information on what kind of stress is to
be applied to the beat with which it is associated.
<!ELEMENT stresses -- Stresses applied to specified beat --
O O (#PCDATA) >
8.3.3 Meter
The concept of meter is expressible in the core by creating a stress
template which models a measure. In 4/4 time, a template may have 4
beats, and may mark the first as having maximum stress, and the third
as having moderate stress. In the case of a complex metric situation,
such as a measure of five which is felt as two and three, a nested
structure of stress templates can be used to accurately indicate the
feel. If ambiguity is desired however, the measure can be represented
as simply five beats.
NOTE: The inclusion of the meter in the core reflects the philosophy
that measures are a basic logical concept in music, rather than
strictly a score related issue. This is certainly not true of all
music, but the facility must be there for those pieces for which it is
important.
8.4 Tempo Sequence
The tempo sequence element is a list of time stamped tempo modifica-
tions which govern the tempo of the piece. Each thread refers to a
particular tempo sequence; there can be several if the piece involves
conflicting tempi.
<!-- 8.4 Tempo -->
<!ELEMENT temposeq -- Relates music time to real time (may be imprecise) --
- O (tempo+) >
<!ATTLIST temposeq id ID #IMPLIED >
8.4.1 Tempo
The tempo element is the basic building block of the tempo sequence.
It specifies a tempo change from the current tempo to a target tempo.
June 16, 1988
- 19 -
(The current tempo is the tempo in effect infinitesimally before the
start time of the tempo element. The target tempo is the tempo in
effect infinitesimally before the start time of the next tempo ele-
ment.) The attributes have been defined to give a large degree of
flexibility in specifying changes over time, and maintaining ambiguity
and imprecision when desired.
The music duration attribute specifies the life of this tempo setting
(the time until the next change) in beats.
The set value attribute specifies a precise target tempo, either abso-
lutely in rtu's per beat or as a percentage of the current tempo.
The set text attribute specifies an imprecise target tempo. The value
is represented as a text string, and presumably will be a common musi-
cal expression such as "presto" or "moderato".
The rate value attribute specifies a precise formula for reaching the
target tempo from the current tempo. It can be specified as "immedi-
ate" (instant change at the start time of the tempo element), "linear"
over the duration of the tempo element, or represented by a mathemati-
cal formula in the form of a text string.
The rate text attribute specifies an imprecise formula for reaching
the target tempo from the current tempo. The value is represented as a
text string, and presumably will be a common musical expression such
as "accelerando" or "ritardando".
The hold duration attribute specifies a precise pause in the counting
of music time. Its value is absolute in beats. It can be used for a
fermata, a full stop, or any other pause or interruption of the normal
time flow of the piece, such as an unaccompanied solo cadenza. The
hold starts at the starting time of the tempo element, and the tempo
duration begins at the completion of the hold.
The hold type attribute specifies an imprecise pause in the counting
of music time. It can be specified as "full stop", "long", "medium",
"short", "none", in non-increasing order of length. The actual time
value of these specifiers is implementation dependant. The hold starts
at the starting time of the tempo element, and the tempo duration
begins at the completion of the hold.
The strictness attribute specifies the precision with which the tempo
should be followed during a realization of the piece. It is specified
as "strict tempo", or represented by a text string containing a common
musical expression such as "rubato".
June 16, 1988
- 20 -
<!ELEMENT tempo -- Real time units per beat --
- O (#PCDATA) >
<!ATTLIST tempo id ID #IMPLIED
musicdur -- Duration of tempo setting in music time --
%BEATS #CURRENT
setval -- Precise final tempo: RTUs/beat (integer #RTU)
or % of earlier tempo (%FRAC idref) --
CDATA #CURRENT
settext -- Imprecise final tempo: moderato --
CDATA #IMPLIED -- Default: use setval --
rateval -- Precise rate of reaching final tempo --
-- Format: (LINEAR | FORMULA data) --
CDATA #IMPLIED -- Default: immediate --
ratetext -- Imprecise rate specification: accel, ritard --
CDATA #IMPLIED -- Default: use rateval --
strict -- Strictness of interpretation: rubato --
CDATA #IMPLIED -- Default: strict tempo --
holdtype -- Imprecise extension of counted duration --
(fullstop|long|medium|short|none) none
holddur -- Precise duration of hold --
%BEATS #CURRENT >
9 Gestural Domain
The gestural section of the piece contains the performances. While
each work has only one core, it may have several gestural sections,
each a different performance (and hence different interpretation) of
the piece, and each linked to a particular score The gestural section
refers to the core for the majority of its musical material, but may
have events of its own. Usually these events will be ad lib notes and
performance control information such as volume or timbre selection.
The gestural section is intended to represent data for an automated
performance of the piece. That data could be generated by a live per-
formance or by non-real-time composition, then returned to a syn-
thesizer for realization.
The performance is the top level gestural element. Each performance
typically realizes the entire piece.
The score attribute identifies a score in the visual domain which
represents the edition which produced this performance, if such a
score exists.
The closure attribute indicates whether every event in the core was
realized in this performance.
June 16, 1988
- 21 -
<!-- 9 Gestural Domain -->
<!ELEMENT perform -- The gestures of a performance (MIDI) --
- O (bibdata?, clicktrk*, track+) >
<!ATTLIST perform id ID #IMPLIED
score IDREFS #IMPLIED
closure -- Are all core events referenced? --
(closed, open) open >
9.1 Track
The track is analogous to the thread in the core. It will be used to
drive one channel of sound output, or one instrument. It is the pre-
cise counterpart of a track on a multi-track. Unlike the thread, the
division of music into tracks may need to follow certain restraints
imposed by the device that will perform the piece. For example a track
may have to be limited to events which are to sound in the same tim-
bre.
A track is made up of gestural event sequences, which are made up of
gestural events, gestural event references, and core event references.
It is through these core event references that the core becomes the
basis of the gestural section. While it would be possible through the
use of gestural events to represent a performance that was unrelated
to the core, the intention is that the track will contain mostly per-
formance control information, and refer to the core for most or all of
the notes, rests, and other basic conceptual material.
<!-- 9.1 Track -->
<!ELEMENT track -- One instrument's time-ordered sequence of gestures --
- O (ges) >
<!ATTLIST track id ID #IMPLIED
instrum CDATA #IMPLIED
clicktrk IDREF #IMPLIED
-- TO DO: other attributes -- >
9.1.1 Gestural Event Sequence
<!-- 9.1.1 Gestural Event Sequence -->
<!ENTITY % e.ge "ge" -- TO DO: replace with real element types -- >
<!ENTITY % m.ges "(ges | geg | %e.ge; | ger | gcer)*" >
<!ELEMENT ges -- Gestural event sequence (has core references) --
O O %m.ges; >
<!ATTLIST ges id ID #IMPLIED
-- TO DO: other attributes -- >
9.1.2 Gestural Event Group
June 16, 1988
- 22 -
<!-- 9.1.2 Gestural Event Group -->
<!ELEMENT geg -- Gestural event group (has core references) --
- - %m.ges; >
<!ATTLIST geg id ID #IMPLIED
-- TO DO: other attributes -- >
9.1.3 Gestural Event
<!-- 9.1.3 Gestural Event -->
<!ENTITY % SECONDS "NUMBERS" -- Format: (seconds?, Real Time Units) -- >
<!ELEMENT (%e.ge;) -- Gestural event: e.g., controller setting, ad lib note --
- O EMPTY >
<!ATTLIST ge id ID #IMPLIED
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
-- TO DO: other attributes -- >
9.1.4 Gestural Event Reference
<!-- 9.1.4.1 Gestural Domain Reference to Gestural Event -->
<!ELEMENT ger -- Gestural event reference (includes geg|ges) --
- O EMPTY >
<!ATTLIST ger idr IDREF #REQUIRED -- ges|ge|geg same perform --
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 9.1.4.2 Gestural Domain References to Core Events -->
<!ELEMENT gcer -- Gestural domain core event reference --
- O EMPTY >
<!ATTLIST gcer idr IDREF #REQUIRED -- ces|ce|ceg in core --
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
9.2 Click Track
The click track is a gestural event sequence with an event to mark
each beat in the piece. This element will provide a means for relating
beats in the core to real time. Click tracks can have arbitrarily
spaced events, so any kind of expressive performance can be
June 16, 1988
- 23 -
represented. The click track will usually be generated by a transcrip-
tion program in the process of creating a work from a live perfor-
mance. Note that a click track does not need to be present, since a
rhythmically exact performance can be generated from the core alone.
<!-- 9.2 Click Track -->
<!ELEMENT clicktrk -- Click track: ordered table of event start-times --
- O (#PCDATA) >
<!ATTLIST clicktrk id ID #IMPLIED -- Default: generated --
nextbeat -- Track and time of next beat --
NMTOKENS #IMPLIED >
10 Visual Domain
The visual section of the piece contains the scores. While each work
has only one core, it may have several scores, each a different edi-
tion (and hence a different interpretation of the piece), and each
linked to a particular performance. The visual section refers to the
core for the majority of its musical material, but may have events of
its own. Usually these events will be symbols that appear on the
score aside from notes, rests, and accidentals. Such items as phrase
markings, beams, accents, dynamic markings, and lyrics would be found
here. The visual section is intended to represent the printed score in
Standard Western Music Notation. The score could be generated by a
music printing system and returned to such a system for printing or
display.
The score element is the top level of the visual domain. Each score is
a presumably complete edition of the piece.
The performance attribute specifies a performance in the gestural
domain which was generated from this particular score (edition), if
such a performance exists.
The closure attribute indicates whether every event in the core was
notated in this score.
<!-- 10 Visual Domain -->
<!ELEMENT score -- Visual representation of work (a la DARMS, MUSTRAN...) --
- O (bibdata?, part+) >
<!ATTLIST score id ID #IMPLIED
perform IDREFS #IMPLIED
closure -- Are all core events referenced? --
(closed, open) open >
10.1 Part
The part is analogous to the thread in the core. It will be used to
print one part of the score for one instrument. It is the precise
counterpart of a staff in a score. The division of music into parts
June 16, 1988
- 24 -
will be based on the desired appearance of the score.
A part is made up of visual event sequences, which are made up of
visual events, visual event references, and core event references. It
is through these core event references that the core becomes the basis
of the visual section. While it would be possible through the use of
visual events to represent a score that was unrelated to the core, the
intention is that the part will contain mostly visual symbols, and
refer to the core for most or all of the notes, rests, and other basic
conceptual material.
<!-- 10.1 Part -->
<!ELEMENT part -- One instrument's portion of the system --
- O (ves) >
<!ATTLIST part id ID #IMPLIED
clef NAMES "treble bass"
-- TO DO: other attributes -- >
10.1.1 Visual Event Sequence
<!-- 10.1.1 Visual Event Sequence -->
<!ENTITY % e.ve "ve" -- TO DO: replace with real element types -- >
<!ENTITY % m.ves "(ves | veg | %e.ve; | ver | vcer)*" >
<!ELEMENT ves -- Visual event sequence (has core references) --
O O %m.ves; >
<!ATTLIST ves id ID #IMPLIED
tuplet -- Triplet (etc.) indicator for sequence --
CDATA #IMPLIED -- Not a tuplet --
cue IDREF #IMPLIED -- ID of ves --
tsinst NUMBERS #IMPLIED -- Time sig for instrument --
tscond NUMBERS #IMPLIED -- Time sig for conductor --
-- TO DO: other attributes -- >
10.1.2 Visual Event Group
<!-- 10.1.2 Visual Event Group -->
<!ELEMENT veg -- Visual event group (has core references) --
- - %m.ves; >
<!ATTLIST veg id ID #IMPLIED
-- TO DO: other attributes -- >
10.1.3 Visual Event
June 16, 1988
- 25 -
<!-- 10.1.3 Visual Event -->
<!ELEMENT (%e.ve;) -- Visual event: e.g., phrase mark, bar line --
- O EMPTY >
<!ATTLIST (%e.ve;) id ID #IMPLIED
-- TO DO: other attributes -- >
10.1.4 Visual Event Reference
<!-- 10.1.4.1 Visual Domain Reference to Visual Event -->
<!ELEMENT ver -- Visual event reference (includes veg|ves) --
- O EMPTY >
<!ATTLIST ver idr IDREF #REQUIRED -- ves|ve|geg same score --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 10.1.4.2 Visual Domain Reference to Core Event -->
<!ELEMENT vcer -- Visual domain core event reference --
- O EMPTY >
<!ATTLIST vcer idr IDREF #REQUIRED -- ces|ce|ceg in core --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
10.2 Space
The unit of space will be defined relative to the size of the staff
and note heads. The actual size of the printed staff is not defined
except perhaps as a global attribute of the visual section. A unit of
one staff space for the vertical and one note head width for the hor-
izontal will provide the basis for all spatial measurements.
Spatial relationship will be representable in several ways: as an
absolute position on a line (staff), as a relative position from
another object, and as a relative position from a logical (time) posi-
tion on a staff. Furthermore, for each of these possibilities there
will be an explicit position (specified in spatial units) and an
implicit position. The implicit position will take the form of a
non-numerical relationship to some other object, such as "above the
staff" or "between this note head and the one to the left".
11 Analytical Domain
The analytical section of the piece contains any analyses that may
have been produced. A work may have several analytical sections, each
a different analysis (and hence a different interpretation of the
piece.) The analytical section refers to the core for the majority of
its musical material, but may also refer to performances and scores.
The analytical section is intended to represent a structuring of the
piece based on any style of analysis. The analysis could be generated
June 16, 1988
- 26 -
by a specialized music printing/editing system and returned to such a
system for printing or display, or might take the ultimate form of a
written document. It might even be generated automatically by a com-
puter system.
The analysis element is the top level of the analysis structure. It
represents a presumably complete analysis of the piece, by a particu-
lar analyst. If several analyses by different analysts exist, they
will each be is a separate analysis. The analysis can refer freely to
any other elements of a work, thus allowing complex relationships to
be represented.
<!-- 11 Analytical Domain -->
<!ELEMENT analysis -- An analysis of a work --
- O (bibdata?, voice+) >
<!ENTITY % a.anal
"core IDREFS #IMPLIED perform IDREFS #IMPLIED score IDREFS #IMPLIED" >
<!ATTLIST analysis id ID #IMPLIED
%a.anal; >
11.1 Voice
The voice is analogous to the thread in the core. It will be used to
represent one voice or melodic line of the piece. It is the counter-
part of a passage of notes that have the same stem direction. The
division of music into voices will be based on the voicing of the
piece intended by the composer or analyst.
A voice is made up of analytical event sequences, which are made up of
analytical events, analytical event references, and core event refer-
ences. It also can contain gestural event references and visual event
references. It is through these references that the analytical section
can arbitrarily structure any aspect of the piece in order to illus-
trate a music theoretical idea.
<!-- 11.1 Voice -->
<!ELEMENT voice -- A single melody line (possibly polyphonic) --
- O (aes) >
<!ENTITY % a.voice "" >
<!ATTLIST voice id ID #IMPLIED
%a.voice; >
11.1.1 Analytical Event Sequence
June 16, 1988
- 27 -
<!-- 11.1.1 Analytical Event Sequence -->
<!ENTITY % e.ae "ae" -- TO DO: replace with real element types -- >
<!ENTITY % m.aes "(aes | aeg | %e.ae; | aer | ver | ger | cer)*" >
<!ELEMENT aes -- Analytical event sequence (multi-domain refs) --
O O %m.aes; >
<!ENTITY % a.aes "class (motif | epmotif | esmotif | elision) motif" >
<!ATTLIST aes id ID #IMPLIED
%a.aes; >
11.1.2 Analytical Event Group
<!-- 11.1.2 Analytical Event Group -->
<!ELEMENT aeg -- Analytical event group (multi-domain refs) --
- - %m.aes; >
<!ENTITY % a.ae "" >
<!ATTLIST aeg id ID #IMPLIED
%a.ae; >
11.1.3 Analytical Event
<!-- 11.1.3 Analytical Event -->
<!ENTITY % m.ae "(%e.ae;|%e.ge;|%e.ve;)*" >
<!ELEMENT (%e.ae;) -- Analytical event --
- O %m.ae; >
<!ATTLIST (%e.ae;) id ID #IMPLIED
%a.ae; >
11.1.4 Analytical Event Reference
<!-- 11.1.4 References -->
<!ELEMENT aer -- Analytical event sequence reference --
- O EMPTY >
<!ENTITY % a.aer "" >
<!ATTLIST aer idr IDREF #REQUIRED -- ID of aes --
%a.aer; >
12 Bibliographic
The bibliographic entry is found at the top level (as an element of
work) and can also be used at lower levels. It contains much of the
bibliographic and discographic data necessary for the cataloging of a
piece.The bibliographic entry will contain the information necessary
to make the Standard useful. Such items as title, author, issuer (pub-
lisher), date, and copyright will all be explicitly defined. In addi-
tion, a miscellaneous area will be available which can contain any
information that is not defined elsewhere. If desired, a bibliographic
entry may be made for each performance in the gestural section, or for
June 16, 1988
- 28 -
each edition in the visual section.
The attributes are explained in the SGML code comments.
NOTE: We have not attempted to form an exhaustive structure for the
representation of complete library cataloging information. Such a
structure would extend the scope of the Standard beyond where we feel
it should go at present. Since we are utilizing the machinery of SGML
to implement this Standard, another committee could easily create such
a complete bibliographic element, and it could be readily included in
music documents. We in fact strongly urge the Library community to
initiate such a project.
<!-- 12 Bibliographic Data -->
<!ENTITY % e.bib "title | author | date | issuer | descript | copr">
<!-- Explanation of bibliographic elements:
title Title of work, performance, score, or analysis
author Work: composer, librettist, computer
Performance: performer, arranger
Score: editor, copyist, arranger
Analysis: theorist
issuer Access information: e.g., publisher, catalog number
date Date of work, performance, score, or analysis
copr Copyright notice
descript Miscellaneous descriptive data: e.g., performance time
-->
<!ENTITY % d.bib "<!ELEMENT (%e.bib;) - O (#PCDATA)>"> %d.bib;
<!ENTITY % m.bib "(%e.bib; | theme)*">
<!ELEMENT bibdata -- Bibliographic data applying to work as a whole --
- O %m.bib; >
12.1 Theme
The theme will contain references to the core which pinpoint key pas-
sages (or famous passages) for the purpose of identification of the
work. It will allow a cataloging application, for instance, to quickly
locate and then display or perform a well known section. This will
make it easy for the user to verify that the correct piece has been
retrieved.
<!-- 12.1 Theme -->
<!ENTITY % a.theme "">
<!ELEMENT theme -- Themes that best identify the work (e.g., incipit) --
- O EMPTY >
<!ATTLIST theme idr IDREFS #REQUIRED -- ID of analysis --
%a.theme; >
13 Conformance
The Standard will define several levels of conformance to allow
June 16, 1988
- 29 -
applications to implement subsets of the language. There will be a
canonical form and a "standard" level described.
NOTE: The issue of conformance will be developed further at a later
date.
June 16, 1988
- 30 -
Annex A
Formal Definition
(This annex is normative and will become an integral part of the Standard.)
This annex contains the formal definition of a work, expressed as an SGML
document type definition.
NOTES
Because the SMDL is still under development, the SGML document type defini-
tion (DTD) is presently incomplete in a number of respects. These are
listed below, and will be updated with the SGML Formal Definition.
1. Little detail is provided on the actual encoding of an instance of
a work. As we are first attempting to identify the potential events and to
define their properties (attributes), the DTD acts as though all events
will be encoded with start-tags and end-tags, with all properties specified
using the SGML attribute notation. The result is a lopsided definition in
which there is only structure and no actual data.
This convention is satisfactory (even advantageous) while we are designing
the structure and semantics of the SMDL. It allows relationships to be
seen easily and requirements to be evaluated, without the intrusion of cod-
ing considerations. Once the design is complete and we understand all of
the information that must be represented, we will create a concise coding
scheme to replace the lower levels of the structure. (In SGML, such a
scheme is known as a "data content notation".)
2. Most attributes have not yet been defined. As a result, many of
the ATTLIST declarations appear identical to one another. In such cases,
we expect that the lists will be differentiated by attributes that will be
defined later.
3. The lowest-level gestural, visual, and analytical event elements
(ge, ve, and ae) are temporary placeholders for lists of distinct element
types (for example, bar lines, clefs, etc.). Eventually, the entity refer-
ences to lists of the distinct types will be completed to replace these
element names. For now, only the lowest-level core events have been
defined.
Moreover, as we are first attempting to define those attributes which all
events have in common, a single ATTLIST is used in each domain. Eventu-
ally, each event may have its own ATTLIST declaration.
4. There are many elements that have common content models and, at
least for the moment, common attribute lists. As a matter of development
methodology, we felt it better to assume that elements that represent dif-
ferent semantic constructs (e.g., tracks and parts) are likely to have dif-
ferent attributes when the design is complete, even though they may have
identical structures. If the presumption proves incorrect in any instance,
we will of course remove the redundancy when finalizing the design, but
premature optimization might cause us to overlook vital differences.
June 16, 1988
- 31 -
5. For attributes that have been defined, particularly those whose
domain is a list of specific values, we have typically provided only a nom-
inal list of values. We expect that once the overall structure is firm,
experts will be able to contribute more complete lists. Such attribute
domains can also be made user-extensible if that is desirable.
<!-- Public document type definition for music representation.
Typical invocation:
<!DOCTYPE work PUBLIC "-//ANSI X3V1.8M//DTD Musical Work//EN">
NOTE: The section heading comments identify the corresponding clause
numbers in the body of this document.
-->
<!-- 7 Work as a Whole -->
<!ELEMENT work -- Musical composition, piece, etc. --
- - (bibdata?, workseg+, analysis*) >
<!ATTLIST work source -- Origin of this representation of the work --
(core | analysis | perform | score) #REQUIRED
companal -- Composer's analysis (may include core-like
controlling factors that distinguish the work)--
IDREF #IMPLIED -- ID of analysis --
rtubase -- Real Time Units per second (0=100,000,000) --
NUMBER 10000 >
<!-- 7.1 Work Segment -->
<!ELEMENT workseg -- Sequential segment of a work: movement, act, etc. --
O O ((workseg, (workseg | worksegr)+) |
(bibdata?, core, perform*, score*)) >
<!ATTLIST workseg id ID #IMPLIED
class -- E.g., movement, section, coda --
CDATA #IMPLIED -- don't care --
delay -- E.g., 15 minute intermission --
CDATA #IMPLIED -- don't care -- >
<!ELEMENT worksegr -- Work segment reference --
- O EMPTY >
<!ATTLIST worksegr idr IDREF #REQUIRED -- ID of any work segment -- >
<!-- 8 Core -->
<!ELEMENT core -- The essential music, common to all domains --
- O (stress*, temposeq+, thread+) >
<!ATTLIST core norm -- Is core timing normalized? (7.5) --
(norm | nonnorm) nonnorm >
June 16, 1988
- 32 -
<!-- 8.1 Thread -->
<!ELEMENT thread -- Voice-like time-ordered sequence of events --
- O (ces) >
<!ATTLIST thread id ID #IMPLIED
temposeq IDREF #IMPLIED
nominst CDATA #IMPLIED -- Nominal instrument --
-- TO DO: other attributes -- >
<!-- 8.1.1 Core Event Sequence -->
<!ENTITY % FRAC "NUMBERS" -- fraction: numerator, denominator? (=1) -- >
<!ENTITY % m.ces "(ces|ceg|note|rest|grcevent|special|cer)*" >
<!ELEMENT ces -- Core event sequence --
O O (chordnm?, %m.ces;) >
<!ATTLIST ces id ID #IMPLIED
factor -- ces beats / sum of subelement beats --
%FRAC "1 1"
stressid -- Beat cycle dynamic stress pattern --
IDREF #IMPLIED -- Default: no change --
stressbt -- Beat # of stress pattern on which ces begins --
NUMBER 1 -- Not 1 only if anacrusis --
ornstyle -- Ornamentation style: e.g., period --
CDATA #IMPLIED -- Default: no ornamentation -- >
<!-- 8.1.2 Core Event Group -->
<!ELEMENT ceg -- Core event group --
- - %m.ces; >
<!ATTLIST ceg id ID #IMPLIED
-- TO DO: other attributes -- >
<!-- 8.1.3.1 Notes and Rests -->
<!ELEMENT (note | rest)
-- Conventionally pitched time-stamped event --
- O EMPTY >
<!ATTLIST (note | rest)
id ID #IMPLIED
%a.ctime;
-- TO DO: other attributes -- >
June 16, 1988
- 33 -
<!-- 8.1.3.2 Graced Event -->
<!ELEMENT grcevent -- Graced core event --
- O ((grcpre, grcsubj) | (grcpre?, grcsubj, grcpost))>
<!ATTLIST grcevent id ID #IMPLIED >
<!ELEMENT (grcpre | grcpost)
-- Core event whose duration is not counted --
- O %m.ces; >
<!ATTLIST (grcpre | grcpost)
id ID #IMPLIED
-- Synchronization with subject:
start-time in the case of grcpre
end-time in the case of grcpref --
grcsync (lead | lag) lead >
<!ELEMENT grcsubj -- Grace sequence subject: that which is graced --
O O (note | rest | special | cer) >
<!-- 8.1.3.3 Special Events -->
<!ELEMENT special -- User-defined time-stamped event: content describes it --
- O (#PCDATA) >
<!ATTLIST special id ID #IMPLIED
%a.ctime;
-- TO DO: other attributes -- >
<!-- 8.1.4 Core Event Reference -->
<!ELEMENT cer -- Reference to core event, sequence, or group --
- O EMPTY >
<!ATTLIST cer idr IDREF #REQUIRED -- ID of ces|ceg|ce --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 8.1.5 Chord Name -->
<!ENTITY % d.chord "<!ELEMENT chordnm - O (#PCDATA)>"> %d.chord;
<!-- 8.2 Time -->
<!ENTITY % BEATS "%FRAC;" -- Measure of music time (fractional) -- >
<!ENTITY % a.ctime -- Core event time attributes (7.2) --
"musicdur %BEATS #CURRENT tie IDREF #IMPLIED" >
<!-- Explanation of core time attributes:
musicdur Duration of event in music time.
tie Succeeding event to which this one is tied (Default: not tied).-->
June 16, 1988
- 34 -
<!-- 8.3 Stress -->
<!ELEMENT stress -- Beat cycle definition; dynamic stress pattern --
- O (beatnum, stresses)+ >
<!ATTLIST stress id ID #IMPLIED
beatcnt NUMBER #REQUIRED -- Number of beats in cycle -->
<!ELEMENT beatnum -- Beat number receiving agogic or dynamic stresses --
O O (#PCDATA) >
<!ELEMENT stresses -- Stresses applied to specified beat --
O O (#PCDATA) >
<!-- 8.4 Tempo -->
<!ELEMENT temposeq -- Relates music time to real time (may be imprecise) --
- O (tempo+) >
<!ATTLIST temposeq id ID #IMPLIED >
<!ELEMENT tempo -- Real time units per beat --
- O (#PCDATA) >
<!ATTLIST tempo id ID #IMPLIED
musicdur -- Duration of tempo setting in music time --
%BEATS #CURRENT
setval -- Precise final tempo: RTUs/beat (integer #RTU)
or % of earlier tempo (%FRAC idref) --
CDATA #CURRENT
settext -- Imprecise final tempo: moderato --
CDATA #IMPLIED -- Default: use setval --
rateval -- Precise rate of reaching final tempo --
-- Format: (LINEAR | FORMULA data) --
CDATA #IMPLIED -- Default: immediate --
ratetext -- Imprecise rate specification: accel, ritard --
CDATA #IMPLIED -- Default: use rateval --
strict -- Strictness of interpretation: rubato --
CDATA #IMPLIED -- Default: strict tempo --
holdtype -- Imprecise extension of counted duration --
(fullstop|long|medium|short|none) none
holddur -- Precise duration of hold --
%BEATS #CURRENT >
<!-- 9 Gestural Domain -->
<!ELEMENT perform -- The gestures of a performance (MIDI) --
- O (bibdata?, clicktrk*, track+) >
<!ATTLIST perform id ID #IMPLIED
score IDREFS #IMPLIED
closure -- Are all core events referenced? --
(closed, open) open >
June 16, 1988
- 35 -
<!-- 9.1 Track -->
<!ELEMENT track -- One instrument's time-ordered sequence of gestures --
- O (ges) >
<!ATTLIST track id ID #IMPLIED
instrum CDATA #IMPLIED
clicktrk IDREF #IMPLIED
-- TO DO: other attributes -- >
<!-- 9.1.1 Gestural Event Sequence -->
<!ENTITY % e.ge "ge" -- TO DO: replace with real element types -- >
<!ENTITY % m.ges "(ges | geg | %e.ge; | ger | gcer)*" >
<!ELEMENT ges -- Gestural event sequence (has core references) --
O O %m.ges; >
<!ATTLIST ges id ID #IMPLIED
-- TO DO: other attributes -- >
<!-- 9.1.2 Gestural Event Group -->
<!ELEMENT geg -- Gestural event group (has core references) --
- - %m.ges; >
<!ATTLIST geg id ID #IMPLIED
-- TO DO: other attributes -- >
<!-- 9.1.3 Gestural Event -->
<!ENTITY % SECONDS "NUMBERS" -- Format: (seconds?, Real Time Units) -- >
<!ELEMENT (%e.ge;) -- Gestural event: e.g., controller setting, ad lib note --
- O EMPTY >
<!ATTLIST ge id ID #IMPLIED
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
-- TO DO: other attributes -- >
<!-- 9.1.4.1 Gestural Domain Reference to Gestural Event -->
<!ELEMENT ger -- Gestural event reference (includes geg|ges) --
- O EMPTY >
<!ATTLIST ger idr IDREF #REQUIRED -- ges|ge|geg same perform --
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
June 16, 1988
- 36 -
<!-- 9.1.4.2 Gestural Domain References to Core Events -->
<!ELEMENT gcer -- Gestural domain core event reference --
- O EMPTY >
<!ATTLIST gcer idr IDREF #REQUIRED -- ces|ce|ceg in core --
start -- Start time (Default: derived from core) --
%SECONDS #IMPLIED
duration -- (Default: derived from core) --
%SECONDS #IMPLIED
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 9.2 Click Track -->
<!ELEMENT clicktrk -- Click track: ordered table of event start-times --
- O (#PCDATA) >
<!ATTLIST clicktrk id ID #IMPLIED -- Default: generated --
nextbeat -- Track and time of next beat --
NMTOKENS #IMPLIED >
<!-- 10 Visual Domain -->
<!ELEMENT score -- Visual representation of work (a la DARMS, MUSTRAN...) --
- O (bibdata?, part+) >
<!ATTLIST score id ID #IMPLIED
perform IDREFS #IMPLIED
closure -- Are all core events referenced? --
(closed, open) open >
<!-- 10.1 Part -->
<!ELEMENT part -- One instrument's portion of the system --
- O (ves) >
<!ATTLIST part id ID #IMPLIED
clef NAMES "treble bass"
-- TO DO: other attributes -- >
<!-- 10.1.1 Visual Event Sequence -->
<!ENTITY % e.ve "ve" -- TO DO: replace with real element types -- >
<!ENTITY % m.ves "(ves | veg | %e.ve; | ver | vcer)*" >
<!ELEMENT ves -- Visual event sequence (has core references) --
O O %m.ves; >
<!ATTLIST ves id ID #IMPLIED
tuplet -- Triplet (etc.) indicator for sequence --
CDATA #IMPLIED -- Not a tuplet --
cue IDREF #IMPLIED -- ID of ves --
tsinst NUMBERS #IMPLIED -- Time sig for instrument --
tscond NUMBERS #IMPLIED -- Time sig for conductor --
-- TO DO: other attributes -- >
June 16, 1988
- 37 -
<!-- 10.1.2 Visual Event Group -->
<!ELEMENT veg -- Visual event group (has core references) --
- - %m.ves; >
<!ATTLIST veg id ID #IMPLIED
-- TO DO: other attributes -- >
<!-- 10.1.3 Visual Event -->
<!ELEMENT (%e.ve;) -- Visual event: e.g., phrase mark, bar line --
- O EMPTY >
<!ATTLIST (%e.ve;) id ID #IMPLIED
-- TO DO: other attributes -- >
<!-- 10.1.4.1 Visual Domain Reference to Visual Event -->
<!ELEMENT ver -- Visual event reference (includes veg|ves) --
- O EMPTY >
<!ATTLIST ver idr IDREF #REQUIRED -- ves|ve|geg same score --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 10.1.4.2 Visual Domain Reference to Core Event -->
<!ELEMENT vcer -- Visual domain core event reference --
- O EMPTY >
<!ATTLIST vcer idr IDREF #REQUIRED -- ces|ce|ceg in core --
shift NUTOKEN 0 -- Transposition in steps --
-- TO DO: other event modifier attributes -- >
<!-- 11 Analytical Domain -->
<!ELEMENT analysis -- An analysis of a work --
- O (bibdata?, voice+) >
<!ENTITY % a.anal
"core IDREFS #IMPLIED perform IDREFS #IMPLIED score IDREFS #IMPLIED" >
<!ATTLIST analysis id ID #IMPLIED
%a.anal; >
<!-- 11.1 Voice -->
<!ELEMENT voice -- A single melody line (possibly polyphonic) --
- O (aes) >
<!ENTITY % a.voice "" >
<!ATTLIST voice id ID #IMPLIED
%a.voice; >
June 16, 1988
- 38 -
<!-- 11.1.1 Analytical Event Sequence -->
<!ENTITY % e.ae "ae" -- TO DO: replace with real element types -- >
<!ENTITY % m.aes "(aes | aeg | %e.ae; | aer | ver | ger | cer)*" >
<!ELEMENT aes -- Analytical event sequence (multi-domain refs) --
O O %m.aes; >
<!ENTITY % a.aes "class (motif | epmotif | esmotif | elision) motif" >
<!ATTLIST aes id ID #IMPLIED
%a.aes; >
<!-- 11.1.2 Analytical Event Group -->
<!ELEMENT aeg -- Analytical event group (multi-domain refs) --
- - %m.aes; >
<!ENTITY % a.ae "" >
<!ATTLIST aeg id ID #IMPLIED
%a.ae; >
<!-- 11.1.3 Analytical Event -->
<!ENTITY % m.ae "(%e.ae;|%e.ge;|%e.ve;)*" >
<!ELEMENT (%e.ae;) -- Analytical event --
- O %m.ae; >
<!ATTLIST (%e.ae;) id ID #IMPLIED
%a.ae; >
<!-- 11.1.4 References -->
<!ELEMENT aer -- Analytical event sequence reference --
- O EMPTY >
<!ENTITY % a.aer "" >
<!ATTLIST aer idr IDREF #REQUIRED -- ID of aes --
%a.aer; >
<!-- 12 Bibliographic Data -->
<!ENTITY % e.bib "title | author | date | issuer | descript | copr">
<!-- Explanation of bibliographic elements:
title Title of work, performance, score, or analysis
author Work: composer, librettist, computer
Performance: performer, arranger
Score: editor, copyist, arranger
Analysis: theorist
issuer Access information: e.g., publisher, catalog number
date Date of work, performance, score, or analysis
copr Copyright notice
descript Miscellaneous descriptive data: e.g., performance time -->
<!ENTITY % d.bib "<!ELEMENT (%e.bib;) - O (#PCDATA)>"> %d.bib;
<!ENTITY % m.bib "(%e.bib; | theme)*">
<!ELEMENT bibdata -- Bibliographic data applying to work as a whole --
- O %m.bib; >
June 16, 1988
- 39 -
<!-- 12.1 Theme -->
<!ENTITY % a.theme "">
<!ELEMENT theme -- Themes that best identify the work (e.g., incipit) --
- O EMPTY >
<!ATTLIST theme idr IDREFS #REQUIRED -- ID of analysis --
%a.theme; >
June 16, 1988
- 40 -
Annex B
Theory of Use
(This annex is informative and will not form an integral part of the Stan-
dard.)
As a language, the Standard can be put to a wide variety of uses ranging
>from the highly appropriate to the completely pathological. It was, how-
ever, designed with a particular set of applications in mind, and will be
most effective if used for these. Knowing the design assumptions will also
facilitate application of the Standard to unforeseen or unusual situations.
It is hoped that this annex will answer many of the questions that will
arise concerning applicability.
NOTE: This section will be developed further at a later date.
B.1 General Application
In general, the Standard is intended as a storage and interchange for-
mat for musical ideas. It is designed to be somewhat human readable so
that a piece could theoretically be created by using a word processor
and entering the encoded material directly. However, it is expected
that it will be used mainly for automated processing in such areas as
music printing, library cataloging and storage, multimedia presenta-
tions, teaching, and research. For other situations, such as live per-
formance or sound recording, other formats are likely to be more
applicable.
A piece to be represented can originate from almost any source. An
automated composition program might generate a core and an associated
gestural section. An interactive music printing system might generate
a core and a visual section. A sequencer might capture a live perfor-
mance and transcribe it into a core and performance section, and then
turn the piece over to a music printing system for the creation of the
visual and analytical sections. There is much flexibility in the way
the Standard can be used and the situations to which it can be
applied. The only common element is the core, the others need not even
be present.
The gestural section is designed to be used for the representation of
computer instrument sequences. This does not mean that it is a
sequencer format for internal use by sequencers. In fact it would be
poorly suited for that application. It is for archiving and transport-
ing music that has been, or will be, processed in some way by a com-
puter system. A performance may be captured on a synthesizer, it may
be interpreted from a MIDI stream, or it may be translated from
another language, such as a MIDI sequence file format or MUSIC V. A
sequencer might read a piece in the Standard, translate it into an
internal data format, and then realize it in real time.
The visual section will be used for representing scores of all kinds.
The score may have an accompanying performance or it may not. The
score may be entered or captured using a music printing system, or it
June 16, 1988
- 41 -
may be translated from DARMS or MUSTRAN. It might be retrieved as a
display on a screen, a printed page, or translated into another
language. Most importantly it will allow systems of all kinds to
interchange scores easily and accurately.
The analytical section will be used to represent theoretical ideas in
a structural format. Any sort of layering and grouping will be possi-
ble, so various styles of analysis will be supported. A given piece
may have several analyses (i.e. one Shenkerian, one classical), which
could even refer to each other. An analysis of a piece with a circular
score could refer to the score and the performance in an attempt to
relate the music to the shape of the score to the vertiginous effect
on the performer.
June 16, 1988
- 42 -
Annex C
Explanation of Editorial Conventions
(This annex is informative and will not form an integral part of the Stan-
dard.) This document observes some of the editorial conventions of a for-
mal standard, but not yet with the strictness and consistency that will be
required in the final document. Those conventions that are observed in this
revision are listed.
C.1 Definitions
Definitions are contained in a separate clause. Ours is presently
incomplete and will probably remain that way for a while. Also, some
of the definitions in it are not as precise as they should be. When
the clause is complete, the definitions will refer to one another in a
top-down hierarchical order, without tautologies, and will define each
term fully.
C.2 Structure
Part Two is structured like a standard in that it observes the follow-
ing conventions:
Clause 0 is an informative introduction (that is, it does not
contain requirements.)
Clause 1 states what the standard includes, and its expected
uses.
Clause 3 contains references to related standards.
Clause 4 contains the definitions.
Clause 5 describes the notational conventions used in the remain-
ing clauses.
The clauses from 6 until the end contain the actual requirements.
There are also annexes (appendixes) containing information that was
segregated from the body of the standard for convenience.
C.3 Segregation
Requirements are distinguished from definitions, examples, and expla-
natory notes and comments.
Anything identified as a "NOTE" is there to aid in understanding the
standard, but does not change the requirements. At present, we also
use notes to discuss matters relating to the development of the stan-
dard.
June 16, 1988
- 43 -
Annexes are designated either "normative" or "informative". The former
contain requirements and have the same force and effect as if they
were in the body of the standard. The latter are extended notes or
tutorial information.
C.4 Language
Some words have formal implications that may differ from casual usage.
Those that are used in this document are as follows:
C.4.1deprecated: Technically allowed, but only in rare situations
a sensible thing to do. The opposite of "should".
C.4.2must: Required by the language; unavoidable.
C.4.3shall: Required by definition. (But not necessarily unavoid-
able syntactically or semantically in the language.)
C.4.4should: Recommended, but not mandatory. The opposite of
"deprecated." (Within a requirement, it is used in place of
"shall" where there is some rare situation in which it wouldn't
work or where it was too burdensome to check for compliance.)
June 16, 1988
- 44 -
Annex D
Guide to SGML Notation
(This annex is informative and will not form an integral part of the Stan-
dard.)
For those unfamiliar with SGML, the following brief explanation will assist
in understanding the code that appears in this document. For a more in-
depth explanation, the ISO standard (ISO 8879-1986) is the definitive
tutorial and reference on the subject.
NOTE: This description is currently "brief" to the point of opacity. We
plan to expand this section at a later date.
D.1 Structure
SGML consists of three basic structural components. It is the usual
intent that these structures will contain data, but in our application
there is only structure for the moment. Elements are structural build-
ing blocks which can be defined to contain data or other elements. An
attribute list is associated with an element and contains values which
describe the element. Entities are a structural tool which allow por-
tions of code to be referenced by a label from one or more places in
the code.
D.2 Punctuation
There are several punctuation marks that are important. Declarations
(definitions) are surrounded by <! ... > and comments to the reader
are surrounded by -- ... --. For the purposes of this document, the
marks - - and -O can be ignored. In each declaration, the following
marks may occur: , this followed by the next, & this and the next, |
this or the next, ? optional, + one or more, * zero or more.
June 16, 1988
- 45 -
Annex E
Status Report
(This annex is informative and will not form an integral part of the Stan-
dard.)
In the first meetings, the committee concentrated on the overall structure
of the SMDL. Many issues were touched upon to ensure that the basic design
would be flexible and powerful enough to handle the wide range of material
demanded by the requirements specification.
More recently, the concentration has focused on the core and related
issues, as this seemed the logical starting place. Subsequent work will
have to build from a basically finished core section. As of the most recent
meeting (February 1 - 4, 1988) we have developed the core substantially,
although some work remains. We expect to finish this section at the next
meeting, and proceed to the gestural and visual sections. It is assumed
that further revisions of the core will be necessary after development of
the other sections.
Because the work has focused on a particular area, the preceding document
is uneven. Some areas have been discused down to minute detail, and some
are as yet merely suggestions of the direction in which to proceed. In par-
ticular the core section is considerably fleshed out, but the others are
unfinished. As the meetings continue, we expect this document (parts 1 and
2) to grow into a Draft Standard which will be complete in all areas.
%%% 30 %%%
June 16, 1988
Reference in New Issue View Git Blame Copy Permalink