[MEI-L] <measure> questions
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Wed Aug 12 20:14:22 CEST 2009
Craig,
> Would it be interesting to store in a <measure> attribute
> the duration of the measure, particularly when complete="i"
> or complete="o" is given?
I assume that by "duration of the measure" you mean the number of beats the measure ought to have according to the prevailing meter signature. If that's the case, then this info can be ascertained by looking back at the meter signature preceding this measure. The only reason I can see for adding another attribute to store this is when you're processing the encoding in single-pass mode and can't perform a "look-back" operation (or whatever the opposite of "look-ahead" is called.) Even in single-pass processing the current meter signature can be preserved for consultation at any time.
My inclination is to not add a new attribute here because
1) XML is usually/often (one might even say designed to be) processed by building a tree first and then walking that tree, grabbing information from any node to generate output. Adding an attribute would be an unnecessary concession to one-pass processing.
2) Adding another attribute would increase redundancy in the encoding (the number of beats per measure would be encoded in the meter signature and, potentially, in every measure). As I'm often reminded, redundancy increases confusion over how to utilize the encoding effectively.
> A related question is: how do I indicate that a barline is actually
> splitting a measure in half (due to a repeat-barline)? I presume
> it is best to store each half-bar in separate <measure> elements
> (since otherwise they would overlap <section> elements), but
> I would like to indicate that these two <measure> containers
> are intended to make a single logical measure within the
> time signature. Using only complete="i" for both half-measure
> is ambiguous with a sequence of two complete measures
> which happen to be underfull.
I see your point on this one. There are a couple of options here:
1. use @corresp to indicate that these measures "correspond" in some fashion. The definition of correspondence, however, is intentionally ambiguous. Basically, it's any relationship at all.
2. On slur and phrase there is a "join" attribute that performs this very function -- joining 2 or more separately encoded slurs/phrases into a single logical one. This is a special kind of correspondence that happens frequently enough with slurs and phrases to create a separate attribute. We could add @join to measure.
Fair enough?
--
p.
__________________________
Perry Roland
Digital Curation Services
University of Virginia Library
P. O. Box 400155
Charlottesville, VA 22904- 4155
434-982-2702 (w)
pdr4h at virginia.edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp [craigsapp at gmail.com]
Sent: Tuesday, August 11, 2009 5:28 PM
To: Music Encoding Initiative
Subject: [MEI-L] <measure> questions
Hi Perry,
For a <measure> object, there is a "complete" attribute,
described in the DTD 1.9b:
"The complete attribute allows the encoding of whether
the measure preceding this barline matches the
prevailing meter: a value of 'c' indicates a metrically
complete measure, 'i' indicates a measure with not
enough beats, while 'o' is for measures with too many
beats."
Would it be interesting to store in a <measure> attribute
the duration of the measure, particularly when complete="i"
or complete="o" is given?
A related question is: how do I indicate that a barline is actually
splitting a measure in half (due to a repeat-barline)? I presume
it is best to store each half-bar in separate <measure> elements
(since otherwise they would overlap <section> elements), but
I would like to indicate that these two <measure> containers
are intended to make a single logical measure within the
time signature. Using only complete="i" for both half-measure
is ambiguous with a sequence of two complete measures
which happen to be underfull.
-=+Craig
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list