[MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
Laurent Pugin
lxpugin at gmail.com
Wed May 27 09:27:52 CEST 2015
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150527/a6753ebc/attachment.html>
More information about the mei-l
mailing list