[MEI-L] Problems encoding CMN

Roland, Perry D. (pdr4h) pdr4h at eservices.virginia.edu
Fri Jan 27 15:03:36 CET 2017 

Hi Daniel,

The release date for MEI 4.0 has not been decided yet.  But, that's likely to be the first item on the agenda of the new Board.

That being said, you don't have to wait for the official release date.  Just follow these steps:

1. Save the ODD file attached to this message;
2. Visit http://custom.simssa.ca/;
3. Choose "Latest Development" as the MEI Release;
4. At "Choose your MEI Customization", select "Local Customization File";
5. Browse to where you saved the attached ODD and select it;
6. Hit the "Process" button; and
7. Choose "Download the Result" on the page that's returned.

You'll get back an RNG schema with the same name as the ODD file (latest_DEV.rng) that contains all the latest modifications to MEI, including <ligatureSpan>.

I encourage everyone interested in the bleeding edge of MEI to do this, not just Daniel.  I also caution everyone that there are no guarantees that come with the generated RNG.  Sometimes it works, sometimes it doesn't.  Not all of its features always end up in the next official release.  But I'm sure that most of you realize that these warnings are inherent in the phrase "Latest Development".  (http://idioms.thefreedictionary.com/You+pays+your+money)

--
p.


> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel
> Alles
> Sent: Friday, January 27, 2017 8:28 AM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] Problems encoding CMN
> 
> Thank you, Laurent, for that link, I already found that discussion and was
> wondering, how it is done at this moment. My M.A. dissertation will be made
> until august 2017, will the next version of MEI be ready by then? Is it possible
> to encode my pieces with the <line> element and convert them later into MEI
> 4.0 (into <ligatureSpan>)? Or should I encode them already with this element
> and use attributes like those mentioned by Perry? They sound useful, I would a
> <ligatureSpan> element wish to have soemthing similar...
> 
> Daniel
> 
> Zitat von Laurent Pugin <lxpugin at gmail.com>:
> 
> > 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
> >>
> >>
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
A non-text attachment was scrubbed...
Name: latest_DEV.odd
Type: application/octet-stream
Size: 266884 bytes
Desc: latest_DEV.odd
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170127/0380ca53/attachment.obj>

More information about the mei-l mailing list