home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-02-08 | 100.2 KB | 2,964 lines |
-
- 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
-