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

[Roland, Perry D. (pdr4h)]

Hi Christopher,

Thanks for taking on this task.  A transformation from MEI to Music21 will prove very useful.

It seems you've misunderstood the use of <staffDef>.  It can be used within <staff>, but only for those special cases where some characteristic(s) of the staff changes before the end of the system.  In this case, its @n attribute can only take the value of the parent <staff>.  

Generally, it should appear within <scoreDef>, which occurs prior to the measures it influences, like so --

<scoreDef>
  <staffDef n="1"/>
  <staffDef n="2"/>
</scoreDef>
<measure n="1">
  <staff n="1">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
  <staff n="2">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
<measure n="2"/>
etc.

When the layout of the score changes, for instance with the addition of a new staff, the <scoreDef> element can be used to indicate the new configuration --

<scoreDef>
  <staffDef n="1" label="tuba"/>
</scoreDef>
<measure n="1">
  <staff n="1">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
</measure>
<scoreDef>
  <staffDef n="1" label="clarinet"/>
  <staffDef n="2" label="tuba"/>
</scoreDef>
<measure n="1">
  <staff n="1">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
  <staff n="2">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
</measure>

Here the score begins with a single staff (labeled 'tuba') and continues with 2 staves (labeled 'clarinet' and 'tuba', respectively).  As you can see, the tuba "part" begins on staff 1 and continues on staff 2; therefore, the @n value changes with respect to the "part".  No attempt, however, is made via @n on either <staffDef> or <staff> to trace the "part".

Often, however, a score is "rectangular"; that is, all staves are listed in the initial <scoreDef> whether they are immediately used or not  --

<scoreDef>
  <staffDef n="1" label="Flutes"/>
  <staffDef n="2" label="Clarinets"/>
  ...
  <staffDef n="14" label="Horns"/>
  <staffDef n="15" label="Trombones"/>
  ...
  <staffDef n="17" label="Tuba"/>
</scoreDef>

Later, only those staves with event-level data need to be enumerated.  Here, only the flutes and horns are sounding.  The other staves are assumed to be empty --

<measure n="1">
  <staff n="1">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
  <staff n="14">
    <layer n="1"><!-- notes, chords, rests, etc. --></layer>
  </staff>
</measure>

In these cases, the @n attribute values don't change with respect to a "part".  The horn "part" will always appear on staff 14.  This is the traditional way of dealing with orchestral scores and is often the method used by computer-based scoring programs.  In essence, all staves are always available even if they are not currently visible.  In MEI, each of the unused staves can be marked as invisible or scoreDef can carry an @optimize attribute, indicating that unused staves should be hidden programmatically.

When each change in score layout is indicated by a <staffDef> element, one must rely on @label attributes (or <label> elements) or @next attributes to trace the path of a part.

I've inserted additional comments below, prefaced with '***', because quoting in Outlook Lite sucks.  :-)

I hope this helps.  If you have additional questions/issues, just let us know.

--
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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Christopher Antila [christopher at antila.ca]
Sent: Wednesday, June 25, 2014 2:23 PM
To: mei-l at lists.uni-paderborn.de
Subject: Re: [MEI-L] Uniqueness and Consistency of @n for <staff> and <layer>

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.

** That's correct.  Two different staves, but a better formulation of your example is

<scoreDef>
  <staffDef n="1">the only tuba part</staffDef>
</scoreDef>
<measure>
   <staff n="1">
      <layer n="1">the tuba part on staff 1</layer>
   </staff>
</measure>
<scoreDef>
  <staffDef n="1">a new part?</staffDef>
  <staffDef n="2">the same tuba part with a new @n</staffDef>
</scoreDef>
<measure>
  <staff n="2">
     <layer n="1">tuba part now on staff 2</layer>
  </staff>
</measure>


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.

** I'm not sure what you're defining as "the desired result".  If there is no system break between the changes, then yes, the clarinet part will be on the same staff as the tuba, indicating that the clarinet player switches to the tuba.  (That would be interesting, wouldn't it?)  With a system break in place, while it will be on staff 1, the clarinet part won't be on the *same staff* as the tuba part, only on the staff formerly occupied by the tuba.
  
single staff system
  staff 1 = tuba
system break
multiple staff system
  staff 1 = clarinet
  staff 2 = tuba
system break
multiple staff system
  staff 1 = flute
  staff 2 = clarinet
  staff 3 = tuba
etc.


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?

** Yes, that's correct.


Thanks again for your guidance.


Christopher