[MEI-L] figured bass
Eleanor Selfridge-Field
esfield at stanford.edu
Thu Oct 28 20:51:46 CEST 2010
Yes, I think no one offers a full set of ornaments. Before there can ever be one, there needs to be an exhaustive inventory, and no one has ever compiled one.
Figured bass has its own tricks, though. One is the figure (or figure set) that is not aligned with a note in the adjacent part because it reflects a harmonic change in upper voices. So the "dur" track for figures is occasionally deviant from the "dur" of the bass.
In graphics, one can always nudge it over with a mouse or reset an xy parameter. That leaves no record in the file (unless one makes one), and the next user has to proofread very carefully.
Eleanor
----- Original Message -----
From: "Johannes Kepper" <kepper at edirom.de>
To: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
Sent: Thursday, October 28, 2010 11:13:35 AM
Subject: Re: [MEI-L] figured bass
Dear Eleanor,
I actually think that MEI already addresses this problem in a sufficient way by offering tags like <orig[inal]>, <reg[ularization]>, <sic> and so on. What we might have to consider is to explicitly differentiate between a written symbol and its musical interpretation, much similar to @dur vs. @dur.ges[tural] and the like.
Ornaments in total are definitely a couple of magnitudes harder than figured bass (which isn't trivial either…). Although I hope we get to this issue at some point, that's probably nothing for the next couple of months. But even then I don't think that MEI should offer a full set of ornaments that can be grasped by their semantics. Currently I'd say that this should happen at the project level.
Best regards,
Johannes
Am 28.10.2010 um 18:40 schrieb Eleanor Selfridge-Field:
> Dear all,
>
> Christine raises a useful point. While it is easy to say that a "style" can determine the rendering, the data file may need to accommodate two symbols for a non-standard rendering, e.g., "sharp" and "<graphical system to be used for sharp>". For sound apps, one would also need either a tuning system indication (e.g., "meantone") in the header or value [long list of possibilities for systems of auditory indicators, such as "frequency").
>
> Corresponding issues arises with ornaments, their signs, and their execution styles. With ornaments there are multiple note objects. MuseData and Humdrum both offer useful models for dealing with these issues.
>
> For both f.b. and ornaments, the range of graphical styles is open-ended. Usage varied from publisher to publisher, composer to composer, year to year, and sometimes (it seems) work to work. (Grove lists more than 250 ornaments for French harpsichord music.)
>
> The most efficient way to deal with Christine's question is to look at both fig. bass and ornaments in a similar way. Unicode is unlikely ever to have assignments for all graphical ornament renderings.
>
> It is also unlikely to have all graphical renderings of fig. bass, since within fig. bass the means of indicating figures like 6# are variable. We have noticed that the order in which multiple-component figures are presented in a source (6#, #6) is variable.
>
> Note that fig. bass parts are prone to error in the figural signs, so there are instances in which one would ideally have a system that indicates what occurs in the source and what the correct figure in the source should be. From that information, a look-up table for the modern rendering can be constructed.
>
> Eleanor
>
>
> Eleanor Selfridge-Field
> Consulting Professor
> Braun Music Center #129
> Stanford University
> Stanford, CA 94305-3076
> http://www.stanford.edu/~esfield/
>
> ----- Original Message -----
> From: "Christine Siegert" <siegert at udk-berlin.de>
> To: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
> Sent: Thursday, October 28, 2010 6:52:37 AM
> Subject: Re: [MEI-L] figured bass
>
> Dear all,
> I am not sure if you have considered it yet, but I think the numbers for the
> figured bass should preferrably not use "#" or its unicode equivalent, but
> something like "sharp" or "natural" or "flat" because sometimes the sharp or
> the natural is indicated in the sources simply by crossing the end of a
> number, and I am not sure that there are unicode equivalents for these
> signs.
> All the best,
> Christine
>
>
> Prof. Dr. Christine Siegert
> Universität der Künste Berlin
> Musikwissenschaft, Fakultät Musik
> Fasanenstr. 1B, D-10623 Berlin
>
> Postanschrift: Postfach 12 05 44, D-10595 Berlin
> Tel.: +49 (0)30-3185-2318
> ----- Original Message -----
> From: "Johannes Kepper" <kepper at edirom.de>
> To: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de>
> Sent: Thursday, October 28, 2010 11:04 AM
> Subject: Re: [MEI-L] figured bass
>
>
>> Hi all,
>>
>> thanks for all these contributions. I think this is a pretty good exercise
>> for Maja and Kristina, our new collaborators here in Detmold. With some
>> help from Benni we will try to draft a model for a richer encoding of
>> figured bass in MEI. Obviously we need the current flexibility for more
>> distant repertoires, but I think we all agree that figured bass is _very_
>> important, even within CMN. I think Benni is right that we should address
>> it directly, perhaps just by adding some syntactic sugar, perhaps by
>> providing a complete new model.
>> Although I can't promise anything, we hope to come up with a draft by the
>> end of next week. Of course we're happy for any input / suggestions /
>> hints / feelings – either before that date or afterwards on the list :-)
>>
>> Best regards,
>> Johannes
>>
>>
>>
>> Am 28.10.2010 um 10:48 schrieb Benjamin Wolff Bohl:
>>
>>> Hi all,
>>>
>>> I'd like to contribute to the current figured bass thread
>>>
>>>> I'm not absolutely committed to the current model of <harm>. I'd
>>>> welcome any suggestions for improving it. However, there are multiple
>>>> ideas on what "logical" means with regard to the notation of harmony.
>>>> For some uses "Cm7" is appropriate, while for some uses "7" is the way
>>>> to go. For other uses, a guitar fretboard diagram or how ever harmony
>>>> is notated in the Far East are better alternatives. Even "traditional"
>>>> figured bass has changed over time.
>>>
>>> In my opinion it should not be the first question of how a <harm> element
>>> will eventually be rendered when it comes to producing score-output. Of
>>> course Cm7 or 7 or a fretboard diagram are all models that could also be
>>> in the source to code, but the main aim should be to support encoding
>>> them semantically ("logical"?). i.e. to make every part of information
>>> accessible and identifiable in it's meaning and thus processable.
>>> For example, when encoding a 7 #3:
>>>> Text in MEI *can* contain musical symbols included in Unicode. For
>>>> example, the standard sharp and flat signs are at U+266F and U+266D,
>>>> respectively.
>>> <stack delim=";">7;U+266F 3;</stack>
>>>
>>> The above would be sufficient, but how should I access it in order to
>>> process it; I would be in need of a strict model how to process the text
>>> in order to get all the info I want to access; but operating in XML I
>>> don't see the point of not using a richer encoding. The figures could be
>>> encoded using the <num>-element but still this it not semantic, and in
>>> need of splitting the stack into units.
>>>
>>> <stack delim=";">
>>> <num>7</num>;U+266F<num>3</num>;
>>> </stack>
>>>
>>> Using an attribute the num-Elements could be specified e.g. as
>>> @n="figuredBass". (By the way, the description of num says it can be used
>>> when you want to identify it by a type attribute, but the @type is not
>>> available in num, which is why I used @n in the example).
>>>
>>> As Maja mentioned figured bass has even more specialities that should be
>>> treated:
>>>>> the current model of harm, […] doesn't provide "logical" access to
>>>>> slashed numbers, individual extensions and so on.
>>>
>>> In an older thread Perry pointed out that a slashed figure could be
>>> encoded using rend:
>>>
>>> <rend rend="slash">5</rend>
>>>
>>> This clearly is a correct transcription in matters of graphical rendition
>>> but the semantics of the fifth actually being flat is not included.
>>> Moreover in an edition, the original rendition might differ from the
>>> intended output. This could be tackled by applying <orig> and <reg>
>>> elements. Which, as I just noticed, in addition give access to the
>>> <accid> element.
>>>
>>> <note pname="a" oct="3" dur="4"/>
>>> <harm staff="1" dur="4" tstamp="1" place="below">
>>> <num>7</num>
>>> <orig>
>>> <accid accid="x"/>
>>> </orig>
>>> <reg>
>>> <accid accid="s"/>
>>> </reg>
>>> <num>3</num>
>>> </harm>
>>>
>>> A remaining issue is how to group corresponding figures and accidentals
>>> and how to deal with individual extensions (and potential other issues).
>>> Of course this could be done using <stack> but only with all the
>>> mentioned drawbacks. I'd prefer eneabling nested <harm>-elements but
>>> that' not currently possible:
>>>
>>> <note pname="a" oct="3" dur="4"/>
>>> <harm staff="1" dur="4" tstamp="1" place="below" n="figuredBass">
>>> <harm dur="4" extender="true">
>>> <num>7</num>
>>> </harm>
>>> <harm>
>>> <orig>
>>> <accid accid="x"/>
>>> </orig>
>>> <reg>
>>> <accid accid="s"/>
>>> </reg>
>>> <num>3</num>
>>> </harm>
>>> </harm>
>>> <note pname="d" oct="3" dur="4"/>
>>> <harm staff="1" dur="4" tstamp="5" place="below" n="figuredBass">
>>> <harm>
>>> <num>5</num>
>>> </harm>
>>> <harm>
>>> <num>3</num>
>>> </harm>
>>> </harm>
>>>
>>> This would allow for quite a lot, although it should be tested.
>>> An open issue: How to indicate on the harm[@tstamp = 5] that its nested
>>> harm/num/text(5) is actually being extended from the foregoing one.
>>>
>>>
>>>> The point is that there is no single "logical" method -- short of
>>>> inventing a new method that will probably have its own idiosyncracies
>>>> and that will require converting existing notations to it. My desire
>>>> was to allow the capture of as many existing systems as possible. With
>>>> this in mind, I settled on using formatted text as a solution. In my
>>>> opinion, given the wide range of stuff to be accommodated, this is the
>>>> best approach.
>>>
>>> Nesting multiple <harm>-elements still would allow entering text only if
>>> one is not in need of semantically encoding the figured bass.
>>>
>>> So far… hoping for further contributions and discussion.
>>> Cheers
>>> Benjamin
>>>
>>>
>>> ***********************************************************
>>> Edirom - Projekt "Digitale Musikedition"
>>> Musikwissenschaftliches Seminar Detmold/Paderborn
>>> Gartenstraße 20
>>> D – 32756 Detmold
>>>
>>> Tel. +49 (0) 5231 / 975-669
>>> Fax: +49 (0) 5231 / 975-668
>>> ***********************************************************
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _______________________________________________
> 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
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list