[MEI-L] Figured Bass in MEI
Benjamin Wolff Bohl
bohl at edirom.de
Wed Apr 6 09:39:36 CEST 2011
Hi everybody!
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!
Navigating in the space of possibilities between
> "very precise, interpretative and very loose, uninterpreted markup needs".
I think MEI is neither nor but tends to be of the first kind.
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.
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.
Some qustions and possibilities:
1.) Should a FB be encoded as a chord giving semi-tone distances to a
root-note or is there another concept?
-- 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.
-- 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.
2.) what is being encoded a source or an edition?
-- Should there be a difference?
-- MEI should allow both!
-- 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.
3.) Do I have to encode it verbose?
-- No. As <harm> should not be eliminated, loose markups are still possible.
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.
Sincerely,
Benjamin
Am 01.12.2010 11:18, schrieb Laurent Pugin:
> 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 <mailto: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>
> [mailto: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 <mailto:pdr4h at virginia.edu>
>
> ________________________________________
> From: mei-l-bounces at lists.uni-paderborn.de
> <mailto:mei-l-bounces at lists.uni-paderborn.de>
> [mei-l-bounces at lists.uni-paderborn.de
> <mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of
> Johannes Kepper
> [kepper at edirom.de <mailto: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 <mailto: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 <mailto: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
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20110406/eecfc024/attachment.htm>
More information about the mei-l
mailing list