[MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
Laurent Pugin
lxpugin at gmail.com
Thu May 28 10:26:53 CEST 2015
On Thu, May 28, 2015 at 12:03 AM, Roland, Perry D. (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:
> 1) <grpSym> provides a standoff method of handling overlapping groups of
> staves. It could also be used inside <part>.
>
This makes sense, I was not aware of it. Is there any example how this
works? I can see it can contain a staffGrp, but then I am a bit lost. Sorry!
>
>
> 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.
>
This makes sense too.
One question regarding the use of parts with a @form="logical". You are
saying "In this case, any layout parameters would be ignored in favor of
those provided within <score> and its descendants."
Does this mean that you would expect to have both <score> and <parts> in
the encoding? Then, would you duplicate the content (staves, layers, notes,
etc.)? Maybe you want to do this in some cases, but I assume in most cases
you would like to avoid it and just point to the content provided in one of
them. I am sure this is possible (even though I am not perfectly clear how
to do it), but is seems that it would make simple cases quite complex.
>
>
> --
>
> 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> 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] *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> 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. J
>
>
>
> --
>
> 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> 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> 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> 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
> T +32 472 52 75 59
>
> 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>
> 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>
> wrote:
>
>
>
> On May 22, 2015, at 9:16 AM, Hans Vereyken <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
> T +32 472 52 75 59
>
> 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>
> 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> 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
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
>
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
>
>
> _______________________________________________
> mei-l mailing list
> 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
> 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/20150528/47df55e7/attachment.html>
More information about the mei-l
mailing list