[MEI-L] Uniqueness and Consistency of @n for <staff> and <layer>

[Christopher Antila]

Hello again!

After some contemplation (and more reading), I can answer my own
questions.

On Fri, 2014-06-20 at 10:13 -0400, Christopher Antila wrote:
> Greetings to the MEI community!
> 
> I'm working on a Python module to import MEI files to the "music21"
> library. I've noticed the MEI Guidelines tend toward flexibility, which
> is good, but I'd like to request clarification on a couple of edge
> cases.
> 
> My questions stem from the nesting of staff and measure objects. In
> music21, a Part (analogous to <staff>) holds Measure objects
> (<measure>), which in turn hold Voice objects (<layer>). Every Part
> therefore runs continuously from beginning to end. In MEI this is
> slightly different: a <measure> holds a <staff>, which holds <layers>.
> Therefore, when importing an MEI <measure>, music21 must determine which
> Part a <staff> tag corresponds to, using the @n and @def attributes. But
> when do those change, and how unique are they?
> 
> Can I rely on @n attributes shared by a <staff> and <staffDef> to be
> unique within a <score>? Or should I account for the possibility that
> the same "source document" staff may have its <staff> tag's @n attribute
> changed by a <staffDef> part-way through the <score>?
> 
> Example... is this valid?
> <measure>
>    <staff n="1">
>       <staffDef n="1">the only tuba part</staffDef>
>    </staff>
> </measure>
> <measure>
>    <staff n="2">
>       <staffDef n="2">the same tuba part with a new @n</staffDef>
>    </staff>
> </measure>
> 
> What if we add a new instrument in the second <measure>, so the same @n
> attribute refers to a different <staff>/<staffDef> combination at
> different times?
> <measure>
>    <staff n="1">
>       <staffDef n="1">the only tuba part</staffDef>
>    </staff>
> </measure>
> <measure>
>    <staff n="1">
>       <staffDef n="1">a new clarinet part with previously-used
> @n</staffDef>
>    </staff>
>    <staff n="2">
>       <staffDef n="2">the same tuba part with a new @n</staffDef>
>    </staff>
> </measure>
> 
> Also, can I trust that every <layer> has an @n that's unique across the
> whole <score>? Or is it that a <layer>'s @n attribute will be unique
> only within its <staff> context?
> 
> Example... is this possible?
> <measure>
>    <staff n="1">
>       <staffDef n="1">clarinet parts</staffDef>
>       <layer n="1"></layer>
>       <layer n="2"></layer>
>    </staff>
>    <staff n="2">
>       <staffDef n="2">tuba parts</staffDef>
>       <layer n="1"></layer>
>       <layer n="2"></layer>
>    </staff>
> </measure>
> 
> Finally, should I account for a situation where the same staff has
> <staff> tags bound to a <staffDef> occasionally with @n and occasionally
> with @def?
> 
> Consider this situation:
> <staffDef n="1" xml:id="2c64" />
> <staff n="1" />
> <staff def="#2c64" />
> <staff n="1" def="#2c64" />
> 
> The Guidelines say a <staff> tag "should always refer to a <staffDef>
> element, using either an @n or @def attribute," so I assume the third
> <staff> tag, which has both @n and @def, is not valid (pg.68ff, if
> you're following along). The Guidelines do show an analogous situation,
> where a <staffDef> defines both @n and @id, and the following two
> <staff> tags use @def then @n. In the example these tags are separated
> by "or" in a comment, but this seems like it's only a per-tag "or," not
> a per-document "or."
> 
> Thanks in advance for your guidance. I'd be happy to clarify any of
> these situations.

The key is this paragraph from the 2013 MEI Guidelines:
"Every <staffDef> must have an @n attribute with an integer as its
value. The first occurrence of a <staffDef> with a given number must
also indicate the number of staff lines via the @lines
attribute." (pg.71)

If only the first <staffDef> with an @n value must indicate the number
of staff lines, this implies that all the following <staffDef> tags with
the same @n attribute will refer to the same source-document staff.
Furthermore, it implies that <staffDef> tags "cascade" hierarchically,
so a <staffDef> in a <measure> is only required to provide the
attributes it intends to override from a <staffDef> in a <section>.
Finally, the @n attribute must therefore be unique within its tag-space.

Going through my examples:
<measure>
   <staff n="1">
      <staffDef n="1">the only tuba part</staffDef>
   </staff>
</measure>
<measure>
   <staff n="2">
      <staffDef n="2">the same tuba part with a new @n</staffDef>
   </staff>
</measure>

This doesn't produce the desired result. The two <staff> tags here
should be interpreted as different source-document staves.

Next example:
<measure>
   <staff n="1">
      <staffDef n="1">the only tuba part</staffDef>
   </staff>
</measure>
<measure>
   <staff n="1">
      <staffDef n="1">a new clarinet part with previously-used
@n</staffDef>
   </staff>
   <staff n="2">
      <staffDef n="2">the same tuba part with a new @n</staffDef>
   </staff>
</measure>

This doesn't produce the desired result either. In the second measure,
the clarinet part will appear on the same staff as the previous
measure's tuba part, and the tuba part will appear on a new staff.

Finally, this example:
<staffDef n="1" xml:id="2c64" />
<staff n="1" />
<staff def="#2c64" />
<staff n="1" def="#2c64" />

The third <staff> tag is invalid because the Guideliness require
*either* @n or @def. Both of the other <staff> tags are valid and work
as expected.

I also have a new situation. Consider this:
<staffDef n="1" xml:id="asdf" lines="5" />
<staff xml:id="a" n="1" />
<staffDef n="1" xml:id="sdfg" lines="4" />
<staff xml:id="b" n="1" />
<staff xml:id="c" def="asdf" />

How many lines for each of these <staff> tags? Going by XML ID, <staff>
"a" will have five lines, "b" will have four, and "c" will have five. Is
this right?

Thanks again for your guidance.


Christopher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140625/1d70dc90/attachment.sig>