[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