[MEI-L] How to distinguish different instruments in the <staffDef> and <staffGrp> elements
Raffaele Viglianti
raffaeleviglianti at gmail.com
Tue May 26 16:57:59 CEST 2015
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 listmei-l at lists.uni-paderborn.dehttps://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/20150526/1798d9dd/attachment.html>
More information about the mei-l
mailing list