<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi everybody!<br>
<br>
Sorry for replying this late to Maja's and Johannes' proposal for
figured bass. Nonetheless, I greatly appreciate your initative in
tackling figured-bass in MEI Maja and Johannes!<br>
<br>
Navigating in the space of possibilities between<br>
<blockquote type="cite">"very precise, interpretative and very
loose, uninterpreted markup needs".</blockquote>
I think MEI is neither nor but tends to be of the first kind.<br>
In terms of elementary parts of CMN (staff, measure, note...) MEI is
very precise,but in terms of additional (text-based) elements such
as figured-bass (so far encoded in <harm>) MEI allows FOR a
rather loose encoding. But each instance of <harm> already can
be enriched by means of references to a <chorddef> of parts of
a facsimile.<br>
<br>
The harm-chorddef concept an the possible child-nodes in harm and
chorddef seem to be designed for common chord-symbols or tabulature
renditions. Why not enhance it for FB needs? In a way offering a
same level of verbosity to all three "chord-types" and avoiding
unbalanced richness in favour of one of them.<br>
<br>
Some qustions and possibilities: <br>
1.) Should a FB be encoded as a chord giving semi-tone distances to
a root-note or is there another concept?<br>
-- This would mean to translate FB-figures to common chord-symbols
and then encode it; as a result notes without a figure will not
necessarily be associated to the same <chorddef> as it could
turn out to be either a major or a minor triad.<br>
-- If there were some kind of measurement-unit one could give in a
<chorddef>, let's say "PITCH_SCALE_STEP", same figures (be it
in major or minor scale) could be encoded as the same thing, for
example in case of a "8 3" or "5 3" figuring. A tiny drawback: For
interpretational purposes the current scale would have to be known.<br>
<br>
2.) what is being encoded a source or an edition?<br>
-- Should there be a difference?<br>
-- MEI should allow both!<br>
-- When encoding a source, you might want to put as much of the
original rendition into the code as possible. This might result in
the need of encoding every single FB individually (en contraire to
my above idea). We might think of a solution with @facs or similar,
as (by now) you cannot replace the original or a facsimile in all of
it's aspects.<br>
<br>
3.) Do I have to encode it verbose?<br>
-- No. As <harm> should not be eliminated, loose markups are
still possible.<br>
<br>
It should be clear that MEI encodes music in an interpretative way
(other than DARMS - thank you Eleanor for the example). That is why
it should also encode FB as something else than mere strings and
thus allow logical access.<br>
<br>
<br>
Sincerely,<br>
Benjamin<br>
<br>
Am 01.12.2010 11:18, schrieb Laurent Pugin:
<blockquote
cite="mid:AANLkTimbXyhUhJB+wJgFF9kwXxLPZK7XcJk9cbPXFWGj@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://www.stanford.edu/%7Eesfield/" target="_blank">http://www.stanford.edu/~esfield/</a><br>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><br>
</div>
<div class="im">[mailto:<a moz-do-not-send="true"
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 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 moz-do-not-send="true" href="mailto:pdr4h@virginia.edu">pdr4h@virginia.edu</a><br>
<br>
________________________________________<br>
From: <a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a><br>
[<a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>]
On Behalf Of Johannes Kepper<br>
[<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
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>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
</body>
</html>