[MEI-L] figured bass
Johannes Kepper
kepper at edirom.de
Thu Oct 28 20:13:35 CEST 2010
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
More information about the mei-l
mailing list