[MEI-L] figured bass

[Christine Siegert]

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