Standard Music Description Language (SMDL)
ISO/IEC DIS 10743


8 Logical domain (cantus)

The concept of the cantus is based on, and is entirely consistent with, the HyTime finite coordinate space (FCS) concept, and with those of its various HyTime-defined substructures and resources.

NOTE 15
To the HyTime FCS concept, SMDL adds one significant enhancement: stress templates (see Section 8.7).

The cantus architectural form represents the essential music information. It forms the common ground on which all of the performances, scores , and analyses are constructed. It contains the logical musical material as opposed tothe performance or score specific material.

8.1 Cantus (cantus)

Derived from the HyTime fcs architectural form, the SMDL cantus (cantus) architectural form represents a finite coordinate space with a single axis measured in virtual time.

The thread (see Section 8.3) and lyric (see Section 8.4) architectural forms in the content of the cantus architectural form are derived from the HyTime evsched architectural form. The abstract notes and rests of the music are represented in threads, and the lyrics, if any, in the lyrics. The elements conforming to the HyTime-defined baton architectural form (see Section 8.5) are used to describe and/or go vern the tempi of actual performances of the cantus. The elements conforming tothe HyTime-defined wand architectural form (see Section 8.6) are used to govern and/or describe the various ways in which instrumental and other sounds may be modified, muted, articulated, etc.

NOTE 16
The music time (virtual time) specifications found in a cantus are more abstract than the timing instructions given in a musical score written in common practice notation. The same cantus could, for example, be scored as sixteenth-note triplets in the context of a 4/8 time signature, oras unmodified eighth notes in the context of a 12/8 time signature. The cantus would not offer guidance as tothe which time signature should be used; it would only specify that a 4-beat stress pattern is in effect, and thateach of the notes has a duration ofone third of a beat.

It is interesting to note that common practice music notation has undergone a largely inexplicable centuries-long process sometimes called "metric notational inflation, " in which ordinary performance practice has been to play the same notevalue as a longerand longer real-time duration, while composers have been notating theirmusic using shorterand shorter note values. What was long ago called a minim-the shortest note -is now called a half-note, which is 128 times longer than the shor test notes Beethoven used; what used to be called a brevis (meaning "short") is now known as a "double whole note, " the longest notevalue used in common practice notation (and only rarely), and what used to be called a "longa" is never seen any more; it is too large to appearin a modern measure. All this tends to support the idea that an abstr act representation of music, such as is used in SMDL, may be particularly useful for archival purposes. Such a representation will be immune to changes in notational and performance practices.

The use of this International Standard does notensure that the cantus of a given piece must always be represented in some particular way. If desired, an algorithm can be applied which translates any arbitrary cantus into some canonical for m. The attribute normalization algorithm (norm) states which algorithm (if any) has been used to normalize the cantus. The user may create such an algorithm to fit the needs of the application. The normalization algorithm must be declared as an SGML NOTATION.

<!--Structure of the cantus -->
<!element cantus -O (thread | lyric | baton | wand)* >
<!attlist cantus
SMDL NAME cantus
--bibinfo attributes --
--authorty attributes --
norm
--Normalization according tothe named algorithm
(declared as a notation) has been applied. --
NOTATION #IMPLIED --Default: not normalized --
--HyTime fcs attributes --
id
ID #REQUIRED
fcsname
--Name of semantic FCS described by the element --
NAME #IMPLIED --Default: FCS is unnamed --
fcsmdu
--SMU to MDU ratiothat makes the MDU a common
denominatorof HMUs forall schedules on all axes
of FCS in a given measurement domain. Constraint:
SMU name and ratio for one ormore of the domains
used in the FCS. An SMU name can occur only once.
lextype((NAME,s+,frac),(s+,NAME,s+,fra c)*). --
CDATA #FIXED "" --Default: equal to docmdu --
axisdefs
--Definitions of FCS axes. Constraint: GIs of axis
element types. lextype(GIL).
--NAMES #FIXED virtime
>

8.2 Axis (axis)

The HyTime architectural form axis (axis) is used to specify that the one-dimensional finite coordinate space described by an SMDL cantus is measured invirtual time and occupies some number of virtual time units. (See the HyTime standard fordetails.)

NOTE 17
The calendar attribute of the HyTime axis architectural form is not used in most musical contexts. However, pieces do exist that are intended to be played (or that were played) at a particular date. If such pieces are represented in SMDL, they will need to use the HyTime calspec architectural form. Since calspec is used for such exceptional pieces exactly as it appears in HyTime, there is no need to describe it in the context of this International Standard. It is available to users of SMDL by virtue of the value of the ArcCopy attribute of the declar ation of the HyTime meta-DTD as an ENTITY in the SMDL meta-DTD (see Section 6.2.2).

NOTE 18
What follows is an example of how an axis might be declared in specific circumstances. The parameter entity %tactvtu; gives the number of virtual time units (VTUs) pertactus (beat). It should be an integer that would allowall named note values to be calculated without remainders. Thevalue giv en belowallows equal division of the beat into 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 14, 16, 18, 20, 21, 24, 25, 27, 28, 30, 32, etc. equal parts. It divides even alargotempo (mm=30 beats permin ute) into o ver 40,000 parts per second, each of which is of sufficiently short duration as to be imperceptible. Given this def ault value and the minimum h yqcnt value of 32 (i.e., 4,294,967,295 quanta), a given cantus's time axis will allow 53,261 beats. CCARH's 1991 issue of Computing in Musicology cites Don Byrd' s Guinness-esque "list of [music] notational records" as giving 1,154 measures as the longest movement. Assuming a generous 8 beats permeasure, we would need only 9,232 beats, giving a comfortable factor of 5 for expansion.

<!ENTITY % tactvtu "80640" >
The following parameter entity declarations could be used in
conjunction with the above %tactvtu; entity:
<!ENTITY % av.cxdm
--Could use this as thevalue of the axisdim
attribute of an axis measured in music time.
(Maximum possible value given hyqcnt=32.) --
"4294967295" >
<!ENTITY % av.cxbg
--Could use this as the value of the basegran
attribute of threads, batons, and wands. --
"vtu"
>
<!ENTITY % av.cxgh
--Could use this as thevalue of the gran2hmu
attribute of threads, batons, and wands. --
"1 1"
>
<!ENTITY % av.cxpg
--Could use this as thevalue of pls2gran
attribute of threads, batons, and wands. --
"1 %tactvtu;"
>
<!ENTITY % av.cxfm
--Could use this as thevalue of the docmdu
attribute (of work), the fcsmdu attribute (of cantus),
and/or the axismdu attribute (of axis). --
"virtime 1 1"
>

8.3 Thread (thread)

Derived from the HyTime evsched architectural form, the SMDL thread (thread) architectural form is a schedule of music events. The purpose of thread is to allow the cantus to be separated, in any fashion that may be convenient, into concurrent, overlapping, sequential, and/or disjunct streams and/or lists of notes and other events.

NOTE 19
For example, threads may be used to encapsulate misical parts and/or voices.

NOTE 20
As in HyTime event schedules, there is no requirement that the events in a cantus appearin the order in which they are intended to be rendered. However, it is often syntactically very convenient to do so, especially in music, and it is certainly normally advisable to do so, if only because to do otherwise would be counter-intuitive and contrary to longstanding musical tradition.

The entity &e.music; is alist of music event types. A musical note is represented by the event type pitched. A chord change of the kind typically notated by common chord symbols or thoroughbass is represented by a chordchg element. A musical rest is represented by the event type rest.

NOTE 21
As always in any application of an architecture it is possible to use a more constrained list of element types than the one given as the content of the %e.music; parameter entity. However, it should also be noted that the &e.music; parameter entity allows indefinite expansion of the number of event types, including all manner of multimedia event types, since the full generality of the HyTime event architectural form is available (see Section 8.3.3.5).

The attribute nominal instrument (nominst) specifies the kind of music performing resource (e.g., "1st violin" ) associated with the events in the thread.

NOTE 22 The remaining attributes are defined by the HyTime International Standard.

<!--Thread -->
<!entity % e.music
--musical events and event groups --
"tuplet | ces | pitched | rest | chordchg | event" >
<!element thread
--schedule of music events and event groups. --
W-O (%e.music;)*
>
<!attlist thread
SMDL NAME thread
--HyTime sched attributes --
axisord
--Orderof axes in schedule. Constraint: GIs of axis
element types. Omitted GI means all events in
schedule fully occupy the omitted axis.
lextype(GIL). --
CDATA #FIXED "" --Default: axisdefs in FCS --
apporder
--Orderof schedule elements is significant to the
application and must be preserved --
(order|disorder) order
sorted
--Representation of schedule elements is sorted by
order of position on axes of schedule --
(sorted|unsorted) unsorted
--HyTime schdmeas attributes --
basegran
--Base granule for each axis. lextype(words) --
CDATA #FIXED "" --Default: SMU for each. --
gran2hmu
--Granule to HMU ratio for each axis. Constraint: 1
ratio peraxis, or 1 forall. lextype(fracs). --
NUMBERS #FIXED "1 1" --HyTime overrun attributes --
overrun
--Handling of dimension that overruns range --
(error|wrap|trunc|ignore) error
--HyTime pls2gran attributes --
pls2gran
--Pulse to granule ratio for each axis. Constraint: 1
ratio peraxis, or 1 forall. lextype(fracs) --
NUMBERS "1 1"
nominst
--nominal instrument(s) or other performing
resource(s) allocated to this thread. --
CDATA #IMPLIED --Default: not specified. --
>

8.3.1 Tuplet (tuplet)

Derived from the HyTime evgrp architectural form, the SMDL tuplet architectural form is used to represent non-duple (or, in certain compound meter contexts, non-triple) subdivisions of vir tual time duration. In all events after the syntactically first event, it is an RSE if the first marker is explicitly specified.

NOTE 23
The use of HyTime evgrps is fully described in the HyTime International Standard.

<!--Tuplet -->
<!element tuplet
-O (%e.music;)
>
<!attlist tuplet
SMDL NAME tuplet
id ID #IMPLIED --Default: none --
grpscope
--Group scope (nominal extent of group). For each
axis, the dimension is the lowest first quantum of
any group member through the highest last quantum
of any group memberon that axis. All of a
member's extents are included. reftype(extent). --
IDREF #IMPLIED --Default: to be calculated --
grpdex
--Group derived extent specification. Use for
resizing, rearrangement, repetition. Group members
are given the derived extents. If nominal extent
is also wanted, it must be specified as one of the
derived extents. Constraint: multiple references
concatenated. reftype(extlist). --
IDREFS #IMPLIED --Default: no derivation --
--pls2gran attributes --
pls2gran
--Pulse to granule ratio for each axis. Constraint:
1 ratio peraxis, or 1 forall. lextype(fracs). --
NUMBERS "1 1"
>

8.3.2 cantus event sequence (ces)

The SMDL ces architectural form is used to associate certain special semantics with arbitrary groups of syntactically sequential music events.

NOTE 24
"Syntactically sequential" does necessarily not mean "sequentially scheduled. " The starting quantum of an event is determined by its extent specification, which may, if the first marker is defaulted (i.e., not explicitly specified), be determined by the event's syntactic position (i.e., it will begin after the end of the preceding event). If the first markeris specified, however, the event's syntactic position has no effect on its scheduled extent.

NOTE 25
The musical concept of chord, characterizable as a phenomenon in which several notes have the same start time and often share the same performing resource, is represented in SMDL by means of a ces in which all the events it contains have the same nominal start time.

The attribute ornamentation style (ornstyle) is used to indicate the style(s) of ornamentation perhaps by naming a historical period (e .g. "late Baroque"), performance styles (e.g. "double-dotted French overture", "Mississippi delta", "Hank Williams", "south Indian classical"), etc.

The attribute pitch gamut (pitchgam) specifies which pitch gamut will be used to look up pitch names. The gamut selected will remain in effect until another occurrence of this attribute.

The attribute musica ficta gamut (fictagam) specifies which misica ficta gamut will be used to look up gamut step adjustments to be applied to pitch names. The music ficta gamut selected will remain in effect until another occurrence of this attribute.

The attribute microtuning unit definition (mudef) identifies the definition that will apply when a quantity of microtuning units is specified. The definition selected will remain in use until another occurrence of this attribute.

The attribute divisi (divisi) indicates whether simultaneous notes, if any, should be allocated among the available performing resources, or whether all simultaneous notes should be play ed by all available performing resources.

The attribute arpeggio (arpeggio) indicates whether any events scheduled to occur simultaneously with the earliest-scheduled event should be arpeggiated, and, if so, whether they should be arpeggiated so that the lowest pitch is played first (rollup) orlast (rolldown).

The attribute grace (grace) indicates whether or not these notes are grace notes.

NOTE 26
If the notes are grace notes , they may be rendered differently from the other notes in a score, often at a smaller point size.

The attribute choice (choice) is used to indicate whether all of the sub elements should be performed, or just one of them.

NOTE 27
An ossia is represented by an event group with a choice of "one. " An application could adopt a convention that the first element in the group is the preferred choice.

The attribute choice criteria (choicrit) supplies information that might be useful to a performer making the choice. The value of this attribute is ignored unless the value of the choice attribute is one.

NOTE 28
For example, "Play the first choice the first time, and the second choice the second time.".

The conloc attribute can be used, for example, to allow passages to be repeated with somevariation without recopying their entire contents. (See the HyTime International Standard for details.)

The attribute repeats (repeats) gives the number of times the passage should be repeated. If the value is "1", there are no repeats. If thevalue is greater than 1, each repeat will begin on the quantum immediately following the last quantum occupied by any event during the previous cycle. The events occupying the earliest occupied quantum of the ces also form the beginning of each repeat, and, during any repeat cycle, the start-times and end-times of all events bear the same numerical quantum relation-ships to each other that they had in the first cycle.

NOTE 29
In other words, even where absolute addressing was used to establish the dimensions of events during the first cycle, all dimensions of all events will be relative to each other, and bear the same numerical quantum differences between each other, in all repeat cycles. Among the many possible uses for cess whose repeat attribute's value is greater than 1 is to notate Alberti bass passages compactly.

<!-- cantus Event Sequence -->
<!element ces
-O (%e.music;)
>
<!attlist ces
SMDL NAME ces
id ID #IMPLIED --Default: none --
ornstyle
--Ornamentation style: e.g., period --
CDATA #IMPLIED
pitchgam
--Current pitch gamut --
IDREF #IMPLIED
--Default: value of syntactically previous pitchgam attribute. --
fictagam
--current ficta gamut --
IDREF #IMPLIED
--Default: value of syntactically previous fictagam attribute. --
mudef
--governing microtuning unit definition --
IDREF #IMPLIED
--Default: value of syntactically previous mudef attribute. --
divisi
--either allocate simultaneous notes among performing
resources, ormake everybody play everything. --
(tutti|divisi) tutti --default: everybody plays everything --
arpeggio
--Either arpeggiate or don't arpeggiate. Applies
only tothe onset of the events scheduled to start
together, and only when that starting time is the
earliest scheduled start time in the entire ces. --
(rollup|rolldown|noroll) noroll
--default: no arpeggiation. --
grace
--are the contained events grace notes? --
(grace|nograce) nograce
--default: these are not grace notes --
choice
--Is only one subelement, chosen by the performer, to
be played at any one time, orare all of them to be
played? (attribute for handling ossia, 1st/2nd
ending, etc. --
(all|one) all
choicrit
--Criteria by which choice should be made. --
CDATA #IMPLIED
--default: no choice needs to be made (choice=all) --
conloc
--ID of schedule, evgrp, or event to be used in place
of, oras content of, this element
(see HyTime International Standard). --
IDREF #CONREF
repeats
--Numberof repetitions beginning at end of last
quantum occupied. lextype(unzi). --
CDATA 1
>

8.3.3 Music Event Types (rest, pitched, chordchg)

8.3.3.1 %a.event; parameter entity

The parameter entity %a.event; defines the attributes used in both pitched events and in rests. All of these attributes are fully defined in the HyTime International Standard.

<!entity % a.event "
--HyTime event attributes --
id ID #IMPLIED --Default: none --
exrecon
--Extent reconciliation rule ifobject won't fit.
reftype(exrecon) --
IDREF #IMPLIED --Default: none --
--HyTime exspec attributes --
exspec
--Extent specification. Constraint: multiple
references concatenated. reftype(extlist). --
IDREFS #REQUIRED
--HyTime pls2gran attributes --
pls2gran
--Pulse to granule ratio for each axis. Constraint:
1 ratio peraxis, or 1 forall. lextype(fracs) --
NUMBERS "1 1"
--HyTime conloc attribute --
conloc
IDREF #CONREF --Default: in content --
">

8.3.3.2 Rest Event (rest)

The architectural form rest (rest) is an imperceivable event. It has duration in music time, but it has no content whatsoever.

NOTE 30
In fact, there is no difference between a rest event occupying some quanta and simply having no event occupying the same quanta. If, howev er, HyTime's first marker defaulting mechanism is used, rests are useful as place holders, so that the first marker of the succeeding event can be defaulted to the quantum immediately after the last quantum of the rest.

<!--Rest -->
<!element rest
--Imperceivable music event --
-O ( extlist?)
>
<!attlist rest
SMDL NAME rest
%a.event;
>

8.3.3.3 Pitched Note Event (pitched)

The architectural form pitched note event (pitched) specifies the duration and pitch of a musical note.

NOTE 31
pitched is the normal way to represent a musical note in SMDL.

The nompitch-form element (see Section 8.8.1) in the content of a pitched-form element is the means whereby pitched events gain access to virtually all of the musical pitch specification apparatus of SMDL (see Section 8.8).

The architectural form variation (vary) specifies a variation of the pitch, such as a vibrato or portamento, which can occur before, during, and/or afterthe nominal pitch. The variation is given as a formula.

The attribute detune value (detune) specifies how far "out of tune" the pitch should be played. The value is given in microtuning units (see Section 8.8.4).

NOTE 32
Detuning and/or variation need not be distinguished from the nominal pitch when it is not convenient or sensible to do so. In many cases, these alterations are more usefully dealt with as part of the timbre of an instrument, or as inherent properties of the nominal pitch, as in some computer music. In the latter case, the formula for the event type would account for any detuning or variation.

The tie (tie) attribute specifies the successor event to which this event is tied. It is an RSE if the first quantum occupied by the successor event is not immediately adjacent tothe last quantum occupied by this event. The purpose of tie is to indicate that the successor event is to be perceived as the continuation of the currentevent.

NOTE 33
The exact method by which the successor event is to be made to be "perceived as the continuation of the current event" is not specified. However, it seems reasonable to expect that the on set articulation of the succeeding event should not be rendered, orat least be made as imperceivable as possible.

<!--Note Event -->
<!element pitched
--A musically-pitched note. Used in: %e.music; --
-O (extlist?, nompitch, vary?)
>
<!attlist pitched
SMDL NAME pitched
--HyTime: event --
%a.event;
detune
--Signed number of MUs to add or subtract. Default
play in tune (0). lextype(snum). --
NMTOKEN 0
tie
--Immediate successor to which this event is tied--
IDREF #IMPLIED --Default: not tied --
>
<!element vary
--Variation in pitch value of note, expressed as a formula. --
O O (#PCDATA)
>
<!attlist vary
SMDL NAME vary notation
--Data content notation. (Actual notation names are
application-specific). (attribute defined by HyTime) --
NOTATION #REQUIRED
conloc
--Formula source (if not in content).
--IDREF #CONREF
>

8.3.3.4 Chord change

A chord change is a specification of a sonority in terms of its intervallic structure (as opposed to actual simultaneous notes, which would be represented by a cantus event group.) It is normally used in works that require (or permit) improvisation. Its pur pose is to conve y a harmonic environment ratherthan the presence of particularnotes.

In SMDL, chord changes are event types. There are two kinds: common chord symbols (see Section 8.8.5.3) and figured bass (thoroughbass) (see Section 8.8.5.4). Both include a reference pitch (the root or bass) and a chord body consisting of a set of intervals, but there are some differences between the two stemming from their normal application: common chord symbols are normally used in popular music and jazz, while figured bass is used chiefly in Baroque music. The visual representation of a common chord symbol is usually an alphameric name (like C7), while that of figured bass is (as its name implies) a series of numbers that represent intervals from the bass pitch.

(For an explanation of the tie and detune attributes, see Section 8.3.3.3.)

<!--Chord Change Event --
> <!element chordchg
--Chord change event --
-O ( extlist?, ( ccschord | figbass)?)?
> <!attlist chordchg
SMDL NAME chordchg
%a.event;
detune
--Signed numberof MUs to add or subtract. Default:
play in tune (0). lextype(snum). --
NMTOKEN 0
tie
--Immediate successortowhich this event is tied--
IDREF #IMPLIED --Default: not tied --
>

8.3.3.5 Event (event)

The HyTime event architectural form should be used to schedule anything that needs to be scheduled in terms of music, or in the context of music. The value of the SMDL attribute should be event, and there need not be a HyTime attribute. See the HyTime International Standard for details.

8.4 Lyric (lyric)

The architectural form lyric (lyric) is a time-based sequence of syllables that are sung to the music of a thread. The dimension specifications of the lyric events ("sung syllable events") are specified with dimension references to express the synchronization with the thread events.

The attribute thread (thread) identifies the thread to which this lyric is to be sung.

<!--Lyric -->
<!element lyric
--Time-ordered sequence of sung syllables.
Synchronized with a thread. --
-O ( syllable | rest)+
>
<!attlist lyric
SMDL NAME lyric
thread
--Notes towhich lyric is sung --
IDREF #REQUIRED
--HyTime sched attributes --
axisord
--Order of axes in schedule. Constraint: GIs of axis
element types. Omitted GI means all events in
schedule fully occupy the omitted axis.
lextype(GIL). --
CDATA #FIXED "" --Default: axisdefs in FCS --
apporder
--Orderof schedule elements is significant to the
application and must be preserved --
(order|disorder) order
sorted
--Representation of schedule elements is sorted by
order of position on axes of schedule --
(sorted|unsorted) unsorted
--HyTime schdmeas attributes --
basegran
--Base granule for each axis. lextype(words) --
CDATA #FIXED "" --Default: SMU for each. --
gran2hmu
--Granule to HMU ratio for each axis. Constraint: 1
ratio peraxis, or 1 forall. lextype(fracs). --
NUMBERS #FIXED "1 1"
--HyTime overrun attributes --
overrun
--Handling of dimension that overruns range --
(error|wrap|trunc|ignore) error
--HyTime pls2gran attributes --
pls2gran
--Pulse to granule ratio for each axis. Constraint: 1
ratio peraxis, or 1 forall. lextype(fracs) --
NUMBERS "1 1"
>

8.4.1 Sung syllable (syllable)

The architectural form sung syllable (syllable) is an event, containing a charactertext object, whose duration is specified by a dimension reference to the corresponding thread event towhich the syllable is sung.

NOTE 34
A single syllable element could comprise more than one actual text syllable, as when it is necessary to sing multiple syllables to a single note.

<!--Sung Syllable -->
<!element syllable
--Sung syllable --
-O ( extlist?, sylltext?)?
>
<!attlist syllable
SMDL NAME syllable
%a.event;
>

8.4.2 Syllable text (sylltext)

The architectural form syllable text (sylltext) is a character text object that occurs in a sung syllable event.

<!element sylltext
--Syllable text --
-O ( #PCDATA)
>
<!attlist sylltext
SMDL NAME sylltext
>

8.5 Baton (baton)

The HyTime baton architectural form is used in SMDL primarily to go vern the "projection" ofevents from a cantus on to another finite coordinate space. In SMDL, the target finite coordinate space is gen-erally measured in real time. (See the HyTime International Standard for more information about the baton architectural form.)

8.6 Wand (wand)

The HyTime wand architectural form is used in SMDL primarily to govern the application of sound modification techniques to the sound output of musical instruments, etc.

NOTE 35
Articulations, mutes, modulations, filters, etc. are examples of modifications that can be applied.

(See the HyTime International Standard for more information about the wand architectur al form.)

8.7 Metric Stress Pattern

The concepts of meter, measure, "swing, " etc. are all represented in SMDL by stress templates. A stress template defines one cycle of a repeated pattern of stresses, and it can be applied to any number and combination of cantus event sequences.

NOTE 36
For example, a passage in 4/4 time may refer to a template with 4 points, and may mark the first as having max-imum stress and the third as ha ving 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 patterns can be used to accurately indicate the feel. (This situation can also be handled using nested event sequences.) If ambiguity is desired however, the measure can be represented as simply five beats.

NOTE 37
The inclusion of meter in the logical domain reflects a conviction that measures referto a basic logical concept in a significant portion of all music, and that they are not merely a matter forthe visual domain.

8.7.1 Stress pattern template

The stress pattern template (stresstem) represents a single stress pattern which can be applied to cantus event sequences of any length, and which can represent any number of MDUs. The stress pattern contains pairs of elements that relate positions in the pattern to lists of stress information for each position. The positions are listed in ascending order, but the set of defined positions can be incomplete.

These positions are specified in terms of points, rather thanvTUs. The relationship of points to VTUs is determined when the template is used, not when it is defined, thus making the template scalable. When the pattern is associated with a cantus event sequence, the relationship betweenvTUs in the sequence and positions in the pattern (points) is specified. This allows one pattern to be used in several different situations, each having a different duration onto which the pattern is mapped.

The attribute point count (pointcnt) specifies the number of positions in the pattern. These positions are evenly distributed o verthe total time occupied by the pattern.

<!--Stress Pattern Template -->
<!element strestem
--Beat cycle definition; dynamic stress pattern.
Pointnums in ascending order. --
-O (pointnum, stresval*)*
> <!attlist strestem
SMDL NAME strestem
id ID #IMPLIED
pointcnt
--Numberof stress points in pattern. --
NUMBER #REQUIRED
>

8.7.1.1 Stress point number

The architectural form stress point number (pointnum) contains an integer in the range from 1 to the pointcnt value. It simply specifies the position in the stress pattern at which the related stress information will be applied.

<!--Stress Point Number -->
<!element pointnum
--Stress point receiving agogic ordynamic stresses.
Integer from 1 to pointcnt --
O O (#PCDATA)
> <!attlist pointnum
SMDL NAME pointnum
>

8.7.1.2 Stress typevalues

The architectural form stress type values (stresval) contains a list of stresses and other modifications to be applied to the events in an event sequence . Alternatively, it can express a relationship to the next level inward in a structure of nested stress patterns.

NOTE 38
The ability to nest stress patterns provides a way to specify complex metric situations.

The attribute stress template use (stresuse) identifies a stress pattern use element that associates a nested stress pattern with the current point number of the current template.

The architectural form stress value text (strestxt) specifies an imprecise stress specification as a character string.

<!--Stress Typevalues -->
<!element stresval
--Stresses applied to specified stress point --
-O (strestxt?, formula?)
>
<!attlist stresval
SMDL NAME stresval
stresuse
--ID of stresuse fornested stress pattern. --
IDREF #CONREF --Default: no nested pattern. --
>
<!element strestxt
--Imprecise stress specification: loud, downbeat --
-O (#PCDATA)
>
<!attlist strestxt
SMDL NAME strestxt
>

8.7.2 Stress pattern use

The architectural form stress pattern use (stresuse) relates a particular stress pattern to a tempo directive in a baton or to a stress typevalue in an outer stress pattern in which this one is nested. If the content of the element is a music time duration, the relation is to a tempo directive; if it is a stress pattern duration, the relation is to an outer stress pattern. If the content is empty , the relation is to a tempo directive and the pattern is mapped o ver the entire duration of the tempo directive.

The stress pattern to be used is referenced by the idr attribute. In a tempo directive, this pattern will remain in effect until changed by another occurrence of a stress pattern use element. To turn off the current stress pattern without starting another, define an empty stress pattern template (one with no con-tent) and reference it.

The content of this element is a dimension specification which specifies the time into which one cycle of the pattern will be mapped. Note that this duration is specified in VTUs (directly or indirectly) for a tempo directive.

NOTE 39
For example, if the pattern is specifying a measure of 4/4 time, and the VTU of the music falls on the quarter note, the stresuse duration will be 4 VTUs. The duration of the music to which this pattern applies will usually be much longer than the pattern duration, so the pattern will be repeated.

The architectural form stress pattern duration (stresdur) specifies the number of points in the outer pattern into which one cycle of this pattern will be mapped.

The attribute stress point (strespt) specifies the position in the pattern (in points) at which to start. In other words, the offset to the pick-up portion of the pattern. This will normally be 1 (the beginning), but may be offset in certain special circumstances, such as an anacrusis.

<!--Stress Pattern Use -->
<!element stresuse
--Use of stress pattern in tempo or outer stress
pattern. Default: entire tempo of tempo directive. --
-O (dimspec | stresdur)?
>
<!attlist stresuse
SMDL NAME stresuse
id ID #REQUIRED
idr
--ID of stress pattern --
IDREF #REQUIRED
strespt
--Stress pt # of pattern on which use begins. Not 1 only
if anacrusis. --
NUMBER 1
>
<!element stresdur
--Duration of one iteration of nested stress pattern.
Format: NUMBERof points. --
-O (#PCDATA)
>
<!attlist stresdur
SMDL NAME stresdur
>

8.8 Pitch Model

The pitch of a note can be specified directly as a frequency, by an expression in a user-defined notation (such as a computer music note list), as an interval from some reference pitch, or as a named pitch that is defined in a pitch gamut.

In an SMDL pitch gamut, pitch names can be associated with frequencies but are manipulated independently of them. This technique allows a gamut to be treated as an equal-tempered gamut for purposes of modulation regardless of how it is actually tuned. The technique also permits uniform application of gamut-based intervals, eitheralone or in chord changes. A gamut can be defined with no frequencies associated with the pitch names, with generated equal-tempered frequencies, with specified arbitrary frequencies, or with any combination of the above (e.g., an equal-tempered gamut with one or more pitch classes detuned).

A gamut contains a number of "gamut steps" (analogous to pitch classes), and an equal or lesser number of "name step groups" (analogous to white keys on a piano). One or more "pitch names" can be as-signed to each gamut step, in either the same "name step group" (e.g., "C" and "DO") or different name step groups (e.g., "C#" and "Db"). Unnamed "gamut steps" (called "musica ficta" in SMDL for purely historical reasons) can be determined via a pitch name and a "gamut step distance" (e.g., C# can be referenced as C with a gamut step distance of +1). The pitch definition associated with such a reference (which may be needed to determine the frequency) can be found as follows:

Gamut steps (both named and unnamed) can also be referenced by an interval from a reference gamut pitch name. Such a reference includes both a name step distance and a gamut step distance. The tar-get pitch name is found as follows:

All of the interval arithmetic is modulo the highest step number (name step or gamut step) in the gamut definition. "Wrapping the gamut" in this way requires raising (or lowering) the frequency of the pitch by an "octave ratio" defined for the gamut.

NOTE 40
Although a pitch gamut can represent a conventional equal-tempered scale in a straightforward way, it is highly generalized, and it can represent arbitrary (even bizarre) pitch systems. This flexibility is because of the following properties:

8.8.1 Nominal pitch (nompitch)

The architectural form nominal pitch (nompitch) specifies the basic pitch (before detuning). It contains no actual information; it is a structural handle which selects one of three ways of specifying pitch: as a selection from a gamut; as an explicit frequency; or as a just intonation pitch (relative pitch). The nompitch form is used only in the content of a pitched note event (see Section 8.3.3.3).

<!--Nominal Pitch -->
<!element nompitch O O ( gampitch | freqspec | jipit) >
<!attlist nompitch SMDL NAME nompitch >

8.8.1.1 Gamut-based pitch (gampitch)

The gamut-based pitch (gampitch) architectural form specifies a pitch by reference to the pitch gamut currently in effect. The pitch is looked up by name, and then may be modified by an optional octave and accidental.

<!--Gamut-based Pitch -->
<!element gampitch
--Named pitch from gamut definition --
O O (octave?, pitchnm, fictadj?)
>
<!attlist gampitch
SMDL NAME gampitch
>

8.8.1.1.1 Octave offset (octave)

The architectural form octave offset (octave) specifies the octave of a named pitch as a signed integer offset from the octave of its gamut. The frequency (if any) of the pitch is multiplied by the octave ratio raised to power of the octave offset. An octave offset of zero refers to the octave of the gamut.

<!--Octave Offset -->
<!element octave
--Octave offset from named pitch. Signed integer: 0
means pitch is in definition octave. Default: no
change from octave of syntactically previous pitch.
lextype( snum). --
O O (#PCDATA)
>
<!attlist octave
SMDL NAME octave
>

8.8.1.1.2 Fictum adjustment (fictadj)

The architectural form fictum adjustment (fictadj) specifies the accidental of a pitch as an offset in gamut steps from the named pitch, as modified by any applicable fictagam.

<!--Fictum Adjustment -->
<!element fictadj
--Fictum (#/b) adjustment from pitchnm: signed
integer. Default: no adjustment. --
O O (gamintvl)
>
<!attlist fictadj
SMDL NAME fictadj
>

8.8.1.2 Frequency specification (freqspec)

The architectural form frequency specification (freqspec) specifies an unnamed pitch as either an exact frequency in Hertz, or as a formula.

The architectural form absolute frequency (hertz) specifies an exact frequency in Hertz.

<!--Frequency Specification -->
<!element freqspec
--Frequency specification --
O O (hertz | formula)
>
<!attlist freqspec
SMDL NAME freqspec
>
<!element hertz
--Absolute frequency in Hertz (decimal fraction). --
O O (#PCDATA)
>
<!attlist hertz
SMDL NAME hertz
>

8.8.2 Pitch gamut definition (pitchgam)

The architectural form pitch gamut definition (pitchgam) establishes a lookup table that maps pitch names to frequencies, and establishes the intervalic relationship between the pitch names. Typically, a pitch gamut represents a scale.

In particular, a pitch gamut is a set of pitch definitions that each associate a pitch name with a name step, a gamut step, and a frequency . It is the name step and gamut step that represent the intervalic relationships between the pitches.

The ordering of the name steps is represented by the orderin which "name step group" elements appear in the pitch gamut. Every pitch definition must occur within one of these groups, which thereby associates each pitch name with a name step.

The ordering of the gamut steps is represented by numbering them explicitly. A pitch name is associated with a gamut step by including a "gamut step number" explicitly in its pitch definition.

The attribute gamut description (gamutdes) is an arbitrary text field that can be used for identification.

The attribute highest gamut step (highstep) specifies the highest gamut step number in the gamut. If not specified, it is the highest gamut step number occurring in any pitch definition in the gamut.

NOTE 41
In other words, not every gamut step number need occur in a pitch definition. Or, to put it another way , gamut steps can be unnamed. These unnamed steps correspond exactly to the "musica ficta" (accidentals) of the conventional diatonic/chromatic scale.

This attribute has two purposes:

NOTE 42
In the conventional equal-tempered scale, there are twelve gamut steps, numbered 0 to 11, so the value of high-step is 11.

The attribute octave ratio (octratio) defines a factor that is used in calculating the frequency of a named pitch when an octave offset is specified for it (that is, when it occurs in an octave other than that of the gamut). It is also used when generating a frequency base f or the gamut. The conventional equal-tempered scale uses an octave ratio of 2 (the next note of the same name is twice the frequency.)

NOTE 43
There is no indication of the "absolute" octave number of a gamut (other than by implication from any frequencies that may be defined in it).

<!--Pitch Gamut Definition -->
<!element pitchgam
--Pitch gamut definition. If genfreq is omitted, no
default frequencies are generated. --
-O (genfreq?, namestep+)
>
<!entity % FRAC "NUMBERS" --fraction: numerator, denominator? (=1) -->
<!attlist pitchgam
SMDL NAME pitchgam
id ID #REQUIRED
gamutdes
--Description of gamut. --
CDATA #IMPLIED --Default: undescribed. --
highstep
--Highest gamut step number: positive integer. --
NUMBER #IMPLIED --Default: highest gamstep. --
octratio
--Octave ratio ("1 1" = no octaves) --
%FRAC; "2 1" --Default: normal octaves. --
>

8.8.2.1 Generated frequency base (genfreq)

The presence of the architectural form generated frequency base (genfreq) indicates that the gamut will automatically generate default equal-tempered frequencies. This means that no frequency in the gamut need be explicitly listed; those omitted will be derived mathematically. If the frequency is stated explicitly, the self-generated frequency will be overridden.

The element contains a particular gamut step and its frequency specification. This is the base around which all others are calculated. The formula for an equal-tempered scale is:

Pitch[n+1] = Pitch[n] * ((highstep+1) root of (octave ratio))
<!--Generated Frequency Base -->
<!element genfreq
--Generated frequency base --
O O (gamstep, freqspec)
>
<!attlist genfreq
SMDL NAME genfreq
>

8.8.2.2 Name step group (namestep)

The architectural form name step group (namestep) contains the pitch definitions forall pitches associated with the same name step.

NOTE 44
Typically, their pitch names will reflect this relationship; for example , C, C flat, C shar p, and C double sharp.

The name step groups can be thought of as the logical concept behind scale steps, white k e ys, orlines and spaces in the staff . In conventional music there will be 7 pitch name groups in the gamut.

If more than one gamut step occurs in the set of pitch definitions comprising a name step group, the one in the first pitch definition of the group is considered the unaltered form of the name step.

<!--Name Step Group -->
<!element namestep
--Name step group: pitches based on same name
(C, C#, C##). In conventional music: 7
namesteps (letternames A-G) --
-O (pitchdef+)
>
<!attlist namestep
SMDL NAME namestep
>

8.8.2.3 Pitch definition (pitchdef)

The architectural form pitch definition (pitchdef) relates a pitch name to a specific chromatic posi-tion in the gamut (gamut step) and an optional frequency. The frequency can be specified explicitly, or by reference to another pitch in the gamut and a ratio.

If the frequency is specified, any automatically generated frequency is overridden. For imprecise tunings, specify the pitch name only (e.g., "high", "medium" and "low" pitches for percussion instruments).

The architectural form gamut step (gamstep) specifies the chromatic position in the gamut of this pitch name. Conventional music will use 12 gamut steps per octave. (This is equivalent tothe Forte analysis pitch class.)

For a simple gamut (i.e., one with no musica ficta), the gamut step can be omitted. Simple gamuts can be used forvar iant tunings, just intonation tonal centers, tuning systems that do not require modulation, etc. If the gamut step is omitted, it is assumed to be one greaterthan the previous pitch definition, or z ero forthe first. The architectural form relative frequency (relfreq) specifies a frequency by reference to another pitch in the gamut. The resultant frequency is the referenced frequency times the integer ratio.

NOTE 45
SMDL does not prohibit circular definitions. Applications are responsible for avoiding inconsistencies.

<!--Pitch Definition -->
<!element pitchdef
--Pitch definition (memberof a pitch gamut).
If gamstep omitted: next sequential (0 if
first). Freqspec overrides generated
frequency for gamstep. --
-O ( pitchnm, gamstep?, (freqspec | relfreq)?)
>
<!attlist pitchdef
SMDL NAME pitchdef
>
<!element gamstep
--Gamut step: Non-negative integer (>= 0).
Conventional music: 12 gamut steps
(chromatic scale). --
O O ( #PCDATA)
>
<!attlist gamstep
SMDL NAME gamstep
>
<!element relfreq
--Relative frequency with respect to another
pitch. --
-O (pitchnm, iratio)
>
<!attlist relfreq
SMDL NAME relfreq
>

8.8.2.3.1 Pitch name (pitchnm)

The architectural form pitch name (pitchnm) holds the name of the pitch (typically a letter like 'C'). The information in the gamut is key ed by this name. If the pitch name is an empty string, the pitch is musica ficta (unnamed).

<!--Pitch Name -->
<!element pitchnm
-- Name of pitch in a gamut --
O O (#PCDATA)
>
<!attlist pitchnum
SMDL NAME pitchnum
>

8.8.2.4 Musica ficta gamut (fictagam)

The architectural form musica ficta gamut (fictagam) specifies a list of pitch names paired with fictum adjustments (accidentals). The gamstep of a specified pitch is implicitly offset by the given number of gamut steps, in addition to any explicit fictum adjustment that may be specified. This element has the logical function of a key signature.

When this gamut is current, the pitch offsets will be applied tothe current pitch gamut. If there is no pitch gamut, orif a pitch does not ref erence the pitch gamut, then this gamut will ha ve no effect.

<!--Musica Ficta Gamut-->
<!element fictagam
--Musica ficta gamut definition. --
-O (pitchnm, fictadj)+
>
<!attlist fictagam
SMDL NAME fictagam
>

8.8.3 Interval (interval)

The architectural form interval (interval) specifies a scale difference between two pitches ("gamintvl") ora frequency ratio ("arbintvl" and "jipit").

The interval can be specified in three diff erent ways, depending on the requirements of the music: as a scale interval (such as a "minorthird"), as an arbitrary interval (eitheras a difference in gamut steps or as a frequency ratio), or as the ratio of two just intonation pitches. The scale interval is called a "gamut-based interval" because it is meaningful only in the context of some pitch gamut.

<!--Interval -->
<!element interval
--Scale difference or frequency ratio of two pitches. --
O O (gamintvl | arbintvl | jipitint)
>
<!attlist interval
SMDL NAME interval
>

8.8.3.1 Gamut-based interval (gamintvl)

The architectural form gamut-based interval (gamintvl) specifies a scale interval. It consists of a di-atonic step value and a chromatic step value. (There is no restriction that these step sizes be those of conventional, equal-tempered music.)

NOTE 46
Both of these values are necessary in order to distinguish between enharmonically equivalent intervals such as "minor third" and "augmented second. "

NOTE 47

<!--Gamut-based Interval -->
<!element gamintvl
--Gamut-based interval: number of name steps and gamut steps
between two gamut pitch definitions --
O O (nsdist, gsdist)
>
<!attlist gamintvl
SMDL NAME gamintvl
>

8.8.3.1.1 Name step distance (nsdist)

The architectural form name step distance (nsdist) specifies the difference in position of two name step groups in a pitch gamut definition.

<!--Name Step Distance -->
<!element nsdist
--Name step distance. lextype( snum). --
O O (#PCDATA)
>
<!attlist nsdist
SMDL NAME nsdist
>

8.8.3.1.2 Gamut-step distance (gsdist)

The architectural form gamut step distance (gsdist) specifies the difference in position of two gamut steps in a pitch gamut definition.

<!--Gamut Step Distance -->
<!element gsdist
--Gamut step distance. lextype( snum). --
O O (#PCDATA)
>
<!attlist gsdist
SMDL NAME gsdist
>

8.8.3.2 Arbitrary interval (arbintvl)

The architectural form arbitrary interval (arbintvl) specifies a simple interval from a reference pitch in the conventional musical sense. It can be specified as a chromatic step value (there is no restriction that these step siz es be those of conv entional, equal tempered music), an integer ratio , or an arbitrary formula.

To determine the resultant pitch:

The architectural form integer ratio (iratio) specifies an integer ratio as two integers (numerator and denominator).

<!--Arbitrary Interval -->
<!element arbintvl
--Arbitrary interval --
O O (gsdist | iratio | formula)
>
<!attlist arbintvl
SMDL NAME arbintvl
>
<!element iratio
--Integer ratio interval. lextype( snzi, s+, snzi); --
O O (#PCDATA)
>
<!attlist iratio
SMDL NAME iratio
>

8.8.4 Microtuning unit definition (mudef)

The architectural form microtuning unit definition (mudef) specifies the basic (smallest) unit of pitch used to specify a detuning. It can be set to cents, orto a fineror coarser value as necessary. The value is specified as a division of an arbitrary interval.

The attribute microtuning unit count (mucount) specifies the size of the division of the interval.

To determine the interval size of one microtuning unit, divide the base interval (as specified by the microtuning unit definition) by the microtuning unit count.

<!element mudef
--Microtuning unit definition --
-O (interval)
>
<!attlist mudef
id ID #REQUIRED
mucount
--Numberof MUs in the interval --
NUMBER #REQUIRED
>
<!attlist mudef
SMDL NAME mudef
>

8.8.5 Just intonation

Just intonation is the use of intervals which are describable as ratios of small integers, as opposed to the mathematically complex equal-tempered intervals found in most music.

Just intonation methodology is fully supported by this International Standard. A pitch can be specified as an exact interval from the any other pitch. This allows context-dependent harmonic dev elopment to any arbitrary degree of complexity.

NOTE 48
Due to a phenomenon sometimes called the "Pythagorean comma," it is quite possible for the perceived tonal center of a just-intoned piece to change its frequency . Therefore, in general, a piece using a mixture of gamut-based pitches and just-intoned pitches may pose challenging esthetic and technical difficulties for both composers and performers.

8.8.5.1 Just intonation pitch (jipit)

The architectural form just intonation pitch (jipit) specifies a pitch in just intonation as a base pitch and an optional interval. The base pitch can be specified in the same way as a non-just nominal pitch, or as a reference to another just intonation pitch.

The resultant pitch is determined by offsetting the base pitch by the interval. If no interval was specified, the resultant pitch is the base pitch.

The architectural form just intonation pitch reference (jipitref) is a reference to a just intonation pitch.

<!--Just Intonation Pitch -->
<!element jipit
--Just intonation nominal pitch --
O O ( ( gampitch | freqspec | jipitref), interval?)
>
<!attlist jipit
SMDL NAME jipit
id ID #IMPLIED
>
<!element jipitref
--Just intonation nominal pitch reference --
-O EMPTY
>
<!attlist jipitref
SMDL NAME jipitref
idr IDREF #REQUIRED
>

8.8.5.2 Just intonation interval (jipitint)

The architectural form just intonation interval (jipitint) specifies a just intonation interval as the relationship between two just intonation pitches. The resulting interval is deriv ed by dividing the second pitch by the first.

<!--Just Intonation Interval -->
<!element jipitint
--Just intonation nominal pitch interval --
O -( jipit, jipit)
>
<!attlist jipitint
SMDL NAME jipitint
>

8.8.5.3 Common chord symbol (ccschord)

Found only in the content of chordchg-form elements (see Section 8.3.3.4), the architectural form common chord symbol (ccschord) specifies a chord change by means of a reference pitch, a chord body, and an optional bass note. The reference pitch represents the root of the chord. The chord body can be specified directly orvia a chord body name from a chord body gamut.

A polychord can be represented by specifying more than one pairing of reference pitch and chord body. They must be specified in descending order by reference pitch.

The attribute chord body gamut (chordgam) identifies the chord body gamut that will be used to look up chord body names. The selected gamut will remain in use until changed by another occurrence of this attribute.

The architectural form bass note (bassnote) identifies the lowest note that should be play ed fort his chord change. It is specified as an interval with reference to the first (or only) reference pitch.

<!--Common Chord Symbol -->
<!element ccschord
--Common chord symbol chord change --
-O ( ( refpitch, ( chordnm | chordbdy))+, bassnote?)
>
<!attlist ccschord
SMDL NAME ccschord
chordgam --Current chord body gamut --
IDREF #IMPLIED --Default: no change --
>
<!element bassnote
--Bass note (may also be in body of chord). If
polychord, interval refers to first refpitch. --
-O (gamintvl)
>
<!attlist bassnote
SMDL NAME bassnote
>

8.8.5.4 Figured bass (thoroughbass) (figbass)

Found only in the content of chordchg-form elements (see Section 8.3.3.4), the architectural formfigured bass (thoroughbass) (figbass) represents a thoroughbass chord by means of a reference pitch (the bass) and a chord body that is specified directly as a set of figured bass intervals.

The architectur al form figured bass interval (figbsint) specifies an interval in terms of a name step distance from the reference pitch, optionally modified by a fictum adjustment.

The attribute interval sustain (sustain) indicates whether the interval is sustained beyond the duration of the current figured bass event. If so, the ID of a succeeding figured bass event is specified and the interval is sustained through the duration of that event.

<!--Figured Bass (Thoroughbass) -->
<!element figbass
--Figured bass (thoroughbass) chord change --
-O ( refpitch, figbsint*)
>
<!attlist figbass
SMDL NAME figbass
id ID #IMPLIED
>
<!element figbsint
--Figured bass (thoroughbass) interval --
-O ( nsdist, fictadj?)
>
<!attlist figbsint
SMDL NAME figbsint
sustain
--ID of last figbass over which voice sustains --
IDREF #IMPLIED --Default: no sustain --
>

8.8.5.5 Reference pitch value (refpitch)

The architectural form reference pitch value (refpitch) specifies the reference pitch on which chord body intervals are based. It is specified as a gamut-based pitch in the current pitch gamut.

NOTE 49
The reference pitch represents the "root" of a common chord symbol or the "bass" of a figured bass.

<!--Reference Pitch Value -->
<!element refpitch
--Reference pitch on which chord intervals are
based. "Root" for CCS chord; "bass" for figured bass. --
-O ( gampitch)
>
<!attlist refpitch
SMDL NAME refpitch
>

8.8.6 Chord body (chordbdy)

The architectural form chord body (chordbdy) specifies the body of a chord either precisely , as a set of gamut-based intervals with respect to the reference pitch, or imprecisely, as a character string that describes the interval set (like "major seventh").

NOTE 50

The architectural form chord text (chordtxt) is a character string that describes a chord body.

<!--Chord Body -->
<!element chordbdy
--Intervals of chord with respect to reference pitch --
O O ( chordtxt?, gamintvl*)
>
<!attlist chordbdy
SMDL NAME chordbdy
>
<!element chordtxt
--Imprecise chord body description (without root or bass) --
-O (#PCDATA)
>
<!attlist chordtxt
SMDL NAME chordtxt
>

8.8.6.1 Chord body gamut (chordgam)

The architectural form chord body gamut (chordgam) defines a lookup table that maps chord body names to chord bodies.

NOTE 51
For example, the name "ma7" could be associated with a chord body containing the gamut intervals fo ra major third, perfect fifth, and major seventh. The gamutentry might look like this (with end-tags omitted by markup minimization):

<chordnm>ma7
<chordbdy>
<chordtxt>Major 7th
<gamintvl><nsintvl>0 2< gsi ntv l>0 4
<gamintvl><nsintvl>0 4< gsi ntv l>0 7
<gamintvl><nsintvl>0 6< gsi ntv l>1 1

The same entry could also look like this, using one possible type of user-defined short reference markup minimization:

ma7 "Major 7th" 02:04, 04:07, 06:11

The architectural form chord body name (chordnm) is a character string that names a chord body.

<!--Chord Body Gamut -->
<!element chordgam --Chord body gamut --
-O ( chordnm, chordbdy)+
>
<!attlist chordgam
SMDL NAME chordgam
id ID #IMPLIED
>
<!element chordnm
--Chord body name --
-O (#PCDATA)
>
<!attlist chordnm
SMDL NAME chordnm
>


[ Index | Previous Paragraph | Next Paragraph ]