[MEI-L] Problems encoding CMN

Fri Jan 27 02:38:29 CET 2017

Hi Giuliano,

One possibility is to use the type attribute:

<line type="ligature">

Also the "label" attribute seems like a possibility:

<line label="ligature">

-=+Craig

On 26 January 2017 at 17:19, Di Bacco, Giuliano <gdibacco at indiana.edu>
wrote:

> Thanks for reminding us about this, Craig; this does need discussion
> indeed.
>
> I can live with the ligature element that remains specific to the mensural
> module,  but then in CMN I would expect an attribute on line to indicate a
> transcription of notes originally in a mens.ligature, otherwise an
> important piece of information would be lost in translation. Any line
> (bracket) has a "function" ,  isn't it?
>
>
> --
>
> Giuliano Di Bacco
> *from a small mobile device: excuse brevity and typos*
> On Jan 27, 2017, at 01:32, Craig Sapp <craigsapp at gmail.com> wrote:
>>
>> Here is a note from Perry from Sept 2015 to the MEI-L mailing list about
>> this topic:
>>
>>
>>
>> Line is the appropriate entity.  I can hear the sighs now, but the
>> ligature element in MEI is not intended for these brackets – “The
>> ligature element should not be used for brackets in modern notation that
>> indicate notes that were part of a ligature in the original source.”
>> (from the description of ligature in the schema) and so it’s currently
>> in the MEI.mensural module – it disappears when MEI.mensural is not
>> invoked.  Creation of a similar entity for CMN or merging of ligatures
>> in both repertoires is a possibility, but the topic needs discussion.
>>
>>
>>
>> Currently, a line can only be positioned relative to the objects
>> referenced by its @startid and @endid attributes using @start(ho|to|vo) and
>> @end(ho|to|vo).  But, I don’t think there’s any reason not to allow
>> @tstamp, @tstamp2, @staff, @layer and @place.  Even so, I think the best
>> (that is, most precise) way to position lines is by associating them with
>> specific events or time stamps.  The @staff, @layer, @place attributes can
>> only be useful for making sure the lines associated with a particular staff
>> are considered when processing that staff’s data, for instance when
>> rendering a single staff (e.g., part extraction).
>>
>>
>>
>> In any case,have a look at the mei-all_anyStart.odd in /develop-perry.
>> Line has undergone some significant changes.  Its new attributes:
>>
>>
>>
>> form:                   dashed, dotted, solid, wavy
>>
>> width:                 narrow, medium, wide, or numeric value + unit
>> (cm|mm|in|pt|pc|px|vu)
>>
>> endsym:             angledown -- 90 degree turn down (similar to Unicode
>> 231D at end of line, 231C at start).
>>
>> angleup -- 90 degree turn up (similar to Unicode 231F at end of line,
>> 231E at start)
>>
>> angleright -- 90 degree turn right (syntactic sugar for "angledown" for
>> vertical or angled lines).
>>
>> angleleft -- 90 degree turn left (syntactic sugar for "angleup" for
>> vertical or angled lines).
>>
>> arrow -- Filled, triangular arrowhead (similar to SMuFL U+EB78).
>>
>> arrowopen -- Open triangular arrowhead (similar to SMuFL U+EB8A).
>>
>> arrowwhite -- Unfilled, triangular arrowhead (similar to SMuFL U+EB82).
>>
>> harpoonleft -- Harpoon-shaped arrowhead left of line (similar to
>> arrowhead of Unicode U+21BD).
>>
>> harpoonright -- Harpoon-shaped arrowhead right of line (similar to
>> arrowhead of Unicode U+21BC).
>>
>> none -- No start symbol.
>>
>> endsymsize:      1-9 (relative size)
>>
>> startsym:            [same as endsym]
>>
>> startsymsize:     [same as endsym]
>>
>>
>>
>> Andrew, when you say you’re supporting MEI 3.0.0 in SibMEI, are you
>> using these new attributes?
>>
>>
>>
>>
>> On 26 January 2017 at 13:57, Andrew Hankinson <
>> andrew.hankinson at mail.mcgill.ca> wrote:
>>
>>> Hi Daniel,
>>>
>>> You've (perhaps unknowingly) stumbled on one of the core tenets of MEI
>>> -- the separation of the semantic and the symbol.
>>>
>>> In MEI, you wouldn't encode the brackets; you would rather encode the
>>> function of the brackets, and leave it to a renderer to deal with adding
>>> the brackets around it.
>>>
>>> There are many 'semantic' places where you may see a bracket ('semantic'
>>> here is in reference to the function of the encoding in describing intent,
>>> rather than describing appearance). You could, for example, use elements
>>> such as 'supplied,' 'sic/corr', or 'orig/reg' to describe why the
>>> accidental should be drawn in brackets in an MEI-aware renderer.
>>>
>>> The same applies to your ligature question. You wouldn't place a line
>>> above a staff in MEI to indicate a ligature; you would instead find a way
>>> to encode the grouping of these notes into a ligature. It will then be up
>>> to the renderer to display that with a line above.
>>>
>>> -Andrew
>>>
>>>
>>>
>>> > On Jan 26, 2017, at 10:40 PM, Daniel Alles <
>>> DanielAlles at stud.uni-frankfurt.de> wrote:
>>> >
>>> > New day, new questions - I hope this will get better soon...
>>> >
>>> > Dear all,
>>> >
>>> > is there a possibility to encode an accidental in brackets (if
>>> possible above the staff)? I use them in my transcription of mensural
>>> notation to indicate where I think might be missing one but should be
>>> there. The Guidelines only mention "regular" accidentals (without
>>> brackets).
>>> >
>>> > How can I use brackets (in CMN) above the staff to indicate a ligature
>>> in the MN-source? And what about coloration in the source? For that I
>>> normaly use half brackets (see attached PDF). How can I encode something
>>> similar?
>>> >
>>> > I hope, someone can help me with that.
>>> >
>>> > Best regards,
>>> > Daniel
>>> > <01_heugel_magnificat_cmn.pdf> ______________________________
>>> _________________
>>> > 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/20170126/b0171980/attachment.html>