[MEI-L] Problems encoding CMN; ligature transcription

Byrd, Donald A. donbyrd at indiana.edu
Fri Jan 27 03:51:00 CET 2017


Oops, Craig's comment and mine crossed in the email. I did miss something, namely the "type" attribute. It seems like the "label" attribute is intended to identify a specific <line>, not a category, but "type" seems to do what's needed. Giuliano?

--DAB

 
On Jan 26, 2017, at 8:38 PM, 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

---
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics
Visiting Scientist, Research Technologies
Indiana University Bloomington









More information about the mei-l mailing list