[MEI-L] figured bass

[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
***********************************************************


-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20101028/e9a8a5cc/attachment.htm>