[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