[MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
Roland, Perry D. (pdr4h)
pdr4h at eservices.virginia.edu
Thu May 28 00:03:10 CEST 2015
1) <grpSym> provides a standoff method of handling overlapping groups of staves. It could also be used inside <part>.
2) Yes, @part on <layerDef> would be necessary.
Making @part available also on events (note, chord, rest, etc.) would make it possible to “disentangle” ambiguities at the sub-layer level and make it possible to create/accommodate/process note-list-like markup.
--
p.
From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin
Sent: Wednesday, May 27, 2015 5:36 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
I'll need some time to digest this. Two remarks.
1) I understand the possibility to have a logical group of parts. This indeed solves the issue of the part identification. However, this is not equivalent to a score. For example, where would you have the staff groups that group several parts represented? If we have all string instruments separated each of them in one part, we cannot (easily?) encode that there is a staff group with a bracket englobing them. Or I am overlooking something?
2) I thought about a @part. This might be the missing piece, and is in a way similar to the @player proposed by Hans. I guess we would also need it on <layerDef> for the case where we have two parts in one staff.
OK, now I go and digest it...
Laurent
On Wed, May 27, 2015 at 11:00 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:
I support the intention/motivation of the proposal, but it raises some issues:
Moving <instrDef> out of the MIDI module doesn’t comply with its current definition because <instrDef> provides a description of a *MIDI instrument*, not a generic instrument. That role is handled somewhat by <instrVoice>, but, as already noted, because <instrVoice> is a child of <instrumentation>, which has a descriptive function and is placed within <meiHead>, pointing to it could be problematic.
Also, if @instr pointed to <instrVoice>, the info provided by <instrDef> would be orphaned/inaccessible. The attributes provided by <instrDef> could be moved to or duplicated on <instrVoice>, but moving them would create a backward compatibility problem and duplicating them would create a processing problem (that is, the same data could potentially be recorded in multiple locations).
Since there are potentially overlapping hierarchies, I believe that the staff, part, and instrument entities should be independent of each other. Using @instr in the way suggested by the proposal creates too close an association between part and instrument concepts. How, for example, would doubling (one performer playing multiple instruments from a single printed part) be accounted for?
A potential solution is to employ <part> for the part-organizing concept, not just a physical part. By adding an attribute to <parts>, <part> can be used to capture both physical and conceptual parts. In essence, we get *part-based markup of the score* for free. Since I’ve spent so much time emphasizing it, I get your point of view that a <part> element can ONLY represent a physically independent thing in MEI. But, that was mostly a way to make sure that everyone got the idea that parts are *independent* of the score, not *components* of the score as in MusicXML. Physical and conceptual parts can maintain this independence even while using the same element. For example,
<parts form="physical">
<part>
<scoreDef page.width="8.5in" page.height="11.0in">
<staffGrp>
<instrDef midi.instrname="Flute" midi.track="1"/>
<staffDef n="1" clef.line="2" clef.shape="G"/>
</staffGrp>
</scoreDef>
</part>
<part>
<scoreDef page.width="11.0in" page.height="8.5in">
<staffGrp>
<instrDef midi.instrname="Acoustic_Grand_Piano" midi.track="2"/>
<staffDef n="1" clef.line="2" clef.shape="G"/>
<staffDef n="2" clef.line="4" clef.shape="F"/>
</staffGrp>
</scoreDef>
</part>
</parts>
represents a set of physically separate parts, each with its own staff definitions, MIDI instrument assignment, and, as an additional bonus, its own layout parameters. Changing @form to “logical” allows the same markup to function as a part-wise representation of the score (to borrow a term from MusicXML). In this case, any layout parameters would be ignored in favor of those provided within <score> and its descendants.
On the other hand, if the grouping of the staves of a score into parts is our only goal, then another, much simpler approach is possible. Adding @part on <staffDef> permits the grouping of staves into parts independently of the grouping provided by <staffGrp>. For example,
<scoreDef key.sig="3f" key.pname="c" key.mode="minor" meter.count="4" meter.unit="4"
meter.sym="common" system.leftline="true">
<staffGrp>
<staffGrp barthru="false" symbol="bracket">
<staffDef xml:id="P1" n="1" clef.shape="G" clef.line="2" lines="5" part="Flute">
<instrDef midi.instrname="Flute"/>
</staffDef>
<staffDef xml:id="P2" n="2" clef.shape="F" clef.line="4" lines="5" part="Tuba">
<instrDef midi.instrname="Tuba"/>
</staffDef>
</staffGrp>
<staffGrp barthru="true" label="Piano" symbol="brace">
<instrDef midi.instrname="Acoustic_Grand_Piano"/>
<staffDef xml:id="P3" n="3" clef.shape="G" clef.line="2" lines="5" part="piano"/>
<staffDef xml:id="P4" n="4" clef.shape="F" clef.line="4" lines="5" part="piano"/>
</staffGrp>
</staffGrp>
</scoreDef>
And the association of staves with MIDI instruments is also preserved.
If the keyboard accompaniment is for organ instead of piano, the following markup can be used --
<scoreDef key.sig="3f" key.pname="c" key.mode="minor" meter.count="4" meter.unit="4"
meter.sym="common" system.leftline="true">
<staffGrp>
<staffGrp barthru="false" symbol="bracket">
<staffDef xml:id="_P1" n="1" clef.shape="G" clef.line="2" lines="5" part="Flute">
<instrDef midi.instrname="Flute"/>
</staffDef>
<staffDef xml:id="_P2" n="2" clef.shape="F" clef.line="4" lines="5" part="Tuba">
<instrDef midi.instrname="Tuba"/>
</staffDef>
</staffGrp>
<staffGrp>
<instrDef midi.instrname="Church_Organ"/>
<staffGrp barthru="true" >
<staffDef xml:id="_P3" n="3" clef.shape="G" clef.line="2" lines="5" part="Organ"/>
<staffDef xml:id="_P4" n="4" clef.shape="F" clef.line="4" lines="5" part="Organ"/>
</staffGrp>
<staffDef n="5" lines="5" clef.shape="F" clef.line="4" part="organ"/>
</staffGrp>
</staffGrp>
</scoreDef>
Note the placement of the instrument definition for the organ to indicate that all 3 staves should be played using the same patch.
And if there are 2 tubas (both written on the same staff) --
<scoreDef key.sig="3f" key.pname="c" key.mode="minor" meter.count="4" meter.unit="4"
meter.sym="common" system.leftline="true">
<staffGrp>
<staffGrp barthru="false" symbol="bracket">
<staffDef xml:id="_P1" n="1" clef.shape="G" clef.line="2" lines="5" part="Flute">
<instrDef midi.instrname="Flute"/>
</staffDef>
<staffDef xml:id="_P2" n="2" clef.shape="F" clef.line="4" lines="5" part="Tuba">
<layerDef n="1">
<instrDef midi.instrname="Tuba"/>
</layerDef>
<layerDef n="2">
<instrDef midi.instrname="Tuba"/>
</layerDef>
</staffDef>
</staffGrp>
<staffGrp>
<instrDef midi.instrname="Church_Organ"/>
<staffGrp barthru="true" symbol="brace">
<staffDef xml:id="_P3" n="3" clef.shape="G" clef.line="2" lines="5" part="Organ"/>
<staffDef xml:id="_P4" n="4" clef.shape="F" clef.line="4" lines="5" part="Organ"/>
</staffGrp>
<staffDef n="5" lines="5" clef.shape="F" clef.line="4" part="Organ"/>
</staffGrp>
</staffGrp>
</scoreDef>
One more possibility -- use @part on <staffDef> and <staffGrp> to indicate that the staff or staff descendants of the group bearing this attribute constitute a distinct part. In this case, @part functions as a marker and only needs one value, e.g. “true” --
<scoreDef key.sig="3f" key.pname="c" key.mode="minor" meter.count="4" meter.unit="4"
meter.sym="common" system.leftline="true">
<staffGrp>
<staffGrp barthru="false" symbol="bracket">
<staffDef xml:id="_P1" n="1" clef.shape="G" clef.line="2" lines="5" part="true">
<instrDef midi.instrname="Flute"/>
</staffDef>
<staffDef xml:id="_P2" n="2" clef.shape="F" clef.line="4" lines="5" part="true">
<layerDef n="1">
<instrDef midi.instrname="Tuba"/>
</layerDef>
<layerDef n="2">
<instrDef midi.instrname="Tuba"/>
</layerDef>
</staffDef>
</staffGrp>
<staffGrp part="true">
<instrDef midi.instrname="Church_Organ"/>
<staffGrp barthru="true" symbol="brace">
<staffDef xml:id="_P3" n="3" clef.shape="G" clef.line="2" lines="5"/>
<staffDef xml:id="_P4" n="4" clef.shape="F" clef.line="4" lines="5"/>
</staffGrp>
<staffDef n="5" lines="5" clef.shape="F" clef.line="4"/>
</staffGrp>
</staffGrp>
</scoreDef>
Here, the @part attribute for the organ moves to the <staffGrp> containing all the staves of the part.
For the ultimate in flexibility; that is, to be able to create “custom” parts from any combination of staves, standoff markup can be used. For example,
<scoreParts>
<partDef staves="1" staffids="_P1"/>
<partDef staves="2" staffids="_P2"/>
<partDef staves="3 4 5" staffids="_P3 _P4 _P5"/>
</scoreParts>
indicates the same part arrangement as the previous markup example, but
<scoreParts>
<partDef staves="1 2" staffids="_P1 _P2"/>
<partDef staves="3 4" staffids="_P3 _P4"/>
<partDef staves="5" staffids="_P5"/>
</scoreParts>
would represent 3 parts -- one made up of staves 1 & 2, another of staves 3 & 4, and one containing only the pedals of the organ. The <partDef> could use either staff numbers or IDs to indicate the appropriate staves.
Hope this helps,
--
p.
From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Laurent Pugin
Sent: Wednesday, May 27, 2015 3:28 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
Hi Perry,
I am not sure I understand what you think of Andrew's proposal to take @instr out of the MIDI module. Does this seem a valid approach to you?
I think it would be nice to have a way to encode parts in a score-based organization in more precise way than we can now. This might serve parts extraction but other purposes. The use of <parts> seems to serve a different purpose to me, which is to encode material in parts when no score is available/desired. As you pointed out, we cannot rely on brackets and braces for this, so I also have the impression we need something more. What Hans pointed out is that currently it would not be easy to extract a piano part (by itself or with another one) precisely because what the piano part is not clearly specified.
Laurent
On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:
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<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
_______________________________________________
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/20150527/a1115723/attachment.html>
More information about the mei-l
mailing list