Hi all,<br><br>Thanks for the very complete proposal. A short comment about the placement question. I saw cases of printed sources where the figured bass symbols (sharps or flats) are within the staff, usually just before the note to which they apply. I remember having seen cases with symbols places a third or a fifth higher than the note, or a third below, but also sometimes at the same pitch. In that last case, the result is ambiguous because it looks exactly like a normal sharp or a normal flat. I don't think we have to bother with encoding the ambiguity, but at least the original placement would be nice. Any thoughts?<br>
<br>Best wishes,<br>Laurent<br><br><div class="gmail_quote">On Wed, Dec 1, 2010 at 12:13 AM, Eleanor Selfridge-Field <span dir="ltr"><<a href="mailto:esfield@stanford.edu">esfield@stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Perry,<br>
<br>
What a masterpiece of ingenuity! The only way, finally, to know what will<br>
work and what will not is to test it on real data with real software.<br>
<br>
Until that happens, I can't resist commenting on your introductory phrase<br>
<div class="im">"very precise, interpretative and very loose, uninterpreted markup needs".<br>
</div>This pendulum has gone back and forth throughout the history of modern<br>
music representation (all 50 years of it). No would should expect it to<br>
stop moving any time soon.<br>
<br>
DARMS (1960s) originated in an era insistent on non-interpretative<br>
approaches. That is why it encoded only staff positions, not letter names<br>
of "notes". We could only "know" what we saw, not what it meant. The<br>
practical downside was, of course, that if the key signature happened to<br>
be wrong, everything that followed was wrong. Neutral interpretations may<br>
need some good defenses against total misunderstanding.<br>
<br>
There are likely to be similar trade-offs in any detailed spec for<br>
individual musical features. The physical appearance of the output is a<br>
matter of negotiation between the encoding and the output software. With<br>
regard to figured bass, MEI faces the same obstacle as optical recognition<br>
programs: unless the output method is known, it is hard to know how best<br>
and most unambiguously to organize the data. Every program has its own<br>
expectations, which are geared to its own processing hierarchy. Ideally,<br>
at the output stage one would select a specific style of FB presentation<br>
(English style, French style, etc.)<br>
<br>
Eleanor<br>
----------------<br>
<font color="#888888"><br>
Eleanor Selfridge-Field<br>
Stanford University<br>
Stanford, CA 94305-3076<br>
USA<br>
<a href="http://www.stanford.edu/%7Eesfield/" target="_blank">http://www.stanford.edu/~esfield/</a><br>
<a href="http://www.ccarh.org" target="_blank">http://www.ccarh.org</a><br>
</font><div class="im"><br>
<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><br>
</div><div class="im">[mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of Roland, Perry<br>
(pdr4h)<br>
Sent: Tuesday, November 30, 2010 8:36 AM<br>
To: Music Encoding Initiative<br>
</div><div><div></div><div class="h5">Subject: Re: [MEI-L] Figured Bass in MEI<br>
<br>
<br>
Hi Maja and Johannes,<br>
<br>
Thanks for the well-thought out proposal. I appreciate the effort that<br>
went into creating it.<br>
<br>
<harm> was created to accommodate (and group) various kinds of harmonic<br>
labels. While some are more "structured" than others, in the end they're<br>
*labels*. When it is necessary to have access to an *interpretation* of<br>
the label, other mechanisms can be used. A simple example of this is the<br>
use of a simple label, say "7", which may occur many, many times<br>
throughout an MEI instance, which may be linked to a more meaningful (and<br>
more verbose) interpretation stored elsewhere, say in <chorddef>. Using<br>
the verbose form at every occurrence of the label swells the size of the<br>
file and complicates the markup for those users who are not interested in<br>
the interpretation. I believe we have to strike a balance between very<br>
precise, interpretative and very loose, uninterpreted markup needs.<br>
<br>
Also, when multiple layers of interpretation may exist, say in the case<br>
where the original figured bass was "7" and a later hand added a natural<br>
below, but that was crossed out by a still later hand, and so on, it is<br>
important to treat the figured bass as element content; i.e., strings.<br>
Therefore, I have some problem with your reliance on attributes in many<br>
cases.<br>
<br>
So, I want to make some suggestions:<br>
<br>
1. Let's make <fb> a child of <harm>. This way <harm> continues to act in<br>
the role of gathering harmonic labels, be they figured bass or something<br>
else. (We may have proposals in the future for more specific handling of<br>
additional harmonic indications, such as Roman numeral analysis, etc.)<br>
Putting all harmonic labels inside <harm> allows one to mix and match, for<br>
example, to use Roman numeral analysis for one measure, Baroque figured<br>
bass for another, and letter notations, such as "Cm7", for others.<br>
<br>
This does not preclude putting figured bass in a separate module. The<br>
elements defined by the module would simply be included in the content of<br>
<harm> rather than <measure>. In fact, doing so would be better because<br>
a) the content model of measure is complex enough already without<br>
complicating it even more and b) it would permit model.transcriptionLike<br>
elements to be used as descendants of <harm> to capture the editorial<br>
processes described above, but within <measure> to indicate the<br>
addition/deletion of harmonic labels over all.<br>
<br>
<fb> should not take the attributes of <harm>. <fb> should only group<br>
figure components. <harm> will continue to provide staff, duration,<br>
placement, etc. data. This way, there's no confusion over when to use<br>
<fb> and when to use <harm>.<br>
<br>
2. Recognizing the need, which you've pointed out, to treat individual<br>
figure components as separate elements, <fb> should contain <f> elements.<br>
Each figure component then is a first-class object, with the possibility<br>
of participating in multiple attribute classes and content models. For<br>
example, each <f> can be associated with a user-defined symbol via @sym or<br>
be analytically linked to other elements via @corresp, @sameas, or<br>
@copyof. The <f> element should have an @extender attribute.<br>
<br>
With just these small changes, it's possible to address the examples given<br>
in your proposal --<br>
<br>
Example 1 presents no particular problems. <harm> continues in its former<br>
role, <fb> gathers <f> elements, and <f> contains a single figure<br>
component.<br>
<br>
Ex. 1<br>
<harm staff="1" tstamp="1" place="above"><br>
<fb><br>
<f>6</f><br>
</fb><br>
</harm><br>
<br>
I believe it's important to allow those users who want to use <harm> in<br>
its current non-specific way to continue to do so. A possible alternative<br>
to the markup above is therefore:<br>
<harm staff="1" tstamp="1" place="above">6</harm><br>
<br>
By the way, all the following examples can be encoded using the current<br>
content model of <harm>, but I won't provide the markup. I leave it as an<br>
"exercise to the reader" to do that. :)<br>
<br>
In example 2, the figured bass consists of a "7" with a natural sign<br>
below. Each is treated as a figure, with the natural encoded using the<br>
Unicode MUSIC NATURAL SIGN character.<br>
<br>
Ex. 2:<br>
<harm staff="1" tstamp="1" place="above"><br>
<fb><br>
<f>7</f><br>
<f>&#x266E;</f><br>
</fb><br>
</harm><br>
<br>
There's no need for an accid.pos attribute in example 3 and 4 since the<br>
encoding order of the characters in <f> explicitly locates the accidentals<br>
after the "7" and before the "3". (By the way, while they often use the<br>
same signs, "accidentals" in figured bass aren't actual accidentals. They<br>
are simply convenient signs to indicate chromatic alteration. A sharp<br>
doesn't necessary mean that there should be a sharp sign in front of the<br>
note forming the interval, but rather than the note should be raised by a<br>
half step. That's why <accid> isn't allowed/necessary within <f>.)<br>
<br>
Ex. 3:<br>
<harm place="below"><br>
<fb><br>
<f>7&#x266D;</f><br>
</fb><br>
</harm><br>
<br>
Ex. 4:<br>
<harm><br>
<fb><br>
<f>6</f><br>
<f>4+</f><br>
<f>&#x266E;3</f><br>
</fb><br>
</harm><br>
<br>
By handling the slashed numbers with Unicode characters (&#x20e5; =<br>
COMBINING REVERSE SOLIDUS OVERLAY and &#x338; = COMBINING LONG SOLIDUS<br>
OVERLAY), there's no need for the "within" value of @accid.pos. The<br>
combining nature of these Unicode characters indicates very clearly that<br>
they "overstrike" (or are "within") the preceding character. Even so,<br>
there's also no reason why the usual convention for slashes can't be<br>
followed, e.g. "6\" and "6/". At some point we could implement something<br>
like the <tei:g> element or allow <symbol> within <f>, but Unicode<br>
provides everything needed at this point.<br>
<br>
Ex. 5:<br>
<harm><br>
<fb><br>
<f>6&#x20E5;</f><br>
<!-- <f>6\</f> --><br>
</fb><br>
</harm><br>
<br>
Your proposal rightly draws attention to the fact that currently @extender<br>
can't be used on individual parts of the harmonic label. Therefore, it's<br>
a good idea to wrap each figure component in an <f> element so @extender<br>
can be used. Similarly, @sym can be used to point to a user-defined symbol<br>
that better represents the figure component, for example, the combined "2"<br>
and "+" below. Similar to the slash in the preceding example before, the<br>
small curve over the "5" in example 6 can be represented by the Unicode<br>
COMBINING INVERTED BREVE.<br>
<br>
Ex. 6:<br>
<harm tstamp="1"><br>
<fb><br>
<f extender="true">5&#x0311;</f><br>
<f sym="combo2plus">2+</f><br>
</fb><br>
</harm><br>
<harm tstamp="3"><br>
<fb><br>
<f>3</f><br>
</fb><br>
</harm><br>
<br>
For figures which consist entirely of a mark indicating repetition of the<br>
preceding figure, as in example 7, I would argue that these are not<br>
extenders and that they should be represented by a dash or another<br>
appropriate character. In some repertoires the repetition sign is a<br>
solidus, i.e. "/". [My personal copy of the Harvard Dictionary of Music<br>
(which the Library doesn't have so I can't cite it right now) has an<br>
example in which "/" is used instead of "-" to indicate repetition.] If<br>
we hope to capture these varying signs, then treating them as characters<br>
is a better option. Using "-" is also consistent with other figured bass<br>
encoding schemes, such as MuseData.<br>
<br>
Ex. 7:<br>
<harm tstamp="1.5"><br>
<fb><br>
<f>-</f><br>
</fb><br>
</harm><br>
<br>
Since only <harm> is allowed to carry @tstamp, etc., there must be a<br>
<harm> element for each figured bass indication. <add> and its editorial<br>
brothers are not yet allowed within <fb> or <f> so they must be wrapped<br>
around <harm> to indicate the editorially supplied indication on the 2nd<br>
beat. If <add> and such are allowed in <fb> or <f>, they will have a<br>
different meaning; that is, they indicate changes to an already existing<br>
figured bass or figure, e.g.,<br>
<br>
<fb><br>
<f>3<add>&#x266F;</add></f><br>
<add><f>7</f></add><br>
</fb><br>
<br>
This indicates that the alteration to "3" and the "7" were added later.<br>
<br>
The editorially supplied extender in example 8 is somewhat problematic,<br>
but not distressingly so. How it's handled depends on what the encoder<br>
wants to emphasize about the notation and whether what's being encoded is<br>
an "edition" or a "source". If the fact that the figure "3" is intended<br>
to sound throughout the measure in this edition, then @dur on the <harm><br>
element is appropriate. What can't be captured by doing this is the<br>
supplied nature of the value for @dur. In order to capture this aspect of<br>
source encoding, we must use an element. While we could add an <extender><br>
element to each <f> and/or <harm>, I would simply treat the added line as<br>
just that -- a line. This approach can provide greater detail regarding<br>
the visual characteristics of the line than @extender or @dur can; that it<br>
starts somewhat farther to the right than the usual extender, for<br>
instance. The set of attributes used on the line element (and their exact<br>
values) is rendering system dependent, but it's possible to relate the<br>
line in visual space and time to any other elements and use @type to<br>
distinguish this class of line from other lines. *Currently, <line> isn't<br>
allowed within <supplied>, but that's fixable. :)*<br>
<br>
Ex. 8:<br>
<harm tstamp="1" dur="0m+3.5"><br>
<fb><br>
<f>7</f><br>
<f>&#x266E;</f><br>
</fb><br>
<supplied resp="MH"><br>
<line type="extender" [other visual attributes]/><br>
</supplied><br>
</harm><br>
<supplied resp="JK"><br>
<harm tstamp="2"><br>
<fb><br>
<f>5&#x266F;</f><br>
</fb><br>
</harm><br>
</supplied><br>
<harm tstamp="3"><br>
<fb><br>
<f>6</f><br>
</fb><br>
</harm><br>
<br>
In example 9, as in example 7, the "-" above the "3" on beat 4 is not an<br>
extender, but a repetition sign. Likewise, for the "-" on beat 4.5. When<br>
extenders are really indicated, @extender may be used on any <f> element<br>
to indicate that an extender should be drawn. Whenever @extender is used<br>
@dur (or probably a better-named substitute) should also be used to<br>
indicate the endpoint of the extending line.<br>
<br>
Ex. 9:<br>
<harm tstamp="3.5"><br>
<fb><br>
<f>&#x266D;3</f><br>
<f extender="true">6</f><br>
<f>5</f><br>
</fb><br>
</harm><br>
<harm tstamp="4"><br>
<fb><br>
<f>-</f><br>
<f extender="true">&#x266F;3</f><br>
</fb><br>
</harm><br>
<harm tstamp="4.5"><br>
<fb><br>
<f>7</f><br>
<f>-</f><br>
</fb><br>
</harm><br>
<br>
I believe the primary goal in using <fb> is not to capture all the visual<br>
"weirdnesses" that can be found in printed and manuscript scores<br>
throughout the centuries, but to provide a more-or-less standardized<br>
label. Neither "6&#x266E;" or "6\" is intended to capture the exact look<br>
and placement of the slash, only its presence. (When you think about it<br>
carefully, "4" doesn't capture the precise look of anything either!) The<br>
@sym attribute can be used to point to a user-defined symbol that can be<br>
substituted and/or @facs can be used to point to a region in an image<br>
where an example can be seen. This is consistent with the use of @sym and<br>
@facs elsewhere in MEI.<br>
<br>
Ex. 10a:<br>
<harm tstamp="3"><br>
<fb><br>
<f>8</f><br>
<f sym="weird6_1">6&#x266E;</f><br>
<f>4+</f><br>
<f>2</f><br>
</fb><br>
</harm><br>
<harm tstamp="4"><br>
<fb><br>
<f sym="weird6_2">6\</f><br>
<f>4</f><br>
<f>3</f><br>
</fb><br>
</harm><br>
<br>
Ex. 10b:<br>
<harm tstamp="4.5"><br>
<fb><br>
<f>6\</f><br>
</fb><br>
</harm><br>
<br>
Ex. 10c:<br>
<harm tstamp="1"><br>
<fb><br>
<f>5/</f><br>
</fb><br>
</harm><br>
<br>
I do not agree with your statement that "@startid implies that there is an<br>
endid". In fact, @startid is intended to "hold a reference to the first<br>
element in a sequence of events to which the feature applies" even when<br>
the sequence contains only a single event. So, there's nothing wrong with<br>
using @startid to reference the bass note to which the figure (actually,<br>
the <harm> element in my counter proposal) is attached. Care should be<br>
exercised, however, that identifying the bass note is not the start of an<br>
attempt to use the contents of <harm> to derive a sounded or<br>
intervallically analyzable version. That capability already exists in<br>
<chorddef>.<br>
<br>
I agree with your suggestion regarding a move from IDREFs to URIs. It's<br>
already on the feature request list.<br>
<br>
I believe my suggestions provide a compromise between the current method<br>
for representing harmonic labels and your proposal. They facilitate more<br>
detailed markup while still treating figured bass indications as labelling<br>
strings, providing optimum flexibility.<br>
<br>
Some additional "tweaking" may be necessary so I encourage more<br>
discussion. For example, I'm not wedded to the names above for the new<br>
elements. Instead of <fb> and <f> we could use <figbass> and <fc> (figure<br>
component).<br>
<br>
Thanks again for the great proposal. It's wonderful to work with such<br>
intelligent and committed people.<br>
<br>
--<br>
p.<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
434-982-2702 (w)<br>
<a href="mailto:pdr4h@virginia.edu">pdr4h@virginia.edu</a><br>
<br>
________________________________________<br>
From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><br>
[<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] On Behalf Of Johannes Kepper<br>
[<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>]<br>
Sent: Monday, November 15, 2010 5:28 AM<br>
To: Music Encoding Initiative<br>
Subject: [MEI-L] Figured Bass in MEI<br>
<br>
Dear all,<br>
<br>
although it took us longer than expected, we have finally finished our<br>
proposal for a (hopefully) improved encoding of figured bass in MEI. We<br>
don't provide a technical schema, but instead offer a couple of examples<br>
that might help to slice the problem down. We hope that this paper will<br>
start an intense discussion that might pave the way for some changes in<br>
the next release of MEI - maybe even a new module!?!<br>
<br>
We're looking forward to lots of comments and suggestions for improvement,<br>
<br>
Maja and Johannes<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</div></div></blockquote></div><br>