<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have no solution to propose, only a short comment to offer: sometimes these in-line accidentals for the continuo are erroneously placed, and occasionally they are the wrong symbol. So then the problem becomes how to (a) show the original placement, (b) show the correction, and (c) indicate the proper placement. This becomes enormously cumbersome. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>As a prospective user, I would rather pursue the EDIROM “show the picture” approach.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Eleanor<o:p></o:p></span></p><div style='mso-element:para-border-div;border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Eleanor Selfridge-Field<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Stanford University<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Stanford, CA 94305-3076<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>USA<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>http://www.stanford.edu/~esfield/<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>http://www.ccarh.org<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu@lists.uni-paderborn.de] <b>On Behalf Of </b>Laurent Pugin<br><b>Sent:</b> Wednesday, December 01, 2010 2:19 AM<br><b>To:</b> Music Encoding Initiative<br><b>Subject:</b> Re: [MEI-L] Figured Bass in MEI<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>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<o:p></o:p></p><div><p class=MsoNormal>On Wed, Dec 1, 2010 at 12:13 AM, Eleanor Selfridge-Field <<a href="mailto:esfield@stanford.edu">esfield@stanford.edu</a>> wrote:<o:p></o:p></p><p class=MsoNormal>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<o:p></o:p></p><div><p class=MsoNormal>"very precise, interpretative and very loose, uninterpreted markup needs".<o:p></o:p></p></div><p class=MsoNormal>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><span style='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></span><o:p></o:p></p><div><p class=MsoNormal><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><o:p></o:p></p></div><div><p class=MsoNormal>[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<o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>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><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>