[MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Wed May 27 00:39:15 CEST 2015


Hi,

There is no “promotion” or “demotion” between what is considered data and what is thought of as metadata -- there is only “separation”.

<symbolTable> exists within <scoreDef> in order to allow differing sets of symbols to be associated at multiple points within the <music> tree.  For example, movements of a multi-movement work need not refer to a single set of symbol definitions.  This makes it possible for a movement (or similar segment) to be more independent (i.e., separable) and permit software to load/track/account for only those symbols necessary to process/render the symbols associated with the segment.

While the data captured by <scoreDef> is intended to be transcriptional in nature, <instrumentation> is placed within the header (as a child of <perfMedium>) because it primarily serves a documentary purpose.  Its data model is based on metadata standards (mainly MARC) and it is a member of attribute classes that place it squarely in the bibliographic realm.  The blending of instrVoice, etc. and staffGrp, etc. would blur the distinction (a useful one, I believe) between these 2 functions.

I second Raffaele’s suggestion of exploring the potential of the <parts> element.  If the conceptual model of the “score” is a collection of parts, then instead of trying to extract the part-level information from data within <score>, why not store the data using <part> elements in the first place?  So that physically-separate and logical parts can be distinguished, it would be useful to add an attribute on <parts> to capture whether the parts are physical or logical.

While MEI can be used as a format for notation editors (and I sincerely hope it will be), I urge caution not to focus on this particular application of it too much.  Requirements for this (and other applications) are good candidates for Schematron assertions applied on top of the baseline rules.  Requiring @instr is a good example of the kind of contextual constraint that Schematron is designed for.

It is fitting that attention also be given to the tradition/convention that staves joined by a bracket are independent instruments, while those joined by a brace represent a single instrument.  A group of staves joined by a brace (such as those for the piano) should be considered a single "part".  A group of staves joined by a bracket (unless there's a further sub-grouping using a brace) represents separate parts.  (The major exception is the organ, where the staff for the pedals is not included in the brace that joins the staves for the manuals. Manuscript notation might also violate the traditional "rule" regarding the function of brackets and braces.)  The issue of separate parts written on a single staff can be handled, as Andrew has suggested, by using <layer> elements.

The generation of parts from a score could also be thought of as an interactive/transformative process that doesn’t need to be explicitly marked in the XML.  For example, why shouldn’t software offer the possibility of creating a “part” from any combination of staves/layers the user selects?  I believe a user interested in creating a piano or organ part would select the appropriate staves.  And the user might even want to create specialized parts, for example, combining the flute and tuba staves because these two players are expected to sit next to each other.  ☺

--
p.


From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti
Sent: Tuesday, May 26, 2015 10:58 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements

Hi Hans,
Thanks for joining MEI-L and for starting this interesting conversation!

Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid.
Having said that, though, I am a bit surprised to see an element like <symbolTable>, which groups user-defined symbols, be contained by <scoreDef>, while <instrumentation> is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding?
Finally, it might be useful to look at <part> as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common.

Raff


On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken <hans at neoscores.com<mailto:hans at neoscores.com>> wrote:
Hi Andrew and Laurent,

@Andrew: Yes! thats what I'm after!
So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data.

So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff.

@Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in <layerDef> and <staffDef> should be required if a part isn't one whole staff.

Thanks!
Hans

On 2015-05-26 10:48, Laurent Pugin wrote:
Hi Andrew and Hans,

This makes sense to me. I guess you would also need to have @instr in <layerDef> when there is more than one instrument represented in one staff, wouldn't you?

Laurent

On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:
I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct?

I believe what you are looking for is in the <instrumentation>, <ensemble>, <instrVoice> and <instrVoiceGrp> cluster of tags. <instrVoice> contains @count which indicates the number of performers.

http://www.music-encoding.org/documentation/guidelines2013/instrVoice

Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an <instrVoice> element, and perhaps do the same and have @instrGrp / <instrGrp> pairs as well. That way you could do:

<instrumentation>
  <instrVoiceGrp n="1">
    <instrVoice n="1" code="sa">Violin I</instrVoice>
    <instrVoice n="2" code="sa">Violin II</instrVoice>
    <instrVoice n="3" code="sb">Viola</instrVoice>
    <instrVoice n="4" code="sc">Violoncello</instrVoice>
  </instrGrp>
  <instrVoice n="6" code="pf" count="1">Piano</instrVoice>
</instrumentation>

And then:

<staffGrp instrGrp="1"> ... </staffGrp>
<staffGrp instr="6">
  <staffDef> ...treble staff... </staffDef>
  <staffDef> ...bass staff... </staffDef>
</staffGrp>

The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice.

Anyone else out there have any ideas?

-Andrew

On May 22, 2015, at 8:01 AM, Hans Vereyken <hans at neoscores.com<mailto:hans at neoscores.com>> wrote:

I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group.
The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1;
@players is required if it's isn't default.

Would this be possible?

Hans Vereyken
Developer

M hans at neoscores.com<mailto:hans at neoscores.com>
T +32 472 52 75 59<tel:%2B32%20472%2052%2075%2059>

neoScores BVBA<http://www.neoscores.com/> // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores
/////////////////////////////////////////////////////////////////////////////////////////////////////

Follow us on: Facebook<http://www.facebook.com/neoscores> // Twitter<http://twitter.com/neoscores>

On 22 May 2015 at 13:34, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:


Notating multiple parts on one staff can be done with the layerDef, looks good, thanks.

one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer.

One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake.

I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation.



Follow us on: Facebook<http://www.facebook.com/neoscores> // Twitter<http://twitter.com/neoscores>

On 22 May 2015 at 09:54, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:

On May 22, 2015, at 9:16 AM, Hans Vereyken <hans at neoscores.com<mailto:hans at neoscores.com>> wrote:

Hi Andrew,

I see, my subject title is a bit confusing, better would be: How to distinguish different players in the <staffDef> and <staffGrp> elements.

"If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)."
I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves.

But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression).


Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this.
I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin).

Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else?


This way you can keep numbering the staves top to bottom  for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts.
I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part.

Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block.

For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff:

<staffDef n="18" xml:id="P18" label="Batteria" label.abbr="Batt." lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117">
  <layerDef n="1">
    <instrDef n="Snare_Drum" xml:id="P18-X2"/>
  </layerDef>
  <layerDef n="2">
    <instrDef n="Bass_Drum" xml:id="P18-X1"/>
  </layerDef>
</staffDef>

and then in the body (for example):

<staff n="18">
   <layer n="1">
      <beam>
         <note xml:id="d1e1818" pname="f" oct="4" dur="16" stem.dir="up"
            instr="#P18-X2" pnum="61"/>
         <note xml:id="d1e1837" pname="f" oct="4" dur="16" stem.dir="up"
            instr="#P18-X2" pnum="61"/>
      </beam>
   </layer>
   <layer n="2">
      <rest xml:id="d1e1859" dur="8"/>
   </layer>
</staff>



At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor).

I think the layerDef mechanism will help here too.



To be sure we are talking about the same:
- staff: needed to notate music
- part: music performed by a single player/instrument

One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff.

Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer.

See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering).



Thanks
Hans

Hans Vereyken
Developer

M hans at neoscores.com<mailto:hans at neoscores.com>
T +32 472 52 75 59<tel:%2B32%20472%2052%2075%2059>

neoScores BVBA<http://www.neoscores.com/> // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores
/////////////////////////////////////////////////////////////////////////////////////////////////////

Follow us on: Facebook<http://www.facebook.com/neoscores> // Twitter<http://twitter.com/neoscores>

On 22 May 2015 at 00:58, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote:
Hi Hans,

Welcome to MEI!

Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else?

If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it).

If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have <staff n="2" ...>. The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not.

-Andrew

> On May 21, 2015, at 4:26 PM, Hans Vereyken <hans at neoscores.com<mailto:hans at neoscores.com>> wrote:
>
> Hi,
>
> This is my first post to the MEI mailing list.
> I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves.
>
> I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for.
>
> So each staff is declared seperatly, with the <staffGrp> certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it.
>
> In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml:
>
>                         <scoreDef meter.count="4" meter.unit="4" meter.sym="common" key.sig="0" key.mode="major">
>                             <staffGrp>
>                                 <staffGrp symbol="brace" barthru="true">
>                                     <staffDef n="1" clef.line="2" clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/>
>                                     <staffDef n="2" clef.line="2" clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/>
>                                     <staffDef n="3" clef.line="2" clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/>
>                                 </staffGrp>
>                                 <staffGrp symbol="bracket" barthru="true">
>                                     <staffDef n="4" clef.shape="G" clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" key.sig="0" label.abbr="P 1 Tr 4" lines="5"/>
>                                     <staffDef n="5" clef.line="4" clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/>
>                                     <staffDef n="6" label="Posaune 3" label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/>
>                                 </staffGrp>
>                             </staffGrp>
>                         </scoreDef>
>
> and: Chopin_Etude_op.10_no.9:
>
>                         <scoreDef meter.count="6" meter.unit="8" key.sig="4f" key.mode="minor">
>                             <staffGrp symbol="brace" barthru="true">
>                                 <staffDef n="1" clef.shape="G" lines="5" clef.line="2"/>
>                                 <staffDef n="2" clef.line="4" clef.shape="F" lines="5"/>
>                             </staffGrp>
>                         </scoreDef>
>
> So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player.
> I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise).
> In a dynamic music renderer, where you can switch parts on/off this is key information.
>
> How should it be done? Am I missing something?
>
> Thanks in advance!
> Hans Vereyken
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l


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

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


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

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


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

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


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



_______________________________________________

mei-l mailing list

mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>

https://lists.uni-paderborn.de/mailman/listinfo/mei-l


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150526/e6428b5f/attachment.html>


More information about the mei-l mailing list