[MEI-L] @clef* inside scoredef
TW
zupftom at googlemail.com
Fri Dec 9 16:20:20 CET 2011
2011/12/9 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> What do clef attributes inside the <scoreDef> of a multi-staff score mean anyway?
>
> Ahh, I'm so glad you asked. I was wondering whether I shouldn't have added this to my response yesterday. ;)
>
> The attributes on <scoreDef> were originally intended to carry *software default* values; that is, they would be a place to store values that could be used to 1) supply inheritable values when a following element, say, a <staffDef> or <staff> somewhere down in the document, lacked a clef and 2) to supply default values when programmatically creating new elements.
>
> As an example of point 2 above, if the value of @clef.shape and @clef.line on <scoreDef> were set to "C" and "3", respectively, then a score editor could put an alto clef on every newly created staff. This also works at the staff and layer levels -- @clef.shape and @clef.line on <staffDef> "over-ride" the values given at the score-level and these attributes on <layerDef> supercede those at the staff-level.
>
> So, "def" in the original sense, meant "default"; it was only later than "def" came to mean "definition". But reframing <scoreDef> this way is useful because it means that the element can be used throughout the document to indicate changes.
>
> Even so, when using MEI to *describe existing notation*, you're right -- some attributes on <scoreDef> aren't particularly useful. Or put a different, hopefully better way, it's better to use those attributes on <staffDef> and <layerDef>. It's a good thing they're optional. :)
>
> Helpful?
Yes, that makes the reasoning clear. (Hey, I have a *great* idea:
Let's introduce yet another domain, the processing domain!! ...
Cough, O.K., I'll go back to my corner and remain quiet.)
Thomas
More information about the mei-l
mailing list