No subject
Sun Oct 24 12:01:15 CEST 2010
tructed.=20
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 th=
e=20
figured bass should preferrably not use "#" or its unicode equivalent, but=
=20
something like "sharp" or "natural" or "flat" because sometimes the sharp o=
r=20
the natural is indicated in the sources simply by crossing the end of a=20
number, and I am not sure that there are unicode equivalents for these=20
signs.
All the best,
Christine
Prof. Dr. Christine Siegert
Universit=C3=A4t der K=C3=BCnste Berlin
Musikwissenschaft, Fakult=C3=A4t Musik
Fasanenstr. 1B, D-10623 Berlin
Postanschrift: Postfach 12 05 44, D-10595 Berlin
Tel.: +49 (0)30-3185-2318
----- Original Message -----=20
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 exercis=
e=20
> for Maja and Kristina, our new collaborators here in Detmold. With some=
=20
> help from Benni we will try to draft a model for a richer encoding of=20
> figured bass in MEI. Obviously we need the current flexibility for more=
=20
> distant repertoires, but I think we all agree that figured bass is _very_=
=20
> important, even within CMN. I think Benni is right that we should address=
=20
> it directly, perhaps just by adding some syntactic sugar, perhaps by=20
> providing a complete new model.
> Although I can't promise anything, we hope to come up with a draft by the=
=20
> end of next week. Of course we're happy for any input / suggestions /=20
> hints / feelings =E2=80=93 either before that date or afterwards on the l=
ist :-)
>
> 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=20
>>> welcome any suggestions for improving it. However, there are multiple=
=20
>>> ideas on what "logical" means with regard to the notation of harmony.=
=20
>>> For some uses "Cm7" is appropriate, while for some uses "7" is the way=
=20
>>> to go. For other uses, a guitar fretboard diagram or how ever harmony=
=20
>>> is notated in the Far East are better alternatives. Even "traditional"=
=20
>>> figured bass has changed over time.
>>
>> In my opinion it should not be the first question of how a <harm> elemen=
t=20
>> will eventually be rendered when it comes to producing score-output. Of=
=20
>> course Cm7 or 7 or a fretboard diagram are all models that could also be=
=20
>> in the source to code, but the main aim should be to support encoding=20
>> them semantically ("logical"?). i.e. to make every part of information=
=20
>> 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=20
>>> example, the standard sharp and flat signs are at U+266F and U+266D,=20
>>> respectively.
>> <stack delim=3D";">7;U+266F 3;</stack>
>>
>> The above would be sufficient, but how should I access it in order to=20
>> process it; I would be in need of a strict model how to process the text=
=20
>> in order to get all the info I want to access; but operating in XML I=20
>> don't see the point of not using a richer encoding. The figures could be=
=20
>> encoded using the <num>-element but still this it not semantic, and in=
=20
>> need of splitting the stack into units.
>>
>> <stack delim=3D";">
>> <num>7</num>;U+266F<num>3</num>;
>> </stack>
>>
>> Using an attribute the num-Elements could be specified e.g. as=20
>> @n=3D"figuredBass". (By the way, the description of num says it can be u=
sed=20
>> when you want to identify it by a type attribute, but the @type is not=
=20
>> available in num, which is why I used @n in the example).
>>
>> As Maja mentioned figured bass has even more specialities that should be=
=20
>> treated:
>>>> the current model of harm, [=E2=80=A6] doesn't provide "logical" acce=
ss to=20
>>>> slashed numbers, individual extensions and so on.
>>
>> In an older thread Perry pointed out that a slashed figure could be=20
>> encoded using rend:
>>
>> <rend rend=3D"slash">5</rend>
>>
>> This clearly is a correct transcription in matters of graphical renditio=
n=20
>> but the semantics of the fifth actually being flat is not included.
>> Moreover in an edition, the original rendition might differ from the=20
>> intended output. This could be tackled by applying <orig> and <reg>=20
>> elements. Which, as I just noticed, in addition give access to the=20
>> <accid> element.
>>
>> <note pname=3D"a" oct=3D"3" dur=3D"4"/>
>> <harm staff=3D"1" dur=3D"4" tstamp=3D"1" place=3D"below">
>> <num>7</num>
>> <orig>
>> <accid accid=3D"x"/>
>> </orig>
>> <reg>
>> <accid accid=3D"s"/>
>> </reg>
>> <num>3</num>
>> </harm>
>>
>> A remaining issue is how to group corresponding figures and accidentals=
=20
>> and how to deal with individual extensions (and potential other issues).=
=20
>> Of course this could be done using <stack> but only with all the=20
>> mentioned drawbacks. I'd prefer eneabling nested <harm>-elements but=20
>> that' not currently possible:
>>
>> <note pname=3D"a" oct=3D"3" dur=3D"4"/>
>> <harm staff=3D"1" dur=3D"4" tstamp=3D"1" place=3D"below" n=3D"fi=
guredBass">
>> <harm dur=3D"4" extender=3D"true">
>> <num>7</num>
>> </harm>
>> <harm>
>> <orig>
>> <accid accid=3D"x"/>
>> </orig>
>> <reg>
>> <accid accid=3D"s"/>
>> </reg>
>> <num>3</num>
>> </harm>
>> </harm>
>> <note pname=3D"d" oct=3D"3" dur=3D"4"/>
>> <harm staff=3D"1" dur=3D"4" tstamp=3D"5" place=3D"below" n=3D"figu=
redBass">
>> <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 =3D 5] that its neste=
d=20
>> harm/num/text(5) is actually being extended from the foregoing one.
>>
>>
>>> The point is that there is no single "logical" method -- short of=20
>>> inventing a new method that will probably have its own idiosyncracies=
=20
>>> and that will require converting existing notations to it. My desire=
=20
>>> was to allow the capture of as many existing systems as possible. With=
=20
>>> this in mind, I settled on using formatted text as a solution. In my=
=20
>>> opinion, given the wide range of stuff to be accommodated, this is the=
=20
>>> best approach.
>>
>> Nesting multiple <harm>-elements still would allow entering text only if=
=20
>> one is not in need of semantically encoding the figured bass.
>>
>> So far=E2=80=A6 hoping for further contributions and discussion.
>> Cheers
>> Benjamin
>>
>>
>> ***********************************************************
>> Edirom - Projekt "Digitale Musikedition"
>> Musikwissenschaftliches Seminar Detmold/Paderborn
>> Gartenstra=C3=9Fe 20
>> D =E2=80=93 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=20
_______________________________________________
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