[MEI-L] Figured Bass in MEI
Eleanor Selfridge-Field
esfield at stanford.edu
Thu Dec 2 01:07:07 CET 2010
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.
As a prospective user, I would rather pursue the EDIROM "show the picture"
approach.
Eleanor
Eleanor Selfridge-Field
Stanford University
Stanford, CA 94305-3076
USA
http://www.stanford.edu/~esfield/
http://www.ccarh.org
From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
[mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
Behalf Of Laurent Pugin
Sent: Wednesday, December 01, 2010 2:19 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Figured Bass in MEI
Hi all,
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?
Best wishes,
Laurent
On Wed, Dec 1, 2010 at 12:13 AM, Eleanor Selfridge-Field
<esfield at stanford.edu> wrote:
Perry,
What a masterpiece of ingenuity! The only way, finally, to know what will
work and what will not is to test it on real data with real software.
Until that happens, I can't resist commenting on your introductory phrase
"very precise, interpretative and very loose, uninterpreted markup needs".
This pendulum has gone back and forth throughout the history of modern
music representation (all 50 years of it). No would should expect it to
stop moving any time soon.
DARMS (1960s) originated in an era insistent on non-interpretative
approaches. That is why it encoded only staff positions, not letter names
of "notes". We could only "know" what we saw, not what it meant. The
practical downside was, of course, that if the key signature happened to
be wrong, everything that followed was wrong. Neutral interpretations may
need some good defenses against total misunderstanding.
There are likely to be similar trade-offs in any detailed spec for
individual musical features. The physical appearance of the output is a
matter of negotiation between the encoding and the output software. With
regard to figured bass, MEI faces the same obstacle as optical recognition
programs: unless the output method is known, it is hard to know how best
and most unambiguously to organize the data. Every program has its own
expectations, which are geared to its own processing hierarchy. Ideally,
at the output stage one would select a specific style of FB presentation
(English style, French style, etc.)
Eleanor
----------------
Eleanor Selfridge-Field
Stanford University
Stanford, CA 94305-3076
USA
http://www.stanford.edu/~esfield/ <http://www.stanford.edu/%7Eesfield/>
http://www.ccarh.org
-----Original Message-----
From: mei-l-bounces at lists.uni-paderborn.de
[mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry
(pdr4h)
Sent: Tuesday, November 30, 2010 8:36 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Figured Bass in MEI
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
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20101201/d8bffcb9/attachment.htm>
More information about the mei-l
mailing list