<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Andrew, Zoltan,<br>
<br>
Zoltan: thanks for your answers to this thread on the W3C CG list.
This reply to Andrew (below) continues the thread here, so its
also a reply to what you said. <br>
<br>
</div>
<blockquote
cite="mid:1181E2D9-350F-4875-8A61-7CB2B2D02022@mail.mcgill.ca"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
AH: For rhythm and duration we differentiate between "@dur"
(written duration) and "@dur.ges" (performed duration). Both of
these are available on note and rest objects.</blockquote>
Yes, that's one of the problems -- see below. :-)<br>
<br>
<blockquote
cite="mid:1181E2D9-350F-4875-8A61-7CB2B2D02022@mail.mcgill.ca"
type="cite">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><span
style="font-size:12.8px" class=""><span
style="font-size:12.8px" class=""> JI: I want to
make an MEI customisation that uses most of the
symbols that are used by CWMN, but without assuming
tempo. If there is no tempo, then neither tuplets
nor grace-notes make sense. It should also be
possible for the description of <i class="">more
than one</i> temporal instantiation to be stored
inside the XML elements that represent the score's
graphics.<br class="">
</span></span></div>
</div>
</blockquote>
<div><br class="">
</div>
<div>AH: I'm not sure I understand this. Tempo is generally
expressed by a playback mechanism. It can be hinted at in
the encoding, but most systems have controls for overriding
it.</div>
</div>
</div>
</blockquote>
The @dur attribute describes both the shape of the symbol and its
meaning (the number of beats it represents in a <measure>).
Beats mean tempo, and that's a problem if I'm trying to create a
customisation that does without it. <br>
<br>
I want to separate the meaning of each duration symbol from its
visual appearance by putting the temporal information in an enclosed
element. Lets call the enclosed element <time>. Actually, I
want (potentially) to have a <i>list</i> of <time> elements
inside each duration symbol, each position in such lists containing
the temporal information for a different performance of the piece.<br>
<br>
[begin aside]<br>
The first <time> element would describe the symbol's default
duration, which in MusicXML and MEI Go can be calculated from the
tempo, ppq, logical value of @dur. etc.<br>
If used in CWMN, the <time> element would make all that tempo,
ppq, logical value @dur.ges stuff redundant. Simplification is
always a good idea! :-) Note that this strategy means that @dur's
logical value and @dur.ges are both being treated as being in the
same dimension (time). Pretending that att.duration.musical and
att.duration.performed need to be treated differently is, I think, a
mistake.<br>
Note also that the latest MIDI standard (the Web MIDI API) no longer
supports tempo. Including tempo in the 1981 MIDI standard was a
mistake, which has now been rectified. The Web MIDI API just uses
milliseconds.<br>
Even CWMN scores should be allowed to contain descriptions of
additional temporal renderings, apart from the default, metronomic
one... This strategy makes metronomes redundant, since scores can
contain accurate temporal renderings of what the composer really
meant, not just an implied mechanical realisation.<br>
[end aside]<br>
<br>
The simplest case would be if the <time> element simply
had an @ms attribute which would be its duration in milliseconds.
But this element should also be able to contain more complex
temporal information. A <note> or <chord> symbol can
contain ornaments that can be described using MIDI information. All
MIDI info is purely temporal. So the duration of the <time>
elements embedded in <note>s and <chord>s should really
be calculated from the durations in the contained MIDI sequence. A
<time> element in a <rest> might just have a simple @ms
attribute.<br>
<br>
But lets forget about such refinements for the moment and just note
that the <time> element has a (or defines) a duration.<br>
<br>
I want to use <measure>, but here again, I want to separate
its graphical aspects from its meaning.<br>
<b>Question:</b> Does setting measure@metcon to false do that? If
@metcon is false, can I then use arbitrary symbols in the various
contained <level>s, and ignore the logical values of all the
@dur attributes?<br>
<br>
Graphically, a measure is just two vertical lines enclosing
<staff> elements that enclose <layer> elements that
enclose duration symbols (<note>s, <chord>s and
<rest>s) and other "events" in a left-right sequence.<br>
The duration symbols' left-right sequence in the measure corresponds
to their earlier-later sequence in time, so there has to be a
mechanism for describing the left-right sequence of all the symbols
in a <measure>.<br>
<br>
[begin aside]<br>
My current solution for this, is to use the default millisecond
duration of the symbol's <time> element (an integer) as a
dimensionless number. The algorithm that creates an (SVG)
instantiation of the abstract XML info first uses this number as a
spatial unit (a number of pixels) in a space wide enough to position
the symbols so that they don't overlap, then compresses the width of
the system into the actually available space. My algorithm is
recursive, and results in spacing that corresponds to what I think
is the best, (most legible) way to space music symbols. If the width
is too small for the symbols to be spaced proportionally to their
durations (the usual case), then less space is given to the longer
durations.<br>
[end aside]<br>
<br>
While the logical durations of the @dur attributes may not have to
add up in a tempoless <measure>, the <measure> still
imposes a restriction on the durations of the <time> elements.
The durations of the <time> elements in each <layer>
have to add up to the same value in any particular performance. They
don't, of course, have to add up to the same value across different
performances. How can I express that in a schema? Maybe I don't <i>need</i>
to express that explicitly, but its still something that can be
validated automatically by software.<br>
<br>
<blockquote
cite="mid:1181E2D9-350F-4875-8A61-7CB2B2D02022@mail.mcgill.ca"
type="cite">
<div class="">
<div>
<div>AH: I'm really not sure where you're going with the
duration symbols and fixed meanings, though. Why would you
be adding gracenotes and tuplets?</div>
</div>
</div>
</blockquote>
In a tempoless notation, there is no need to litter the score with
little numbers and brackets (tuplets) or to make some symbols
smaller in order to make it clear that some notes are outside the
counting scheme (grace-notes) or to add little dots to the symbols
to mean that they are longer than they would be otherwise
(augmentation dots). I think of all these as <i>annotations</i>
that can be added ad lib to a score, without affecting the playback
of the contained temporal information.<br>
Tuplets and grace-notes only make sense in music that has tempo
(CWMN).<br>
I'm not so sure about augmentation dots -- which could be used as
annotations in tempoless music to imply that the note should be
performed longishly... But a tenuto articulation could do that just
as well. Its probably something that should be left to the composer
to decide. Maybe the composer wants to use tenuto to imply something
else (emphasis of some kind).<br>
Apropos verification: Maybe there's some way in CWMN to ensure that
the default <time> durations inside a tuplet are as equal as
possible. But those durations <b>must be </b><b>integers</b> in
order to prevent the endless hassle with rounding floating point
numbers. None of the durations in the default (metronomic)
performance should be allowed to be more than one millisecond longer
than any of the others. Grace notes inside tuplets complicate things
of course, but the problem should not be insoluble.<br>
<br class="">
<blockquote
cite="mid:1181E2D9-350F-4875-8A61-7CB2B2D02022@mail.mcgill.ca"
type="cite">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class=""><span
style="font-size:12.8px" class=""><span
style="font-size:12.8px" class=""> JI: Can you
imagine such a hierarchy of customisations? I'm also
thinking of the container hierarchy that could
become part of the W3C standard for describing <i
class="">any </i>polyphonic music notation.<br
class="">
</span></span></div>
</div>
</blockquote>
<div><br class="">
</div>
<div>AH: A customization is not arranged in a hierarchy. The
primary reason for a customization is to produce a schema
that will validate an encoding. <br>
</div>
</div>
</div>
</blockquote>
That's not a problem. <br>
I was thinking more of another level: I think that all polyphonic
music notations could share the same container hierarchy. The
page->system->staff->layer hierarchy is actually
independent of the graphics. Notations can use the same terms, even
if they are read left to right, top to bottom or round in circles.
The graphic representation is really just up to the software that
instantiates the score. I just didn't want to miss the chance of
some more modularity.<br>
Its probably not very important in polyphonic music, but it might
help the evolution of software for homophonic music, if the
developers always used the same names for their simplified container
hierarchy. For example: page->staff.<br>
<br>
Hope that helps,<br>
James<br>
<br>
<br>
</body>
</html>