[MEI-L] Combining MEI ornament elements
Kőmíves Zoltán
zolaemil at gmail.com
Mon Jul 13 18:50:50 CEST 2015
Hi Perry,
The schema currently clearly defines <dir>
<https://music-encoding.org/documentation/2.1.1/dir/> as "a text
expression", but in the notes it says it also includes "music symbols, such
as segno and coda symbols, fermatas over a bar line, etc."
Maybe the definition could be improved to clear up the confusion? Perhaps
something like: "an instruction expressed either as text or as a symbol,
such as segno and coda symbols, fermatas over a bar line, etc."?
Zoltan
2015-07-13 17:14 GMT+01:00 Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> Hi Perry,
>
> Thanks! Looks like I made this more complicated than it needed to be. If
> this is the recommended encoding for these cases, Chapter 8 of the
> guidelines should probably recommend and explain this use of <dir>.
>
> Best,
> Raff
>
> On Mon, Jul 13, 2015 at 11:28 AM, Roland, Perry D. (pdr4h) <
> pdr4h at eservices.virginia.edu> wrote:
>
>>
>>
>> Hi Raffaele,
>>
>>
>>
>> The short answer is, <mordent>, <trill>, and <turn> can’t be combined to
>> represent more complex ornaments.
>>
>>
>>
>> The longer answer is, they weren’t intended to be used that way. These
>> elements are named, simple instances of the more generic element <dir>,
>> which should be used in cases like this. One can use character entity
>> references to either Unicode or SMuFL entities to indicate the desired
>> symbol For example,
>>
>>
>>
>> <dir></dir>
>>
>>
>>
>> The resolution of such directives should be encoded inside the stream of
>> events; that is, within <layer>. The notated and performed versions can be
>> wrapped with <choice> and its sub-elements such as <orig> and <reg>.
>>
>>
>>
>> <layer>
>>
>> <orig><!-- written note --></orig>
>>
>> <reg><!-- resolution of the ornament (probably multiple notes) --></reg>
>>
>> </layer>
>>
>>
>>
>> --
>>
>> p.
>>
>>
>>
>>
>>
>> *From:* mei-l [mailto:mei-l-bounces+pdr4h=
>> virginia.edu at lists.uni-paderborn.de] *On Behalf Of *Raffaele Viglianti
>> *Sent:* Sunday, July 12, 2015 7:18 PM
>> *To:* Music Encoding Initiative
>> *Subject:* [MEI-L] Combining MEI ornament elements
>>
>>
>>
>> Dear list,
>>
>>
>>
>> I was wondering if it is possible to combine two ornaments in MEi to
>> describe one ornament on the page.
>>
>>
>>
>> (Please forgive any possible misunderstandings because of my limited
>> knowledge of ornamentation outside of common symbols and little more.)
>>
>>
>>
>> For example how could I encode the type of mordent that in SMuFL is
>> called "mordent with release"?
>> http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/
>>
>>
>>
>> The MEI encoding would definitely depend on context. Factors that will
>> determine the encoding are: what kind of score is it in; who is the
>> composer; which geographical place is the composer writing in; time/era of
>> composition; and many more.
>>
>>
>>
>> Either way, none of the MEI elements <mordent>, <trill>, and <turn> will
>> be able to represent it adequately on its own. It will need to be a
>> combination of those elements.
>>
>>
>>
>> Based solely on my training as a pianist, I would guess that this
>> ornament should be treated as a trill plus a turn. If it were on a c note,
>> I would resolve it as d-c-d-c d-c-b-c.
>>
>> I might be wrong about the exact resolution, but bear with me for the
>> sake of discussing combining MEI ornaments.
>>
>>
>>
>> So I could encode this "mordent with release" with:
>>
>>
>>
>> <trill />
>>
>> <turn form="norm"/>
>>
>>
>>
>> I could then connect them together with @prev and @next
>>
>>
>>
>> <trill xml:id="trill_1" next="#turn_1" />
>>
>> <turn xml:id="turn_1" form="norm" prev="#turn_1"/>
>>
>>
>>
>> That could be enough for what MEI is concerned. Do you agree? Is there a
>> better way of encoding this?
>>
>>
>>
>> Finally, what if I wanted to map this to a specific rendition? eg to a
>> SMuFL code, or my own SVG drawing? -- if I understand correctly, this is
>> what the user defined symbol module is for (for some elements) [1].
>>
>>
>>
>> However, there is currently no way of using the user defined symbol
>> module for mapping one ornament element to a symbol. Though there is good
>> reason to believe this is in the process of being adjusted for the 2015
>> release [2] [3]. This will likely be done with @altsym, and/or other
>> dedicated attributes.
>>
>>
>>
>> But even with that upgrade in mind, how would I map my "combined"
>> elements with one symbol? The only solution I could think of is a bit
>> redundant, ideas?
>>
>>
>>
>> <trill xml:id="trill_1" next="#turn_1" altsym="#combinedSymbol" />
>>
>> <turn xml:id="turn_1" form="norm" prev="#turn_1"
>> altsym="#combinedSymbol"/>
>>
>> (this is invalid in MEI 2014, but possibly valid in 2015)
>>
>>
>>
>> Thanks,
>>
>> Raff
>>
>>
>>
>> [1] http://music-encoding.org/documentation/2.1.1/userSymbols/
>>
>> [2] https://github.com/music-encoding/music-encoding/issues/232
>>
>> [3]
>> https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150713/d461f799/attachment.html>
More information about the mei-l
mailing list