[MEI-L] Figured Bass in MEI
Laurent Pugin
laurent at music.mcgill.ca
Wed Dec 1 11:18:30 CET 2010
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
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20101201/a8fd8f59/attachment.htm>
More information about the mei-l
mailing list