[MEI-L] Problems encoding CMN

Fri Jan 27 11:22:19 CET 2017

Hi,

In the next version of MEI there will be a <ligatureSpan> for this. See
https://github.com/music-encoding/music-encoding/issues/274

Best wishes,
Laurent

On Fri, Jan 27, 2017 at 2:38 AM, Craig Sapp <craigsapp at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20170127/26a9c208/attachment.html>