[MEI-L] @clef* inside scoredef

[Roland, Perry (pdr4h)]

> 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?

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com]
Sent: Friday, December 09, 2011 3:01 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] @clef* inside scoredef

2011/12/8 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> I think you're asking -- Why are the clef* attributes allowed on
> <scoreDef> but the <clef> element isn't allowed as a child of <scoreDef>?
> Is that right?
>

Right.

>
> I've been waiting for someone else to notice this before I brought it up
> myself :) because I anticipated that the next request would be for <clef>
> and <meter> elements and so on until all the attributes on <scoreDef> were
> duplicated by element children.  I was hoping to limit these requests to
> those that couldn't be fulfilled by an attribute -- in other words, where
> more than one value might be needed or where more detailed data was needed,
> such as explicit placement information on the accidentals in a key
> signature.
>
>
>
> But, the tech group could/should discuss adding <clef> (and perhaps
> <clefGrp>) as well -- these are members of model.staffDefPart. Next, maybe
> <meter>.  These can all be proposed for the next, next MEI revision
> (2013?).  But, we must be careful because if the list of new elements for
> <scoreDef> goes much beyond these, then it will have ripple effects
> throughout the schema that will require much more discussion / work.
>

Maybe less is more?  Couldn't the clef attributes be removed from
<scoreDef>?  I might be missing the reason why they were allowed there
in the first place.  A clef doesn't make sense without a staff, and
where there's a staff, there is a <staffDef> where the clef attributes
and elements can go.  What do clef attributes inside the <scoreDef> of
a multi-staff score mean anyway?

Thomas

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l