[MEI-L] Figured Bass in MEI
Roland, Perry (pdr4h)
pdr4h at eservices.virginia.edu
Tue Nov 30 17:36:08 CET 2010
Hi Maja and Johannes,
Thanks for the well-thought out proposal. I appreciate the effort that went into creating it.
<harm> was created to accommodate (and group) various kinds of harmonic labels. While some are more "structured" than others, in the end they're *labels*. When it is necessary to have access to an *interpretation* of the label, other mechanisms can be used. A simple example of this is the use of a simple label, say "7", which may occur many, many times throughout an MEI instance, which may be linked to a more meaningful (and more verbose) interpretation stored elsewhere, say in <chorddef>. Using the verbose form at every occurrence of the label swells the size of the file and complicates the markup for those users who are not interested in the interpretation. I believe we have to strike a balance between very precise, interpretative and very loose, uninterpreted markup needs.
Also, when multiple layers of interpretation may exist, say in the case where the original figured bass was "7" and a later hand added a natural below, but that was crossed out by a still later hand, and so on, it is important to treat the figured bass as element content; i.e., strings. Therefore, I have some problem with your reliance on attributes in many cases.
So, I want to make some suggestions:
1. Let's make <fb> a child of <harm>. This way <harm> continues to act in the role of gathering harmonic labels, be they figured bass or something else. (We may have proposals in the future for more specific handling of additional harmonic indications, such as Roman numeral analysis, etc.) Putting all harmonic labels inside <harm> allows one to mix and match, for example, to use Roman numeral analysis for one measure, Baroque figured bass for another, and letter notations, such as "Cm7", for others.
This does not preclude putting figured bass in a separate module. The elements defined by the module would simply be included in the content of <harm> rather than <measure>. In fact, doing so would be better because a) the content model of measure is complex enough already without complicating it even more and b) it would permit model.transcriptionLike elements to be used as descendants of <harm> to capture the editorial processes described above, but within <measure> to indicate the addition/deletion of harmonic labels over all.
<fb> should not take the attributes of <harm>. <fb> should only group figure components. <harm> will continue to provide staff, duration, placement, etc. data. This way, there's no confusion over when to use <fb> and when to use <harm>.
2. Recognizing the need, which you've pointed out, to treat individual figure components as separate elements, <fb> should contain <f> elements. Each figure component then is a first-class object, with the possibility of participating in multiple attribute classes and content models. For example, each <f> can be associated with a user-defined symbol via @sym or be analytically linked to other elements via @corresp, @sameas, or @copyof. The <f> element should have an @extender attribute.
With just these small changes, it's possible to address the examples given in your proposal --
Example 1 presents no particular problems. <harm> continues in its former role, <fb> gathers <f> elements, and <f> contains a single figure component.
Ex. 1
<harm staff="1" tstamp="1" place="above">
<fb>
<f>6</f>
</fb>
</harm>
I believe it's important to allow those users who want to use <harm> in its current non-specific way to continue to do so. A possible alternative to the markup above is therefore:
<harm staff="1" tstamp="1" place="above">6</harm>
By the way, all the following examples can be encoded using the current content model of <harm>, but I won't provide the markup. I leave it as an "exercise to the reader" to do that. :)
In example 2, the figured bass consists of a "7" with a natural sign below. Each is treated as a figure, with the natural encoded using the Unicode MUSIC NATURAL SIGN character.
Ex. 2:
<harm staff="1" tstamp="1" place="above">
<fb>
<f>7</f>
<f>♮</f>
</fb>
</harm>
There's no need for an accid.pos attribute in example 3 and 4 since the encoding order of the characters in <f> explicitly locates the accidentals after the "7" and before the "3". (By the way, while they often use the same signs, "accidentals" in figured bass aren't actual accidentals. They are simply convenient signs to indicate chromatic alteration. A sharp doesn't necessary mean that there should be a sharp sign in front of the note forming the interval, but rather than the note should be raised by a half step. That's why <accid> isn't allowed/necessary within <f>.)
Ex. 3:
<harm place="below">
<fb>
<f>7♭</f>
</fb>
</harm>
Ex. 4:
<harm>
<fb>
<f>6</f>
<f>4+</f>
<f>♮3</f>
</fb>
</harm>
By handling the slashed numbers with Unicode characters (⃥ = COMBINING REVERSE SOLIDUS OVERLAY and ̸ = COMBINING LONG SOLIDUS OVERLAY), there's no need for the "within" value of @accid.pos. The combining nature of these Unicode characters indicates very clearly that they "overstrike" (or are "within") the preceding character. Even so, there's also no reason why the usual convention for slashes can't be followed, e.g. "6\" and "6/". At some point we could implement something like the <tei:g> element or allow <symbol> within <f>, but Unicode provides everything needed at this point.
Ex. 5:
<harm>
<fb>
<f>6⃥</f>
<!-- <f>6\</f> -->
</fb>
</harm>
Your proposal rightly draws attention to the fact that currently @extender can't be used on individual parts of the harmonic label. Therefore, it's a good idea to wrap each figure component in an <f> element so @extender can be used. Similarly, @sym can be used to point to a user-defined symbol that better represents the figure component, for example, the combined "2" and "+" below. Similar to the slash in the preceding example before, the small curve over the "5" in example 6 can be represented by the Unicode COMBINING INVERTED BREVE.
Ex. 6:
<harm tstamp="1">
<fb>
<f extender="true">5̑</f>
<f sym="combo2plus">2+</f>
</fb>
</harm>
<harm tstamp="3">
<fb>
<f>3</f>
</fb>
</harm>
For figures which consist entirely of a mark indicating repetition of the preceding figure, as in example 7, I would argue that these are not extenders and that they should be represented by a dash or another appropriate character. In some repertoires the repetition sign is a solidus, i.e. "/". [My personal copy of the Harvard Dictionary of Music (which the Library doesn't have so I can't cite it right now) has an example in which "/" is used instead of "-" to indicate repetition.] If we hope to capture these varying signs, then treating them as characters is a better option. Using "-" is also consistent with other figured bass encoding schemes, such as MuseData.
Ex. 7:
<harm tstamp="1.5">
<fb>
<f>-</f>
</fb>
</harm>
Since only <harm> is allowed to carry @tstamp, etc., there must be a <harm> element for each figured bass indication. <add> and its editorial brothers are not yet allowed within <fb> or <f> so they must be wrapped around <harm> to indicate the editorially supplied indication on the 2nd beat. If <add> and such are allowed in <fb> or <f>, they will have a different meaning; that is, they indicate changes to an already existing figured bass or figure, e.g.,
<fb>
<f>3<add>♯</add></f>
<add><f>7</f></add>
</fb>
This indicates that the alteration to "3" and the "7" were added later.
The editorially supplied extender in example 8 is somewhat problematic, but not distressingly so. How it's handled depends on what the encoder wants to emphasize about the notation and whether what's being encoded is an "edition" or a "source". If the fact that the figure "3" is intended to sound throughout the measure in this edition, then @dur on the <harm> element is appropriate. What can't be captured by doing this is the supplied nature of the value for @dur. In order to capture this aspect of source encoding, we must use an element. While we could add an <extender> element to each <f> and/or <harm>, I would simply treat the added line as just that -- a line. This approach can provide greater detail regarding the visual characteristics of the line than @extender or @dur can; that it starts somewhat farther to the right than the usual extender, for instance. The set of attributes used on the line element (and their exact values) is rendering system dependent, but it's possible to relate the line in visual space and time to any other elements and use @type to distinguish this class of line from other lines. *Currently, <line> isn't allowed within <supplied>, but that's fixable. :)*
Ex. 8:
<harm tstamp="1" dur="0m+3.5">
<fb>
<f>7</f>
<f>♮</f>
</fb>
<supplied resp="MH">
<line type="extender" [other visual attributes]/>
</supplied>
</harm>
<supplied resp="JK">
<harm tstamp="2">
<fb>
<f>5♯</f>
</fb>
</harm>
</supplied>
<harm tstamp="3">
<fb>
<f>6</f>
</fb>
</harm>
In example 9, as in example 7, the "-" above the "3" on beat 4 is not an extender, but a repetition sign. Likewise, for the "-" on beat 4.5. When extenders are really indicated, @extender may be used on any <f> element to indicate that an extender should be drawn. Whenever @extender is used @dur (or probably a better-named substitute) should also be used to indicate the endpoint of the extending line.
Ex. 9:
<harm tstamp="3.5">
<fb>
<f>♭3</f>
<f extender="true">6</f>
<f>5</f>
</fb>
</harm>
<harm tstamp="4">
<fb>
<f>-</f>
<f extender="true">♯3</f>
</fb>
</harm>
<harm tstamp="4.5">
<fb>
<f>7</f>
<f>-</f>
</fb>
</harm>
I believe the primary goal in using <fb> is not to capture all the visual "weirdnesses" that can be found in printed and manuscript scores throughout the centuries, but to provide a more-or-less standardized label. Neither "6♮" or "6\" is intended to capture the exact look and placement of the slash, only its presence. (When you think about it carefully, "4" doesn't capture the precise look of anything either!) The @sym attribute can be used to point to a user-defined symbol that can be substituted and/or @facs can be used to point to a region in an image where an example can be seen. This is consistent with the use of @sym and @facs elsewhere in MEI.
Ex. 10a:
<harm tstamp="3">
<fb>
<f>8</f>
<f sym="weird6_1">6♮</f>
<f>4+</f>
<f>2</f>
</fb>
</harm>
<harm tstamp="4">
<fb>
<f sym="weird6_2">6\</f>
<f>4</f>
<f>3</f>
</fb>
</harm>
Ex. 10b:
<harm tstamp="4.5">
<fb>
<f>6\</f>
</fb>
</harm>
Ex. 10c:
<harm tstamp="1">
<fb>
<f>5/</f>
</fb>
</harm>
I do not agree with your statement that "@startid implies that there is an endid". In fact, @startid is intended to "hold a reference to the first element in a sequence of events to which the feature applies" even when the sequence contains only a single event. So, there's nothing wrong with using @startid to reference the bass note to which the figure (actually, the <harm> element in my counter proposal) is attached. Care should be exercised, however, that identifying the bass note is not the start of an attempt to use the contents of <harm> to derive a sounded or intervallically analyzable version. That capability already exists in <chorddef>.
I agree with your suggestion regarding a move from IDREFs to URIs. It's already on the feature request list.
I believe my suggestions provide a compromise between the current method for representing harmonic labels and your proposal. They facilitate more detailed markup while still treating figured bass indications as labelling strings, providing optimum flexibility.
Some additional "tweaking" may be necessary so I encourage more discussion. For example, I'm not wedded to the names above for the new elements. Instead of <fb> and <f> we could use <figbass> and <fc> (figure component).
Thanks again for the great proposal. It's wonderful to work with such intelligent and committed people.
--
p.
__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
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 Johannes Kepper [kepper at edirom.de]
Sent: Monday, November 15, 2010 5:28 AM
To: Music Encoding Initiative
Subject: [MEI-L] Figured Bass in MEI
Dear all,
although it took us longer than expected, we have finally finished our proposal for a (hopefully) improved encoding of figured bass in MEI. We don't provide a technical schema, but instead offer a couple of examples that might help to slice the problem down. We hope that this paper will start an intense discussion that might pave the way for some changes in the next release of MEI – maybe even a new module!?!
We're looking forward to lots of comments and suggestions for improvement,
Maja and Johannes
More information about the mei-l
mailing list