From bohl at edirom.de Sun Jan 1 21:49:30 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Sun, 1 Jan 2017 21:49:30 +0100 Subject: [MEI-L] MEI Board elections Message-ID: Dear MEI Community, unfortunately Christmas Holidays got in the way in contacting all nominees for the upcoming MEI Board elections. At the moment we are busy collecting the last candidate infos and statements for publication on the website prior to the elections. As soon as everything is set up the elections will start. You will receive a separate mail with the elections details. Of course the election phase will be adjusted accordingly. I’m very sorry for this inconvenience! Looking forward to a uncomplicated election phase, Sincerely Benjamin Bohl MEI Elections Officer 2016 by appointment of the MEI-Board From bohl at edirom.de Wed Jan 4 12:16:25 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Wed, 4 Jan 2017 12:16:25 +0100 Subject: [MEI-L] 2016 MEI Board elections Message-ID: Dear MEI community, we finally managed to get the 2016 MEI Board elections up and running! I thank all of those involved in preparation and especially the 7 great candidates that announced their willingness to serve on the MEI Board for 2017–2019! You can find the candidates statements at: http://music-encoding.org/community/mei-organization/elections/candidates/ The election phase starts this moment and will stop 31 Jan 2017 at 23:59 CET Your individual voting link should have reached you in a separate email by "noreply at opavote.com" with the subject "2016 MEI Board elections”. With all the best wishes for a smooth election Benjamin W. Bohl — MEI Elections Officer 2016 by appointment of the MEI Board -------------- next part -------------- An HTML attachment was scrubbed... URL: From beate.kutschke at gmx.de Fri Jan 6 09:58:26 2017 From: beate.kutschke at gmx.de (Beate Kutschke) Date: Fri, 6 Jan 2017 09:58:26 +0100 Subject: [MEI-L] Job announcement In-Reply-To: References: Message-ID: <99a30f31-bc82-3ae7-e667-c1537aa2d90c@gmx.de> Dear MEI community, Attached please find the announcement of a job for a doctoral researcher (or MA student) with knowledge in machine learning and C++. Best regards, Beate Kutschke -------------- next part -------------- A non-text attachment was scrubbed... Name: Job announcement.pdf Type: unknown/application Size: 52485 bytes Desc: not available URL: From DanielAlles at stud.uni-frankfurt.de Fri Jan 13 12:35:48 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Fri, 13 Jan 2017 12:35:48 +0100 Subject: [MEI-L] Sample encoding of mensural notation Message-ID: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Hello everyone in the world of music encoding, at the moment, I am preparing my dissertation for my M.A.-degree at the Goethe-University in Frankfurt, Germany, which I am planning to write this year about the possibilities and difficulties of editing mensural notation. Since I have barely no experience in encoding music at all (however, the tutorial an the MEI-Website was very helpful to get the first steps and to encode a first piece of CMN), I am now wondering, if I could find a sample encoding of mensural notation, to get an overview on how it is done. I tried encoding out by relating on a sample I found at http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not sure, whether I did something wrong or how else the common standard is. (If someone is interested: You can find my first attempts here: https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, all comments on them are very welcome!) I did not find any MN-sample in the sample encodings package, so could anyone please send me one? Yours sincerely, Daniel Alles -------------- next part -------------- An HTML attachment was scrubbed... URL: From esfield at stanford.edu Fri Jan 13 23:55:05 2017 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Fri, 13 Jan 2017 22:55:05 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: Hi, Daniel, There are hundreds of examples of the MEI encodings of mensural notation at the Josquin Research Project (http://jrp.stanford.edu). The data here does not originate as MEI, so the examples are a little artificial. Nonetheless, the encodings provide a simple model of what this kind of notation looks like in MEI. I looked at Dufay (http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Duf3007.2) as an arbitrary choice. (The display currently comes from MuseData.) Here is Josquin’s Miserere: http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Jos1803. Best regards, Eleanor Selfridge-Field Braun Music Center #130 Stanford University Stanford, CA 94305-3076 esfield at stanford.edu From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel Alles Sent: Friday, January 13, 2017 3:36 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Sample encoding of mensural notation Hello everyone in the world of music encoding, at the moment, I am preparing my dissertation for my M.A.-degree at the Goethe-University in Frankfurt, Germany, which I am planning to write this year about the possibilities and difficulties of editing mensural notation. Since I have barely no experience in encoding music at all (however, the tutorial an the MEI-Website was very helpful to get the first steps and to encode a first piece of CMN), I am now wondering, if I could find a sample encoding of mensural notation, to get an overview on how it is done. I tried encoding out by relating on a sample I found at http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not sure, whether I did something wrong or how else the common standard is. (If someone is interested: You can find my first attempts here: https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, all comments on them are very welcome!) I did not find any MN-sample in the sample encodings package, so could anyone please send me one? Yours sincerely, Daniel Alles -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Sat Jan 14 00:02:41 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 13 Jan 2017 23:02:41 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: Hi Daniel, Unfortunately, the files Eleanor refers to are encodings of *modern notation/measured transcriptions* of mensural notation, not encodings of mensural notation per se. They also don't validate against the latest version of MEI. :-( -- p. _________________________________________ Perry Roland Metadata Librarian for Research and Scholarship University of Virginia P. O. Box 400874 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Eleanor Selfridge-Field Sent: Friday, January 13, 2017 5:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Sample encoding of mensural notation Hi, Daniel, There are hundreds of examples of the MEI encodings of mensural notation at the Josquin Research Project (http://jrp.stanford.edu). The data here does not originate as MEI, so the examples are a little artificial. Nonetheless, the encodings provide a simple model of what this kind of notation looks like in MEI. I looked at Dufay (http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Duf3007.2) as an arbitrary choice. (The display currently comes from MuseData.) Here is Josquin’s Miserere: http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Jos1803. Best regards, Eleanor Selfridge-Field Braun Music Center #130 Stanford University Stanford, CA 94305-3076 esfield at stanford.edu From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel Alles Sent: Friday, January 13, 2017 3:36 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Sample encoding of mensural notation Hello everyone in the world of music encoding, at the moment, I am preparing my dissertation for my M.A.-degree at the Goethe-University in Frankfurt, Germany, which I am planning to write this year about the possibilities and difficulties of editing mensural notation. Since I have barely no experience in encoding music at all (however, the tutorial an the MEI-Website was very helpful to get the first steps and to encode a first piece of CMN), I am now wondering, if I could find a sample encoding of mensural notation, to get an overview on how it is done. I tried encoding out by relating on a sample I found at http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not sure, whether I did something wrong or how else the common standard is. (If someone is interested: You can find my first attempts here: https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, all comments on them are very welcome!) I did not find any MN-sample in the sample encodings package, so could anyone please send me one? Yours sincerely, Daniel Alles -------------- next part -------------- An HTML attachment was scrubbed... URL: From esfield at stanford.edu Sat Jan 14 00:10:12 2017 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Fri, 13 Jan 2017 23:10:12 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: Perry, You’re right: I’m not current with the latest version, but I passed the info on to Craig. It would obviously be best if someone from the mensural working group weighed in on this. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Friday, January 13, 2017 3:03 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Sample encoding of mensural notation Hi Daniel, Unfortunately, the files Eleanor refers to are encodings of *modern notation/measured transcriptions* of mensural notation, not encodings of mensural notation per se. They also don't validate against the latest version of MEI. :-( -- p. _________________________________________ Perry Roland Metadata Librarian for Research and Scholarship University of Virginia P. O. Box 400874 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Eleanor Selfridge-Field Sent: Friday, January 13, 2017 5:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Sample encoding of mensural notation Hi, Daniel, There are hundreds of examples of the MEI encodings of mensural notation at the Josquin Research Project (http://jrp.stanford.edu). The data here does not originate as MEI, so the examples are a little artificial. Nonetheless, the encodings provide a simple model of what this kind of notation looks like in MEI. I looked at Dufay (http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Duf3007.2) as an arbitrary choice. (The display currently comes from MuseData.) Here is Josquin’s Miserere: http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Jos1803. Best regards, Eleanor Selfridge-Field Braun Music Center #130 Stanford University Stanford, CA 94305-3076 esfield at stanford.edu From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel Alles Sent: Friday, January 13, 2017 3:36 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Sample encoding of mensural notation Hello everyone in the world of music encoding, at the moment, I am preparing my dissertation for my M.A.-degree at the Goethe-University in Frankfurt, Germany, which I am planning to write this year about the possibilities and difficulties of editing mensural notation. Since I have barely no experience in encoding music at all (however, the tutorial an the MEI-Website was very helpful to get the first steps and to encode a first piece of CMN), I am now wondering, if I could find a sample encoding of mensural notation, to get an overview on how it is done. I tried encoding out by relating on a sample I found at http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not sure, whether I did something wrong or how else the common standard is. (If someone is interested: You can find my first attempts here: https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, all comments on them are very welcome!) I did not find any MN-sample in the sample encodings package, so could anyone please send me one? Yours sincerely, Daniel Alles -------------- next part -------------- An HTML attachment was scrubbed... URL: From craigsapp at gmail.com Sat Jan 14 00:55:30 2017 From: craigsapp at gmail.com (Craig Sapp) Date: Fri, 13 Jan 2017 15:55:30 -0800 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: On 13 January 2017 at 15:02, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > They also don't validate against the latest version of MEI. :-( If an XML file specifies one version of a DTD/schema, then how it is magically supposed to validate against another version, unless the newer version is backwards compatible with the older version? In any case I am on strike at Stanford this year, so updating JRP scores to the most recent schema won't be happening anytime soon, even though it would only take me 5 minutes to do so. But as Perry says, these scores are encoded in modern notation, although they do have mensural features, such as mensural signs and preservation of original rhythmic levels (breve, semi-breve, etc). Ligature groupings are one feature that is not encoded. -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomaemartha at gmail.com Sat Jan 14 01:04:13 2017 From: thomaemartha at gmail.com (Martha Thomae) Date: Fri, 13 Jan 2017 19:04:13 -0500 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: Hi Daniel Perry is right, the JRP only contains modern transcription of mensural music. I am currently working with Mensural MEI files, and something I found really useful is an example of a Mensural MEI file in the Verovio webpage at this particular address: *http://www.verovio.org/features.xhtml?id=mensural * You can download the whole file (it is larger than the short excerpt shown there). It includes everything one needs know, you can see how they encoded imperfections, alterations, dots and their effect in the note (augmentation or division), changes in mensuration, etc. It also includes coloration, but I think there is no agreement between the Mensural MEI community in how to encode this particular feature (although I think the way it is encoded in this example from the Verovio webpage is really good). Hope this helps, Martha Martha E. Thomae DDMAL Lab, Music Technology McGill University On Fri, Jan 13, 2017 at 6:10 PM, Eleanor Selfridge-Field < esfield at stanford.edu> wrote: > Perry, > > > > You’re right: I’m not current with the latest version, but I passed the > info on to Craig. > > > > It would obviously be best if someone from the mensural working group > weighed in on this. > > > > Eleanor > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Roland, Perry D. (pdr4h) > *Sent:* Friday, January 13, 2017 3:03 PM > *To:* Music Encoding Initiative > > *Subject:* Re: [MEI-L] Sample encoding of mensural notation > > > > > > Hi Daniel, > > > > Unfortunately, the files Eleanor refers to are encodings of *modern > notation/measured transcriptions* of mensural notation, not encodings of > mensural notation per se. They also don't validate against the latest > version of MEI. :-( > > > > -- > > p. > > > > _________________________________________ > Perry Roland > > Metadata Librarian for Research and Scholarship > University of Virginia > P. O. Box 400874 > > Charlottesville, VA 22904 > 434-982-2702 <(434)%20982-2702> (w) > pdr4h (at) virginia (dot) edu > > > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *On Behalf Of *Eleanor > Selfridge-Field > *Sent:* Friday, January 13, 2017 5:57 PM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Sample encoding of mensural notation > > > > Hi, Daniel, > > > > There are hundreds of examples of the MEI encodings of mensural notation > at the Josquin Research Project (http://jrp.stanford.edu). The data here > does not originate as MEI, so the examples are a little artificial. > Nonetheless, the encodings provide a simple model of what this kind of > notation looks like in MEI. I looked at Dufay ( > http://josquin.stanford.edu/cgi-bin/jrp?a=mei&f=Duf3007.2) as an > arbitrary choice. (The display currently comes from MuseData.) Here is > Josquin’s Miserere: http://josquin.stanford.edu/ > cgi-bin/jrp?a=mei&f=Jos1803. > > > > Best regards, > > > > > > Eleanor Selfridge-Field > > Braun Music Center #130 > > Stanford University > > Stanford, CA 94305-3076 > > esfield at stanford.edu > > > > > > > > > > > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *On Behalf Of *Daniel Alles > *Sent:* Friday, January 13, 2017 3:36 AM > *To:* mei-l at lists.uni-paderborn.de > *Subject:* [MEI-L] Sample encoding of mensural notation > > > > Hello everyone in the world of music encoding, > > at the moment, I am preparing my dissertation for my M.A.-degree at the > Goethe-University in Frankfurt, Germany, which I am planning to write this > year about the possibilities and difficulties of editing mensural > notation. > > Since I have barely no experience in encoding music at all (however, the > tutorial an the MEI-Website was very helpful to get the first steps and to > encode a first piece of CMN), I am now wondering, if I could find a sample > encoding of mensural notation, to get an overview on how it is done. I > tried encoding out by relating on a sample I found at > http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not > sure, whether I did something wrong or how else the common standard is. (If > someone is interested: You can find my first attempts here: > https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, > all comments on them are very welcome!) > > I did not find any MN-sample in the sample encodings package, so could > anyone please send me one? > > Yours sincerely, > Daniel Alles > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -- *Martha E. Thomae* -------------- next part -------------- An HTML attachment was scrubbed... URL: From marnixvanberchum at gmail.com Sat Jan 14 12:31:48 2017 From: marnixvanberchum at gmail.com (Marnix van Berchum) Date: Sat, 14 Jan 2017 12:31:48 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: Dear Daniel, You might be interested in the editions of the CMME Project as well, e.g. http://www.cmme.org/database/projects/4. Although they are not encoded in MEI (they use a 'dialect' of MusicXML), they are transcribed from original sources and include all features of (white) mensural notation: ligatures, mensural note shapes, signs, original note values etc. As editions they also include variant readings and critical notes. Due to lack of funding and time, the project is currently in a dormant stage. So unfortunately in the short run we aren't able to solve the browser-Java problems you will experience... Best solution is to download our software, install it locally on your machine and download the music-files from the website. The latest version of the software can be downloaded at http://www.cmme.org/Editor-Latest/. A brief manual (editor.html) can be found in the folder /doc. More music examples can be found at https://github.com/tdumitrescu/cmme-music ; as well as the full source code on https://github.com/tdumitrescu/cmme-editor . Please contact me if you need more information on the use of the software, and the background of CMME! all best, Marnix van Berchum *Associate Director CMME* On 13 January 2017 at 12:35, Daniel Alles wrote: > Hello everyone in the world of music encoding, > > at the moment, I am preparing my dissertation for my M.A.-degree at the > Goethe-University in Frankfurt, Germany, which I am planning to write this > year about the possibilities and difficulties of editing mensural > notation. > > Since I have barely no experience in encoding music at all (however, the > tutorial an the MEI-Website was very helpful to get the first steps and to > encode a first piece of CMN), I am now wondering, if I could find a sample > encoding of mensural notation, to get an overview on how it is done. I > tried encoding out by relating on a sample I found at > http://www.digital-musicology.at/de-at/mei_mensual.html, but I'm not > sure, whether I did something wrong or how else the common standard is. (If > someone is interested: You can find my first attempts here: > https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0, > all comments on them are very welcome!) > > I did not find any MN-sample in the sample encodings package, so could > anyone please send me one? > > Yours sincerely, > Daniel Alles > > _______________________________________________ > 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: From DanielAlles at stud.uni-frankfurt.de Sat Jan 14 23:29:38 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Sat, 14 Jan 2017 23:29:38 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: <20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> Hi Martha and all the others, thank you very much for your replies, they helped me very much in understanding the encoding of MN. Especially Martha's hint to the Verovio-website was very useful (although I don't understand completely "coloration including augmentation/imperfectino", but that's Ok for the moment). A thing that confuses me a lot is the displaying of the Verovio-MEI-viewer: I have the impression, that it doesn't align the corect "beats" vertically; I already recognized this when rendering my attempt. Is that right? How can I fix that? Best regard, Daniel Zitat von Martha Thomae : > Hi Daniel > > Perry is right, the JRP only contains modern transcription of mensural > music. > > I am currently working with Mensural MEI files, and something I found > really useful is an example of a Mensural MEI file in the Verovio webpage > at this particular address: > *http://www.verovio.org/features.xhtml?id=mensural > * > You can download the whole file (it is larger than the short excerpt shown > there). It includes everything one needs know, you can see how they encoded > imperfections, alterations, dots and their effect in the note (augmentation > or division), changes in mensuration, etc. It also includes coloration, but > I think there is no agreement between the Mensural MEI community in how to > encode this particular feature (although I think the way it is encoded in > this example from the Verovio webpage is really good). > > Hope this helps, > > Martha > > Martha E. Thomae > DDMAL Lab, > Music Technology > McGill University > From andrew.hankinson at mail.mcgill.ca Sun Jan 15 14:22:51 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sun, 15 Jan 2017 13:22:51 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> Message-ID: <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> Can you send along a sample of your encoding? We can help you better if we can see what you did. -Andrew > On Jan 14, 2017, at 10:29 PM, Daniel Alles wrote: > > Hi Martha and all the others, > > thank you very much for your replies, they helped me very much in understanding the encoding of MN. Especially Martha's hint to the Verovio-website was very useful (although I don't understand completely "coloration including augmentation/imperfectino", but that's Ok for the moment). A thing that confuses me a lot is the displaying of the Verovio-MEI-viewer: I have the impression, that it doesn't align the corect "beats" vertically; I already recognized this when rendering my attempt. Is that right? How can I fix that? > > Best regard, > Daniel > > > > Zitat von Martha Thomae : > >> Hi Daniel >> >> Perry is right, the JRP only contains modern transcription of mensural >> music. >> >> I am currently working with Mensural MEI files, and something I found >> really useful is an example of a Mensural MEI file in the Verovio webpage >> at this particular address: *http://www.verovio.org/features.xhtml?id=mensural >> * >> You can download the whole file (it is larger than the short excerpt shown >> there). It includes everything one needs know, you can see how they encoded >> imperfections, alterations, dots and their effect in the note (augmentation >> or division), changes in mensuration, etc. It also includes coloration, but >> I think there is no agreement between the Mensural MEI community in how to >> encode this particular feature (although I think the way it is encoded in >> this example from the Verovio webpage is really good). >> >> Hope this helps, >> >> Martha >> >> Martha E. Thomae >> DDMAL Lab, >> Music Technology >> McGill University >> > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From DanielAlles at stud.uni-frankfurt.de Sun Jan 15 23:27:15 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Sun, 15 Jan 2017 23:27:15 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> Message-ID: <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> Hello, I'll attach the samples to this email. The sources can be found at https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 Best regards, Daniel Zitat von Andrew Hankinson : > Can you send along a sample of your encoding? We can help you better > if we can see what you did. > > -Andrew > >> On Jan 14, 2017, at 10:29 PM, Daniel Alles >> wrote: >> >> Hi Martha and all the others, >> >> thank you very much for your replies, they helped me very much in >> understanding the encoding of MN. Especially Martha's hint to the >> Verovio-website was very useful (although I don't understand >> completely "coloration including augmentation/imperfectino", but >> that's Ok for the moment). A thing that confuses me a lot is the >> displaying of the Verovio-MEI-viewer: I have the impression, that it >> doesn't align the corect "beats" vertically; I already recognized >> this when rendering my attempt. Is that right? How can I fix that? >> >> Best regard, >> Daniel >> >> >> >> Zitat von Martha Thomae : >> >>> Hi Daniel >>> >>> Perry is right, the JRP only contains modern transcription of mensural >>> music. >>> >>> I am currently working with Mensural MEI files, and something I found >>> really useful is an example of a Mensural MEI file in the Verovio webpage >>> at this particular address: >>> *http://www.verovio.org/features.xhtml?id=mensural >>> * >>> You can download the whole file (it is larger than the short excerpt shown >>> there). It includes everything one needs know, you can see how they encoded >>> imperfections, alterations, dots and their effect in the note (augmentation >>> or division), changes in mensuration, etc. It also includes coloration, but >>> I think there is no agreement between the Mensural MEI community in how to >>> encode this particular feature (although I think the way it is encoded in >>> this example from the Verovio webpage is really good). >>> >>> Hope this helps, >>> >>> Martha >>> >>> Martha E. Thomae >>> DDMAL Lab, >>> Music Technology >>> McGill University >>> >> >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: 001 MEI CMN Mensur.mei Type: application/xml Size: 88315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 001 MEI MN.mei Type: application/xml Size: 49759 bytes Desc: not available URL: From thomaemartha at gmail.com Mon Jan 16 08:37:08 2017 From: thomaemartha at gmail.com (Martha Thomae) Date: Mon, 16 Jan 2017 02:37:08 -0500 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> Message-ID: Hi Daniel, I took a look at your files. I think the mistake is the way that the dots are encoded. In Mensural MEI you don't use the attribute @dots. Any dot after a note is encoded as an element . And if this dot is behaving as a "dot of addition" (which is called "dot of augmentation") you have to add two attributes: @num and @numbase. These attributes change the note's value. If the dot is a 'dot of augmentation' you should use @num="2" and @numbase="3" (this will make your note 1.5 times its original value). There is an example in the Verovio file that we talked about. So for a dot of addition you must do: I made these changes to your file and all voices lined up except for the tenor. I realized this is because the at the beginning is given a duration of 3 breves instead of 2 breves, this is not a mistake in your encoding, but in the way Verovio is interpreting that "longa" rest. I will raise an issue about it. Besides that, everything should be working fine. Hope this helps, Martha -- Martha E. Thomae DDMAL Lab, Music Technology McGill University On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles < DanielAlles at stud.uni-frankfurt.de> wrote: > Hello, > > I'll attach the samples to this email. The sources can be found at > https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 > > Best regards, > Daniel > > > Zitat von Andrew Hankinson : > > > > Can you send along a sample of your encoding? We can help you better > > if we can see what you did. > > > > -Andrew > > > >> On Jan 14, 2017, at 10:29 PM, Daniel Alles > >> wrote: > >> > >> Hi Martha and all the others, > >> > >> thank you very much for your replies, they helped me very much in > >> understanding the encoding of MN. Especially Martha's hint to the > >> Verovio-website was very useful (although I don't understand > >> completely "coloration including augmentation/imperfectino", but > >> that's Ok for the moment). A thing that confuses me a lot is the > >> displaying of the Verovio-MEI-viewer: I have the impression, that it > >> doesn't align the corect "beats" vertically; I already recognized > >> this when rendering my attempt. Is that right? How can I fix that? > >> > >> Best regard, > >> Daniel > >> > >> > >> > >> Zitat von Martha Thomae : > >> > >>> Hi Daniel > >>> > >>> Perry is right, the JRP only contains modern transcription of mensural > >>> music. > >>> > >>> I am currently working with Mensural MEI files, and something I found > >>> really useful is an example of a Mensural MEI file in the Verovio > webpage > >>> at this particular address: > >>> *http://www.verovio.org/features.xhtml?id=mensural > >>> * > >>> You can download the whole file (it is larger than the short excerpt > shown > >>> there). It includes everything one needs know, you can see how they > encoded > >>> imperfections, alterations, dots and their effect in the note > (augmentation > >>> or division), changes in mensuration, etc. It also includes > coloration, but > >>> I think there is no agreement between the Mensural MEI community in > how to > >>> encode this particular feature (although I think the way it is encoded > in > >>> this example from the Verovio webpage is really good). > >>> > >>> Hope this helps, > >>> > >>> Martha > >>> > >>> Martha E. Thomae > >>> DDMAL Lab, > >>> Music Technology > >>> McGill University > >>> > >> > >> > >> _______________________________________________ > >> 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 > > -- *Martha E. Thomae* -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomaemartha at gmail.com Mon Jan 16 09:35:42 2017 From: thomaemartha at gmail.com (Martha Thomae) Date: Mon, 16 Jan 2017 03:35:42 -0500 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> Message-ID: Ups! Sorry for that last part. It is not a Verovio problem. I just realize that in your elements you have @tempus="2" (which means that a breve = 2 semibreves) and @prolatio="2" (which means a semibreve = 2 minimas), but you haven't stablished the relationship between the longa and the breve. To do this you should use @modusminor. As you want the longa = 2 breves, you should use @modusminor="2". If you don't specify this value, Verovio will assume it is "3". That is why your longa was assumed to be equal to 3 breves, you can clearly see this at the beginning of the tenor, where the longa rest occupies the same space as 3 breves in the other voices. On Mon, Jan 16, 2017 at 2:37 AM, Martha Thomae wrote: > Hi Daniel, > > I took a look at your files. I think the mistake is the way that the dots > are encoded. In Mensural MEI you don't use the attribute @dots. Any dot > after a note is encoded as an element . And if this dot is behaving > as a "dot of addition" (which is called "dot of augmentation") you have to > add two attributes: @num and @numbase. These attributes change the note's > value. If the dot is a 'dot of augmentation' you should use @num="2" and > @numbase="3" (this will make your note 1.5 times its original value). > > There is an example in the Verovio file that we talked about. So for a dot > of addition you must do: > > > > > I made these changes to your file and all voices lined up except for the > tenor. I realized this is because the at the beginning > is given a duration of 3 breves instead of 2 breves, this is not a mistake > in your encoding, but in the way Verovio is interpreting that "longa" rest. > I will raise an issue about it. Besides that, everything should be working > fine. > > Hope this helps, > > Martha > -- > Martha E. Thomae > DDMAL Lab, > Music Technology > McGill University > > On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles frankfurt.de> wrote: > >> Hello, >> >> I'll attach the samples to this email. The sources can be found at >> https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 >> >> Best regards, >> Daniel >> >> >> Zitat von Andrew Hankinson : >> >> >> > Can you send along a sample of your encoding? We can help you better >> > if we can see what you did. >> > >> > -Andrew >> > >> >> On Jan 14, 2017, at 10:29 PM, Daniel Alles >> >> wrote: >> >> >> >> Hi Martha and all the others, >> >> >> >> thank you very much for your replies, they helped me very much in >> >> understanding the encoding of MN. Especially Martha's hint to the >> >> Verovio-website was very useful (although I don't understand >> >> completely "coloration including augmentation/imperfectino", but >> >> that's Ok for the moment). A thing that confuses me a lot is the >> >> displaying of the Verovio-MEI-viewer: I have the impression, that it >> >> doesn't align the corect "beats" vertically; I already recognized >> >> this when rendering my attempt. Is that right? How can I fix that? >> >> >> >> Best regard, >> >> Daniel >> >> >> >> >> >> >> >> Zitat von Martha Thomae : >> >> >> >>> Hi Daniel >> >>> >> >>> Perry is right, the JRP only contains modern transcription of mensural >> >>> music. >> >>> >> >>> I am currently working with Mensural MEI files, and something I found >> >>> really useful is an example of a Mensural MEI file in the Verovio >> webpage >> >>> at this particular address: >> >>> *http://www.verovio.org/features.xhtml?id=mensural >> >>> * >> >>> You can download the whole file (it is larger than the short excerpt >> shown >> >>> there). It includes everything one needs know, you can see how they >> encoded >> >>> imperfections, alterations, dots and their effect in the note >> (augmentation >> >>> or division), changes in mensuration, etc. It also includes >> coloration, but >> >>> I think there is no agreement between the Mensural MEI community in >> how to >> >>> encode this particular feature (although I think the way it is >> encoded in >> >>> this example from the Verovio webpage is really good). >> >>> >> >>> Hope this helps, >> >>> >> >>> Martha >> >>> >> >>> Martha E. Thomae >> >>> DDMAL Lab, >> >>> Music Technology >> >>> McGill University >> >>> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> > > > -- > *Martha E. Thomae* > -- *Martha E. Thomae* -------------- next part -------------- An HTML attachment was scrubbed... URL: From DanielAlles at stud.uni-frankfurt.de Mon Jan 16 11:10:53 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Mon, 16 Jan 2017 11:10:53 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> Message-ID: <20170116111053.Horde.1C2YnVsPYQTGpQ8h3m1usNy@webmail.server.uni-frankfurt.de> Hi Martha, your solution sounds good and is very logically, but it seems not to work for me: I deleted @dots, added @num, @numbase and @modusminor as suggested and added everywhere needed. Now Verovio displays the Cantus only, and just the part before the first @num-attribute (see attached PNG-file). I can't find the mistake... Additionally, there seems a problem with the mensur-sign. Instead of a C with one slash (as encoded), Verovio just shows the slash. Is there something I can do about that? And (last question, I hope) is there a possibility to beam semiminimae in Verovio correctly? I remember them not being displayed as a kind of beamed 8ths, but as to semiminimae (with flag) and a not good positioned beam... I'll attach my corrected MEI-file again. Daniel Zitat von Martha Thomae : > Ups! Sorry for that last part. It is not a Verovio problem. I just realize > that in your elements you have @tempus="2" (which means that a > breve = 2 semibreves) and @prolatio="2" (which means a semibreve = 2 > minimas), but you haven't stablished the relationship between the longa and > the breve. To do this you should use @modusminor. As you want the longa = 2 > breves, you should use @modusminor="2". If you don't specify this value, > Verovio will assume it is "3". That is why your longa was assumed to be > equal to 3 breves, you can clearly see this at the beginning of the tenor, > where the longa rest occupies the same space as 3 breves in the other > voices. > > On Mon, Jan 16, 2017 at 2:37 AM, Martha Thomae > wrote: > >> Hi Daniel, >> >> I took a look at your files. I think the mistake is the way that the dots >> are encoded. In Mensural MEI you don't use the attribute @dots. Any dot >> after a note is encoded as an element . And if this dot is behaving >> as a "dot of addition" (which is called "dot of augmentation") you have to >> add two attributes: @num and @numbase. These attributes change the note's >> value. If the dot is a 'dot of augmentation' you should use @num="2" and >> @numbase="3" (this will make your note 1.5 times its original value). >> >> There is an example in the Verovio file that we talked about. So for a dot >> of addition you must do: >> >> >> >> >> I made these changes to your file and all voices lined up except for the >> tenor. I realized this is because the at the beginning >> is given a duration of 3 breves instead of 2 breves, this is not a mistake >> in your encoding, but in the way Verovio is interpreting that "longa" rest. >> I will raise an issue about it. Besides that, everything should be working >> fine. >> >> Hope this helps, >> >> Martha >> -- >> Martha E. Thomae >> DDMAL Lab, >> Music Technology >> McGill University >> >> On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles > frankfurt.de> wrote: >> >>> Hello, >>> >>> I'll attach the samples to this email. The sources can be found at >>> https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 >>> >>> Best regards, >>> Daniel >>> >>> >>> Zitat von Andrew Hankinson : >>> >>> >>> > Can you send along a sample of your encoding? We can help you better >>> > if we can see what you did. >>> > >>> > -Andrew >>> > >>> >> On Jan 14, 2017, at 10:29 PM, Daniel Alles >>> >> wrote: >>> >> >>> >> Hi Martha and all the others, >>> >> >>> >> thank you very much for your replies, they helped me very much in >>> >> understanding the encoding of MN. Especially Martha's hint to the >>> >> Verovio-website was very useful (although I don't understand >>> >> completely "coloration including augmentation/imperfectino", but >>> >> that's Ok for the moment). A thing that confuses me a lot is the >>> >> displaying of the Verovio-MEI-viewer: I have the impression, that it >>> >> doesn't align the corect "beats" vertically; I already recognized >>> >> this when rendering my attempt. Is that right? How can I fix that? >>> >> >>> >> Best regard, >>> >> Daniel >>> >> >>> >> >>> >> >>> >> Zitat von Martha Thomae : >>> >> >>> >>> Hi Daniel >>> >>> >>> >>> Perry is right, the JRP only contains modern transcription of mensural >>> >>> music. >>> >>> >>> >>> I am currently working with Mensural MEI files, and something I found >>> >>> really useful is an example of a Mensural MEI file in the Verovio >>> webpage >>> >>> at this particular address: >>> >>> *http://www.verovio.org/features.xhtml?id=mensural >>> >>> * >>> >>> You can download the whole file (it is larger than the short excerpt >>> shown >>> >>> there). It includes everything one needs know, you can see how they >>> encoded >>> >>> imperfections, alterations, dots and their effect in the note >>> (augmentation >>> >>> or division), changes in mensuration, etc. It also includes >>> coloration, but >>> >>> I think there is no agreement between the Mensural MEI community in >>> how to >>> >>> encode this particular feature (although I think the way it is >>> encoded in >>> >>> this example from the Verovio webpage is really good). >>> >>> >>> >>> Hope this helps, >>> >>> >>> >>> Martha >>> >>> >>> >>> Martha E. Thomae >>> >>> DDMAL Lab, >>> >>> Music Technology >>> >>> McGill University >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >> >> >> -- >> *Martha E. Thomae* >> > > > > -- > *Martha E. Thomae* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 001 MEI MN.mei Type: application/xml Size: 51597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fehler.PNG Type: image/png Size: 20314 bytes Desc: not available URL: From andrew.hankinson at mail.mcgill.ca Mon Jan 16 11:27:23 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 16 Jan 2017 10:27:23 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: <26687_1484561495_587C9C55_26687_144_1_20170116111053.Horde.1C2YnVsPYQTGpQ8h3m1usNy@webmail.server.uni-frankfurt.de> References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> <26687_1484561495_587C9C55_26687_144_1_20170116111053.Horde.1C2YnVsPYQTGpQ8h3m1usNy@webmail.server.uni-frankfurt.de> Message-ID: You have quite a few self-closing note tag ( ), but also a . (lines 66, 87, 124, etc.) -Andrew > On Jan 16, 2017, at 10:10 AM, Daniel Alles wrote: > > Hi Martha, > > your solution sounds good and is very logically, but it seems not to work for me: I deleted @dots, added @num, @numbase and @modusminor as suggested and added everywhere needed. Now Verovio displays the Cantus only, and just the part before the first @num-attribute (see attached PNG-file). I can't find the mistake... > > Additionally, there seems a problem with the mensur-sign. Instead of a C with one slash (as encoded), Verovio just shows the slash. Is there something I can do about that? > > And (last question, I hope) is there a possibility to beam semiminimae in Verovio correctly? I remember them not being displayed as a kind of beamed 8ths, but as to semiminimae (with flag) and a not good positioned beam... > > I'll attach my corrected MEI-file again. > > Daniel > > > > > Zitat von Martha Thomae >: > > > Ups! Sorry for that last part. It is not a Verovio problem. I just realize > > that in your elements you have @tempus="2" (which means that a > > breve = 2 semibreves) and @prolatio="2" (which means a semibreve = 2 > > minimas), but you haven't stablished the relationship between the longa and > > the breve. To do this you should use @modusminor. As you want the longa = 2 > > breves, you should use @modusminor="2". If you don't specify this value, > > Verovio will assume it is "3". That is why your longa was assumed to be > > equal to 3 breves, you can clearly see this at the beginning of the tenor, > > where the longa rest occupies the same space as 3 breves in the other > > voices. > > > > On Mon, Jan 16, 2017 at 2:37 AM, Martha Thomae > > > wrote: > > > >> Hi Daniel, > >> > >> I took a look at your files. I think the mistake is the way that the dots > >> are encoded. In Mensural MEI you don't use the attribute @dots. Any dot > >> after a note is encoded as an element . And if this dot is behaving > >> as a "dot of addition" (which is called "dot of augmentation") you have to > >> add two attributes: @num and @numbase. These attributes change the note's > >> value. If the dot is a 'dot of augmentation' you should use @num="2" and > >> @numbase="3" (this will make your note 1.5 times its original value). > >> > >> There is an example in the Verovio file that we talked about. So for a dot > >> of addition you must do: > >> > >> > >> > >> > >> I made these changes to your file and all voices lined up except for the > >> tenor. I realized this is because the at the beginning > >> is given a duration of 3 breves instead of 2 breves, this is not a mistake > >> in your encoding, but in the way Verovio is interpreting that "longa" rest. > >> I will raise an issue about it. Besides that, everything should be working > >> fine. > >> > >> Hope this helps, > >> > >> Martha > >> -- > >> Martha E. Thomae > >> DDMAL Lab, > >> Music Technology > >> McGill University > >> > >> On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles - > >> frankfurt.de> wrote: > >> > >>> Hello, > >>> > >>> I'll attach the samples to this email. The sources can be found at > >>> https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 > >>> > >>> Best regards, > >>> Daniel > >>> > >>> > >>> Zitat von Andrew Hankinson >: > >>> > >>> > >>> > Can you send along a sample of your encoding? We can help you better > >>> > if we can see what you did. > >>> > > >>> > -Andrew > >>> > > >>> >> On Jan 14, 2017, at 10:29 PM, Daniel Alles > >>> >> > wrote: > >>> >> > >>> >> Hi Martha and all the others, > >>> >> > >>> >> thank you very much for your replies, they helped me very much in > >>> >> understanding the encoding of MN. Especially Martha's hint to the > >>> >> Verovio-website was very useful (although I don't understand > >>> >> completely "coloration including augmentation/imperfectino", but > >>> >> that's Ok for the moment). A thing that confuses me a lot is the > >>> >> displaying of the Verovio-MEI-viewer: I have the impression, that it > >>> >> doesn't align the corect "beats" vertically; I already recognized > >>> >> this when rendering my attempt. Is that right? How can I fix that? > >>> >> > >>> >> Best regard, > >>> >> Daniel > >>> >> > >>> >> > >>> >> > >>> >> Zitat von Martha Thomae >: > >>> >> > >>> >>> Hi Daniel > >>> >>> > >>> >>> Perry is right, the JRP only contains modern transcription of mensural > >>> >>> music. > >>> >>> > >>> >>> I am currently working with Mensural MEI files, and something I found > >>> >>> really useful is an example of a Mensural MEI file in the Verovio > >>> webpage > >>> >>> at this particular address: > >>> >>> *http://www.verovio.org/features.xhtml?id=mensural > >>> >>> >* > >>> >>> You can download the whole file (it is larger than the short excerpt > >>> shown > >>> >>> there). It includes everything one needs know, you can see how they > >>> encoded > >>> >>> imperfections, alterations, dots and their effect in the note > >>> (augmentation > >>> >>> or division), changes in mensuration, etc. It also includes > >>> coloration, but > >>> >>> I think there is no agreement between the Mensural MEI community in > >>> how to > >>> >>> encode this particular feature (although I think the way it is > >>> encoded in > >>> >>> this example from the Verovio webpage is really good). > >>> >>> > >>> >>> Hope this helps, > >>> >>> > >>> >>> Martha > >>> >>> > >>> >>> Martha E. Thomae > >>> >>> DDMAL Lab, > >>> >>> Music Technology > >>> >>> McGill University > >>> >>> > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> 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 > >>> > >>> > >> > >> > >> -- > >> *Martha E. Thomae* > >> > > > > > > > > -- > > *Martha E. Thomae* > > <001 MEI MN.mei>_______________________________________________ > 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: From DanielAlles at stud.uni-frankfurt.de Mon Jan 16 11:40:48 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Mon, 16 Jan 2017 11:40:48 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> Message-ID: <20170116114048.Horde.XyR5RvwTXp-VYK0ogzlerfD@webmail.server.uni-frankfurt.de> Never mind the question about the cut-time-Symbol: I added it at the correct place (in the section) and it works fine - at least for the Cantus, as I can't see the other voices. Zitat von Martha Thomae : > Ups! Sorry for that last part. It is not a Verovio problem. I just realize > that in your elements you have @tempus="2" (which means that a > breve = 2 semibreves) and @prolatio="2" (which means a semibreve = 2 > minimas), but you haven't stablished the relationship between the longa and > the breve. To do this you should use @modusminor. As you want the longa = 2 > breves, you should use @modusminor="2". If you don't specify this value, > Verovio will assume it is "3". That is why your longa was assumed to be > equal to 3 breves, you can clearly see this at the beginning of the tenor, > where the longa rest occupies the same space as 3 breves in the other > voices. > > On Mon, Jan 16, 2017 at 2:37 AM, Martha Thomae > wrote: > >> Hi Daniel, >> >> I took a look at your files. I think the mistake is the way that the dots >> are encoded. In Mensural MEI you don't use the attribute @dots. Any dot >> after a note is encoded as an element . And if this dot is behaving >> as a "dot of addition" (which is called "dot of augmentation") you have to >> add two attributes: @num and @numbase. These attributes change the note's >> value. If the dot is a 'dot of augmentation' you should use @num="2" and >> @numbase="3" (this will make your note 1.5 times its original value). >> >> There is an example in the Verovio file that we talked about. So for a dot >> of addition you must do: >> >> >> >> >> I made these changes to your file and all voices lined up except for the >> tenor. I realized this is because the at the beginning >> is given a duration of 3 breves instead of 2 breves, this is not a mistake >> in your encoding, but in the way Verovio is interpreting that "longa" rest. >> I will raise an issue about it. Besides that, everything should be working >> fine. >> >> Hope this helps, >> >> Martha >> -- >> Martha E. Thomae >> DDMAL Lab, >> Music Technology >> McGill University >> >> On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles > frankfurt.de> wrote: >> >>> Hello, >>> >>> I'll attach the samples to this email. The sources can be found at >>> https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 >>> >>> Best regards, >>> Daniel >>> >>> >>> Zitat von Andrew Hankinson : >>> >>> >>> > Can you send along a sample of your encoding? We can help you better >>> > if we can see what you did. >>> > >>> > -Andrew >>> > >>> >> On Jan 14, 2017, at 10:29 PM, Daniel Alles >>> >> wrote: >>> >> >>> >> Hi Martha and all the others, >>> >> >>> >> thank you very much for your replies, they helped me very much in >>> >> understanding the encoding of MN. Especially Martha's hint to the >>> >> Verovio-website was very useful (although I don't understand >>> >> completely "coloration including augmentation/imperfectino", but >>> >> that's Ok for the moment). A thing that confuses me a lot is the >>> >> displaying of the Verovio-MEI-viewer: I have the impression, that it >>> >> doesn't align the corect "beats" vertically; I already recognized >>> >> this when rendering my attempt. Is that right? How can I fix that? >>> >> >>> >> Best regard, >>> >> Daniel >>> >> >>> >> >>> >> >>> >> Zitat von Martha Thomae : >>> >> >>> >>> Hi Daniel >>> >>> >>> >>> Perry is right, the JRP only contains modern transcription of mensural >>> >>> music. >>> >>> >>> >>> I am currently working with Mensural MEI files, and something I found >>> >>> really useful is an example of a Mensural MEI file in the Verovio >>> webpage >>> >>> at this particular address: >>> >>> *http://www.verovio.org/features.xhtml?id=mensural >>> >>> * >>> >>> You can download the whole file (it is larger than the short excerpt >>> shown >>> >>> there). It includes everything one needs know, you can see how they >>> encoded >>> >>> imperfections, alterations, dots and their effect in the note >>> (augmentation >>> >>> or division), changes in mensuration, etc. It also includes >>> coloration, but >>> >>> I think there is no agreement between the Mensural MEI community in >>> how to >>> >>> encode this particular feature (although I think the way it is >>> encoded in >>> >>> this example from the Verovio webpage is really good). >>> >>> >>> >>> Hope this helps, >>> >>> >>> >>> Martha >>> >>> >>> >>> Martha E. Thomae >>> >>> DDMAL Lab, >>> >>> Music Technology >>> >>> McGill University >>> >>> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >> >> >> -- >> *Martha E. Thomae* >> > > > > -- > *Martha E. Thomae* From DanielAlles at stud.uni-frankfurt.de Mon Jan 16 21:03:30 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Mon, 16 Jan 2017 21:03:30 +0100 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> <13977_1484433020_587AA67C_13977_398_1_20170114232938.Horde.A9iP8gdZr3AYHWMzfaXazPA@webmail.server.uni-frankfurt.de> <166D2A75-467D-4A64-B1E7-36358BC46885@mail.mcgill.ca> <20170115232715.Horde.FMwi2kNgsFW-CEJEff8rGt-@webmail.server.uni-frankfurt.de> <26687_1484561495_587C9C55_26687_144_1_20170116111053.Horde.1C2YnVsPYQTGpQ8h3m1usNy@webmail.server.uni-frankfurt.de> Message-ID: <20170116210330.Horde.OBp-E4MfWg0J8P--5kpfOsY@webmail.server.uni-frankfurt.de> Thank you Andrew, that was definitely one of my "copy-and-paste-stupidities". Now it works fine. Daniel Zitat von Andrew Hankinson : > You have quite a few self-closing note tag ( ), but also a > . (lines 66, 87, 124, etc.) > > -Andrew > >> On Jan 16, 2017, at 10:10 AM, Daniel Alles >> wrote: >> >> Hi Martha, >> >> your solution sounds good and is very logically, but it seems not >> to work for me: I deleted @dots, added @num, @numbase and >> @modusminor as suggested and added everywhere needed. Now >> Verovio displays the Cantus only, and just the part before the >> first @num-attribute (see attached PNG-file). I can't find the >> mistake... >> >> Additionally, there seems a problem with the mensur-sign. Instead >> of a C with one slash (as encoded), Verovio just shows the slash. >> Is there something I can do about that? >> >> And (last question, I hope) is there a possibility to beam >> semiminimae in Verovio correctly? I remember them not being >> displayed as a kind of beamed 8ths, but as to semiminimae (with >> flag) and a not good positioned beam... >> >> I'll attach my corrected MEI-file again. >> >> Daniel >> >> >> >> >> Zitat von Martha Thomae > >: >> >> > Ups! Sorry for that last part. It is not a Verovio problem. I just realize >> > that in your elements you have @tempus="2" (which means that a >> > breve = 2 semibreves) and @prolatio="2" (which means a semibreve = 2 >> > minimas), but you haven't stablished the relationship between the >> longa and >> > the breve. To do this you should use @modusminor. As you want the >> longa = 2 >> > breves, you should use @modusminor="2". If you don't specify this value, >> > Verovio will assume it is "3". That is why your longa was assumed to be >> > equal to 3 breves, you can clearly see this at the beginning of the tenor, >> > where the longa rest occupies the same space as 3 breves in the other >> > voices. >> > >> > On Mon, Jan 16, 2017 at 2:37 AM, Martha Thomae >> > >> > wrote: >> > >> >> Hi Daniel, >> >> >> >> I took a look at your files. I think the mistake is the way that the dots >> >> are encoded. In Mensural MEI you don't use the attribute @dots. Any dot >> >> after a note is encoded as an element . And if this dot is behaving >> >> as a "dot of addition" (which is called "dot of augmentation") >> you have to >> >> add two attributes: @num and @numbase. These attributes change the note's >> >> value. If the dot is a 'dot of augmentation' you should use @num="2" and >> >> @numbase="3" (this will make your note 1.5 times its original value). >> >> >> >> There is an example in the Verovio file that we talked about. So >> for a dot >> >> of addition you must do: >> >> >> >> >> >> >> >> >> >> I made these changes to your file and all voices lined up except for the >> >> tenor. I realized this is because the at the >> beginning >> >> is given a duration of 3 breves instead of 2 breves, this is not >> a mistake >> >> in your encoding, but in the way Verovio is interpreting that >> "longa" rest. >> >> I will raise an issue about it. Besides that, everything should >> be working >> >> fine. >> >> >> >> Hope this helps, >> >> >> >> Martha >> >> -- >> >> Martha E. Thomae >> >> DDMAL Lab, >> >> Music Technology >> >> McGill University >> >> >> >> On Sun, Jan 15, 2017 at 5:27 PM, Daniel Alles >> - >> >> frankfurt.de> wrote: >> >> >> >>> Hello, >> >>> >> >>> I'll attach the samples to this email. The sources can be found at >> >>> >> https://www.dropbox.com/sh/15v9inaose2z8e8/AACXfPru5v3H5fg2cwgNZJFKa?dl=0 >> >> >>> >> >>> Best regards, >> >>> Daniel >> >>> >> >>> >> >>> Zitat von Andrew Hankinson > >: >> >>> >> >>> >> >>> > Can you send along a sample of your encoding? We can help you better >> >>> > if we can see what you did. >> >>> > >> >>> > -Andrew >> >>> > >> >>> >> On Jan 14, 2017, at 10:29 PM, Daniel Alles >> >>> >> > > wrote: >> >>> >> >> >>> >> Hi Martha and all the others, >> >>> >> >> >>> >> thank you very much for your replies, they helped me very much in >> >>> >> understanding the encoding of MN. Especially Martha's hint to the >> >>> >> Verovio-website was very useful (although I don't understand >> >>> >> completely "coloration including augmentation/imperfectino", but >> >>> >> that's Ok for the moment). A thing that confuses me a lot is the >> >>> >> displaying of the Verovio-MEI-viewer: I have the impression, that it >> >>> >> doesn't align the corect "beats" vertically; I already recognized >> >>> >> this when rendering my attempt. Is that right? How can I fix that? >> >>> >> >> >>> >> Best regard, >> >>> >> Daniel >> >>> >> >> >>> >> >> >>> >> >> >>> >> Zitat von Martha Thomae > >: >> >>> >> >> >>> >>> Hi Daniel >> >>> >>> >> >>> >>> Perry is right, the JRP only contains modern transcription >> of mensural >> >>> >>> music. >> >>> >>> >> >>> >>> I am currently working with Mensural MEI files, and >> something I found >> >>> >>> really useful is an example of a Mensural MEI file in the Verovio >> >>> webpage >> >>> >>> at this particular address: >> >>> >>> *http://www.verovio.org/features.xhtml?id=mensural >> >> >>> >>> > >* >> >>> >>> You can download the whole file (it is larger than the short excerpt >> >>> shown >> >>> >>> there). It includes everything one needs know, you can see how they >> >>> encoded >> >>> >>> imperfections, alterations, dots and their effect in the note >> >>> (augmentation >> >>> >>> or division), changes in mensuration, etc. It also includes >> >>> coloration, but >> >>> >>> I think there is no agreement between the Mensural MEI community in >> >>> how to >> >>> >>> encode this particular feature (although I think the way it is >> >>> encoded in >> >>> >>> this example from the Verovio webpage is really good). >> >>> >>> >> >>> >>> Hope this helps, >> >>> >>> >> >>> >>> Martha >> >>> >>> >> >>> >>> Martha E. Thomae >> >>> >>> DDMAL Lab, >> >>> >>> Music Technology >> >>> >>> McGill University >> >>> >>> >> >>> >> >> >>> >> >> >>> >> _______________________________________________ >> >>> >> 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 >> >> >>> >> >>> >> >> >> >> >> >> -- >> >> *Martha E. Thomae* >> >> >> > >> > >> > >> > -- >> > *Martha E. Thomae* >> >> <001 MEI MN.mei>_______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Wed Jan 18 15:29:46 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 18 Jan 2017 14:29:46 +0000 Subject: [MEI-L] Sample encoding of mensural notation In-Reply-To: References: <20170113123548.Horde.pXyA6VDd6FvqzV-cYuxh3vu@webmail.server.uni-frankfurt.de> Message-ID: > If an XML file specifies one version of a DTD/schema, then how it is magically supposed to validate against another version, unless the newer version is backwards compatible with the older version? Sorry to break it to you, but there is no Santa Claus, Easter Bunny, or validation magic. But, there are XSLT stylesheets that help convert MEI from one version to the next. :-) -- p. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Fri Jan 20 11:19:14 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 20 Jan 2017 10:19:14 +0000 Subject: [MEI-L] Music Encoding Conference Dates Message-ID: Dear all, I've just noticed that there may be a mix-up in the dates for the MEC on the website. On the front page it says "16-19 May" which would seem to be correct; however, on the call for proposals, it says the 16-17, with pre-conference workshops on the 15 and the unconference day on the 18. http://music-encoding.org/community/conference/call-for-proposals/ I believe this should be corrected to say that the pre-conference workshops will be on the 16th, and the unconference day on the 19, with the main days of the conference the 17–18. Or have I missed something? Clarification would be appreciated. Thanks, -Andrew From Richard.Chesser at bl.uk Fri Jan 20 11:30:29 2017 From: Richard.Chesser at bl.uk (Chesser, Richard) Date: Fri, 20 Jan 2017 10:30:29 +0000 Subject: [MEI-L] Music Encoding Conference Dates In-Reply-To: References: Message-ID: Dear Andrew Yes, to my horror I just noticed this discrepancy the other day too. 16-19 May is correct, with workshops on 16th, conference 17-18th and unconference day on 19th. Richard -----Original Message----- From: mei-l [mailto:mei-l-bounces+richard.chesser=bl.uk at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: 20 January 2017 10:19 To: Music Encoding Initiative Subject: [MEI-L] Music Encoding Conference Dates Dear all, I've just noticed that there may be a mix-up in the dates for the MEC on the website. On the front page it says "16-19 May" which would seem to be correct; however, on the call for proposals, it says the 16-17, with pre-conference workshops on the 15 and the unconference day on the 18. http://music-encoding.org/community/conference/call-for-proposals/ I believe this should be corrected to say that the pre-conference workshops will be on the 16th, and the unconference day on the 19, with the main days of the conference the 17–18. Or have I missed something? Clarification would be appreciated. Thanks, -Andrew _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l ****************************************************************************************************************** Experience the British Library online at www.bl.uk The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled ***************************************************************************************************************** The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. ***************************************************************************************************************** Think before you print From kepper at edirom.de Fri Jan 20 11:36:09 2017 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 20 Jan 2017 11:36:09 +0100 Subject: [MEI-L] Music Encoding Conference Dates In-Reply-To: References: Message-ID: I've fixed the page accordingly, but please double-check. jo > Am 20.01.2017 um 11:30 schrieb Chesser, Richard : > > Dear Andrew > > Yes, to my horror I just noticed this discrepancy the other day too. 16-19 May is correct, with workshops on 16th, conference 17-18th and unconference day on 19th. > > Richard > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+richard.chesser=bl.uk at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson > Sent: 20 January 2017 10:19 > To: Music Encoding Initiative > Subject: [MEI-L] Music Encoding Conference Dates > > Dear all, > > I've just noticed that there may be a mix-up in the dates for the MEC on the website. On the front page it says "16-19 May" which would seem to be correct; however, on the call for proposals, it says the 16-17, with pre-conference workshops on the 15 and the unconference day on the 18. > > http://music-encoding.org/community/conference/call-for-proposals/ > > I believe this should be corrected to say that the pre-conference workshops will be on the 16th, and the unconference day on the 19, with the main days of the conference the 17–18. > > Or have I missed something? Clarification would be appreciated. > > Thanks, > -Andrew > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > ****************************************************************************************************************** > Experience the British Library online at www.bl.uk > The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html > Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook > The Library's St Pancras site is WiFi - enabled > ***************************************************************************************************************** > The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. > The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. > ***************************************************************************************************************** > Think before you print > _______________________________________________ > 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: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From Richard.Chesser at bl.uk Fri Jan 20 11:41:22 2017 From: Richard.Chesser at bl.uk (Chesser, Richard) Date: Fri, 20 Jan 2017 10:41:22 +0000 Subject: [MEI-L] Music Encoding Conference Dates In-Reply-To: References: Message-ID: Thanks, Jo: looks good now. Richard -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes Kepper Sent: 20 January 2017 10:36 To: Music Encoding Initiative Subject: Re: [MEI-L] Music Encoding Conference Dates I've fixed the page accordingly, but please double-check. jo > Am 20.01.2017 um 11:30 schrieb Chesser, Richard : > > Dear Andrew > > Yes, to my horror I just noticed this discrepancy the other day too. 16-19 May is correct, with workshops on 16th, conference 17-18th and unconference day on 19th. > > Richard > > -----Original Message----- > From: mei-l > [mailto:mei-l-bounces+richard.chesser=bl.uk at lists.uni-paderborn.de] On > Behalf Of Andrew Hankinson > Sent: 20 January 2017 10:19 > To: Music Encoding Initiative > Subject: [MEI-L] Music Encoding Conference Dates > > Dear all, > > I've just noticed that there may be a mix-up in the dates for the MEC on the website. On the front page it says "16-19 May" which would seem to be correct; however, on the call for proposals, it says the 16-17, with pre-conference workshops on the 15 and the unconference day on the 18. > > http://music-encoding.org/community/conference/call-for-proposals/ > > I believe this should be corrected to say that the pre-conference workshops will be on the 16th, and the unconference day on the 19, with the main days of the conference the 17–18. > > Or have I missed something? Clarification would be appreciated. > > Thanks, > -Andrew > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > ********************************************************************** > ******************************************** > Experience the British Library online at www.bl.uk > The British Library’s latest Annual Report and Accounts : > www.bl.uk/aboutus/annrep/index.html dex.html> Help the British Library conserve the world's knowledge. > Adopt a Book. www.bl.uk/adoptabook > The Library's St Pancras site is WiFi - enabled > ********************************************************************** > ******************************************* > The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. > The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. > ********************************************************************** > ******************************************* > Think before you print > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From vincent.besson at univ-tours.fr Fri Jan 20 13:48:54 2017 From: vincent.besson at univ-tours.fr (Vincent Besson) Date: Fri, 20 Jan 2017 13:48:54 +0100 (CET) Subject: [MEI-L] Music Encoding Conference Dates In-Reply-To: References: Message-ID: <644804816.570413.1484916534375.JavaMail.zimbra@univ-tours.fr> Dear Johannes, Please, change the link for CESR. The address is "http://www.cesr.cnrs.fr/" and not "http://cesr.univ-tours.fr/" Thanks! Vincent ----- Mail original ----- De: "kepper" À: "Music Encoding Initiative" Envoyé: Vendredi 20 Janvier 2017 11:36:09 Objet: Re: [MEI-L] Music Encoding Conference Dates I've fixed the page accordingly, but please double-check. jo > Am 20.01.2017 um 11:30 schrieb Chesser, Richard : > > Dear Andrew > > Yes, to my horror I just noticed this discrepancy the other day too. 16-19 May is correct, with workshops on 16th, conference 17-18th and unconference day on 19th. > > Richard > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+richard.chesser=bl.uk at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson > Sent: 20 January 2017 10:19 > To: Music Encoding Initiative > Subject: [MEI-L] Music Encoding Conference Dates > > Dear all, > > I've just noticed that there may be a mix-up in the dates for the MEC on the website. On the front page it says "16-19 May" which would seem to be correct; however, on the call for proposals, it says the 16-17, with pre-conference workshops on the 15 and the unconference day on the 18. > > http://music-encoding.org/community/conference/call-for-proposals/ > > I believe this should be corrected to say that the pre-conference workshops will be on the 16th, and the unconference day on the 19, with the main days of the conference the 17–18. > > Or have I missed something? Clarification would be appreciated. > > Thanks, > -Andrew > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > ****************************************************************************************************************** > Experience the British Library online at www.bl.uk > The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html > Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook > The Library's St Pancras site is WiFi - enabled > ***************************************************************************************************************** > The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. > The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. > ***************************************************************************************************************** > Think before you print > _______________________________________________ > 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 -- Vincent BESSON ♦ CENTRE D'ÉTUDES SUPÉRIEURES DE LA RENAISSANCE – http://www.cesr.cnrs.fr/ ♦ CONSORTIUM MUSICA – https://musica.hypotheses.org/ 59, rue Néricault-Destouches BP 12050 37020 Tours Cedex France +33 2 47 36 77 84 From bohl at edirom.de Mon Jan 23 12:35:47 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Mon, 23 Jan 2017 12:35:47 +0100 Subject: [MEI-L] encoding orchestra cast with alternative instruments Message-ID: Dear MEI-L:isteners, can anyone help me how to encode a cast list for an orchestra that gives alternating instruments for the players and potential replacements if certain instruments not being available? E.g.: In the cast list: “3 Oboes – 1. And 2. Also oboe d’amore, 3. Also cor anglais” Amongst other at the end of the cast list: “If necessary, the oboe d’amore can be replaced by an oboe, […]” Simple case ignoring additions: Alternatively trying to capture all instrument info: Oboe Oboe d'amore Cor d'anglais Nevertheless I can’t capture the idea of alternating instruments for the first two oboes resp. The oboes d’amore or the third oboe and the cor d’anglais… What if I use even a deeper nesting: Oboe Oboe d'amore Oboe Cor d'anglais I’m not sure whether this captures the meaning, especially since there is no possibility of stating the exclusive alteration, like e.g. in TEI with @exclude. Any thoughts would be appreciated! Many thanks Benjamin From njp2 at columbia.edu Wed Jan 25 17:50:18 2017 From: njp2 at columbia.edu (Nick Patterson) Date: Wed, 25 Jan 2017 11:50:18 -0500 Subject: [MEI-L] Any people working on MEI projects in the NYC area? Message-ID: Hi all, A PhD candidate in the Music Dept. here is participating in a Digital Internship program in the Libraries here this year. Part of his work concerns digital music notation, and he is investigating MEI. We're aware of the tutorials and resources on the MEI site, but, is anyone here aware of people working on MEI projects in the New York City area? He might like to reach out to them for some conversations. We are already aware of the Marenzio Project, which includes Columbia faculty person Giuseppe Gerbino, but any other leads would be greatly appreciated. Many thanks, /Nick -- Nick Patterson, Music Librarian Music & Arts Library, Columbia University 701 Dodge, 2960 Broadway New York, NY 10027 212-854-8523 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaeleviglianti at gmail.com Wed Jan 25 19:57:50 2017 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 25 Jan 2017 13:57:50 -0500 Subject: [MEI-L] Announcing the Society for Textual Scholarship's 2017 CFP Message-ID: *ANNOUNCING THE SOCIETY FOR TEXTUAL SCHOLARSHIP’S 2017 CFP * (With apologies for cross-posting) The Maryland Institute for Technology in the Humanities (MITH) and the Andrew W. Mellon-funded African American Digital Humanities Initiative (AADHum) invite your participation in “Textual Embodiments,” the Society for Textual Scholarship’s International Interdisciplinary Conference for 2017. *Date:* Wednesday, May 31 - Friday, June 2, 2017 *Location:* University of Maryland, College Park, Maryland USA Program Chairs: Neil Fraistat, Purdom Lindblad, Catherine Knight Steele, Raffaele Viglianti Deadline for Proposals: February 26, 2017 Keynote speakers: Marisa Parham (Amherst University) Susan Brown (University of Guelph) Our conference theme is "Textual Embodiments," broadly construed. With this theme we hope to engage a range of issues involving the materiality of texts, including their physical, virtual, or performative manifestations as objects that can decay or break down and can potentially be repaired and sustained over time. It also concerns the processes of inclusion and exclusion through which bodies of texts take shape in the form of editions, archives, collections, and exhibition building, as well as the ethical responsibilities faced by textual scholars, archivists, conservationists, media archeologists, digital resource creators, and cultural heritage professionals engaging in these processes. As always, the conference is open to submissions involving interdisciplinary discussion of current research into particular aspects of textual work: the discovery, enumeration, description, bibliographical analysis, editing, annotation, mark-up, and sustainability of texts in disciplines such as cultural studies, literature, history, musicology, classical and biblical studies, philosophy, art history, legal history, history of science and technology, computer science, library and information science, archives, lexicography, epigraphy, paleography, codicology, cinema studies, new media studies, game studies, theater, linguistics, and textual and literary theory. Considerations of the role of computational methodologies, tools, and technologies in textual theory and practice are of course welcome, as are papers addressing aspects of archival theory and practice as they pertain to textual criticism and scholarly editing. Especially welcome are interdisciplinary papers addressing the theme of Textual Embodiment in the fields of Black Diaspora Studies, Indigenous Studies, LGBTQ Studies, Latinx Studies, Disability Studies, Women’s Studies, and Critical Theory. Submissions may take the following traditional forms: 1. Papers. Papers should be no more than 20 minutes in length, making a significant original contribution to scholarship. Papers that are primarily reports or demonstrations of tools or projects are discouraged. 2. Panels. Panels may consist of either three associated papers or four to six roundtable speakers. Roundtables should address topics of broad interest and scope, with the goal of fostering lively debate with audience participation. 3. Workshops. Workshops should propose a specific problem, tool, or skill set for which the workshop leader will provide expert guidance and instruction. Examples might be an introduction to forensic computing or paleography. Workshop proposals that are accepted will be announced on the conference Web site (http://www.textual.org) and attendees will be required to enroll with the workshop leader(s). 4. Submissions may also take the form of Open Fishbowl sessions . Drawing on the expertise of both speakers and attendees, Fishbowls are small group discussions in which 5 initial participants face one another in a circle, in the middle of the larger audience. Participants cycle out as audience members join the inner circle to create dialogue across perspectives and different types of research. Submitted proposals should include a brief statement as to the core idea or theme for the fishbowl, emphasizing its relation to conference themes or relevance to the larger Textual Studies community. Naming some or all of the initial five “fish” is encouraged. Potential topics for Fishbowl session might include, for example, “Minimal Computing, Globalized Editions,” “Participatory Editions,” and “#ArchivesSoWhite.” Proposals for all formats should include a title; abstract (250 words max.) of the proposed paper, panel, seminar, or workshop; and name, email address, and institutional affiliation for all participants. Format should be clearly indicated. Seminar, fishbowl, and workshop proposals in particular should take care to articulate the imagined audience and any expectations of prior knowledge or preparation. *All abstracts should indicate what if any technological support will be required.* Inquiries and proposals should be submitted electronically to https://goo.gl/forms/B6xi4SmZAkmwWB9o2/. Responses will be sent by March 10. -------------- next part -------------- An HTML attachment was scrubbed... URL: From atge at kb.dk Wed Jan 25 22:27:27 2017 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 25 Jan 2017 21:27:27 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> Hi Benni Good question. I would love to see a solution as well. So far we have really just worked around the problem by only mentioning alternative or alternating instruments in plain text like this (using your example): Oboe / oboe d'amore This is obviously not well suited for any computerized use of the information (which, however, we haven't needed yet). The current schema does not allow nesting , so your suggested approach doesn't validate out of the box. While allowing child elements in may be the way to go, I would perhaps not suggest nesting itself: As you say, simply nesting them doesn't make it clear whether the instruments are possible replacements or one player playing alternating instruments. More specific elements or attributes may be required. The problem may be that is intended to describe a single instrument (or ensemble), not all the instruments played by a single performer. What may be needed is a "performer" grouping device. As is exactly that: a grouping device, perhaps simply adding an attribute such as @type to and may do the trick: Oboe Oboe d'amore Oboe Oboe d'amore Oboe Cor anglais However, this would probably require omitting the @count attribute: What would, say, count="2" mean with a single performer? Perhaps that one has to play 2 oboes simultaneously. :-/ If you want to group both by performer and instrument family ("Oboe") you might need another to wrap the three performers: Oboes Oboe Oboe d'amore Oboe Oboe d'amore Oboe Cor anglais I am not sure this is the way to go. Any thoughts? Best, Axel ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin W. Bohl [bohl at edirom.de] Sendt: 23. januar 2017 12:35 Til: Music Encoding Initiative Emne: [MEI-L] encoding orchestra cast with alternative instruments Dear MEI-L:isteners, can anyone help me how to encode a cast list for an orchestra that gives alternating instruments for the players and potential replacements if certain instruments not being available? E.g.: In the cast list: “3 Oboes – 1. And 2. Also oboe d’amore, 3. Also cor anglais” Amongst other at the end of the cast list: “If necessary, the oboe d’amore can be replaced by an oboe, […]” Simple case ignoring additions: Alternatively trying to capture all instrument info: Oboe Oboe d'amore Cor d'anglais Nevertheless I can’t capture the idea of alternating instruments for the first two oboes resp. The oboes d’amore or the third oboe and the cor d’anglais… What if I use even a deeper nesting: Oboe Oboe d'amore Oboe Cor d'anglais I’m not sure whether this captures the meaning, especially since there is no possibility of stating the exclusive alteration, like e.g. in TEI with @exclude. Any thoughts would be appreciated! Many thanks Benjamin _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From atge at kb.dk Wed Jan 25 22:34:41 2017 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 25 Jan 2017 21:34:41 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> References: , <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> Oops: You'll notice that I forgot to change the @codedval values when copy-pasting... Cor anglais should have @codedval="wf" :-) /axel ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Axel Teich Geertinger [atge at kb.dk] Sendt: 25. januar 2017 22:27 Til: Music Encoding Initiative Emne: Re: [MEI-L] encoding orchestra cast with alternative instruments Hi Benni Good question. I would love to see a solution as well. So far we have really just worked around the problem by only mentioning alternative or alternating instruments in plain text like this (using your example): Oboe / oboe d'amore This is obviously not well suited for any computerized use of the information (which, however, we haven't needed yet). The current schema does not allow nesting , so your suggested approach doesn't validate out of the box. While allowing child elements in may be the way to go, I would perhaps not suggest nesting itself: As you say, simply nesting them doesn't make it clear whether the instruments are possible replacements or one player playing alternating instruments. More specific elements or attributes may be required. The problem may be that is intended to describe a single instrument (or ensemble), not all the instruments played by a single performer. What may be needed is a "performer" grouping device. As is exactly that: a grouping device, perhaps simply adding an attribute such as @type to and may do the trick: Oboe Oboe d'amore Oboe Oboe d'amore Oboe Cor anglais However, this would probably require omitting the @count attribute: What would, say, count="2" mean with a single performer? Perhaps that one has to play 2 oboes simultaneously. :-/ If you want to group both by performer and instrument family ("Oboe") you might need another to wrap the three performers: Oboes Oboe Oboe d'amore Oboe Oboe d'amore Oboe Cor anglais I am not sure this is the way to go. Any thoughts? Best, Axel ________________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin W. Bohl [bohl at edirom.de] Sendt: 23. januar 2017 12:35 Til: Music Encoding Initiative Emne: [MEI-L] encoding orchestra cast with alternative instruments Dear MEI-L:isteners, can anyone help me how to encode a cast list for an orchestra that gives alternating instruments for the players and potential replacements if certain instruments not being available? E.g.: In the cast list: “3 Oboes – 1. And 2. Also oboe d’amore, 3. Also cor anglais” Amongst other at the end of the cast list: “If necessary, the oboe d’amore can be replaced by an oboe, […]” Simple case ignoring additions: Alternatively trying to capture all instrument info: Oboe Oboe d'amore Cor d'anglais Nevertheless I can’t capture the idea of alternating instruments for the first two oboes resp. The oboes d’amore or the third oboe and the cor d’anglais… What if I use even a deeper nesting: Oboe Oboe d'amore Oboe Cor d'anglais I’m not sure whether this captures the meaning, especially since there is no possibility of stating the exclusive alteration, like e.g. in TEI with @exclude. Any thoughts would be appreciated! Many thanks Benjamin _______________________________________________ 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 From pdr4h at eservices.virginia.edu Wed Jan 25 23:48:53 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 25 Jan 2017 22:48:53 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> References: , <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> Message-ID: Hi Benni and Axel, everyone, This is why is self-nesting and why it is named, perhaps a little obtusely, "performance resource list". It's a way of grouping performing resources, whether they are groups of like instruments, such as strings or woodwinds, or whether they are resources used/supplied (?) by a single performer. I tried to inject a element in the model, but I remember that it became too complex for my meager faculties to contemplate. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel > Teich Geertinger > Sent: Wednesday, January 25, 2017 4:35 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments > > Oops: You'll notice that I forgot to change the @codedval values when copy- > pasting... > Cor anglais should have @codedval="wf" :-) > > /axel > > ________________________________________ > Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Axel Teich > Geertinger [atge at kb.dk] > Sendt: 25. januar 2017 22:27 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] encoding orchestra cast with alternative instruments > > Hi Benni > > Good question. I would love to see a solution as well. So far we have really just > worked around the problem by only mentioning alternative or alternating > instruments in plain text like this (using your example): > > Oboe / oboe > d'amore > > This is obviously not well suited for any computerized use of the information > (which, however, we haven't needed yet). > > The current schema does not allow nesting , so your suggested > approach doesn't validate out of the box. While allowing child elements in > may be the way to go, I would perhaps not suggest nesting > itself: As you say, simply nesting them doesn't make it clear whether > the instruments are possible replacements or one player playing alternating > instruments. More specific elements or attributes may be required. > > The problem may be that is intended to describe a single instrument > (or ensemble), not all the instruments played by a single performer. What may > be needed is a "performer" grouping device. As is exactly that: a > grouping device, perhaps simply adding an attribute such as @type > to and may do the trick: > > > > > Oboe > Oboe > d'amore > > > Oboe > Oboe > d'amore > > > Oboe > Cor > anglais > > > > > However, this would probably require omitting the @count attribute: What > would, say, count="2" mean with a single performer? Perhaps that one has to > play 2 oboes simultaneously. :-/ > > If you want to group both by performer and instrument family ("Oboe") you > might need another to wrap the three performers: > > > > > Oboes > > Oboe > Oboe > d'amore > > > Oboe > Oboe > d'amore > > > Oboe > Cor > anglais > > > > > > I am not sure this is the way to go. Any thoughts? > > Best, > Axel > > ________________________________________ > Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin > W. Bohl [bohl at edirom.de] > Sendt: 23. januar 2017 12:35 > Til: Music Encoding Initiative > Emne: [MEI-L] encoding orchestra cast with alternative instruments > > Dear MEI-L:isteners, > > can anyone help me how to encode a cast list for an orchestra that gives > alternating instruments for the players and potential replacements if certain > instruments not being available? > > E.g.: > In the cast list: > “3 Oboes – 1. And 2. Also oboe d’amore, 3. Also cor anglais” > > Amongst other at the end of the cast list: > “If necessary, the oboe d’amore can be replaced by an oboe, […]” > > Simple case ignoring additions: > > > > > > > > Alternatively trying to capture all instrument info: > > > > > Oboe > Oboe > d'amore > Cor d'anglais > > > > > Nevertheless I can’t capture the idea of alternating instruments for the first > two oboes resp. The oboes d’amore or the third oboe and the cor d’anglais… > > What if I use even a deeper nesting: > > > > > > Oboe > Oboe > d'amore > > > Oboe > Cor > d'anglais > > > > > > I’m not sure whether this captures the meaning, especially since there is no > possibility of stating the exclusive alteration, like e.g. in TEI with @exclude. > > Any thoughts would be appreciated! > Many thanks > Benjamin > > > _______________________________________________ > 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 From DanielAlles at stud.uni-frankfurt.de Thu Jan 26 22:40:42 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 26 Jan 2017 22:40:42 +0100 Subject: [MEI-L] Problems encoding CMN In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> Message-ID: <20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_heugel_magnificat_cmn.pdf Type: application/pdf Size: 99869 bytes Desc: not available URL: From andrew.hankinson at mail.mcgill.ca Thu Jan 26 22:57:10 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 26 Jan 2017 22:57:10 +0100 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> Message-ID: <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> 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 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 From DanielAlles at stud.uni-frankfurt.de Thu Jan 26 23:45:03 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 26 Jan 2017 23:45:03 +0100 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> Message-ID: <20170126234503.Horde.C8fhUWMgPuHFJ4YRzYpMPJi@webmail.server.uni-frankfurt.de> Hello Andrew, thank you very much for your reply, that really clarified a lot for me! So let me rephrase my questions: Is there a general consens on how to encode those accidentals or has every project its own rules? What about the grouping of former ligatures in CMN? Does the element work in CMN? Daniel Zitat von Andrew Hankinson : > 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 >> 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 From craigsapp at gmail.com Fri Jan 27 01:28:14 2017 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 26 Jan 2017 16:28:14 -0800 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdibacco at indiana.edu Fri Jan 27 02:19:47 2017 From: gdibacco at indiana.edu (Di Bacco, Giuliano) Date: Fri, 27 Jan 2017 01:19:47 +0000 Subject: [MEI-L] Problems encoding CMN In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> Message-ID: <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> 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 > 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From craigsapp at gmail.com Fri Jan 27 02:38:29 2017 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 26 Jan 2017 17:38:29 -0800 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> Message-ID: Hi Giuliano, One possibility is to use the type attribute: Also the "label" attribute seems like a possibility: -=+Craig On 26 January 2017 at 17:19, Di Bacco, Giuliano 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 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: From donbyrd at indiana.edu Fri Jan 27 03:38:48 2017 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Fri, 27 Jan 2017 02:38:48 +0000 Subject: [MEI-L] Problems encoding CMN; element for ligature transcription In-Reply-To: <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> Message-ID: It sure does need discussion, and a few sighs wouldn't be out of place. Andrew described "one of the core tenets of MEI -- the separation of the semantic and the symbol...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." That sounds good, but then Perry says you'd use a element to indicate a ligature. Okay, so the MEI element has some semantics -- it can encode grouping -- but (as far as I can see) it has no way to say that the group is a transcription of notes originally in a mensural ligature. I'm not sure that the answer to Giuliano's last question is "yes"; it could be that some lines don't have a function. Other than that, unless I'm completely missing something, he's absolutely correct. --Don On Jan 26, 2017, at 8:19 PM, "Di Bacco, Giuliano" 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 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 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 --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From donbyrd at indiana.edu Fri Jan 27 03:51:00 2017 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Fri, 27 Jan 2017 02:51:00 +0000 Subject: [MEI-L] Problems encoding CMN; ligature transcription In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> Message-ID: <70E3ABE5-14FF-4DF3-998E-6D214277B2B5@indiana.edu> 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 , not a category, but "type" seems to do what's needed. Giuliano? --DAB On Jan 26, 2017, at 8:38 PM, Craig Sapp wrote: > Hi Giuliano, > > One possibility is to use the type attribute: > > > > Also the "label" attribute seems like a possibility: > > > > > > -=+Craig > > > On 26 January 2017 at 17:19, Di Bacco, Giuliano 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 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 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 From lxpugin at gmail.com Fri Jan 27 11:22:19 2017 From: lxpugin at gmail.com (Laurent Pugin) Date: Fri, 27 Jan 2017 11:22:19 +0100 Subject: [MEI-L] Problems encoding CMN In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <23659_1485466878_588A6CFD_23659_152_1_20170126224042.Horde.Wx15rafij6IEKx5IDS49Wrz@webmail.server.uni-frankfurt.de> <63DCB493-325A-49D4-84A8-CE0E2B47E6BD@mail.mcgill.ca> <439df7f9-f266-4b0a-9290-da997643a7cd@typeapp.com> Message-ID: Hi, In the next version of MEI there will be a 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 wrote: > Hi Giuliano, > > One possibility is to use the type attribute: > > > > Also the "label" attribute seems like a possibility: > > > > > > -=+Craig > > > On 26 January 2017 at 17:19, Di Bacco, Giuliano > 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 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: From DanielAlles at stud.uni-frankfurt.de Fri Jan 27 14:27:22 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Fri, 27 Jan 2017 14:27:22 +0100 Subject: [MEI-L] Problems encoding CMN Message-ID: <20170127142722.Horde.kBvTJGoSduY5lnqgZ37lsWJ@webmail.server.uni-frankfurt.de> 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 element and convert them later into MEI 4.0 (into )? Or should I encode them already with this element and use attributes like those mentioned by Perry? They sound useful, I would a element wish to have soemthing similar... Daniel Zitat von Laurent Pugin : > Hi, > > In the next version of MEI there will be a 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 wrote: > >> Hi Giuliano, >> >> One possibility is to use the type attribute: >> >> >> >> Also the "label" attribute seems like a possibility: >> >> >> >> >> >> -=+Craig >> >> >> On 26 January 2017 at 17:19, Di Bacco, Giuliano >> 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 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 >> >> From pdr4h at eservices.virginia.edu Fri Jan 27 15:03:36 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 27 Jan 2017 14:03:36 +0000 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <20170127142722.Horde.kBvTJGoSduY5lnqgZ37lsWJ@webmail.server.uni-frankfurt.de> References: <20170127142722.Horde.kBvTJGoSduY5lnqgZ37lsWJ@webmail.server.uni-frankfurt.de> Message-ID: 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 . 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 element and convert them later into MEI > 4.0 (into )? Or should I encode them already with this element > and use attributes like those mentioned by Perry? They sound useful, I would a > element wish to have soemthing similar... > > Daniel > > Zitat von Laurent Pugin : > > > Hi, > > > > In the next version of MEI there will be a 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 wrote: > > > >> Hi Giuliano, > >> > >> One possibility is to use the type attribute: > >> > >> > >> > >> Also the "label" attribute seems like a possibility: > >> > >> > >> > >> > >> > >> -=+Craig > >> > >> > >> On 26 January 2017 at 17:19, Di Bacco, Giuliano > >> > >> 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 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: From andrew.hankinson at mail.mcgill.ca Fri Jan 27 23:05:14 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 27 Jan 2017 23:05:14 +0100 Subject: [MEI-L] Problems encoding CMN In-Reply-To: <21711_1485526054_588B5425_21711_4_15_BBCC497C40D85642B90E9F94FC30343DDBFE2F0D@REAGAN1.eservices.virginia.edu> References: <20170127142722.Horde.kBvTJGoSduY5lnqgZ37lsWJ@webmail.server.uni-frankfurt.de> <21711_1485526054_588B5425_21711_4_15_BBCC497C40D85642B90E9F94FC30343DDBFE2F0D@REAGAN1.eservices.virginia.edu> Message-ID: <1BE14DCC-171E-45B1-8106-14A509F5BDD2@mail.mcgill.ca> Note that the "official" URL for the customization service is http://custom.music-encoding.org/ . :) -Andrew > On Jan 27, 2017, at 3:03 PM, Roland, Perry D. (pdr4h) wrote: > > > 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 . > > 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 element and convert them later into MEI >> 4.0 (into )? Or should I encode them already with this element >> and use attributes like those mentioned by Perry? They sound useful, I would a >> element wish to have soemthing similar... >> >> Daniel >> >> Zitat von Laurent Pugin : >> >>> Hi, >>> >>> In the next version of MEI there will be a 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 wrote: >>> >>>> Hi Giuliano, >>>> >>>> One possibility is to use the type attribute: >>>> >>>> >>>> >>>> Also the "label" attribute seems like a possibility: >>>> >>>> >>>> >>>> >>>> >>>> -=+Craig >>>> >>>> >>>> On 26 January 2017 at 17:19, Di Bacco, Giuliano >>>> >>>> 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 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 > _______________________________________________ > 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: From bohl at edirom.de Tue Jan 31 12:09:17 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Tue, 31 Jan 2017 12:09:17 +0100 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> Message-ID: <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Dear Axel and Perry, thanks for your advice. I like the idea of using @type but it’s not allowed on perfResList in MEI v3.0.0 is that to change in the next release? For the moment I came up with the following to capture the whole situation: Oboes Oboe Oboe d'amore Oboe Oboe Cor d'anglais How do you like it? I’m not sure whether I’ll keep @count on the parent but I think I will, in order to provide a "flat processing”. >> The current schema does not allow nesting N.B. according to the data dictionary and the schema it is allowed; maybe a mistake? I see your point, that nesting is much more feasible ;-) > On 25 Jan 2017, at 23:48, Roland, Perry D. (pdr4h) wrote: > > > Hi Benni and Axel, everyone, > > This is why is self-nesting and why it is named, perhaps a little obtusely, "performance resource list". It's a way of grouping performing resources, whether they are groups of like instruments, such as strings or woodwinds, or whether they are resources used/supplied (?) by a single performer. I tried to inject a element in the model, but I remember that it became too complex for my meager faculties to contemplate. > > -- > p. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel >> Teich Geertinger >> Sent: Wednesday, January 25, 2017 4:35 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments >> >> Oops: You'll notice that I forgot to change the @codedval values when copy- >> pasting... >> Cor anglais should have @codedval="wf" :-) >> >> /axel >> >> ________________________________________ >> Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Axel Teich >> Geertinger [atge at kb.dk] >> Sendt: 25. januar 2017 22:27 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] encoding orchestra cast with alternative instruments >> >> Hi Benni >> >> Good question. I would love to see a solution as well. So far we have really just >> worked around the problem by only mentioning alternative or alternating >> instruments in plain text like this (using your example): >> >> Oboe / oboe >> d'amore >> >> This is obviously not well suited for any computerized use of the information >> (which, however, we haven't needed yet). >> >> The current schema does not allow nesting , so your suggested >> approach doesn't validate out of the box. While allowing child elements in >> may be the way to go, I would perhaps not suggest nesting >> itself: As you say, simply nesting them doesn't make it clear whether >> the instruments are possible replacements or one player playing alternating >> instruments. More specific elements or attributes may be required. >> >> The problem may be that is intended to describe a single instrument >> (or ensemble), not all the instruments played by a single performer. What may >> be needed is a "performer" grouping device. As is exactly that: a >> grouping device, perhaps simply adding an attribute such as @type >> to and may do the trick: >> >> >> >> >> Oboe >> Oboe >> d'amore >> >> >> Oboe >> Oboe >> d'amore >> >> >> Oboe >> Cor >> anglais >> >> >> >> >> However, this would probably require omitting the @count attribute: What >> would, say, count="2" mean with a single performer? Perhaps that one has to >> play 2 oboes simultaneously. :-/ >> >> If you want to group both by performer and instrument family ("Oboe") you >> might need another to wrap the three performers: >> >> >> >> >> Oboes >> >> Oboe >> Oboe >> d'amore >> >> >> Oboe >> Oboe >> d'amore >> >> >> Oboe >> Cor >> anglais >> >> >> >> >> >> I am not sure this is the way to go. Any thoughts? >> >> Best, >> Axel >> >> ________________________________________ >> Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Benjamin >> W. Bohl [bohl at edirom.de] >> Sendt: 23. januar 2017 12:35 >> Til: Music Encoding Initiative >> Emne: [MEI-L] encoding orchestra cast with alternative instruments >> >> Dear MEI-L:isteners, >> >> can anyone help me how to encode a cast list for an orchestra that gives >> alternating instruments for the players and potential replacements if certain >> instruments not being available? >> >> E.g.: >> In the cast list: >> “3 Oboes – 1. And 2. Also oboe d’amore, 3. Also cor anglais” >> >> Amongst other at the end of the cast list: >> “If necessary, the oboe d’amore can be replaced by an oboe, […]” >> >> Simple case ignoring additions: >> >> >> >> >> >> >> >> Alternatively trying to capture all instrument info: >> >> >> >> >> Oboe >> Oboe >> d'amore >> Cor d'anglais >> >> >> >> >> Nevertheless I can’t capture the idea of alternating instruments for the first >> two oboes resp. The oboes d’amore or the third oboe and the cor d’anglais… >> >> What if I use even a deeper nesting: >> >> >> >> >> >> Oboe >> Oboe >> d'amore >> >> >> Oboe >> Cor >> d'anglais >> >> >> >> >> >> I’m not sure whether this captures the meaning, especially since there is no >> possibility of stating the exclusive alteration, like e.g. in TEI with @exclude. >> >> Any thoughts would be appreciated! >> Many thanks >> Benjamin >> >> >> _______________________________________________ >> 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 From pdr4h at eservices.virginia.edu Tue Jan 31 15:58:06 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 31 Jan 2017 14:58:06 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Message-ID: Hi Benni, Yes, @type will be added in the next release. Your solution looks good, but may I suggest -- 1. 2. 3. Oboes 4. 5. Oboe 6. 7. Oboe d'amore 8. Oboe 9. 10. 11. 12. Oboe 13. Cor d'anglais 14. 15. 16. This puts the indication of substitution on the rather than on the secondary instrument. Also, @count at line 5 has been removed. -- p. From lxpugin at gmail.com Tue Jan 31 16:00:03 2017 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 31 Jan 2017 16:00:03 +0100 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Message-ID: Sorry, I might be completely off-topic here, but would in be an option? Laurent On Tue, Jan 31, 2017 at 3:58 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > Hi Benni, > > Yes, @type will be added in the next release. > > Your solution looks good, but may I suggest -- > > 1. > 2. > 3. Oboes > 4. > 5. Oboe > 6. > 7. Oboe d'amore > 8. Oboe > 9. > 10. > 11. > 12. Oboe > 13. Cor d'anglais > 14. > 15. > 16. > > This puts the indication of substitution on the rather than > on the secondary instrument. Also, @count at line 5 has been removed. > > -- > p. > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Tue Jan 31 17:34:40 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 31 Jan 2017 16:34:40 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Message-ID: marks editorial options. It's a member of model.editLike and its children are all members of the model.editLike or model.editorialLike classes. It's not intended to be used for generic "either-or" encoding decisions. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Tuesday, January 31, 2017 10:01 AM To: Music Encoding Initiative Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments Sorry, I might be completely off-topic here, but would in be an option? Laurent On Tue, Jan 31, 2017 at 3:58 PM, Roland, Perry D. (pdr4h) > wrote: Hi Benni, Yes, @type will be added in the next release. Your solution looks good, but may I suggest -- 1. 2. 3. Oboes 4. 5. Oboe 6. 7. Oboe d'amore 8. Oboe 9. 10. 11. 12. Oboe 13. Cor d'anglais 14. 15. 16. This puts the indication of substitution on the rather than on the secondary instrument. Also, @count at line 5 has been removed. -- p. _______________________________________________ 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: From atge at kb.dk Tue Jan 31 18:04:22 2017 From: atge at kb.dk (Axel Teich Geertinger) Date: Tue, 31 Jan 2017 17:04:22 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D101986FB4FB@EXCHANGE-01.kb.dk> Hi Perry & Benni I am not quite sure about either of your solutions. Especially line 8 bothers me. Isn't that redundant? It just repeats the information in line 5 – isn't that asking for trouble? Benni, does the @type="substitution" in your version of line 8 mean to say explicitly that it is the oboe which may be substituted? I don't see why that is necessary (at least not in this simple case). Omitting that line, however, brings us back to my suggestion (slightly modified here): Oboe Oboe d'amore As long as the situation is not overly complex, this seems to be a far simpler solution to me. Or are you trying to take into account the possibility that a performer may play more than one instrument, one or more of which may be substituted? In that case I do see the need for something more specific. However, I would like to omit repeating any instrument declaration. An alternative way of making explicit which instrument may be substituted would be to invent another attribute to point to that instrument. Then perhaps you could even omit @type: Oboe Oboe d'amore Just an idea. /axel -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Tuesday, January 31, 2017 3:58 PM To: Music Encoding Initiative Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments Hi Benni, Yes, @type will be added in the next release. Your solution looks good, but may I suggest -- 1. 2. 3. Oboes 4. 5. Oboe 6. 7. Oboe d'amore 8. Oboe 9. 10. 11. 12. Oboe 13. Cor d'anglais 14. 15. 16. This puts the indication of substitution on the rather than on the secondary instrument. Also, @count at line 5 has been removed. -- p. _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From lxpugin at gmail.com Tue Jan 31 19:09:02 2017 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 31 Jan 2017 19:09:02 +0100 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> Message-ID: > > > > marks editorial options. It's a member of model.editLike and its > children are all members of the model.editLike or model.editorialLike > classes. It's not intended to be used for generic "either-or" encoding > decisions. > I thought so, but since it is used in a few places in the header (, ) I thought it could be an option. These are different cases. > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Tuesday, January 31, 2017 10:01 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] encoding orchestra cast with alternative > instruments > > > > Sorry, I might be completely off-topic here, but would in > be an option? > > > > Laurent > > > > On Tue, Jan 31, 2017 at 3:58 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > Hi Benni, > > Yes, @type will be added in the next release. > > Your solution looks good, but may I suggest -- > > 1. > 2. > 3. Oboes > 4. > 5. Oboe > 6. > 7. Oboe d'amore > 8. Oboe > 9. > 10. > 11. > 12. Oboe > 13. Cor d'anglais > 14. > 15. > 16. > > This puts the indication of substitution on the rather than > on the secondary instrument. Also, @count at line 5 has been removed. > > -- > p. > > > _______________________________________________ > 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: From bohl at edirom.de Wed Feb 1 09:15:48 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Wed, 1 Feb 2017 09:15:48 +0100 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D101986FB4FB@EXCHANGE-01.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D101986FB4FB@EXCHANGE-01.kb.dk> Message-ID: Hi everybody, yes , as stated in my initial mail I’m trying to take account of the following situation. 3 Oboe players - 1 and 2 also play Oboe d’amore that might be substituted by Oboe - 3 also plays Cor d’anglais that may not be substituted The idea is to state somehow, that Oboe and Oboe d’amore (1 and 2) and Oboe and Cor d’anglais (3) are in exclusive alteration, AND that in case there is no Oboe d’amore available, 1 and 2 might keep playing their Oboe for those sections. In the following suggestion by Perry: > 6. > 7. Oboe d'amore > 8. Oboe > 9. I miss the indication, which instrument is the “regular” and which one the “alternative”. Axels idea of @substitutes is comes way closer to that: > Oboe > Oboe d'amore Nevertheless it can be misunderstood I think, as you could read it as verb (1) or as noun (2): 1) Oboe d’amore substitutes Oboe 2) Oboe d’amore has a potential substitute, namely Oboe Of course that’s something that c an become clear from the documentation, but maybe omitting the ’s’ (@substitute) would make it clearer? Benni > On 31 Jan 2017, at 18:04, Axel Teich Geertinger wrote: > > Hi Perry & Benni > > I am not quite sure about either of your solutions. Especially line 8 bothers me. Isn't that redundant? It just repeats the information in line 5 – isn't that asking for trouble? > Benni, does the @type="substitution" in your version of line 8 mean to say explicitly that it is the oboe which may be substituted? I don't see why that is necessary (at least not in this simple case). > Omitting that line, however, brings us back to my suggestion (slightly modified here): > > > Oboe > Oboe d'amore > > > As long as the situation is not overly complex, this seems to be a far simpler solution to me. Or are you trying to take into account the possibility that a performer may play more than one instrument, one or more of which may be substituted? In that case I do see the need for something more specific. However, I would like to omit repeating any instrument declaration. An alternative way of making explicit which instrument may be substituted would be to invent another attribute to point to that instrument. Then perhaps you could even omit @type: > > Oboe > Oboe d'amore > > Just an idea. > > /axel > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) > Sent: Tuesday, January 31, 2017 3:58 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments > > > Hi Benni, > > Yes, @type will be added in the next release. > > Your solution looks good, but may I suggest -- > > 1. > 2. > 3. Oboes > 4. > 5. Oboe > 6. > 7. Oboe d'amore > 8. Oboe > 9. > 10. > 11. > 12. Oboe > 13. Cor d'anglais > 14. > 15. > 16. > > This puts the indication of substitution on the rather than on the secondary instrument. Also, @count at line 5 has been removed. > > -- > p. > > _______________________________________________ > 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 From pdr4h at eservices.virginia.edu Wed Feb 1 17:00:57 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 1 Feb 2017 16:00:57 +0000 Subject: [MEI-L] encoding orchestra cast with alternative instruments In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10195B00AA4@EXCHANGE-03.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10195B01ACD@EXCHANGE-03.kb.dk> <8A074119-1BEC-4627-A5DE-1FBACEDD5268@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D101986FB4FB@EXCHANGE-01.kb.dk> Message-ID: A discussion happening in the MEI Github repo on the topic of encoding order influenced my suggestion here. In this case, however, relying on encoding order inside may not be helpful. So, at present you can use -- Oboes Oboe Oboe d'amore Oboe Oboe Cor d'anglais which types the elements. This should be sufficient for your needs, but won't be enforce-able across multiple projects. A @substitute attribute is a good suggestion because it is more machine-processable than the ad hoc values of @type. Naming it @substitutefor or @subfor would make the direction/meaning of the reference explicit. BTW, the @solo attribute isn't necessary. One can assume that any performing resource not marked with @solo="true" is not a soloist. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Benjamin W. Bohl > Sent: Wednesday, February 01, 2017 3:16 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments > > Hi everybody, > > yes , as stated in my initial mail I’m trying to take account of the following > situation. > > 3 Oboe players > - 1 and 2 also play Oboe d’amore that might be substituted by Oboe > - 3 also plays Cor d’anglais that may not be substituted > > The idea is to state somehow, that Oboe and Oboe d’amore (1 and 2) and > Oboe and Cor d’anglais (3) are in exclusive alteration, AND that in case there is > no Oboe d’amore available, 1 and 2 might keep playing their Oboe for those > sections. > > In the following suggestion by Perry: > > > 6. > > 7. Oboe d'amore > > 8. Oboe > > 9. > > > I miss the indication, which instrument is the “regular” and which one the > “alternative”. Axels idea of @substitutes is comes way closer to that: > > > Oboe > > Oboe > d'amore > > Nevertheless it can be misunderstood I think, as you could read it as verb (1) or > as noun (2): > 1) Oboe d’amore substitutes Oboe > 2) Oboe d’amore has a potential substitute, namely Oboe > > Of course that’s something that c an become clear from the documentation, > but maybe omitting the ’s’ (@substitute) would make it clearer? > > Benni > > > > On 31 Jan 2017, at 18:04, Axel Teich Geertinger wrote: > > > > Hi Perry & Benni > > > > I am not quite sure about either of your solutions. Especially line 8 bothers > me. Isn't that redundant? It just repeats the information in line 5 – isn't that > asking for trouble? > > Benni, does the @type="substitution" in your version of line 8 mean to say > explicitly that it is the oboe which may be substituted? I don't see why that is > necessary (at least not in this simple case). > > Omitting that line, however, brings us back to my suggestion (slightly > modified here): > > > > > > Oboe > > Oboe > d'amore > > > > > > As long as the situation is not overly complex, this seems to be a far simpler > solution to me. Or are you trying to take into account the possibility that a > performer may play more than one instrument, one or more of which may be > substituted? In that case I do see the need for something more specific. > However, I would like to omit repeating any instrument declaration. An > alternative way of making explicit which instrument may be substituted would > be to invent another attribute to point to that instrument. Then perhaps you > could even omit @type: > > > > Oboe > > Oboe > d'amore > > > > Just an idea. > > > > /axel > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Roland, Perry D. (pdr4h) > > Sent: Tuesday, January 31, 2017 3:58 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] encoding orchestra cast with alternative instruments > > > > > > Hi Benni, > > > > Yes, @type will be added in the next release. > > > > Your solution looks good, but may I suggest -- > > > > 1. xmlns:svg="http://www.w3.org/2000/svg"> > > 2. > > 3. Oboes > > 4. > > 5. Oboe > > 6. > > 7. Oboe d'amore > > 8. Oboe > > 9. > > 10. > > 11. > > 12. Oboe > > 13. Cor d'anglais > > 14. > > 15. > > 16. > > > > This puts the indication of substitution on the rather than on > the secondary instrument. Also, @count at line 5 has been removed. > > > > -- > > p. > > > > _______________________________________________ > > 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 From bohl at edirom.de Wed Feb 1 21:07:30 2017 From: bohl at edirom.de (Benjamin W. Bohl) Date: Wed, 1 Feb 2017 21:07:30 +0100 Subject: [MEI-L] Results 2016 Board elections Message-ID: Dear MEI community, I’m happy to announce that elections have closed for the three vacant positions on the MEI Board. The three candidates that will serve for the upcoming three years (until the end of 2019) are: Andrew Hankinson, Johannes Kepper, and Eleanor Selfridge-Field. Congratulations to the three of you and many thanks to all candidates that stood for election! We had 256 potential voters and a turnout of 38,7%. Detailed election results can be found at https://www.opavote.com/results/5671446693019648 These results will be available until 8 Feb 2017 at 11:29 CET. Wit all the best wishes for the upcoming year of MEI, Benjamin W. Bohl — MEI Elections Officer 2016 by appointment of the MEI Board -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Fri Feb 3 19:58:31 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 3 Feb 2017 18:58:31 +0000 Subject: [MEI-L] Results 2016 Board elections In-Reply-To: <4514_1485979654_1cZ1Bl-0007QN-L8_ADFA192B-58F6-46AF-81D7-08C6E0161D27@edirom.de> References: <4514_1485979654_1cZ1Bl-0007QN-L8_ADFA192B-58F6-46AF-81D7-08C6E0161D27@edirom.de> Message-ID: Hello everyone, When I first began working on MEI, one of my goals was to bring together people who shared an interest in data modeling and music representation to share ideas and maybe a few beers. Now that it has come to fruition, I remain impressed by the knowledge, passion, and compassion shown by everyone in this community. I firmly believe it's the *community* that binds us and keeps us striving toward a common goal. With that in mind, I want to recognize everyone involved in the recent election. Congratulations to the re-elected Board members, Eleanor and Johannes and to the Board's newest member, Andrew. All three have been involved in the development of MEI almost since its inception. I'm pleased to count all three as colleagues and friends and I look forward to continuing to work together. Of course, Axel is my colleague and friend too, I am proud to say. Thanks, Axel, for MerMEId, for your contributions to the Board, and for often setting me straight on metadata issues. You weren't elected to the Board this time, but I hope that your tenure was fun and that you'll remain involved in MEI. I hope to attend the Music Encoding Conference in Copenhagen in the not-too-distant future. Thanks also to the other candidates who were not elected. The qualifications of each candidate was very impressive. There wasn't a single person on the list who wouldn't have been a fine addition to the Board. Even though you weren't chosen, I believe your *willingness to serve* is commendable in itself. I hope you aren't dispirited in any way and that you'll consider running for the Board again in the future. An election is no small undertaking, so we owe Benni a debt of gratitude for his work preparing for and overseeing the election process. Finally, I want to thank all those who voted. Your participation in the community is sincerely appreciated. Best wishes, -- p. _________________________________________ Perry Roland Metadata Librarian for Research and Scholarship University of Virginia P. O. Box 400874 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rolf.Wissmann at gmx.net Thu Feb 9 17:20:26 2017 From: Rolf.Wissmann at gmx.net (Rolf Wissmann) Date: Thu, 9 Feb 2017 17:20:26 +0100 Subject: [MEI-L] Problem: Encoding omissions Message-ID: An HTML attachment was scrubbed... URL: From aseipelt at mail.uni-paderborn.de Thu Feb 9 17:34:36 2017 From: aseipelt at mail.uni-paderborn.de (Agnes Seipelt) Date: Thu, 09 Feb 2017 17:34:36 +0100 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> Message-ID: <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> Dear Rolf, in my opinion, the equivalent to could be, like you have it in your version, with the elements and . So you can encode the slur in the -Element, because it is the original. And for the omission, what is in your case a regularization, you can encode the notes without the slur in the -element. Of course, you should add a @resp. Maybe someone has another solution? Greets, Agnes   Von: mei-l im Auftrag von Rolf Wissmann Antworten an: Music Encoding Initiative Datum: Donnerstag, 9. Februar 2017 um 17:20 An: Betreff: [MEI-L] Problem: Encoding omissions Dear MEI-L:isteners, can anyone help me how to encode an editorial decision to omit a slur which is present in the source? I have some proposals, but I'm not satisfied with anyone. 1.) This version doesn't fit because it's too strong to say that this slur is a mistake. I only would like to say that it makes no sense in the musical context. 2.) This version doesn't fit because it's my proposal to omit the slur and it's not based on a source. If I understand the Guidelines in a right way, than it's not possible to use the element in this case because it's not a part of the source material. I couldn't find a equivalent to the element . I hope, someone can help me. Best regards, Rolf Wissmann _______________________________________________ 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: From Rolf.Wissmann at gmx.net Sat Feb 11 12:28:57 2017 From: Rolf.Wissmann at gmx.net (Rolf Wissmann) Date: Sat, 11 Feb 2017 12:28:57 +0100 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49>, <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> Message-ID: An HTML attachment was scrubbed... URL: From kepper at edirom.de Sat Feb 11 13:45:31 2017 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 11 Feb 2017 13:45:31 +0100 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> Message-ID: <9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> Dear Rolf, I tend to suggesting a new element, because you're absolutely right that and work on different levels, and there is currently no equivalent to in the sense of an editorial omission. Unless you're willing to not encode the thing in question – in which case you may use as an indicator – there is no way to say something like "yes I know it's there, but let's ignore it for now…". However, I'm not sure if we shouldn't advertise the -solution instead. In your example, you want to get rid of a slur completely, with no replacement. A problem that seems at least equally common is the need to "reposition" the slur on one or both ends. For such cases one would definitely use . Isn't the complete omission just a special case of that very same problem? I wonder if TEI ever discussed this problem. Maybe they didn't, because in my (limited) understanding (verbal) texts usually don't have this "sugar topping" that our slurs, articulations etc. are. But maybe Peter or Raff have more insight? Best, jo > Am 11.02.2017 um 12:28 schrieb Rolf Wissmann : > > Dear Agnes, > > thank you very much for your quick answer. > I like your suggestion but I'm not sure if I should use it. In my opinion your proposal is not an equivalent to the > element. If I apply the model in this case, than I have consistently to replace all the elements, for example slurs, with . I'm curious to hear your opinion! > > Are there any other recommendations or opinions? > > Greets, > Rolf > Gesendet: Donnerstag, 09. Februar 2017 um 17:34 Uhr > Von: "Agnes Seipelt" > An: "Music Encoding Initiative" > Betreff: Re: [MEI-L] Problem: Encoding omissions > Dear Rolf, > > > in my opinion, the equivalent to could be, like you have it in your version, with the elements and . So you can encode the slur in the -Element, because it is the original. And for the omission, what is in your case a regularization, you can encode the notes without the slur in the -element. Of course, you should add a @resp. > > Maybe someone has another solution? > > > Greets, > > Agnes > > Von: mei-l im Auftrag von Rolf Wissmann > Antworten an: Music Encoding Initiative > Datum: Donnerstag, 9. Februar 2017 um 17:20 > An: > Betreff: [MEI-L] Problem: Encoding omissions > > > Dear MEI-L:isteners, > > > can anyone help me how to encode an editorial decision to omit a slur which is present in the source? > > > I have some proposals, but I'm not satisfied with anyone. > > > 1.) This version doesn't fit because it's too strong to say that this slur is a mistake. I only would like to say > > that it makes no sense in the musical context. > > > > > > > > > 2.) This version doesn't fit because it's my proposal to omit the slur and it's not based on a source. > > > > > > > > If I understand the Guidelines in a right way, than it's not possible to use the element in this case because it's > not a part of the source material. > I couldn't find a equivalent to the element . > > I hope, someone can help me. > Best regards, > Rolf Wissmann > > > _______________________________________________ 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: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From raffaeleviglianti at gmail.com Sat Feb 11 15:32:20 2017 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sat, 11 Feb 2017 09:32:20 -0500 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> Message-ID: Hello, is supposed to be the opposite of because it encodes editorial omissions (from the guidelines : "Indicates a point where material has been omitted in a transcription, whether as part of sampling practice or *for editorial reasons* described in the MEI header"). By definition, is empty because the text is omitted (FWIW TEI gap now allows description elements as its content to further describe the omission, but the text is still not to be provided, otherwise it's not an omission!). For the case being considered, I think using with orig/reg is the best way to indicate that there was some original text that was "normalized to nothing", or omitted in the edited text. We could also try and flip the problem on its head: instead of marking the omission of the slur, we could mark that the slur was in the original text, but needs flagging for some reason. can be used outside of to this effect. In TEI this is typically used to mark up unusual spellings without providing a regularization (perhaps because a regularization is not appropriate, e.g. regularizing to which spelling of which time period?). A combination of @type and @evidence could be used to determine, when rendering, whether to show this "original" text in the edition or not. Raff On Feb 11, 2017 07:45, "Johannes Kepper" wrote: > Dear Rolf, > > I tend to suggesting a new element, because you're absolutely > right that and work on different levels, and there is > currently no equivalent to in the sense of an editorial > omission. Unless you're willing to not encode the thing in question – in > which case you may use as an indicator – there is no way to say > something like "yes I know it's there, but let's ignore it for now…". > However, I'm not sure if we shouldn't advertise the -solution > instead. In your example, you want to get rid of a slur completely, with no > replacement. A problem that seems at least equally common is the need to > "reposition" the slur on one or both ends. For such cases one would > definitely use . Isn't the complete omission just a special case of > that very same problem? > > I wonder if TEI ever discussed this problem. Maybe they didn't, because in > my (limited) understanding (verbal) texts usually don't have this "sugar > topping" that our slurs, articulations etc. are. But maybe Peter or Raff > have more insight? > > Best, > jo > > > > > Am 11.02.2017 um 12:28 schrieb Rolf Wissmann : > > > > Dear Agnes, > > > > thank you very much for your quick answer. > > I like your suggestion but I'm not sure if I should use it. In my > opinion your proposal is not an equivalent to the > > element. If I apply the model in this case, than I > have consistently to replace all the elements, for example > slurs, with . I'm curious to hear your opinion! > > > > Are there any other recommendations or opinions? > > > > Greets, > > Rolf > > Gesendet: Donnerstag, 09. Februar 2017 um 17:34 Uhr > > Von: "Agnes Seipelt" > > An: "Music Encoding Initiative" > > Betreff: Re: [MEI-L] Problem: Encoding omissions > > Dear Rolf, > > > > > > in my opinion, the equivalent to could be, like you have it > in your version, with the elements and . So you can > encode the slur in the -Element, because it is the original. And for > the omission, what is in your case a regularization, you can encode the > notes without the slur in the -element. Of course, you should add a > @resp. > > > > Maybe someone has another solution? > > > > > > Greets, > > > > Agnes > > > > Von: mei-l im Auftrag von Rolf > Wissmann > > Antworten an: Music Encoding Initiative > > Datum: Donnerstag, 9. Februar 2017 um 17:20 > > An: > > Betreff: [MEI-L] Problem: Encoding omissions > > > > > > Dear MEI-L:isteners, > > > > > > can anyone help me how to encode an editorial decision to omit a slur > which is present in the source? > > > > > > I have some proposals, but I'm not satisfied with anyone. > > > > > > 1.) This version doesn't fit because it's too strong to say that this > slur is a mistake. I only would like to say > > > > that it makes no sense in the musical context. > > > > > > > > > > > > > > > > > > 2.) This version doesn't fit because it's my proposal to omit the slur > and it's not based on a source. > > > > > > > > > > > > > > > > If I understand the Guidelines in a right way, than it's not possible to > use the element in this case because it's > > not a part of the source material. > > I couldn't find a equivalent to the element . > > > > I hope, someone can help me. > > Best regards, > > Rolf Wissmann > > > > > > _______________________________________________ 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: From gdibacco at indiana.edu Sun Feb 12 09:22:50 2017 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Sun, 12 Feb 2017 09:22:50 +0100 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> Message-ID: <80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> An HTML attachment was scrubbed... URL: From Rolf.Wissmann at gmx.net Mon Feb 13 21:43:46 2017 From: Rolf.Wissmann at gmx.net (Rolf Wissmann) Date: Mon, 13 Feb 2017 21:43:46 +0100 Subject: [MEI-L] Problem: Encoding omissions In-Reply-To: <20286_1486889787_1ccpxK-0004xk-Rd_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com>, <20286_1486889787_1ccpxK-0004xk-Rd_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> Message-ID: An HTML attachment was scrubbed... URL: From esfield at stanford.edu Tue Feb 14 00:44:52 2017 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 13 Feb 2017 23:44:52 +0000 Subject: [MEI-L] Problem: Encoding omissions: slur positions Message-ID: Just a general comment on Johannes's slur example: We've encoded a great deal of Handel in MuseData (long before MEI came along) and in the manuscripts there are often slurs of ambiguous length. In the scholarly world, a lot of ink has been devoted to the subject of how to interpret Handel's slurs (as well as his dotted rhythmic figures and divisi parts that begin abruptly in the absence of a preceding composite part, e.g. violin and oboe). Handel is almost a special case for encoding, because most of these problems are rarely found in the manuscripts of his peers. If you belong to the "no interpretation in encoding" school, then you do want some indication of the fuzziness of the source. This leads to the question of whether it is advisable to indicate in a header whether the following data should be understood as "uninterpreted" (virtual facsimile of the source). This can be good for efficiency but not conducive to avoiding dependencies. In this discussion, lots of workable solutions have been proposed. The question is: Which ones will work across many different circumstances? Which ones are "local" to one repertory? And how do we prioritize efficiency in relation to exactness? CMME (http://cmme.org/) deals with some of these kinds of questions--with more focus on mutable graphics--for mensural music (no slurs of course) and, like MEI, remains a work-in-progress. Eleanor -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Johannes Kepper Sent: Saturday, February 11, 2017 4:46 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Problem: Encoding omissions Dear Rolf, I tend to suggesting a new element, because you're absolutely right that and work on different levels, and there is currently no equivalent to in the sense of an editorial omission. Unless you're willing to not encode the thing in question – in which case you may use as an indicator – there is no way to say something like "yes I know it's there, but let's ignore it for now…". However, I'm not sure if we shouldn't advertise the -solution instead. In your example, you want to get rid of a slur completely, with no replacement. A problem that seems at least equally common is the need to "reposition" the slur on one or both ends. For such cases one would definitely use . Isn't the complete omission just a special case of that very same problem? I wonder if TEI ever discussed this problem. Maybe they didn't, because in my (limited) understanding (verbal) texts usually don't have this "sugar topping" that our slurs, articulations etc. are. But maybe Peter or Raff have more insight? Best, jo > Am 11.02.2017 um 12:28 schrieb Rolf Wissmann : > > Dear Agnes, > > thank you very much for your quick answer. > I like your suggestion but I'm not sure if I should use it. In my > opinion your proposal is not an equivalent to the element. If I apply the model in this case, than I have consistently to replace all the elements, for example slurs, with . I'm curious to hear your opinion! > > Are there any other recommendations or opinions? > > Greets, > Rolf > Gesendet: Donnerstag, 09. Februar 2017 um 17:34 Uhr > Von: "Agnes Seipelt" > An: "Music Encoding Initiative" > Betreff: Re: [MEI-L] Problem: Encoding omissions Dear Rolf, > > > in my opinion, the equivalent to could be, like you have it in your version, with the elements and . So you can encode the slur in the -Element, because it is the original. And for the omission, what is in your case a regularization, you can encode the notes without the slur in the -element. Of course, you should add a @resp. > > Maybe someone has another solution? > > > Greets, > > Agnes > > Von: mei-l im Auftrag von Rolf > Wissmann Antworten an: Music Encoding > Initiative > Datum: Donnerstag, 9. Februar 2017 um 17:20 > An: > Betreff: [MEI-L] Problem: Encoding omissions > > > Dear MEI-L:isteners, > > > can anyone help me how to encode an editorial decision to omit a slur which is present in the source? > > > I have some proposals, but I'm not satisfied with anyone. > > > 1.) This version doesn't fit because it's too strong to say that this > slur is a mistake. I only would like to say > > that it makes no sense in the musical context. > > > > > > > > 2.) This version doesn't fit because it's my proposal to omit the slur and it's not based on a source. > > > > > > > > If I understand the Guidelines in a right way, than it's not possible > to use the element in this case because it's not a part of the source material. > I couldn't find a equivalent to the element . > > I hope, someone can help me. > Best regards, > Rolf Wissmann > > > _______________________________________________ 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 From DanielAlles at stud.uni-frankfurt.de Thu Feb 16 13:52:58 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 16 Feb 2017 13:52:58 +0100 Subject: [MEI-L] Further information In-Reply-To: <19291_1486887987_1ccpUI-0003iN-SY_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> <19291_1486887987_1ccpUI-0003iN-SY_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> Message-ID: <20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> Dear Giuliano, as you know, I'm writing my M.A. thesis on digital editions of mensural notation, for which I'm transcribing and encoding a source of the 16th century. But that is just one part of my thesis, the other part will be a short review on the possibilities and limits of digital editions, problems while encoding (and decoding) etc. For this second part, I would like to ask some questions about the work on digital editions: What are the possible uses of machine readable music-code? Of course I know, that MEI is still work in progress and that many tools are about to be developed, but are there any tools yet that are able to analyze a piece of music or to do something else with it (beyond displaying it more or less correctly)? As you are Director of the CHMTL and therefore related to the Thesaurus Musicarum Latinarum, I hope you can help me finding some answers on the limits that music encoding has today. Maybe you encountered unsovable problems during setting up the TML, or problems that are solved now? It would really help me with my thesis, if I could find all those answers. With best regards, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From DanielAlles at stud.uni-frankfurt.de Thu Feb 16 13:54:20 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 16 Feb 2017 13:54:20 +0100 Subject: [MEI-L] Further information In-Reply-To: <32334_1487249588_1ceLYZ-0002GN-OX_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> <19291_1486887987_1ccpUI-0003iN-SY_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> <32334_1487249588_1ceLYZ-0002GN-OX_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> Message-ID: <20170216135420.Horde.eUtCWbw81F3E2C3C5Sl3rR4@webmail.server.uni-frankfurt.de> Sorry for that last mail, it was meant to be sent directly to Giuliano... Daniel From gdibacco at indiana.edu Fri Feb 17 13:35:45 2017 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Fri, 17 Feb 2017 13:35:45 +0100 Subject: [MEI-L] Further information In-Reply-To: <28678_1487249585_1ceLYX-0002GN-N7_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> <19291_1486887987_1ccpUI-0003iN-SY_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> <28678_1487249585_1ceLYX-0002GN-N7_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> Message-ID: <9d5d6071-62b3-e44a-24c0-cc9c5eefcce9@indiana.edu> An HTML attachment was scrubbed... URL: From j.ingram at netcologne.de Sun Feb 19 12:09:33 2017 From: j.ingram at netcologne.de (James Ingram) Date: Sun, 19 Feb 2017 12:09:33 +0100 Subject: [MEI-L] Further information In-Reply-To: <32334_1487249588_1ceLYZ-0002GN-OX_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> References: <9336_1486657233_1cbrSR-0005tr-69_trinity-8eabb793-6eef-4e2b-933b-8eb8a022dc4b-1486657226322@3capp-gmx-bs49> <5D0BD1B4-D1C9-4209-9F26-F3B2EED04DA3@mail.uni-paderborn.de> <18350_1486812669_1ccVtV-0006DH-6n_trinity-23eeb3fc-6fb0-42b1-962c-70de3173b8e2-1486812537344@3capp-gmx-bs43> <28540_1486817141_1ccX3c-0003kt-8l_9F888644-B801-48DB-9F1E-BCE1C15D4A7E@edirom.de> <28540_1486823567_1ccYjG-0007bQ-IA_CAMyHAnOOD2gxVeN7Eb4m5OCTterejrH8G_0o17v9VLa9s6ASFA@mail.gmail.com> <19291_1486887987_1ccpUI-0003iN-SY_80baae2d-362a-d372-dcd9-bf2f4666eb44@indiana.edu> <32334_1487249588_1ceLYZ-0002GN-OX_20170216135258.Horde.DNM-AyUgppqZlxmUDLg0vGP@webmail.server.uni-frankfurt.de> Message-ID: Dear Daniel, Apropos > the possibilities and limits of digital editions and > What are the possible uses of machine readable music-code? [...] are > there any tools yet that are able to analyze a piece of music or to do > something else with it (beyond displaying it more or less correctly)? Digital editions can store both spatial and temporal information, so they can, in principle, be used to store performances that are synchronized with the notation. My experimental Assistant Performer software [1] does this already. The long term goal is to be able to study (and develop) performance practice traditions for both old and new notations, but there's some way to go before we can start talking seriously about that. :-) All the best, James Ingram [1] http://james-ingram-act-two.de/open-source/assistantPerformer/assistantPerformer.html -- http://james-ingram-act-two.de https://github.com/notator From andrew.hankinson at mail.mcgill.ca Sun Feb 19 16:36:20 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sun, 19 Feb 2017 15:36:20 +0000 Subject: [MEI-L] New releases: Sibmei 2.1.0; new MEI test set Message-ID: <6321E0E5-27A4-4C24-A275-7928FDC45A3F@mail.mcgill.ca> Hello MEI Community, Two new releases to bring to your attention: 1. A new update to the Sibelius to MEI plugin is now available, version 2.1.0. I want to thank Thomas Weber for his extensive contributions in this release -- he expanded support for complex things like nested tuplets and secondary beams, and fixed some very tricky bugs! You can download the plugin and read the release notes here: https://github.com/music-encoding/sibmei/releases/tag/v2.1.0 2. Over the last few years we've been assembling an MEI Test Set, with contributions from our team at McGill, Zoltán Kőmíves, and the official MEI 'sample encodings'. It's not been a secret, per se, but I don't think it was ever officially announced on this mailing list. I've just spent a bit of time polishing it up, and you can view it here: http://ddmal.github.io/mei-test-set/ And the source for it is available here: https://github.com/DDMAL/mei-test-set The "MEI-test-set" section contains the bulk of the individual test cases. So how is this different from the sample encodings? This test set is explicitly designed to test basic functionality and edge cases in software applications. Many of the MEI files contain just enough encoding to demonstrate a particular feature or encoding that should be supported. As a result, it's not very pretty. In fact, the MEI-test-set folder is the closet where the Sibelius-to-MEI plugin (and Verovio) hides all its skeletons! Looking at the test cases you can see a good portion of what is, and what isn't, supported yet. You should also be aware that if you see something rendered on the page, it may be that Verovio is rendering it properly and that it just wasn't exported correctly in the sibmei plugin (most likely!) or vice versa. We haven't covered everything, so if you have test cases you would like to see included in this, please let me know. The only restriction is that we would like to keep licensing non-restrictive, so including an encoding in the test set means you will have to also agree to release it under a Creative-Commons Attribution (CC-BY) license. As always, please get in touch with questions or comments. Cheers, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ul at openlilylib.org Mon Feb 27 23:57:37 2017 From: ul at openlilylib.org (Urs Liska) Date: Mon, 27 Feb 2017 23:57:37 +0100 Subject: [MEI-L] [OT] LilyPond @ GSoC 2017 Message-ID: Dear MEI community, this is somewhat off-topic, but I'd say not *completely*, and I can imagine there are some people on this list that are interested in it and can especially forward it to circles that would otherwise not be reached. I'm happy to announce that both LilyPond (as part of GNU) and the LilyPond IDE Frescobaldi (http://frescobaldi.org) have been accepted as mentoring organizations for Google Summer of Code 2017 :-) This means we have the chance to get up to four (realistically) students to work on improving LilyPond and Frescobaldi full-time over the summer for three months. The project ideas for LilyPond can be found at http://lilypond.org/google-summer-of-code.html, those for Frescobaldi at https://github.com/wbsoft/frescobaldi/wiki/Google-Summer-of-Code. If you are a full-time enrolled student and think you could apply for such a project please go ahead. Full information about the program, including the program rules can be found at https://summerofcode.withgoogle.com/ If you don't think you want to apply for whatever reason please think about where you can spread this information so it gets to the inbox of potential students. Best regards Urs -- ul at openlilylib.org https://openlilylib.org http://lilypondblog.org From Richard.Chesser at bl.uk Wed Mar 1 11:49:08 2017 From: Richard.Chesser at bl.uk (Chesser, Richard) Date: Wed, 1 Mar 2017 10:49:08 +0000 Subject: [MEI-L] MEI conference, Tours, 16-19 May: booking open very soon Message-ID: Dear colleagues Just to let you know that the conference details will be published very soon. I know that everyone has been holding the dates in anticipation and we are looking forward very much to publishing the programme. I will send a message to the list when this is done and booking opens. Best wishes Richard Chesser Chair, Conference Programme Committee ****************************************************************************************************************** Experience the British Library online at www.bl.uk The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled ***************************************************************************************************************** The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. ***************************************************************************************************************** Think before you print -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Wed Mar 1 19:13:49 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 1 Mar 2017 18:13:49 +0000 Subject: [MEI-L] Call for Music Encoding Conference proposals for 2018 and 2019 Message-ID: PLEASE CIRCULATE WIDELY Greetings, The MEI Board invites proposals for the organization of the 6th and 7th editions of the annual Music Encoding Conference, to be held in 2018 and 2019. In the past, annual hosting calls have been issued; however, the Board recently decided to request hosting bids for the next two years. We hope this will make the organizing process smoother. As many of you are aware, among its activities MEI oversees the organization of an annual conference, the Music Encoding Conference (MEC), to provide a meeting place for scholars interested in discussing the modeling, generation and uses of music encoding. While the conference has an emphasis on the development and uses of MEI, other contributions related to general approaches to music encoding are always welcome, as an opportunity for exchanges between scholars from various research communities, including technologists, librarians, historians, and theorists. The official conference hosting document, available at , provides information and guidelines to prospective organizers. In addition to addressing the proposal requirements indicated there, applicants should clearly indicate which years they are willing to host, with the caveat that no institution may host the conference two consecutive years. Historically, the conference has been organized by institutions involved in MEI, such as MEI member institutions or those hosting MEI-based projects, but proposals from any interested group or institution will be happily received, and ideas other than those expressed in the official document are welcome. The deadline for sending proposals is 15 April 2017. The Board will notify bidders of its decision by 1 May 2017. Successful bidders should be prepared to make a short presentation at the conference in Tours. Please direct all proposals and inquiries to >. On behalf of the MEI Board, best wishes, -- p. _________________________________________ Perry Roland University of Virginia P. O. Box 400874 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Chesser at bl.uk Fri Mar 3 19:15:17 2017 From: Richard.Chesser at bl.uk (Chesser, Richard) Date: Fri, 3 Mar 2017 18:15:17 +0000 Subject: [MEI-L] MEI conference, Tours, 16-19 May: programme now published Message-ID: Dear colleagues I’m delighted to say that the conference programme is now available at http://music-encoding.org/community/conference/tours17/program/. I hope you agree that it is very exciting. In addition details of hotel accommodation is provided at http://music-encoding.org/community/conference/tours17/accomodations/. Conference registration itself will open very shortly, and I will send another message to the list when this is ready. But meanwhile I hope these details whet your appetite and permit you to start making travel plans! Best wishes Richard Chesser Chair, Conference Committee ****************************************************************************************************************** Experience the British Library online at www.bl.uk The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled ***************************************************************************************************************** The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. ***************************************************************************************************************** Think before you print -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiago at debian.org Fri Mar 3 20:05:00 2017 From: tiago at debian.org (Tiago Bortoletto Vaz) Date: Fri, 3 Mar 2017 14:05:00 -0500 Subject: [MEI-L] MEI conference, Tours, 16-19 May: programme now published In-Reply-To: References: Message-ID: <20170303190500.GA25254@riseup.net> Hi There, On Fri, Mar 03, 2017 at 06:15:17PM +0000, Chesser, Richard wrote: > Dear colleagues > > I’m delighted to say that the conference programme is now available at http://music-encoding.org/community/conference/tours17/program/. I hope you agree that it is very exciting. In addition details of hotel accommodation is provided at http://music-encoding.org/community/conference/tours17/accomodations/. Conference registration itself will open very shortly, and I will send another message to the list when this is ready. The program seems really nice, thansk for sharing. Are you going to provide any video/audio recording of them? Thanks, -- tiago From donbyrd at indiana.edu Sat Mar 4 01:36:36 2017 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sat, 4 Mar 2017 00:36:36 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation Message-ID: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at https://github.com/rism-ch/verovio/issues/389 and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. Giuliano has raised a related concern. He wrote yesterday that "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. I'm looking forward to hearing people's thoughts on all of this! --Don --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From gdibacco at indiana.edu Sat Mar 4 12:27:40 2017 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Sat, 4 Mar 2017 12:27:40 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> Message-ID: <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Sat Mar 4 16:27:02 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sat, 4 Mar 2017 15:27:02 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> Message-ID: Hi everyone, Let's not dive too deeply into where/how things are displayed before making sure the semantics of and are clear. is, indeed, intended to capture performance directions that aren't already dealt with by more specific elements. Phrases like "con sordino", "sul ponticello", and "Rock out!" are good examples. They affect performance but don't fit the definition of articulations or tempo indications. They're also not words (sung or spoken) intended to be performed. Although for obvious reasons it can't have the same name, is analogous to TEI's element, which is defined (in a circular way) as "a note or annotation". Delving a little more deeply into the TEI Guidelines one finds "A note is any additional comment found in a text, marked in some way as being out of the main textual stream. All notes should be marked using the same tag, note, whether they appear as block notes in the main text area, at the foot of the page, at the end of the chapter or volume, in the margin, or in some other place. Notes may be in a different hand or typeface, may be authorial or editorial, and may have been added later. Attributes may be used to specify these and other characteristics of notes, as detailed below. A note is usually attached to a specific point or span within a text, which we term here its point of attachment. In conventional printed text, the point of attachment is represented by some siglum such as a star or cross, or a superscript digit." This narrows the definition somewhat, but it's still fairly broad. Functionally, a note/annot can contain anything the "text" (in the generic sense) may, the only difference being that the note is somehow "out of the main textual stream". In other words, it's a text inside the main text. Sometimes this is referred to as "floating text". Because an annotation can be either *authorial* or *editorial*, I do not agree that indications shouldn't appear in the score. In fact, if they don't appear in the score, they're not annotations according to the definition above. However, I can see the need to mark some notes as visible/invisible or to define the intended audience, for example "public" and "private". With regard to *where* to display it, can be linked to starting and ending times via @tstamp and @tstamp2 (most useful in the CMN repertoire) or @startid and @endid (in any repertoire). So, even though it permits a broader range of content than -- plain text, text components (like fig, list, and p), phrase-level elements, and editorial and transcriptional elements -- it can behave exactly the same as with regard to its position relative to musical events. Given that the content of *does not* include any of the non-textual entities that are allowed in or , such as , , , , etc., it can't be used to encode any of these things added by a later scribe (composer, editor, etc.) *without egregious tag abuse*. Therefore, Bernstein's "annotations" of a Mahler score don't fit the MEI definition of . These must be addressed in the musical text; that is, at the measure level (in CMN), staff level (in Mensural notation), or syllable level (in Neume notation). Since Bernstein's additions were made on an already-printed edition, they should be marked with the element. It is these additions, not per se, whose positioning must be given more thought. With the addition of @place (newly available on in MEI development) one can now indicate where the added material is to be placed, for example, in the margins or directly in the musical text. When necessary, @place can also record whether the addition is superimposed over other material. Given an addition with @place containing "superimposed", rendering software must position it according to information provided by the individual slur, dynam, etc., but *without regard* for other material. Making @place available on will provide the same behavior for it. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, > Donald A. > Sent: Friday, March 03, 2017 7:37 PM > To: Music Encoding Initiative > Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation > > For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus > other members of the mensural IG -- have been discussing the need for > annotations with arbitrary text that are displayed on the music. Unfortunately, > the discussion so far has been scattered among several places, including the > mensural IG mailing list and Verovio GitHub issues #248 ("Directives in > mensural notation aren't drawn"), 388 ("@n for "), and especially 389 > ("implement display"). You can read #389 at > > https://github.com/rism-ch/verovio/issues/389 > > and similarly for the other Verovio issues. Anyway, I'll try to summarize the > issues here. > > We've talked about using one of two existing tags for these annotations, > namely and . It seems clear that is not what we want > because it's specifically intended for performance directions. As for s, > of course they are currently only for annotating the encoding, not the music, > and they're not displayed in the SVG. We could add a @visible attribute to > , but the problem then is _where_ on the music should they appear? > But it seems to me this is only a serious problem if you expect the notation > engine to position everything automatically, and that's something that I think > is completely unrealistic for complex music regardless of annotation. I suggest > visible s should have a crudely-calculated default position, and it'd be > up to the user to specify a different position if they want. > > Giuliano has raised a related concern. He wrote yesterday that > > "[N]ot only something like for arbitrary non-lyric text is needed, but also > some arbitrary segmentation, to encapsulate portions of music and/or > lyric/non-lyric text where things happen (such as, lyric text loosely connected > with a portion of music, or passages where the mensuration is uncertain...). > > "If I understand correctly, most of the problem with originates from the > missing level in the hierarchy (at least this creates problems with > Verovio), so I was wondering whether the introduction of a tag at > that level could be useful. The latter, contrary to would be totally > optional, and contrary to or
would be used without any > structural meaning. > > "This is the point where we felt the need that the discussion escalates on MEI- > L. Non-structural segmentation is something that TEI introduced lately in their > schema (they call it when the portion of text is shorter than a paragraph, > and when an 'anonymous block' of text is found that escapes from the > paragraph structure). In my experience this is one of the most useful features > when dealing with complex documents, and in past projects I used it also to > provide annotations. I wonder whether there are any reasons for not having a > -like tag available at any level." > > Giuliano's ideas make sense to me, but I don't feel very well qualified to > evaluate them. > > I'm looking forward to hearing people's thoughts on all of this! > > --Don > > > --- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics Visiting Scientist, Research > Technologies Indiana University Bloomington > > > > > > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Sat Mar 4 17:04:54 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sat, 4 Mar 2017 16:04:54 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> Message-ID: Hi, Text underlay doesn't have anything to do with or . I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. Ooh Ah For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. For those situations where the sung text is visually separate from the musical material, one can use -- Oh, say can you see To associate each syllable of these words with the notes, one can add elements -- Oh, say can >you see One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Saturday, March 04, 2017 6:28 AM To: Byrd, Donald A.; Music Encoding Initiative Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Thanks, Don: I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. Best, Giuliano Byrd, Donald A. wrote on 04/03/2017 01:36: For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at https://github.com/rism-ch/verovio/issues/389 and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. Giuliano has raised a related concern. He wrote yesterday that "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. I'm looking forward to hearing people's thoughts on all of this! --Don --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Sat Mar 4 19:29:32 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sat, 4 Mar 2017 18:29:32 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> Message-ID: Could someone boil down the decisions that need to be made, even just in point form, for those of us who haven't been part of the discussion? I'm afraid I don't quite understand what we're supposed to be commenting on. -Andrew > On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) wrote: > > > Hi, > > Text underlay doesn't have anything to do with or . > > I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." > > The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. > > > > Ooh > > > Ah > > > > For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. > > For those situations where the sung text is visually separate from the musical material, one can use -- > > > > Oh, say can you see > > > > To associate each syllable of these words with the notes, one can add elements -- > > > > > Oh, > say > can > >you > see > > > > One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. > > -- > p. > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco > Sent: Saturday, March 04, 2017 6:28 AM > To: Byrd, Donald A.; Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation > > Thanks, Don: > > I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: > > 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . > > 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. > > As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. > > Best, > > Giuliano > > > > Byrd, Donald A. wrote on 04/03/2017 01:36: > For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at > > https://github.com/rism-ch/verovio/issues/389 > > and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. > > We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. > > Giuliano has raised a related concern. He wrote yesterday that > > "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). > > "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. > > "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." > > Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. > > I'm looking forward to hearing people's thoughts on all of this! > > --Don > > > --- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > > > > > > > _______________________________________________ > 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: From DanielAlles at stud.uni-frankfurt.de Mon Mar 6 08:57:55 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Mon, 06 Mar 2017 08:57:55 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> Message-ID: <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> Dear all, I think one of the problems (at least one of my problems while encoding MN) is the spacing of the lyrics. It is not always clear, which syllable belongs where, so a connection of syllables to notes is not always given. The possibility to encode the lyrics separately and then attach them to a staff seems unlikely too, as the syllables would be spaced according to the rhythm off the staff (the lyrics would only appear at the beginning of the staff, as there normally are more notes then syllables). A possibility to connect not only syllables but also whole phrases of text to phrases of notes would be really nice; something like "this text starts on that note and ends on that note". As it is not clear in all the cases how the underlayed text is to be sung and therefore a spacing of the lyrics would be an editorial intervention, a solution like @startid and @endid (or something else) would at least represent the source material the best. Best, Daniel Zitat von Andrew Hankinson : > Could someone boil down the decisions that need to be made, even > just in point form, for those of us who haven't been part of the > discussion? > > I'm afraid I don't quite understand what we're supposed to be commenting on. > > -Andrew > >> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) >> wrote: >> >> >> Hi, >> >> Text underlay doesn't have anything to do with or . >> >> I apologize for the confusion created by the definition of >> -- it was too short and too cryptic. In the version of MEI >> currently under development, verse is defined as "Division of a >> poem or song lyrics; a stanza." >> >> The verse/syl construct is only applicable at the note level. For >> musical material which is repeated, but with different >> words/lyrics/sung text, provides a method of recording >> which words belong with each repetition. >> >> >> >> Ooh >> >> >> Ah >> >> >> >> For text not directly associated with individual notes, lyrics/lg >> should be used instead. occurs outside the stream of >> notated events; that is, inside and , although >> not within or as might be required for mensural >> notation. I'll correct this oversight soon. The element is, >> of course, borrowed from TEI. >> >> For those situations where the sung text is visually separate from >> the musical material, one can use -- >> >> >> >> Oh, say can you see >> >> >> >> To associate each syllable of these words with the notes, one can >> add elements -- >> >> >> >> >> Oh, >> say >> can >> >you >> see >> >> >> >> One may object to calling the text of a 15th century motet >> "lyrics", but the same markup applies. >> >> -- >> p. >> >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >> Of Giuliano Di Bacco >> Sent: Saturday, March 04, 2017 6:28 AM >> To: Byrd, Donald A.; Music Encoding Initiative >> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >> segmentation >> >> Thanks, Don: >> >> I swear that I am not trying to complicate the issue further, but I >> should recall that it was another moving part of the mechanism that >> originated this discussions on MEI-Mens, that is, . That is, >> also arbitrary segmentation/alignment of... non-arbitrary text (!) >> deserves attention: >> >> 1 - about its use, as regard to the issue described by Don: how >> best to record arbitrary (I prefer: "non standard") placement of >> text underlay (alignment of chunks of text in with >> s), when not possible/easy to do it with . >> >> 2- about its definition. This may be slightly off-topic, but >> important: discussion on MEI-Mens reveals that there may be some >> confusion about what is supposed to be used for. The >> specifications say that this is for "lyric verse". Period. First, I >> am not sure whether "verse" has to be intended as "a body of >> metrical writing/poetry" or a "stanza/strophe of poetry" or a >> "single line of a metrical writing" -- definitions in major >> Brit+American dictionaries (and people's opinions) fluctuate >> between these poles. Second, I am not sure whether "lyric" stands >> for the genre (lyric poetry as opposed to narrative, epic, didactic >> poetry) or generically for "the words of a song". Admittedly, in >> romance languages both terms are less ambiguous than in English, so >> I suppose that we just need to clarify, through a more generous >> description, if is "whatever poetic text underlay" (my best >> guess) or what. It would be very useful to clarify this point while >> we talk about "text". The next step would be to decide if we >> need/want to represent poetical structures of lower (or higher) >> order (it would seem logical to me if we borrowed stuff from TEI), >> and how to distinguish text underlay proper from >> text-that-goes-with-these-notes but not-laid-under-the-notes, that >> is, written/printed somewhere else in the page (introducing some >> tag/att like "underlay" and "displaced" perhaps). But this is >> really off-topic (premature) for now. >> >> As usual, please don't hesitate to correct me if I >> misunderstood/misrepresented anything -- it would be helpful. >> >> Best, >> >> Giuliano >> >> >> >> Byrd, Donald A. wrote on 04/03/2017 01:36: >> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, >> Perry and I, plus other members of the mensural IG -- have been >> discussing the need for annotations with arbitrary text that are >> displayed on the music. Unfortunately, the discussion so far has >> been scattered among several places, including the mensural IG >> mailing list and Verovio GitHub issues #248 ("Directives in >> mensural notation aren't drawn"), 388 ("@n for "), and >> especially 389 ("implement display"). You can read #389 at >> >> https://github.com/rism-ch/verovio/issues/389 >> >> >> and similarly for the other Verovio issues. Anyway, I'll try to >> summarize the issues here. >> >> We've talked about using one of two existing tags for these >> annotations, namely and . It seems clear that is >> not what we want because it's specifically intended for performance >> directions. As for s, of course they are currently only for >> annotating the encoding, not the music, and they're not displayed >> in the SVG. We could add a @visible attribute to , but the >> problem then is _where_ on the music should they appear? But it >> seems to me this is only a serious problem if you expect the >> notation engine to position everything automatically, and that's >> something that I think is completely unrealistic for complex music >> regardless of annotation. I suggest visible s should have a >> crudely-calculated default position, and it'd be up to the user to >> specify a different position if they want. >> >> Giuliano has raised a related concern. He wrote yesterday that >> >> "[N]ot only something like for arbitrary non-lyric text is >> needed, but also some arbitrary segmentation, to encapsulate >> portions of music and/or lyric/non-lyric text where things happen >> (such as, lyric text loosely connected with a portion of music, or >> passages where the mensuration is uncertain...). >> >> "If I understand correctly, most of the problem with >> originates from the missing level in the hierarchy (at >> least this creates problems with Verovio), so I was wondering >> whether the introduction of a tag at that level could be >> useful. The latter, contrary to would be totally >> optional, and contrary to or
would be used >> without any structural meaning. >> >> "This is the point where we felt the need that the discussion >> escalates on MEI-L. Non-structural segmentation is something that >> TEI introduced lately in their schema (they call it when the >> portion of text is shorter than a paragraph, and when an >> 'anonymous block' of text is found that escapes from the paragraph >> structure). In my experience this is one of the most useful >> features when dealing with complex documents, and in past projects >> I used it also to provide annotations. I wonder whether there are >> any reasons for not having a -like tag available at any level." >> >> Giuliano's ideas make sense to me, but I don't feel very well >> qualified to evaluate them. >> >> I'm looking forward to hearing people's thoughts on all of this! >> >> --Don >> >> >> --- >> Donald Byrd >> Woodrow Wilson Indiana Teaching Fellow >> Adjunct Associate Professor of Informatics >> Visiting Scientist, Research Technologies >> Indiana University Bloomington >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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: lyrics_confusion.PNG Type: image/png Size: 480936 bytes Desc: not available URL: From gdibacco at indiana.edu Mon Mar 6 12:16:36 2017 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Mon, 6 Mar 2017 12:16:36 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> Message-ID: <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Mon Mar 6 12:49:32 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 6 Mar 2017 11:49:32 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> Message-ID: <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> If you’re talking about *visually* spacing the lyrics given an unknown association with the notes, then this is not an MEI problem, as far as I can see. This would need to be down to a particularly clever renderer, or some other means of computationally deriving syllable-note relationships. It really comes down to whether or not you are asserting or estimating. If you are asserting a relationship, you would put it in MEI. If you are estimating a relationship, based on informed guesses, it’s probably best to leave that to an interpretive layer that sits above the encoding, and only assert the things that you know. Just a quick glance through the elements lyrics, lg, and l, it seems that the `@corresp` attribute might be the best solution. This is already available on lyrics, but not on lg or l. I could imagine something like: … -Andrew > On 6 Mar 2017, at 07:57, Daniel Alles wrote: > > Dear all, > > I think one of the problems (at least one of my problems while encoding MN) is the spacing of the lyrics. It is not always clear, which syllable belongs where, so a connection of syllables to notes is not always given. The possibility to encode the lyrics separately and then attach them to a staff seems unlikely too, as the syllables would be spaced according to the rhythm off the staff (the lyrics would only appear at the beginning of the staff, as there normally are more notes then syllables). > > A possibility to connect not only syllables but also whole phrases of text to phrases of notes would be really nice; something like "this text starts on that note and ends on that note". As it is not clear in all the cases how the underlayed text is to be sung and therefore a spacing of the lyrics would be an editorial intervention, a solution like @startid and @endid (or something else) would at least represent the source material the best. > > Best, > Daniel > > > > > Zitat von Andrew Hankinson : > >> Could someone boil down the decisions that need to be made, even just in point form, for those of us who haven't been part of the discussion? >> >> I'm afraid I don't quite understand what we're supposed to be commenting on. >> >> -Andrew >> >>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) wrote: >>> >>> >>> Hi, >>> >>> Text underlay doesn't have anything to do with or . >>> >>> I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." >>> >>> The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. >>> >>> >>> >>> Ooh >>> >>> >>> Ah >>> >>> >>> >>> For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. >>> >>> For those situations where the sung text is visually separate from the musical material, one can use -- >>> >>> >>> >>> Oh, say can you see >>> >>> >>> >>> To associate each syllable of these words with the notes, one can add elements -- >>> >>> >>> >>> >>> Oh, >>> say >>> can >>> >you >>> see >>> >>> >>> >>> One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. >>> >>> -- >>> p. >>> >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco >>> Sent: Saturday, March 04, 2017 6:28 AM >>> To: Byrd, Donald A.; Music Encoding Initiative >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation >>> >>> Thanks, Don: >>> >>> I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: >>> >>> 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . >>> >>> 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. >>> >>> As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. >>> >>> Best, >>> >>> Giuliano >>> >>> >>> >>> Byrd, Donald A. wrote on 04/03/2017 01:36: >>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at >>> >>> https://github.com/rism-ch/verovio/issues/389 >>> >>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. >>> >>> We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. >>> >>> Giuliano has raised a related concern. He wrote yesterday that >>> >>> "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). >>> >>> "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. >>> >>> "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." >>> >>> Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. >>> >>> I'm looking forward to hearing people's thoughts on all of this! >>> >>> --Don >>> >>> >>> --- >>> Donald Byrd >>> Woodrow Wilson Indiana Teaching Fellow >>> Adjunct Associate Professor of Informatics >>> Visiting Scientist, Research Technologies >>> Indiana University Bloomington >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 From pdr4h at eservices.virginia.edu Mon Mar 6 15:59:13 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 14:59:13 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> Message-ID: If temporal alignment is the objective, then @corresp is not specific enough. Better to use @synch. The fact that these attributes are missing from and is remediable. :-) @startid/@endid can also be added to , as Daniel suggested, or to another still more specific element, to indicate starting and ending points for a text string. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Andrew Hankinson > Sent: Monday, March 06, 2017 6:51 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > If you’re talking about *visually* spacing the lyrics given an unknown > association with the notes, then this is not an MEI problem, as far as I can see. > This would need to be down to a particularly clever renderer, or some other > means of computationally deriving syllable-note relationships. > > It really comes down to whether or not you are asserting or estimating. If you > are asserting a relationship, you would put it in MEI. If you are estimating a > relationship, based on informed guesses, it’s probably best to leave that to an > interpretive layer that sits above the encoding, and only assert the things that > you know. > > Just a quick glance through the elements lyrics, lg, and l, it seems that the > `@corresp` attribute might be the best solution. This is already available on > lyrics, but not on lg or l. > > I could imagine something like: > > > > … > > > > -Andrew > > > On 6 Mar 2017, at 07:57, Daniel Alles > wrote: > > > > Dear all, > > > > I think one of the problems (at least one of my problems while encoding MN) > is the spacing of the lyrics. It is not always clear, which syllable belongs where, > so a connection of syllables to notes is not always given. The possibility to > encode the lyrics separately and then attach them to a staff seems unlikely too, > as the syllables would be spaced according to the rhythm off the staff (the > lyrics would only appear at the beginning of the staff, as there normally are > more notes then syllables). > > > > A possibility to connect not only syllables but also whole phrases of text to > phrases of notes would be really nice; something like "this text starts on that > note and ends on that note". As it is not clear in all the cases how the > underlayed text is to be sung and therefore a spacing of the lyrics would be an > editorial intervention, a solution like @startid and @endid (or something else) > would at least represent the source material the best. > > > > Best, > > Daniel > > > > > > > > > > Zitat von Andrew Hankinson : > > > >> Could someone boil down the decisions that need to be made, even just in > point form, for those of us who haven't been part of the discussion? > >> > >> I'm afraid I don't quite understand what we're supposed to be commenting > on. > >> > >> -Andrew > >> > >>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > wrote: > >>> > >>> > >>> Hi, > >>> > >>> Text underlay doesn't have anything to do with or . > >>> > >>> I apologize for the confusion created by the definition of -- it was > too short and too cryptic. In the version of MEI currently under development, > verse is defined as "Division of a poem or song lyrics; a stanza." > >>> > >>> The verse/syl construct is only applicable at the note level. For musical > material which is repeated, but with different words/lyrics/sung text, > provides a method of recording which words belong with each repetition. > >>> > >>> > >>> > >>> Ooh > >>> > >>> > >>> Ah > >>> > >>> > >>> > >>> For text not directly associated with individual notes, lyrics/lg should be > used instead. occurs outside the stream of notated events; that is, > inside and , although not within or as > might be required for mensural notation. I'll correct this oversight soon. The > element is, of course, borrowed from TEI. > >>> > >>> For those situations where the sung text is visually separate from > >>> the musical material, one can use -- > >>> > >>> > >>> > >>> Oh, say can you see > >>> > >>> > >>> > >>> To associate each syllable of these words with the notes, one can > >>> add elements -- > >>> > >>> > >>> > >>> > >>> Oh, > >>> say > >>> can > >>> >you > >>> see > >>> > >>> > >>> > >>> One may object to calling the text of a 15th century motet "lyrics", but the > same markup applies. > >>> > >>> -- > >>> p. > >>> > >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >>> Of Giuliano Di Bacco > >>> Sent: Saturday, March 04, 2017 6:28 AM > >>> To: Byrd, Donald A.; Music Encoding Initiative > >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > >>> segmentation > >>> > >>> Thanks, Don: > >>> > >>> I swear that I am not trying to complicate the issue further, but I should > recall that it was another moving part of the mechanism that originated this > discussions on MEI-Mens, that is, . That is, also arbitrary > segmentation/alignment of... non-arbitrary text (!) deserves attention: > >>> > >>> 1 - about its use, as regard to the issue described by Don: how best to > record arbitrary (I prefer: "non standard") placement of text underlay > (alignment of chunks of text in with s), when not possible/easy > to do it with . > >>> > >>> 2- about its definition. This may be slightly off-topic, but important: > discussion on MEI-Mens reveals that there may be some confusion about what > is supposed to be used for. The specifications say that this is for "lyric > verse". Period. First, I am not sure whether "verse" has to be intended as "a > body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single > line of a metrical writing" -- definitions in major Brit+American dictionaries (and > people's opinions) fluctuate between these poles. Second, I am not sure > whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, > didactic poetry) or generically for "the words of a song". Admittedly, in > romance languages both terms are less ambiguous than in English, so I suppose > that we just need to clarify, through a more generous description, if is > "whatever poetic text underlay" (my best guess) or what. It would be very > useful to clarify this point while we talk about "text". The next step would be > to decide if we need/want to represent poetical structures of lower (or higher) > order (it would seem logical to me if we borrowed stuff from TEI), and how to > distinguish text underlay proper from text-that-goes-with-these-notes but not- > laid-under-the-notes, that is, written/printed somewhere else in the page > (introducing some tag/att like "underlay" and "displaced" perhaps). But this is > really off-topic (premature) for now. > >>> > >>> As usual, please don't hesitate to correct me if I > misunderstood/misrepresented anything -- it would be helpful. > >>> > >>> Best, > >>> > >>> Giuliano > >>> > >>> > >>> > >>> Byrd, Donald A. wrote on 04/03/2017 01:36: > >>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > >>> Perry and I, plus other members of the mensural IG -- have been > >>> discussing the need for annotations with arbitrary text that are > >>> displayed on the music. Unfortunately, the discussion so far has > >>> been scattered among several places, including the mensural IG > >>> mailing list and Verovio GitHub issues #248 ("Directives in mensural > >>> notation aren't drawn"), 388 ("@n for "), and especially 389 > >>> ("implement display"). You can read #389 at > >>> > >>> https://github.com/rism-ch/verovio/issues/389 > >>> > >>> > >>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the > issues here. > >>> > >>> We've talked about using one of two existing tags for these annotations, > namely and . It seems clear that is not what we want > because it's specifically intended for performance directions. As for s, > of course they are currently only for annotating the encoding, not the music, > and they're not displayed in the SVG. We could add a @visible attribute to > , but the problem then is _where_ on the music should they appear? > But it seems to me this is only a serious problem if you expect the notation > engine to position everything automatically, and that's something that I think > is completely unrealistic for complex music regardless of annotation. I suggest > visible s should have a crudely-calculated default position, and it'd be > up to the user to specify a different position if they want. > >>> > >>> Giuliano has raised a related concern. He wrote yesterday that > >>> > >>> "[N]ot only something like for arbitrary non-lyric text is needed, but > also some arbitrary segmentation, to encapsulate portions of music and/or > lyric/non-lyric text where things happen (such as, lyric text loosely connected > with a portion of music, or passages where the mensuration is uncertain...). > >>> > >>> "If I understand correctly, most of the problem with originates from > the missing level in the hierarchy (at least this creates problems > with Verovio), so I was wondering whether the introduction of a tag > at that level could be useful. The latter, contrary to > would be totally optional, and contrary to or
would be > used without any structural meaning. > >>> > >>> "This is the point where we felt the need that the discussion escalates on > MEI-L. Non-structural segmentation is something that TEI introduced lately in > their schema (they call it when the portion of text is shorter than a > paragraph, and when an 'anonymous block' of text is found that escapes > from the paragraph structure). In my experience this is one of the most useful > features when dealing with complex documents, and in past projects I used it > also to provide annotations. I wonder whether there are any reasons for not > having a -like tag available at any level." > >>> > >>> Giuliano's ideas make sense to me, but I don't feel very well qualified to > evaluate them. > >>> > >>> I'm looking forward to hearing people's thoughts on all of this! > >>> > >>> --Don > >>> > >>> > >>> --- > >>> Donald Byrd > >>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor > >>> of Informatics Visiting Scientist, Research Technologies Indiana > >>> University Bloomington > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 From andrew.hankinson at mail.mcgill.ca Mon Mar 6 16:09:17 2017 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 6 Mar 2017 15:09:17 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> Message-ID: <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> I was thinking more semantic alignment, but maybe that’s what you were thinking of by ‘temporal’ alignment. I was trying to answer Daniel’s use case where “these lyrics belong to these notes with no specific information on which lyric belongs to which note” would “correspond” but not necessarily “synchronise”. That is, there is no specific time information (‘chronos’ in ’synchronise') but there *is* a relationship between them. The specific case I was imagining was where a tune and lyrics were given separately, with multiple possible realisations of the alignment. Rather than making the statement that a given lyric is in sync with a tune, it would be best to just say that these lyrics ‘belong’ to this group of notes / measure / whatever. -Andrew > On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h) wrote: > > > If temporal alignment is the objective, then @corresp is not specific enough. Better to use @synch. The fact that these attributes are missing from and is remediable. :-) @startid/@endid can also be added to , as Daniel suggested, or to another still more specific element, to indicate starting and ending points for a text string. > > -- > p. > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Andrew Hankinson >> Sent: Monday, March 06, 2017 6:51 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >> segmentation >> >> If you’re talking about *visually* spacing the lyrics given an unknown >> association with the notes, then this is not an MEI problem, as far as I can see. >> This would need to be down to a particularly clever renderer, or some other >> means of computationally deriving syllable-note relationships. >> >> It really comes down to whether or not you are asserting or estimating. If you >> are asserting a relationship, you would put it in MEI. If you are estimating a >> relationship, based on informed guesses, it’s probably best to leave that to an >> interpretive layer that sits above the encoding, and only assert the things that >> you know. >> >> Just a quick glance through the elements lyrics, lg, and l, it seems that the >> `@corresp` attribute might be the best solution. This is already available on >> lyrics, but not on lg or l. >> >> I could imagine something like: >> >> >> >> … >> >> >> >> -Andrew >> >>> On 6 Mar 2017, at 07:57, Daniel Alles >> wrote: >>> >>> Dear all, >>> >>> I think one of the problems (at least one of my problems while encoding MN) >> is the spacing of the lyrics. It is not always clear, which syllable belongs where, >> so a connection of syllables to notes is not always given. The possibility to >> encode the lyrics separately and then attach them to a staff seems unlikely too, >> as the syllables would be spaced according to the rhythm off the staff (the >> lyrics would only appear at the beginning of the staff, as there normally are >> more notes then syllables). >>> >>> A possibility to connect not only syllables but also whole phrases of text to >> phrases of notes would be really nice; something like "this text starts on that >> note and ends on that note". As it is not clear in all the cases how the >> underlayed text is to be sung and therefore a spacing of the lyrics would be an >> editorial intervention, a solution like @startid and @endid (or something else) >> would at least represent the source material the best. >>> >>> Best, >>> Daniel >>> >>> >>> >>> >>> Zitat von Andrew Hankinson : >>> >>>> Could someone boil down the decisions that need to be made, even just in >> point form, for those of us who haven't been part of the discussion? >>>> >>>> I'm afraid I don't quite understand what we're supposed to be commenting >> on. >>>> >>>> -Andrew >>>> >>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) >> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> Text underlay doesn't have anything to do with or . >>>>> >>>>> I apologize for the confusion created by the definition of -- it was >> too short and too cryptic. In the version of MEI currently under development, >> verse is defined as "Division of a poem or song lyrics; a stanza." >>>>> >>>>> The verse/syl construct is only applicable at the note level. For musical >> material which is repeated, but with different words/lyrics/sung text, >> provides a method of recording which words belong with each repetition. >>>>> >>>>> >>>>> >>>>> Ooh >>>>> >>>>> >>>>> Ah >>>>> >>>>> >>>>> >>>>> For text not directly associated with individual notes, lyrics/lg should be >> used instead. occurs outside the stream of notated events; that is, >> inside and , although not within or as >> might be required for mensural notation. I'll correct this oversight soon. The >> element is, of course, borrowed from TEI. >>>>> >>>>> For those situations where the sung text is visually separate from >>>>> the musical material, one can use -- >>>>> >>>>> >>>>> >>>>> Oh, say can you see >>>>> >>>>> >>>>> >>>>> To associate each syllable of these words with the notes, one can >>>>> add elements -- >>>>> >>>>> >>>>> >>>>> >>>>> Oh, >>>>> say >>>>> can >>>>> >you >>>>> see >>>>> >>>>> >>>>> >>>>> One may object to calling the text of a 15th century motet "lyrics", but the >> same markup applies. >>>>> >>>>> -- >>>>> p. >>>>> >>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >>>>> Of Giuliano Di Bacco >>>>> Sent: Saturday, March 04, 2017 6:28 AM >>>>> To: Byrd, Donald A.; Music Encoding Initiative >>>>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >>>>> segmentation >>>>> >>>>> Thanks, Don: >>>>> >>>>> I swear that I am not trying to complicate the issue further, but I should >> recall that it was another moving part of the mechanism that originated this >> discussions on MEI-Mens, that is, . That is, also arbitrary >> segmentation/alignment of... non-arbitrary text (!) deserves attention: >>>>> >>>>> 1 - about its use, as regard to the issue described by Don: how best to >> record arbitrary (I prefer: "non standard") placement of text underlay >> (alignment of chunks of text in with s), when not possible/easy >> to do it with . >>>>> >>>>> 2- about its definition. This may be slightly off-topic, but important: >> discussion on MEI-Mens reveals that there may be some confusion about what >> is supposed to be used for. The specifications say that this is for "lyric >> verse". Period. First, I am not sure whether "verse" has to be intended as "a >> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single >> line of a metrical writing" -- definitions in major Brit+American dictionaries (and >> people's opinions) fluctuate between these poles. Second, I am not sure >> whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, >> didactic poetry) or generically for "the words of a song". Admittedly, in >> romance languages both terms are less ambiguous than in English, so I suppose >> that we just need to clarify, through a more generous description, if is >> "whatever poetic text underlay" (my best guess) or what. It would be very >> useful to clarify this point while we talk about "text". The next step would be >> to decide if we need/want to represent poetical structures of lower (or higher) >> order (it would seem logical to me if we borrowed stuff from TEI), and how to >> distinguish text underlay proper from text-that-goes-with-these-notes but not- >> laid-under-the-notes, that is, written/printed somewhere else in the page >> (introducing some tag/att like "underlay" and "displaced" perhaps). But this is >> really off-topic (premature) for now. >>>>> >>>>> As usual, please don't hesitate to correct me if I >> misunderstood/misrepresented anything -- it would be helpful. >>>>> >>>>> Best, >>>>> >>>>> Giuliano >>>>> >>>>> >>>>> >>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: >>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, >>>>> Perry and I, plus other members of the mensural IG -- have been >>>>> discussing the need for annotations with arbitrary text that are >>>>> displayed on the music. Unfortunately, the discussion so far has >>>>> been scattered among several places, including the mensural IG >>>>> mailing list and Verovio GitHub issues #248 ("Directives in mensural >>>>> notation aren't drawn"), 388 ("@n for "), and especially 389 >>>>> ("implement display"). You can read #389 at >>>>> >>>>> https://github.com/rism-ch/verovio/issues/389 >>>>> >>>>> >>>>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the >> issues here. >>>>> >>>>> We've talked about using one of two existing tags for these annotations, >> namely and . It seems clear that is not what we want >> because it's specifically intended for performance directions. As for s, >> of course they are currently only for annotating the encoding, not the music, >> and they're not displayed in the SVG. We could add a @visible attribute to >> , but the problem then is _where_ on the music should they appear? >> But it seems to me this is only a serious problem if you expect the notation >> engine to position everything automatically, and that's something that I think >> is completely unrealistic for complex music regardless of annotation. I suggest >> visible s should have a crudely-calculated default position, and it'd be >> up to the user to specify a different position if they want. >>>>> >>>>> Giuliano has raised a related concern. He wrote yesterday that >>>>> >>>>> "[N]ot only something like for arbitrary non-lyric text is needed, but >> also some arbitrary segmentation, to encapsulate portions of music and/or >> lyric/non-lyric text where things happen (such as, lyric text loosely connected >> with a portion of music, or passages where the mensuration is uncertain...). >>>>> >>>>> "If I understand correctly, most of the problem with originates from >> the missing level in the hierarchy (at least this creates problems >> with Verovio), so I was wondering whether the introduction of a tag >> at that level could be useful. The latter, contrary to >> would be totally optional, and contrary to or
would be >> used without any structural meaning. >>>>> >>>>> "This is the point where we felt the need that the discussion escalates on >> MEI-L. Non-structural segmentation is something that TEI introduced lately in >> their schema (they call it when the portion of text is shorter than a >> paragraph, and when an 'anonymous block' of text is found that escapes >> from the paragraph structure). In my experience this is one of the most useful >> features when dealing with complex documents, and in past projects I used it >> also to provide annotations. I wonder whether there are any reasons for not >> having a -like tag available at any level." >>>>> >>>>> Giuliano's ideas make sense to me, but I don't feel very well qualified to >> evaluate them. >>>>> >>>>> I'm looking forward to hearing people's thoughts on all of this! >>>>> >>>>> --Don >>>>> >>>>> >>>>> --- >>>>> Donald Byrd >>>>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor >>>>> of Informatics Visiting Scientist, Research Technologies Indiana >>>>> University Bloomington >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 From pdr4h at eservices.virginia.edu Mon Mar 6 16:41:37 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 15:41:37 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> Message-ID: The approach Giuliano suggests may work for single-staff notation, but it won't work for music on multiple staves because the segment boundary would have to be the same for all staves. Unless the total duration of the segment is the same in all layers of all the staves (which is likely not to be the case because of the polyphonic style with which mensural notation is usually associated), then the following won't work -- Also, in the case of multiple staves, to which staff are the lyrics to be attached? Even if were used lower in the hierarchy, say at the layer level -- the same problem would persist. The only possibility left is to forego segmentation other than that of and and associate text directly with events via @synch -- Hmmm? This method works regardless of where the element is actually placed, be it inside , , or elsewhere. It can be extended to if necessary -- Hmm? Say what? In case you're wondering why @synch and not @startid -- I know it's somewhat arbitrary, but @startid is reserved for musical events (like , , and such) that are attached to other musical events, while @synch (borrowed from TEI) is used on elements that may or may not be musical events (,

, ). If a new element for performed text that was always a musical event were created, then it would use @startid instead of @synch. > I am not sure what the remark about "@align" means at the bottom of http://music-encoding.org/documentation/3.0.0/syl/ -- do we have such attribute on syl? That's an error which has been fixed in the development version. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Monday, March 06, 2017 6:17 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Daniel Alles wrote on 06/03/2017 08:57: "this text starts on that note and ends on that note". This is where I saw the *possibility* to do also the reverse, giving priority to the music: Something like exultavit which would mean "this chunk of music here has a chunk of text under-laid to it". Perry: I know that directions and lyrics are two different things. What I meant to say is that both things can share the nature of being a chunk of text to be aligned with a chunk of music. Daniel: of course your idea of using pointers is good as well. But I though that to identify an "arbitrary" chunk of music may be also useful. And this is just an idea, probably there are a hundred reasons why this may be wrong. Let me clarify that it sprang to my mind because of something Don mentioned, that the absence of in the hierarchy makes it difficult for Verovio to process textual stuff in the mensural module. Note above that is where would be in CMN. But I may have misinterpreted his words! One may say that this is relevant to the effort of reproducing the source as closely as possible, when ultimately we are supposed to interpret where the scribe wanted us to sing each syllable. I also believe this, but I see some good value in encoding the original, especially if one cannot show the image. So I suppose that I need to make one step forward and try to get both the diplomatic and the interpretive edition: ... exultavit exultavit ... Here I would use a pointer on to reconnect syllables with the s they belong. [I am not sure what the remark about "@align" means at the bottom of http://music-encoding.org/documentation/3.0.0/syl/ -- do we have such attribute on syl?] All in all, I am sure there are better methods to do this -- but I wanted to explain what my words quoted in Don's first message implied. Giuliano Daniel Alles wrote on 06/03/2017 08:57: Dear all, I think one of the problems (at least one of my problems while encoding MN) is the spacing of the lyrics. It is not always clear, which syllable belongs where, so a connection of syllables to notes is not always given. The possibility to encode the lyrics separately and then attach them to a staff seems unlikely too, as the syllables would be spaced according to the rhythm off the staff (the lyrics would only appear at the beginning of the staff, as there normally are more notes then syllables). A possibility to connect not only syllables but also whole phrases of text to phrases of notes would be really nice; something like "this text starts on that note and ends on that note". As it is not clear in all the cases how the underlayed text is to be sung and therefore a spacing of the lyrics would be an editorial intervention, a solution like @startid and @endid (or something else) would at least represent the source material the best. Best, Daniel Zitat von Andrew Hankinson : Could someone boil down the decisions that need to be made, even just in point form, for those of us who haven't been part of the discussion? I'm afraid I don't quite understand what we're supposed to be commenting on. -Andrew On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) wrote: Hi, Text underlay doesn't have anything to do with

or . I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. Ooh Ah For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. For those situations where the sung text is visually separate from the musical material, one can use -- Oh, say can you see To associate each syllable of these words with the notes, one can add elements -- Oh, say can >you see One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Saturday, March 04, 2017 6:28 AM To: Byrd, Donald A.; Music Encoding Initiative Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Thanks, Don: I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. Best, Giuliano Byrd, Donald A. wrote on 04/03/2017 01:36: For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at https://github.com/rism-ch/verovio/issues/389 and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. Giuliano has raised a related concern. He wrote yesterday that "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. I'm looking forward to hearing people's thoughts on all of this! --Don --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington _______________________________________________ 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: From pdr4h at eservices.virginia.edu Mon Mar 6 17:04:30 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 16:04:30 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: You're right, @corresp can be used instead of @synch for generic "correspondence". But, if the goal is to render the text, then it should be associated with the notes in a more specific way. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Andrew Hankinson > Sent: Monday, March 06, 2017 10:11 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > I was thinking more semantic alignment, but maybe that’s what you were > thinking of by ‘temporal’ alignment. > > I was trying to answer Daniel’s use case where “these lyrics belong to these > notes with no specific information on which lyric belongs to which note” > would “correspond” but not necessarily “synchronise”. That is, there is no > specific time information (‘chronos’ in ’synchronise') but there *is* a > relationship between them. > > The specific case I was imagining was where a tune and lyrics were given > separately, with multiple possible realisations of the alignment. Rather than > making the statement that a given lyric is in sync with a tune, it would be best > to just say that these lyrics ‘belong’ to this group of notes / measure / > whatever. > > -Andrew > > > On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h) > wrote: > > > > > > If temporal alignment is the objective, then @corresp is not specific enough. > Better to use @synch. The fact that these attributes are missing from and > is remediable. :-) @startid/@endid can also be added to , as Daniel > suggested, or to another still more specific element, to indicate starting and > ending points for a text string. > > > > -- > > p. > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Andrew Hankinson > >> Sent: Monday, March 06, 2017 6:51 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > >> segmentation > >> > >> If you’re talking about *visually* spacing the lyrics given an > >> unknown association with the notes, then this is not an MEI problem, as far > as I can see. > >> This would need to be down to a particularly clever renderer, or some > >> other means of computationally deriving syllable-note relationships. > >> > >> It really comes down to whether or not you are asserting or > >> estimating. If you are asserting a relationship, you would put it in > >> MEI. If you are estimating a relationship, based on informed guesses, > >> it’s probably best to leave that to an interpretive layer that sits > >> above the encoding, and only assert the things that you know. > >> > >> Just a quick glance through the elements lyrics, lg, and l, it seems > >> that the `@corresp` attribute might be the best solution. This is > >> already available on lyrics, but not on lg or l. > >> > >> I could imagine something like: > >> > >> > >> > >> … > >> > >> > >> > >> -Andrew > >> > >>> On 6 Mar 2017, at 07:57, Daniel Alles > >>> > >> wrote: > >>> > >>> Dear all, > >>> > >>> I think one of the problems (at least one of my problems while > >>> encoding MN) > >> is the spacing of the lyrics. It is not always clear, which syllable > >> belongs where, so a connection of syllables to notes is not always > >> given. The possibility to encode the lyrics separately and then > >> attach them to a staff seems unlikely too, as the syllables would be > >> spaced according to the rhythm off the staff (the lyrics would only > >> appear at the beginning of the staff, as there normally are more notes then > syllables). > >>> > >>> A possibility to connect not only syllables but also whole phrases > >>> of text to > >> phrases of notes would be really nice; something like "this text > >> starts on that note and ends on that note". As it is not clear in all > >> the cases how the underlayed text is to be sung and therefore a > >> spacing of the lyrics would be an editorial intervention, a solution > >> like @startid and @endid (or something else) would at least represent the > source material the best. > >>> > >>> Best, > >>> Daniel > >>> > >>> > >>> > >>> > >>> Zitat von Andrew Hankinson : > >>> > >>>> Could someone boil down the decisions that need to be made, even > >>>> just in > >> point form, for those of us who haven't been part of the discussion? > >>>> > >>>> I'm afraid I don't quite understand what we're supposed to be > >>>> commenting > >> on. > >>>> > >>>> -Andrew > >>>> > >>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > >> wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> Text underlay doesn't have anything to do with or . > >>>>> > >>>>> I apologize for the confusion created by the definition of > >>>>> -- it was > >> too short and too cryptic. In the version of MEI currently under > >> development, verse is defined as "Division of a poem or song lyrics; a > stanza." > >>>>> > >>>>> The verse/syl construct is only applicable at the note level. For > >>>>> musical > >> material which is repeated, but with different words/lyrics/sung > >> text, provides a method of recording which words belong with each > repetition. > >>>>> > >>>>> > >>>>> > >>>>> Ooh > >>>>> > >>>>> > >>>>> Ah > >>>>> > >>>>> > >>>>> > >>>>> For text not directly associated with individual notes, lyrics/lg > >>>>> should be > >> used instead. occurs outside the stream of notated events; > >> that is, inside and , although not within > >> or as might be required for mensural notation. I'll correct > >> this oversight soon. The element is, of course, borrowed from TEI. > >>>>> > >>>>> For those situations where the sung text is visually separate from > >>>>> the musical material, one can use -- > >>>>> > >>>>> > >>>>> > >>>>> Oh, say can you see > >>>>> > >>>>> > >>>>> > >>>>> To associate each syllable of these words with the notes, one can > >>>>> add elements -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Oh, > >>>>> say > >>>>> can > >>>>> >you > >>>>> see > >>>>> > >>>>> > >>>>> > >>>>> One may object to calling the text of a 15th century motet > >>>>> "lyrics", but the > >> same markup applies. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On > >>>>> Behalf Of Giuliano Di Bacco > >>>>> Sent: Saturday, March 04, 2017 6:28 AM > >>>>> To: Byrd, Donald A.; Music Encoding Initiative > >>>>> Subject: Re: [MEI-L] Annotations visible on the music and > >>>>> arbitrary segmentation > >>>>> > >>>>> Thanks, Don: > >>>>> > >>>>> I swear that I am not trying to complicate the issue further, but > >>>>> I should > >> recall that it was another moving part of the mechanism that > >> originated this discussions on MEI-Mens, that is, . That is, > >> also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves > attention: > >>>>> > >>>>> 1 - about its use, as regard to the issue described by Don: how > >>>>> best to > >> record arbitrary (I prefer: "non standard") placement of text > >> underlay (alignment of chunks of text in with s), when > >> not possible/easy to do it with . > >>>>> > >>>>> 2- about its definition. This may be slightly off-topic, but important: > >> discussion on MEI-Mens reveals that there may be some confusion about > >> what is supposed to be used for. The specifications say that > >> this is for "lyric verse". Period. First, I am not sure whether > >> "verse" has to be intended as "a body of metrical writing/poetry" or > >> a "stanza/strophe of poetry" or a "single line of a metrical writing" > >> -- definitions in major Brit+American dictionaries (and people's > >> opinions) fluctuate between these poles. Second, I am not sure > >> whether "lyric" stands for the genre (lyric poetry as opposed to > >> narrative, epic, didactic poetry) or generically for "the words of a > >> song". Admittedly, in romance languages both terms are less ambiguous > >> than in English, so I suppose that we just need to clarify, through a > >> more generous description, if is "whatever poetic text > >> underlay" (my best guess) or what. It would be very useful to clarify > >> this point while we talk about "text". The next step would be to > >> decide if we need/want to represent poetical structures of lower (or > >> higher) order (it would seem logical to me if we borrowed stuff from > >> TEI), and how to distinguish text underlay proper from > >> text-that-goes-with-these-notes but not- laid-under-the-notes, that is, > written/printed somewhere else in the page (introducing some tag/att like > "underlay" and "displaced" perhaps). But this is really off-topic (premature) for > now. > >>>>> > >>>>> As usual, please don't hesitate to correct me if I > >> misunderstood/misrepresented anything -- it would be helpful. > >>>>> > >>>>> Best, > >>>>> > >>>>> Giuliano > >>>>> > >>>>> > >>>>> > >>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: > >>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > >>>>> Perry and I, plus other members of the mensural IG -- have been > >>>>> discussing the need for annotations with arbitrary text that are > >>>>> displayed on the music. Unfortunately, the discussion so far has > >>>>> been scattered among several places, including the mensural IG > >>>>> mailing list and Verovio GitHub issues #248 ("Directives in > >>>>> mensural notation aren't drawn"), 388 ("@n for "), and > >>>>> especially 389 ("implement display"). You can read #389 at > >>>>> > >>>>> https://github.com/rism-ch/verovio/issues/389 > >>>>> > >>>>> > >>>>> and similarly for the other Verovio issues. Anyway, I'll try to > >>>>> summarize the > >> issues here. > >>>>> > >>>>> We've talked about using one of two existing tags for these > >>>>> annotations, > >> namely and . It seems clear that is not what we > >> want because it's specifically intended for performance directions. > >> As for s, of course they are currently only for annotating the > >> encoding, not the music, and they're not displayed in the SVG. We > >> could add a @visible attribute to , but the problem then is _where_ > on the music should they appear? > >> But it seems to me this is only a serious problem if you expect the > >> notation engine to position everything automatically, and that's > >> something that I think is completely unrealistic for complex music > >> regardless of annotation. I suggest visible s should have a > >> crudely-calculated default position, and it'd be up to the user to specify a > different position if they want. > >>>>> > >>>>> Giuliano has raised a related concern. He wrote yesterday that > >>>>> > >>>>> "[N]ot only something like for arbitrary non-lyric text is > >>>>> needed, but > >> also some arbitrary segmentation, to encapsulate portions of music > >> and/or lyric/non-lyric text where things happen (such as, lyric text > >> loosely connected with a portion of music, or passages where the > mensuration is uncertain...). > >>>>> > >>>>> "If I understand correctly, most of the problem with > >>>>> originates from > >> the missing level in the hierarchy (at least this creates > >> problems with Verovio), so I was wondering whether the introduction > >> of a tag at that level could be useful. The latter, > >> contrary to would be totally optional, and contrary to > >> or
would be used without any structural meaning. > >>>>> > >>>>> "This is the point where we felt the need that the discussion > >>>>> escalates on > >> MEI-L. Non-structural segmentation is something that TEI introduced > >> lately in their schema (they call it when the portion of text > >> is shorter than a paragraph, and when an 'anonymous block' of > >> text is found that escapes from the paragraph structure). In my > >> experience this is one of the most useful features when dealing with > >> complex documents, and in past projects I used it also to provide > >> annotations. I wonder whether there are any reasons for not having a > -like tag available at any level." > >>>>> > >>>>> Giuliano's ideas make sense to me, but I don't feel very well > >>>>> qualified to > >> evaluate them. > >>>>> > >>>>> I'm looking forward to hearing people's thoughts on all of this! > >>>>> > >>>>> --Don > >>>>> > >>>>> > >>>>> --- > >>>>> Donald Byrd > >>>>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor > >>>>> of Informatics Visiting Scientist, Research Technologies Indiana > >>>>> University Bloomington > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 From from.mei-l at jdlh.com Mon Mar 6 18:28:52 2017 From: from.mei-l at jdlh.com (Jim DeLaHunt) Date: Mon, 6 Mar 2017 09:28:52 -0800 Subject: [MEI-L] Combining alternate lyrics with digital scores in the field [was: Re: Annotations visible on the music and arbitrary segmentation] In-Reply-To: <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: I'm not competent to debate the details of representing lyrics in MEI, but I would like to highlight this use case Andrew mentions: On 2017-03-06 07:09, Andrew Hankinson wrote: > The specific case I was imagining was where a tune and lyrics were given separately... I have a similar use case, and I would love for MEI to be able to handle it. It goes like this: * Verdi writes an opera, with a libretto in Italian, and specifies which words go with which notes. * An engraver from Ricordi expresses Verdi's notes and words and alignment as printed notation. * Over a century later, one person ("Alice") transcribes the printed notation, including words aligned with notes, into MEI form. She posts this digital score on a web page, with a free-use licence. * Another person ("Bob") translates the libretto of Verdi's opera into singable Thai, and specifies which words go with which notes. Bob posts this information in some MEI-related format on a web page, with a free-use licence. * A third person ("Carol", a singer), will be performing the Verdi opera in Thai. She downloads both Alice's digital score and Bob's Thai translation. She wants to make a digital score which includes Bob's Thai words aligned with the notes in Alice's score, and drops the Italian libretto. * A fourth person ("David") doesn't like Alice's transcription, so makes an MEI transcription of the same Verdi opera from a different printed edition. It has different staff and page breaks than does Alice's score. David also downloads Bob's Thai translation. David also wants to make a digital score which includes Bob's Thai words aligned with the notes in David's score. One of my aspirations for MEI is that it have all the technical features needed to make this use case practical. I would like to see a way for a translator to make an alternate set of lyrics which is packaged separate from the score, and can be combined with a score. This packaging is to succeed regardless of the page layout the score happens to embody. In fact, it should be possible to revise the layout of the score, and have the alternate lyrics follow along. It's fine if something like a notation editor is required to combine alternate lyrics and digital score, but the operation should be automatic. It should not require hand-editing by the end user. Do I understand from this conversation that this is not yet possible in MEI? That is, we have not yet worked out how a separate package of lyrics should relate to notes in a layout-independent way? Thank you, --Jim DeLaHunt, Keyboard Philharmonic project, http://KeyboardPhilharmonic.org On 2017-03-06 07:09, Andrew Hankinson wrote: > I was thinking more semantic alignment, but maybe that’s what you were thinking of by ‘temporal’ alignment. > > I was trying to answer Daniel’s use case where “these lyrics belong to these notes with no specific information on which lyric belongs to which note” would “correspond” but not necessarily “synchronise”. That is, there is no specific time information (‘chronos’ in ’synchronise') but there *is* a relationship between them. > > The specific case I was imagining was where a tune and lyrics were given separately, with multiple possible realisations of the alignment. Rather than making the statement that a given lyric is in sync with a tune, it would be best to just say that these lyrics ‘belong’ to this group of notes / measure / whatever. > > -Andrew > >> On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h) wrote: >> >> >> If temporal alignment is the objective, then @corresp is not specific enough. Better to use @synch. The fact that these attributes are missing from and is remediable. :-) @startid/@endid can also be added to , as Daniel suggested, or to another still more specific element, to indicate starting and ending points for a text string. >> >> -- >> p. >> >>> -----Original Message----- >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >>> Andrew Hankinson >>> Sent: Monday, March 06, 2017 6:51 AM >>> To: Music Encoding Initiative >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >>> segmentation >>> >>> If you’re talking about *visually* spacing the lyrics given an unknown >>> association with the notes, then this is not an MEI problem, as far as I can see. >>> This would need to be down to a particularly clever renderer, or some other >>> means of computationally deriving syllable-note relationships. >>> >>> It really comes down to whether or not you are asserting or estimating. If you >>> are asserting a relationship, you would put it in MEI. If you are estimating a >>> relationship, based on informed guesses, it’s probably best to leave that to an >>> interpretive layer that sits above the encoding, and only assert the things that >>> you know. >>> >>> Just a quick glance through the elements lyrics, lg, and l, it seems that the >>> `@corresp` attribute might be the best solution. This is already available on >>> lyrics, but not on lg or l. >>> >>> I could imagine something like: >>> >>> >>> >>> … >>> >>> >>> >>> -Andrew >>> >>>> On 6 Mar 2017, at 07:57, Daniel Alles >>> wrote: >>>> Dear all, >>>> >>>> I think one of the problems (at least one of my problems while encoding MN) >>> is the spacing of the lyrics. It is not always clear, which syllable belongs where, >>> so a connection of syllables to notes is not always given. The possibility to >>> encode the lyrics separately and then attach them to a staff seems unlikely too, >>> as the syllables would be spaced according to the rhythm off the staff (the >>> lyrics would only appear at the beginning of the staff, as there normally are >>> more notes then syllables). >>>> A possibility to connect not only syllables but also whole phrases of text to >>> phrases of notes would be really nice; something like "this text starts on that >>> note and ends on that note". As it is not clear in all the cases how the >>> underlayed text is to be sung and therefore a spacing of the lyrics would be an >>> editorial intervention, a solution like @startid and @endid (or something else) >>> would at least represent the source material the best. >>>> Best, >>>> Daniel >>>> >>>> >>>> >>>> >>>> Zitat von Andrew Hankinson : >>>> >>>>> Could someone boil down the decisions that need to be made, even just in >>> point form, for those of us who haven't been part of the discussion? >>>>> I'm afraid I don't quite understand what we're supposed to be commenting >>> on. >>>>> -Andrew >>>>> >>>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) >>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Text underlay doesn't have anything to do with or . >>>>>> >>>>>> I apologize for the confusion created by the definition of -- it was >>> too short and too cryptic. In the version of MEI currently under development, >>> verse is defined as "Division of a poem or song lyrics; a stanza." >>>>>> The verse/syl construct is only applicable at the note level. For musical >>> material which is repeated, but with different words/lyrics/sung text, >>> provides a method of recording which words belong with each repetition. >>>>>> >>>>>> >>>>>> Ooh >>>>>> >>>>>> >>>>>> Ah >>>>>> >>>>>> >>>>>> >>>>>> For text not directly associated with individual notes, lyrics/lg should be >>> used instead. occurs outside the stream of notated events; that is, >>> inside and , although not within or as >>> might be required for mensural notation. I'll correct this oversight soon. The >>> element is, of course, borrowed from TEI. >>>>>> For those situations where the sung text is visually separate from >>>>>> the musical material, one can use -- >>>>>> >>>>>> >>>>>> >>>>>> Oh, say can you see >>>>>> >>>>>> >>>>>> >>>>>> To associate each syllable of these words with the notes, one can >>>>>> add elements -- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Oh, >>>>>> say >>>>>> can >>>>>> >you >>>>>> see >>>>>> >>>>>> >>>>>> >>>>>> One may object to calling the text of a 15th century motet "lyrics", but the >>> same markup applies. >>>>>> -- >>>>>> p. >>>>>> >>>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >>>>>> Of Giuliano Di Bacco >>>>>> Sent: Saturday, March 04, 2017 6:28 AM >>>>>> To: Byrd, Donald A.; Music Encoding Initiative >>>>>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >>>>>> segmentation >>>>>> >>>>>> Thanks, Don: >>>>>> >>>>>> I swear that I am not trying to complicate the issue further, but I should >>> recall that it was another moving part of the mechanism that originated this >>> discussions on MEI-Mens, that is, . That is, also arbitrary >>> segmentation/alignment of... non-arbitrary text (!) deserves attention: >>>>>> 1 - about its use, as regard to the issue described by Don: how best to >>> record arbitrary (I prefer: "non standard") placement of text underlay >>> (alignment of chunks of text in with s), when not possible/easy >>> to do it with . >>>>>> 2- about its definition. This may be slightly off-topic, but important: >>> discussion on MEI-Mens reveals that there may be some confusion about what >>> is supposed to be used for. The specifications say that this is for "lyric >>> verse". Period. First, I am not sure whether "verse" has to be intended as "a >>> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single >>> line of a metrical writing" -- definitions in major Brit+American dictionaries (and >>> people's opinions) fluctuate between these poles. Second, I am not sure >>> whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, >>> didactic poetry) or generically for "the words of a song". Admittedly, in >>> romance languages both terms are less ambiguous than in English, so I suppose >>> that we just need to clarify, through a more generous description, if is >>> "whatever poetic text underlay" (my best guess) or what. It would be very >>> useful to clarify this point while we talk about "text". The next step would be >>> to decide if we need/want to represent poetical structures of lower (or higher) >>> order (it would seem logical to me if we borrowed stuff from TEI), and how to >>> distinguish text underlay proper from text-that-goes-with-these-notes but not- >>> laid-under-the-notes, that is, written/printed somewhere else in the page >>> (introducing some tag/att like "underlay" and "displaced" perhaps). But this is >>> really off-topic (premature) for now. >>>>>> As usual, please don't hesitate to correct me if I >>> misunderstood/misrepresented anything -- it would be helpful. >>>>>> Best, >>>>>> >>>>>> Giuliano >>>>>> >>>>>> >>>>>> >>>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: >>>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, >>>>>> Perry and I, plus other members of the mensural IG -- have been >>>>>> discussing the need for annotations with arbitrary text that are >>>>>> displayed on the music. Unfortunately, the discussion so far has >>>>>> been scattered among several places, including the mensural IG >>>>>> mailing list and Verovio GitHub issues #248 ("Directives in mensural >>>>>> notation aren't drawn"), 388 ("@n for "), and especially 389 >>>>>> ("implement display"). You can read #389 at >>>>>> >>>>>> https://github.com/rism-ch/verovio/issues/389 >>>>>> >>>>>> >>>>>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the >>> issues here. >>>>>> We've talked about using one of two existing tags for these annotations, >>> namely and . It seems clear that is not what we want >>> because it's specifically intended for performance directions. As for s, >>> of course they are currently only for annotating the encoding, not the music, >>> and they're not displayed in the SVG. We could add a @visible attribute to >>> , but the problem then is _where_ on the music should they appear? >>> But it seems to me this is only a serious problem if you expect the notation >>> engine to position everything automatically, and that's something that I think >>> is completely unrealistic for complex music regardless of annotation. I suggest >>> visible s should have a crudely-calculated default position, and it'd be >>> up to the user to specify a different position if they want. >>>>>> Giuliano has raised a related concern. He wrote yesterday that >>>>>> >>>>>> "[N]ot only something like for arbitrary non-lyric text is needed, but >>> also some arbitrary segmentation, to encapsulate portions of music and/or >>> lyric/non-lyric text where things happen (such as, lyric text loosely connected >>> with a portion of music, or passages where the mensuration is uncertain...). >>>>>> "If I understand correctly, most of the problem with originates from >>> the missing level in the hierarchy (at least this creates problems >>> with Verovio), so I was wondering whether the introduction of a tag >>> at that level could be useful. The latter, contrary to >>> would be totally optional, and contrary to or
would be >>> used without any structural meaning. >>>>>> "This is the point where we felt the need that the discussion escalates on >>> MEI-L. Non-structural segmentation is something that TEI introduced lately in >>> their schema (they call it when the portion of text is shorter than a >>> paragraph, and when an 'anonymous block' of text is found that escapes >>> from the paragraph structure). In my experience this is one of the most useful >>> features when dealing with complex documents, and in past projects I used it >>> also to provide annotations. I wonder whether there are any reasons for not >>> having a -like tag available at any level." >>>>>> Giuliano's ideas make sense to me, but I don't feel very well qualified to >>> evaluate them. >>>>>> I'm looking forward to hearing people's thoughts on all of this! >>>>>> >>>>>> --Don >>>>>> >>>>>> >>>>>> --- >>>>>> Donald Byrd >>>>>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor >>>>>> of Informatics Visiting Scientist, Research Technologies Indiana >>>>>> University Bloomington >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 -- --Jim DeLaHunt, jdlh at jdlh.com http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 157-2906 West Broadway, Vancouver BC V6K 2G8, Canada Canada mobile +1-604-376-8953 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Chesser at bl.uk Mon Mar 6 18:54:24 2017 From: Richard.Chesser at bl.uk (Chesser, Richard) Date: Mon, 6 Mar 2017 17:54:24 +0000 Subject: [MEI-L] MEI conference, Tours, 16-19 May: BOOKING NOW OPEN Message-ID: Dear colleagues A few days ago I posted the MEI conference programme at http://music-encoding.org/community/conference/tours17/program/ . I am now delighted to say that full conference details, including how to register, are now available at the conference website of https://mei2017.sciencesconf.org/resource/page/id/3 . Tours is a marvellous place to visit in any event, so with the added attraction of a lively MEI conference and the opportunity to meet others working in the field of music encoding, I hope you find the invitation to attend irresistible! My fellow programme committee members and colleagues in Tours have greatly enjoyed putting the programme together, and look forward to meeting you all very soon. If we can help or advise further, please let us know. Kind regards Richard Chesser Chair, Programme Committee ****************************************************************************************************************** Experience the British Library online at www.bl.uk The British Library’s latest Annual Report and Accounts : www.bl.uk/aboutus/annrep/index.html Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook The Library's St Pancras site is WiFi - enabled ***************************************************************************************************************** The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster at bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. ***************************************************************************************************************** Think before you print -------------- next part -------------- An HTML attachment was scrubbed... URL: From DanielAlles at stud.uni-frankfurt.de Mon Mar 6 22:39:27 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Mon, 06 Mar 2017 22:39:27 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> Message-ID: <20170306223927.Horde.uBPGp53L7i_GpnRrZoJIY0F@webmail.server.uni-frankfurt.de> Maybe I understand it wrong, but I have a problem with @synch: Does it only give me a starting-point for the text? Wouldn't then the text be associated to only one note and not to the whole line it is written under? That was why I suggested @startid AND @endid (or something similar), which would (in my imagination) span a widely spread word wider in the layout, if necessary, just like it does with slurs. Daniel Zitat von "Roland, Perry D. (pdr4h)" : > The approach Giuliano suggests may work for single-staff notation, > but it won't work for music on multiple staves because the segment > boundary would have to be the same for all staves. Unless the total > duration of the segment is the same in all layers of all the staves > (which is likely not to be the case because of the polyphonic style > with which mensural notation is usually associated), then the > following won't work -- > > > > > > > > > > > > > > > > > > > > > > Also, in the case of multiple staves, to which staff are the lyrics > to be attached? > > Even if were used lower in the hierarchy, say at the layer level -- > > > > > > > > > > > > > > > > > > > > > the same problem would persist. > > The only possibility left is to forego segmentation other than that > of and and associate text directly with events via > @synch -- > > > > > > > > > > > > > > > > > Hmmm? > > > > > This method works regardless of where the element is > actually placed, be it inside , , or elsewhere. It > can be extended to if necessary -- > > Hmm? Say what? > > In case you're wondering why @synch and not @startid -- I know it's > somewhat arbitrary, but @startid is reserved for musical events > (like , , and such) that are attached to other > musical events, while @synch (borrowed from TEI) is used on elements > that may or may not be musical events (,

, ). If a new > element for performed text that was always a musical event were > created, then it would use @startid instead of @synch. > >> I am not sure what the remark about "@align" means at the bottom of >> http://music-encoding.org/documentation/3.0.0/syl/ -- do we have >> such attribute on syl? > > That's an error which has been fixed in the development version. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > Of Giuliano Di Bacco > Sent: Monday, March 06, 2017 6:17 AM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > > Daniel Alles wrote on 06/03/2017 08:57: > "this text starts on that note and ends on that note". > This is where I saw the *possibility* to do also the reverse, giving > priority to the music: Something like > > > > > > > > > > exultavit > > > > which would mean "this chunk of music here has a chunk of text > under-laid to it". > > Perry: I know that directions and lyrics are two different things. > What I meant to say is that both things can share the nature of > being a chunk of text to be aligned with a chunk of music. > > Daniel: of course your idea of using pointers is good as well. But I > though that to identify an "arbitrary" chunk of music may be also > useful. > > And this is just an idea, probably there are a hundred reasons why > this may be wrong. Let me clarify that it sprang to my mind because > of something Don mentioned, that the absence of in the > hierarchy makes it difficult for Verovio to process textual stuff in > the mensural module. Note above that is where > would be in CMN. But I may have misinterpreted his words! > > One may say that this is relevant to the effort of reproducing the > source as closely as possible, when ultimately we are supposed to > interpret where the scribe wanted us to sing each syllable. I also > believe this, but I see some good value in encoding the original, > especially if one cannot show the image. So I suppose that I need to > make one step forward and try to get both the diplomatic and the > interpretive edition: > > > ... > > > exultavit > exultavit > > > ... > > > Here I would use a pointer on to reconnect syllables with the > s they belong. [I am not sure what the remark about "@align" > means at the bottom of > http://music-encoding.org/documentation/3.0.0/syl/ -- do we have > such attribute on syl?] > > All in all, I am sure there are better methods to do this -- but I > wanted to explain what my words quoted in Don's first message implied. > > Giuliano > > > > Daniel Alles wrote on 06/03/2017 08:57: > Dear all, > > I think one of the problems (at least one of my problems while > encoding MN) is the spacing of the lyrics. It is not always clear, > which syllable belongs where, so a connection of syllables to notes > is not always given. The possibility to encode the lyrics separately > and then attach them to a staff seems unlikely too, as the syllables > would be spaced according to the rhythm off the staff (the lyrics > would only appear at the beginning of the staff, as there normally > are more notes then syllables). > > A possibility to connect not only syllables but also whole phrases > of text to phrases of notes would be really nice; something like > "this text starts on that note and ends on that note". As it is not > clear in all the cases how the underlayed text is to be sung and > therefore a spacing of the lyrics would be an editorial > intervention, a solution like @startid and @endid (or something > else) would at least represent the source material the best. > > Best, > Daniel > > > > > Zitat von Andrew Hankinson > : > > > Could someone boil down the decisions that need to be made, even > just in point form, for those of us who haven't been part of the > discussion? > > I'm afraid I don't quite understand what we're supposed to be commenting on. > > -Andrew > > > On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > > wrote: > > > Hi, > > Text underlay doesn't have anything to do with

or . > > I apologize for the confusion created by the definition of > -- it was too short and too cryptic. In the version of MEI > currently under development, verse is defined as "Division of a poem > or song lyrics; a stanza." > > The verse/syl construct is only applicable at the note level. For > musical material which is repeated, but with different > words/lyrics/sung text, provides a method of recording which > words belong with each repetition. > > > > Ooh > > > Ah > > > > For text not directly associated with individual notes, lyrics/lg > should be used instead. occurs outside the stream of > notated events; that is, inside and , although > not within or as might be required for mensural > notation. I'll correct this oversight soon. The element is, > of course, borrowed from TEI. > > For those situations where the sung text is visually separate from > the musical material, one can use -- > > > > Oh, say can you see > > > > To associate each syllable of these words with the notes, one can > add elements -- > > > > > Oh, > say > can > >you > see > > > > One may object to calling the text of a 15th century motet "lyrics", > but the same markup applies. > > -- > p. > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > Of Giuliano Di Bacco > Sent: Saturday, March 04, 2017 6:28 AM > To: Byrd, Donald A.; Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > Thanks, Don: > > I swear that I am not trying to complicate the issue further, but I > should recall that it was another moving part of the mechanism that > originated this discussions on MEI-Mens, that is, . That is, > also arbitrary segmentation/alignment of... non-arbitrary text (!) > deserves attention: > > 1 - about its use, as regard to the issue described by Don: how best > to record arbitrary (I prefer: "non standard") placement of text > underlay (alignment of chunks of text in with s), when > not possible/easy to do it with . > > 2- about its definition. This may be slightly off-topic, but > important: discussion on MEI-Mens reveals that there may be some > confusion about what is supposed to be used for. The > specifications say that this is for "lyric verse". Period. First, I > am not sure whether "verse" has to be intended as "a body of > metrical writing/poetry" or a "stanza/strophe of poetry" or a > "single line of a metrical writing" -- definitions in major > Brit+American dictionaries (and people's opinions) fluctuate between > these poles. Second, I am not sure whether "lyric" stands for the > genre (lyric poetry as opposed to narrative, epic, didactic poetry) > or generically for "the words of a song". Admittedly, in romance > languages both terms are less ambiguous than in English, so I > suppose that we just need to clarify, through a more generous > description, if is "whatever poetic text underlay" (my best > guess) or what. It would be very useful to clarify this point while > we talk about "text". The next step would be to decide if we > need/want to represent poetical structures of lower (or higher) > order (it would seem logical to me if we borrowed stuff from TEI), > and how to distinguish text underlay proper from > text-that-goes-with-these-notes but not-laid-under-the-notes, that > is, written/printed somewhere else in the page (introducing some > tag/att like "underlay" and "displaced" perhaps). But this is really > off-topic (premature) for now. > > As usual, please don't hesitate to correct me if I > misunderstood/misrepresented anything -- it would be helpful. > > Best, > > Giuliano > > > > Byrd, Donald A. wrote on 04/03/2017 01:36: > For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > Perry and I, plus other members of the mensural IG -- have been > discussing the need for annotations with arbitrary text that are > displayed on the music. Unfortunately, the discussion so far has > been scattered among several places, including the mensural IG > mailing list and Verovio GitHub issues #248 ("Directives in mensural > notation aren't drawn"), 388 ("@n for "), and especially 389 > ("implement display"). You can read #389 at > > https://github.com/rism-ch/verovio/issues/389 > > > and similarly for the other Verovio issues. Anyway, I'll try to > summarize the issues here. > > We've talked about using one of two existing tags for these > annotations, namely and . It seems clear that is > not what we want because it's specifically intended for performance > directions. As for s, of course they are currently only for > annotating the encoding, not the music, and they're not displayed in > the SVG. We could add a @visible attribute to , but the > problem then is _where_ on the music should they appear? But it > seems to me this is only a serious problem if you expect the > notation engine to position everything automatically, and that's > something that I think is completely unrealistic for complex music > regardless of annotation. I suggest visible s should have a > crudely-calculated default position, and it'd be up to the user to > specify a different position if they want. > > Giuliano has raised a related concern. He wrote yesterday that > > "[N]ot only something like for arbitrary non-lyric text is > needed, but also some arbitrary segmentation, to encapsulate > portions of music and/or lyric/non-lyric text where things happen > (such as, lyric text loosely connected with a portion of music, or > passages where the mensuration is uncertain...). > > "If I understand correctly, most of the problem with > originates from the missing level in the hierarchy (at > least this creates problems with Verovio), so I was wondering > whether the introduction of a tag at that level could be > useful. The latter, contrary to would be totally optional, > and contrary to or
would be used without any > structural meaning. > > "This is the point where we felt the need that the discussion > escalates on MEI-L. Non-structural segmentation is something that > TEI introduced lately in their schema (they call it when the > portion of text is shorter than a paragraph, and when an > 'anonymous block' of text is found that escapes from the paragraph > structure). In my experience this is one of the most useful features > when dealing with complex documents, and in past projects I used it > also to provide annotations. I wonder whether there are any reasons > for not having a -like tag available at any level." > > Giuliano's ideas make sense to me, but I don't feel very well > qualified to evaluate them. > > I'm looking forward to hearing people's thoughts on all of this! > > --Don > > > --- > Donald Byrd > Woodrow Wilson Indiana Teaching Fellow > Adjunct Associate Professor of Informatics > Visiting Scientist, Research Technologies > Indiana University Bloomington > > > > > > > > > _______________________________________________ > 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 From donbyrd at indiana.edu Mon Mar 6 22:44:06 2017 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Mon, 6 Mar 2017 21:44:06 +0000 Subject: [MEI-L] Annotations visible on the music... In-Reply-To: <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> Message-ID: <92AF24E3-17E9-4EE2-9AB4-1666857DDF31@indiana.edu> My original message mentioned two related issues: as the subject line said, "annotations visible on the music and arbitrary segmentation". But the discussion here has focused almost entirely on the latter, so let me say more about the annotations issue. My personal interest in this has nothing to do with the "arbitrary ([or] 'non standard') placement of text underlay (alignment of chunks of text in with s)" that Giuliano and Daniel have been talking about. I've attached the MEI file and corresponding SVG (from my experimental version of Verovio; you won't get this from anything public!) that brought the issue up for me in the first place. Of course, this isn't real music, just my test file. But I simply wanted to put labels on the music to say what type of mensural notation -- black, black colored, white, or white colored -- each part of the example showed, and, to my surprise, I couldn't find anything better than to do it with. NB that I ran this with the "--even-note-spacing" argument, so the wide spacing after the maximas has nothing to do with their duration; it's just because Verovio understandably thought the s were lyrics, requiring their own space before the next note. I actually think this is a pretty simple question. As I said when I started this thread, s "are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and I think expecting good results from that is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want." I think Perry agreed in one of his recent messages, though I can't find it now. While the attached example is what led _me_ to think about this, it was Craig who opened Issue #389, where much of the previous discussion occurred. He suggested visible "would function in a very similar manner to the current implementation, but both should add horizontal collision avoidance between adjacent and entries (similar to the current implementation of ." But there was much more discussion on the Issue #389 page ( (https://github.com/rism-ch/verovio/issues/389), which I won't try to summarize here. I strongly recommend that anyone interested read that. --DAB > Zitat von Andrew Hankinson : > >> Could someone boil down the decisions that need to be made, even just in point form, for those of us who haven't been part of the discussion? >> >> I'm afraid I don't quite understand what we're supposed to be commenting on. >> >> -Andrew >> >>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) wrote: >>> >>> Hi, >>> >>> Text underlay doesn't have anything to do with or . >>> >>> I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." >>> >>> The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. >>> >>> >>> >>> Ooh >>> >>> >>> Ah >>> >>> >>> >>> For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. >>> >>> For those situations where the sung text is visually separate from the musical material, one can use -- >>> >>> >>> >>> Oh, say can you see >>> >>> >>> >>> To associate each syllable of these words with the notes, one can add elements -- >>> >>> >>> >>> >>> Oh, >>> say >>> can >>> >you >>> see >>> >>> >>> >>> One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. >>> >>> -- >>> p. >>> >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco >>> Sent: Saturday, March 04, 2017 6:28 AM >>> To: Byrd, Donald A.; Music Encoding Initiative >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation >>> >>> Thanks, Don: >>> >>> I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: >>> >>> 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . >>> >>> 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. >>> >>> As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. >>> >>> Best, >>> >>> Giuliano >>> >>> >>> >>> Byrd, Donald A. wrote on 04/03/2017 01:36: >>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at >>> >>> https://github.com/rism-ch/verovio/issues/389 >>> >>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. >>> >>> We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. >>> >>> Giuliano has raised a related concern. He wrote yesterday that >>> >>> "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). >>> >>> "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. >>> >>> "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." >>> >>> Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. >>> >>> I'm looking forward to hearing people's thoughts on all of this! >>> >>> --Don >>> >>> >>> >>> > > > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: AllMensuralDurs.mei Type: application/octet-stream Size: 6080 bytes Desc: AllMensuralDurs.mei URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AllMensuralDurs.svg Type: image/svg+xml Size: 18561 bytes Desc: AllMensuralDurs.svg URL: From gdibacco at indiana.edu Mon Mar 6 22:46:45 2017 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Mon, 6 Mar 2017 22:46:45 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> Message-ID: <07db8f72-527d-e6ab-8fc9-18ea2748ba50@indiana.edu> An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Mon Mar 6 23:25:17 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 22:25:17 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <07db8f72-527d-e6ab-8fc9-18ea2748ba50@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> <07db8f72-527d-e6ab-8fc9-18ea2748ba50@indiana.edu> Message-ID: Comments below -- -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Monday, March 06, 2017 4:47 PM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Thank you Perry. Not to insist -- at all -- but just to understand: You are right about the need of going down in the hierarchy when the segment is not the same for all staves. Well, I thought that we could go down as needed: segments on one staff (or layer) would work independently from each other. Why not? (Apart from upsetting Verovio perhaps.) As for your objection that in multiple staves (or layers) we wouldn't know how to indicate which layer or staff the lyrics are attached to, I thought @staff and @layer were there for that purpose. Am I missing something? [PR: ] As long as there's no ambiguity or disagreement in the attachment of the lyrics to a , everything is fine. But if I say the words are attached to the first 3 notes and you say that they're attached to 3 notes beginning with my 2nd one, we have a problem -- Overlapping hierarchies like this aren't permitted in XML. One could require that the segments be independently (and, at the note level, redundantly) encoded -- But I hope you can see how this can quickly lead to other problems. Stand-off markup is the better option. I see how one can align all the children of pointing out from them ( ). But what if, as I think Daniel wanted, the task is to have a pointer that points out from a string of one, two or more words (less than a line, more than a syllable)? can we record a more arbitrary chunk of text? [PR: ] The definition of a line of text is already pretty arbitrary as far as I'm concerned, but yes, could be added within to capture a group of related syllables or words. Another option would be to use a more specific element than in the first place, probably not , but you get the idea. I do agree on the use of a pointer more specific than @corresp, but again if you are pointing from the text to somewhere, and the "elsewhere" is not a single note but a group of notes, where do you put the xml:id to point to? I would say that to use @sync you would still need a container grouping that chunk of notes. If we don't want a container, I guess we need a start/end attribute pair. [PR: ] This is a valid observation. I think we'd have to provide @plist in addition to @startid and @endid, so that rather than pointing to a group of notes, one can indicate each of the notes that participates in the (virtual) group. The fact that @plist doesn't fit the character of our repurposed TEI and elements is yet another reason to create a purpose-specific element instead of using the lyrics/lg/l hierarchy. At the end of the day, any working solution will... work. But the conversation started with a prompt by Don about difficulties in text management in Verovio, so ultimately we should only make sure that we know how to make our friend Verovio happy. [PR: ] I don't believe text management is particularly difficult in Verovio. One can attach text of any type to a staff or layer, almost anywhere using . The problem is that doesn't provide an accurate name for the thing we're trying to model. So, just come up with a name that isn't , , , , , etc. Giuliano Roland, Perry D. (pdr4h) wrote on 06/03/2017 16:41: The approach Giuliano suggests may work for single-staff notation, but it won't work for music on multiple staves because the segment boundary would have to be the same for all staves. Unless the total duration of the segment is the same in all layers of all the staves (which is likely not to be the case because of the polyphonic style with which mensural notation is usually associated), then the following won't work -- Also, in the case of multiple staves, to which staff are the lyrics to be attached? Even if were used lower in the hierarchy, say at the layer level -- the same problem would persist. The only possibility left is to forego segmentation other than that of and and associate text directly with events via @synch -- Hmmm? This method works regardless of where the element is actually placed, be it inside , , or elsewhere. It can be extended to if necessary -- Hmm? Say what? In case you're wondering why @synch and not @startid -- I know it's somewhat arbitrary, but @startid is reserved for musical events (like , , and such) that are attached to other musical events, while @synch (borrowed from TEI) is used on elements that may or may not be musical events (,

, ). If a new element for performed text that was always a musical event were created, then it would use @startid instead of @synch. > I am not sure what the remark about "@align" means at the bottom of http://music-encoding.org/documentation/3.0.0/syl/ -- do we have such attribute on syl? That's an error which has been fixed in the development version. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Monday, March 06, 2017 6:17 AM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Daniel Alles wrote on 06/03/2017 08:57: "this text starts on that note and ends on that note". This is where I saw the *possibility* to do also the reverse, giving priority to the music: Something like exultavit which would mean "this chunk of music here has a chunk of text under-laid to it". Perry: I know that directions and lyrics are two different things. What I meant to say is that both things can share the nature of being a chunk of text to be aligned with a chunk of music. Daniel: of course your idea of using pointers is good as well. But I though that to identify an "arbitrary" chunk of music may be also useful. And this is just an idea, probably there are a hundred reasons why this may be wrong. Let me clarify that it sprang to my mind because of something Don mentioned, that the absence of in the hierarchy makes it difficult for Verovio to process textual stuff in the mensural module. Note above that is where would be in CMN. But I may have misinterpreted his words! One may say that this is relevant to the effort of reproducing the source as closely as possible, when ultimately we are supposed to interpret where the scribe wanted us to sing each syllable. I also believe this, but I see some good value in encoding the original, especially if one cannot show the image. So I suppose that I need to make one step forward and try to get both the diplomatic and the interpretive edition: ... exultavit exultavit ... Here I would use a pointer on to reconnect syllables with the s they belong. [I am not sure what the remark about "@align" means at the bottom of http://music-encoding.org/documentation/3.0.0/syl/ -- do we have such attribute on syl?] All in all, I am sure there are better methods to do this -- but I wanted to explain what my words quoted in Don's first message implied. Giuliano Daniel Alles wrote on 06/03/2017 08:57: Dear all, I think one of the problems (at least one of my problems while encoding MN) is the spacing of the lyrics. It is not always clear, which syllable belongs where, so a connection of syllables to notes is not always given. The possibility to encode the lyrics separately and then attach them to a staff seems unlikely too, as the syllables would be spaced according to the rhythm off the staff (the lyrics would only appear at the beginning of the staff, as there normally are more notes then syllables). A possibility to connect not only syllables but also whole phrases of text to phrases of notes would be really nice; something like "this text starts on that note and ends on that note". As it is not clear in all the cases how the underlayed text is to be sung and therefore a spacing of the lyrics would be an editorial intervention, a solution like @startid and @endid (or something else) would at least represent the source material the best. Best, Daniel Zitat von Andrew Hankinson : Could someone boil down the decisions that need to be made, even just in point form, for those of us who haven't been part of the discussion? I'm afraid I don't quite understand what we're supposed to be commenting on. -Andrew On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) wrote: Hi, Text underlay doesn't have anything to do with

or . I apologize for the confusion created by the definition of -- it was too short and too cryptic. In the version of MEI currently under development, verse is defined as "Division of a poem or song lyrics; a stanza." The verse/syl construct is only applicable at the note level. For musical material which is repeated, but with different words/lyrics/sung text, provides a method of recording which words belong with each repetition. Ooh Ah For text not directly associated with individual notes, lyrics/lg should be used instead. occurs outside the stream of notated events; that is, inside and , although not within or as might be required for mensural notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. For those situations where the sung text is visually separate from the musical material, one can use -- Oh, say can you see To associate each syllable of these words with the notes, one can add elements -- Oh, say can >you see One may object to calling the text of a 15th century motet "lyrics", but the same markup applies. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Giuliano Di Bacco Sent: Saturday, March 04, 2017 6:28 AM To: Byrd, Donald A.; Music Encoding Initiative Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation Thanks, Don: I swear that I am not trying to complicate the issue further, but I should recall that it was another moving part of the mechanism that originated this discussions on MEI-Mens, that is, . That is, also arbitrary segmentation/alignment of... non-arbitrary text (!) deserves attention: 1 - about its use, as regard to the issue described by Don: how best to record arbitrary (I prefer: "non standard") placement of text underlay (alignment of chunks of text in with s), when not possible/easy to do it with . 2- about its definition. This may be slightly off-topic, but important: discussion on MEI-Mens reveals that there may be some confusion about what is supposed to be used for. The specifications say that this is for "lyric verse". Period. First, I am not sure whether "verse" has to be intended as "a body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" -- definitions in major Brit+American dictionaries (and people's opinions) fluctuate between these poles. Second, I am not sure whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, didactic poetry) or generically for "the words of a song". Admittedly, in romance languages both terms are less ambiguous than in English, so I suppose that we just need to clarify, through a more generous description, if is "whatever poetic text underlay" (my best guess) or what. It would be very useful to clarify this point while we talk about "text". The next step would be to decide if we need/want to represent poetical structures of lower (or higher) order (it would seem logical to me if we borrowed stuff from TEI), and how to distinguish text underlay proper from text-that-goes-with-these-notes but not-laid-under-the-notes, that is, written/printed somewhere else in the page (introducing some tag/att like "underlay" and "displaced" perhaps). But this is really off-topic (premature) for now. As usual, please don't hesitate to correct me if I misunderstood/misrepresented anything -- it would be helpful. Best, Giuliano Byrd, Donald A. wrote on 04/03/2017 01:36: For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, Perry and I, plus other members of the mensural IG -- have been discussing the need for annotations with arbitrary text that are displayed on the music. Unfortunately, the discussion so far has been scattered among several places, including the mensural IG mailing list and Verovio GitHub issues #248 ("Directives in mensural notation aren't drawn"), 388 ("@n for "), and especially 389 ("implement display"). You can read #389 at https://github.com/rism-ch/verovio/issues/389 and similarly for the other Verovio issues. Anyway, I'll try to summarize the issues here. We've talked about using one of two existing tags for these annotations, namely and . It seems clear that is not what we want because it's specifically intended for performance directions. As for s, of course they are currently only for annotating the encoding, not the music, and they're not displayed in the SVG. We could add a @visible attribute to , but the problem then is _where_ on the music should they appear? But it seems to me this is only a serious problem if you expect the notation engine to position everything automatically, and that's something that I think is completely unrealistic for complex music regardless of annotation. I suggest visible s should have a crudely-calculated default position, and it'd be up to the user to specify a different position if they want. Giuliano has raised a related concern. He wrote yesterday that "[N]ot only something like for arbitrary non-lyric text is needed, but also some arbitrary segmentation, to encapsulate portions of music and/or lyric/non-lyric text where things happen (such as, lyric text loosely connected with a portion of music, or passages where the mensuration is uncertain...). "If I understand correctly, most of the problem with originates from the missing level in the hierarchy (at least this creates problems with Verovio), so I was wondering whether the introduction of a tag at that level could be useful. The latter, contrary to would be totally optional, and contrary to or
would be used without any structural meaning. "This is the point where we felt the need that the discussion escalates on MEI-L. Non-structural segmentation is something that TEI introduced lately in their schema (they call it when the portion of text is shorter than a paragraph, and when an 'anonymous block' of text is found that escapes from the paragraph structure). In my experience this is one of the most useful features when dealing with complex documents, and in past projects I used it also to provide annotations. I wonder whether there are any reasons for not having a -like tag available at any level." Giuliano's ideas make sense to me, but I don't feel very well qualified to evaluate them. I'm looking forward to hearing people's thoughts on all of this! --Don --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington _______________________________________________ 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: From pdr4h at eservices.virginia.edu Mon Mar 6 23:50:25 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 22:50:25 +0000 Subject: [MEI-L] Annotations visible on the music... In-Reply-To: <92AF24E3-17E9-4EE2-9AB4-1666857DDF31@indiana.edu> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <92AF24E3-17E9-4EE2-9AB4-1666857DDF31@indiana.edu> Message-ID: Don, There's no reason to abuse verse/syl to attach non-sung text to a note. Abuse instead. :-) Or better yet, suggest a new element for holding such text. Using @tstamp on to make the association is appropriate for CMN but not for mensural notation, so use @startid. The element doesn't have to go inside or . Since there's only one note with the xml:id of "n1", can be placed anywhere in the field, although inside is probably the best location -- black colored testing -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, > Donald A. > Sent: Monday, March 06, 2017 4:44 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music... > > My original message mentioned two related issues: as the subject line said, > "annotations visible on the music and arbitrary segmentation". But the > discussion here has focused almost entirely on the latter, so let me say more > about the annotations issue. > > My personal interest in this has nothing to do with the "arbitrary ([or] 'non > standard') placement of text underlay (alignment of chunks of text in > with s)" that Giuliano and Daniel have been talking about. I've attached > the MEI file and corresponding SVG (from my experimental version of Verovio; > you won't get this from anything public!) that brought the issue up for me in > the first place. Of course, this isn't real music, just my test file. But I simply > wanted to put labels on the music to say what type of mensural notation -- > black, black colored, white, or white colored -- each part of the example > showed, and, to my surprise, I couldn't find anything better than to do it > with. NB that I ran this with the "--even-note-spacing" argument, so the wide > spacing after the maximas has nothing to do with their duration; it's just > because Verovio understandably thought the s were lyrics, requiring their > own space before the next note. > > I actually think this is a pretty simple question. As I said when I started this > thread, s "are currently only for annotating the encoding, not the > music, and they're not displayed in the SVG. We could add a @visible attribute > to , but the problem then is _where_ on the music should they > appear? But it seems to me this is only a serious problem if you expect the > notation engine to position everything automatically, and I think expecting > good results from that is completely unrealistic for complex music regardless of > annotation. I suggest visible s should have a crudely-calculated default > position, and it'd be up to the user to specify a different position if they want." > I think Perry agreed in one of his recent messages, though I can't find it now. > While the attached example is what led _me_ to think about this, it was Craig > who opened Issue #389, where much of the previous discussion occurred. He > suggested visible "would function in a very similar manner to the > current implementation, but both should add horizontal collision > avoidance between adjacent and entries (similar to the > current implementation of ." But there was much more discussion on > the Issue #389 page ( (https://github.com/rism-ch/verovio/issues/389), which I > won't try to summarize here. I strongly recommend that anyone interested > read that. > > --DAB > > > > Zitat von Andrew Hankinson : > > > >> Could someone boil down the decisions that need to be made, even just in > point form, for those of us who haven't been part of the discussion? > >> > >> I'm afraid I don't quite understand what we're supposed to be commenting > on. > >> > >> -Andrew > >> > >>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > wrote: > >>> > >>> Hi, > >>> > >>> Text underlay doesn't have anything to do with or . > >>> > >>> I apologize for the confusion created by the definition of -- it was > too short and too cryptic. In the version of MEI currently under development, > verse is defined as "Division of a poem or song lyrics; a stanza." > >>> > >>> The verse/syl construct is only applicable at the note level. For musical > material which is repeated, but with different words/lyrics/sung text, > provides a method of recording which words belong with each repetition. > >>> > >>> > >>> > >>> Ooh > >>> > >>> > >>> Ah > >>> > >>> > >>> > >>> For text not directly associated with individual notes, lyrics/lg should be > used instead. occurs outside the stream of notated events; that is, > inside and , although not within or as > might be required for mensural notation. I'll correct this oversight soon. The > element is, of course, borrowed from TEI. > >>> > >>> For those situations where the sung text is visually separate from > >>> the musical material, one can use -- > >>> > >>> > >>> > >>> Oh, say can you see > >>> > >>> > >>> > >>> To associate each syllable of these words with the notes, one can > >>> add elements -- > >>> > >>> > >>> > >>> > >>> Oh, > >>> say > >>> can > >>> >you > >>> see > >>> > >>> > >>> > >>> One may object to calling the text of a 15th century motet "lyrics", but the > same markup applies. > >>> > >>> -- > >>> p. > >>> > >>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >>> Of Giuliano Di Bacco > >>> Sent: Saturday, March 04, 2017 6:28 AM > >>> To: Byrd, Donald A.; Music Encoding Initiative > >>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > >>> segmentation > >>> > >>> Thanks, Don: > >>> > >>> I swear that I am not trying to complicate the issue further, but I should > recall that it was another moving part of the mechanism that originated this > discussions on MEI-Mens, that is, . That is, also arbitrary > segmentation/alignment of... non-arbitrary text (!) deserves attention: > >>> > >>> 1 - about its use, as regard to the issue described by Don: how best to > record arbitrary (I prefer: "non standard") placement of text underlay > (alignment of chunks of text in with s), when not possible/easy > to do it with . > >>> > >>> 2- about its definition. This may be slightly off-topic, but important: > discussion on MEI-Mens reveals that there may be some confusion about what > is supposed to be used for. The specifications say that this is for "lyric > verse". Period. First, I am not sure whether "verse" has to be intended as "a > body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single > line of a metrical writing" -- definitions in major Brit+American dictionaries (and > people's opinions) fluctuate between these poles. Second, I am not sure > whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, > didactic poetry) or generically for "the words of a song". Admittedly, in > romance languages both terms are less ambiguous than in English, so I suppose > that we just need to clarify, through a more generous description, if is > "whatever poetic text underlay" (my best guess) or what. It would be very > useful to clarify this point while we talk about "text". The next step would be > to decide if we need/want to represent poetical structures of lower (or higher) > order (it would seem logical to me if we borrowed stuff from TEI), and how to > distinguish text underlay proper from text-that-goes-with-these-notes but not- > laid-under-the-notes, that is, written/printed somewhere else in the page > (introducing some tag/att like "underlay" and "displaced" perhaps). But this is > really off-topic (premature) for now. > >>> > >>> As usual, please don't hesitate to correct me if I > misunderstood/misrepresented anything -- it would be helpful. > >>> > >>> Best, > >>> > >>> Giuliano > >>> > >>> > >>> > >>> Byrd, Donald A. wrote on 04/03/2017 01:36: > >>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > >>> Perry and I, plus other members of the mensural IG -- have been > >>> discussing the need for annotations with arbitrary text that are > >>> displayed on the music. Unfortunately, the discussion so far has > >>> been scattered among several places, including the mensural IG > >>> mailing list and Verovio GitHub issues #248 ("Directives in mensural > >>> notation aren't drawn"), 388 ("@n for "), and especially 389 > >>> ("implement display"). You can read #389 at > >>> > >>> https://github.com/rism-ch/verovio/issues/389 > >>> > >>> > >>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the > issues here. > >>> > >>> We've talked about using one of two existing tags for these annotations, > namely and . It seems clear that is not what we want > because it's specifically intended for performance directions. As for s, > of course they are currently only for annotating the encoding, not the music, > and they're not displayed in the SVG. We could add a @visible attribute to > , but the problem then is _where_ on the music should they appear? > But it seems to me this is only a serious problem if you expect the notation > engine to position everything automatically, and that's something that I think > is completely unrealistic for complex music regardless of annotation. I suggest > visible s should have a crudely-calculated default position, and it'd be > up to the user to specify a different position if they want. > >>> > >>> Giuliano has raised a related concern. He wrote yesterday that > >>> > >>> "[N]ot only something like for arbitrary non-lyric text is needed, but > also some arbitrary segmentation, to encapsulate portions of music and/or > lyric/non-lyric text where things happen (such as, lyric text loosely connected > with a portion of music, or passages where the mensuration is uncertain...). > >>> > >>> "If I understand correctly, most of the problem with originates from > the missing level in the hierarchy (at least this creates problems > with Verovio), so I was wondering whether the introduction of a tag > at that level could be useful. The latter, contrary to > would be totally optional, and contrary to or
would be > used without any structural meaning. > >>> > >>> "This is the point where we felt the need that the discussion escalates on > MEI-L. Non-structural segmentation is something that TEI introduced lately in > their schema (they call it when the portion of text is shorter than a > paragraph, and when an 'anonymous block' of text is found that escapes > from the paragraph structure). In my experience this is one of the most useful > features when dealing with complex documents, and in past projects I used it > also to provide annotations. I wonder whether there are any reasons for not > having a -like tag available at any level." > >>> > >>> Giuliano's ideas make sense to me, but I don't feel very well qualified to > evaluate them. > >>> > >>> I'm looking forward to hearing people's thoughts on all of this! > >>> > >>> --Don > >>> > >>> > >>> > >>> > > > > > > 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 > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: AllMensuralDurs.mei Type: application/octet-stream Size: 5045 bytes Desc: AllMensuralDurs.mei URL: From pdr4h at eservices.virginia.edu Mon Mar 6 23:53:08 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 6 Mar 2017 22:53:08 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <20170306223927.Horde.uBPGp53L7i_GpnRrZoJIY0F@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <9beee914-1002-98bc-c2c1-432bedc9943c@indiana.edu> <20170306223927.Horde.uBPGp53L7i_GpnRrZoJIY0F@webmail.server.uni-frankfurt.de> Message-ID: Hi Daniel, Yes, @synch only provides a *point of synchronization*. But rather than add @startid and @endid on text elements borrowed from TEI, I'd rather the mensural group came up with a new MEI element that can express these semantics. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel > Alles > Sent: Monday, March 06, 2017 4:40 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > Maybe I understand it wrong, but I have a problem with @synch: Does it only > give me a starting-point for the text? Wouldn't then the text be associated to > only one note and not to the whole line it is written under? That was why I > suggested @startid AND @endid (or something similar), which would (in my > imagination) span a widely spread word wider in the layout, if necessary, just > like it does with slurs. > > Daniel > > > > Zitat von "Roland, Perry D. (pdr4h)" : > > > The approach Giuliano suggests may work for single-staff notation, but > > it won't work for music on multiple staves because the segment > > boundary would have to be the same for all staves. Unless the total > > duration of the segment is the same in all layers of all the staves > > (which is likely not to be the case because of the polyphonic style > > with which mensural notation is usually associated), then the > > following won't work -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, in the case of multiple staves, to which staff are the lyrics to > > be attached? > > > > Even if were used lower in the hierarchy, say at the layer > > level -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the same problem would persist. > > > > The only possibility left is to forego segmentation other than that of > > and and associate text directly with events via @synch > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hmmm? > > > > > > > > > > This method works regardless of where the element is actually > > placed, be it inside , , or elsewhere. It can be > > extended to if necessary -- > > > > Hmm? Say what? > > > > In case you're wondering why @synch and not @startid -- I know it's > > somewhat arbitrary, but @startid is reserved for musical events (like > > , , and such) that are attached to other musical > > events, while @synch (borrowed from TEI) is used on elements that may > > or may not be musical events (,

, ). If a new element for > > performed text that was always a musical event were created, then it > > would use @startid instead of @synch. > > > >> I am not sure what the remark about "@align" means at the bottom of > >> http://music-encoding.org/documentation/3.0.0/syl/ -- do we have > >> such attribute on syl? > > > > That's an error which has been fixed in the development version. > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Giuliano Di Bacco > > Sent: Monday, March 06, 2017 6:17 AM > > To: mei-l at lists.uni-paderborn.de > > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > > segmentation > > > > > > Daniel Alles wrote on 06/03/2017 08:57: > > "this text starts on that note and ends on that note". > > This is where I saw the *possibility* to do also the reverse, giving > > priority to the music: Something like > > > > > > > > > > > > > > > > > > > > exultavit > > > > > > > > which would mean "this chunk of music here has a chunk of text > > under-laid to it". > > > > Perry: I know that directions and lyrics are two different things. > > What I meant to say is that both things can share the nature of > > being a chunk of text to be aligned with a chunk of music. > > > > Daniel: of course your idea of using pointers is good as well. But I > > though that to identify an "arbitrary" chunk of music may be also > > useful. > > > > And this is just an idea, probably there are a hundred reasons why > > this may be wrong. Let me clarify that it sprang to my mind because > > of something Don mentioned, that the absence of in the > > hierarchy makes it difficult for Verovio to process textual stuff in > > the mensural module. Note above that is where > > would be in CMN. But I may have misinterpreted his words! > > > > One may say that this is relevant to the effort of reproducing the > > source as closely as possible, when ultimately we are supposed to > > interpret where the scribe wanted us to sing each syllable. I also > > believe this, but I see some good value in encoding the original, > > especially if one cannot show the image. So I suppose that I need to > > make one step forward and try to get both the diplomatic and the > > interpretive edition: > > > > > > ... > > > > > > exultavit > > exultavit > > > > > > ... > > > > > > Here I would use a pointer on to reconnect syllables with the > > s they belong. [I am not sure what the remark about "@align" > > means at the bottom of > > http://music-encoding.org/documentation/3.0.0/syl/ -- do we have > > such attribute on syl?] > > > > All in all, I am sure there are better methods to do this -- but I > > wanted to explain what my words quoted in Don's first message implied. > > > > Giuliano > > > > > > > > Daniel Alles wrote on 06/03/2017 08:57: > > Dear all, > > > > I think one of the problems (at least one of my problems while > > encoding MN) is the spacing of the lyrics. It is not always clear, > > which syllable belongs where, so a connection of syllables to notes > > is not always given. The possibility to encode the lyrics separately > > and then attach them to a staff seems unlikely too, as the syllables > > would be spaced according to the rhythm off the staff (the lyrics > > would only appear at the beginning of the staff, as there normally > > are more notes then syllables). > > > > A possibility to connect not only syllables but also whole phrases > > of text to phrases of notes would be really nice; something like > > "this text starts on that note and ends on that note". As it is not > > clear in all the cases how the underlayed text is to be sung and > > therefore a spacing of the lyrics would be an editorial > > intervention, a solution like @startid and @endid (or something > > else) would at least represent the source material the best. > > > > Best, > > Daniel > > > > > > > > > > Zitat von Andrew Hankinson > > > >: > > > > > > Could someone boil down the decisions that need to be made, even > > just in point form, for those of us who haven't been part of the > > discussion? > > > > I'm afraid I don't quite understand what we're supposed to be commenting > on. > > > > -Andrew > > > > > > On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > > > > wrote: > > > > > > Hi, > > > > Text underlay doesn't have anything to do with

or . > > > > I apologize for the confusion created by the definition of > > -- it was too short and too cryptic. In the version of MEI > > currently under development, verse is defined as "Division of a poem > > or song lyrics; a stanza." > > > > The verse/syl construct is only applicable at the note level. For > > musical material which is repeated, but with different > > words/lyrics/sung text, provides a method of recording which > > words belong with each repetition. > > > > > > > > Ooh > > > > > > Ah > > > > > > > > For text not directly associated with individual notes, lyrics/lg > > should be used instead. occurs outside the stream of > > notated events; that is, inside and , although > > not within or as might be required for mensural > > notation. I'll correct this oversight soon. The element is, > > of course, borrowed from TEI. > > > > For those situations where the sung text is visually separate from > > the musical material, one can use -- > > > > > > > > Oh, say can you see > > > > > > > > To associate each syllable of these words with the notes, one can > > add elements -- > > > > > > > > > > Oh, > > say > > can > > >you > > see > > > > > > > > One may object to calling the text of a 15th century motet "lyrics", > > but the same markup applies. > > > > -- > > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > > Of Giuliano Di Bacco > > Sent: Saturday, March 04, 2017 6:28 AM > > To: Byrd, Donald A.; Music Encoding Initiative > > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > > segmentation > > > > Thanks, Don: > > > > I swear that I am not trying to complicate the issue further, but I > > should recall that it was another moving part of the mechanism that > > originated this discussions on MEI-Mens, that is, . That is, > > also arbitrary segmentation/alignment of... non-arbitrary text (!) > > deserves attention: > > > > 1 - about its use, as regard to the issue described by Don: how best > > to record arbitrary (I prefer: "non standard") placement of text > > underlay (alignment of chunks of text in with s), when > > not possible/easy to do it with . > > > > 2- about its definition. This may be slightly off-topic, but > > important: discussion on MEI-Mens reveals that there may be some > > confusion about what is supposed to be used for. The > > specifications say that this is for "lyric verse". Period. First, I > > am not sure whether "verse" has to be intended as "a body of > > metrical writing/poetry" or a "stanza/strophe of poetry" or a > > "single line of a metrical writing" -- definitions in major > > Brit+American dictionaries (and people's opinions) fluctuate between > > these poles. Second, I am not sure whether "lyric" stands for the > > genre (lyric poetry as opposed to narrative, epic, didactic poetry) > > or generically for "the words of a song". Admittedly, in romance > > languages both terms are less ambiguous than in English, so I > > suppose that we just need to clarify, through a more generous > > description, if is "whatever poetic text underlay" (my best > > guess) or what. It would be very useful to clarify this point while > > we talk about "text". The next step would be to decide if we > > need/want to represent poetical structures of lower (or higher) > > order (it would seem logical to me if we borrowed stuff from TEI), > > and how to distinguish text underlay proper from > > text-that-goes-with-these-notes but not-laid-under-the-notes, that > > is, written/printed somewhere else in the page (introducing some > > tag/att like "underlay" and "displaced" perhaps). But this is really > > off-topic (premature) for now. > > > > As usual, please don't hesitate to correct me if I > > misunderstood/misrepresented anything -- it would be helpful. > > > > Best, > > > > Giuliano > > > > > > > > Byrd, Donald A. wrote on 04/03/2017 01:36: > > For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > > Perry and I, plus other members of the mensural IG -- have been > > discussing the need for annotations with arbitrary text that are > > displayed on the music. Unfortunately, the discussion so far has > > been scattered among several places, including the mensural IG > > mailing list and Verovio GitHub issues #248 ("Directives in mensural > > notation aren't drawn"), 388 ("@n for "), and especially 389 > > ("implement display"). You can read #389 at > > > > https://github.com/rism-ch/verovio/issues/389 > > ch/verovio/issues/389> > > > > and similarly for the other Verovio issues. Anyway, I'll try to > > summarize the issues here. > > > > We've talked about using one of two existing tags for these > > annotations, namely and . It seems clear that is > > not what we want because it's specifically intended for performance > > directions. As for s, of course they are currently only for > > annotating the encoding, not the music, and they're not displayed in > > the SVG. We could add a @visible attribute to , but the > > problem then is _where_ on the music should they appear? But it > > seems to me this is only a serious problem if you expect the > > notation engine to position everything automatically, and that's > > something that I think is completely unrealistic for complex music > > regardless of annotation. I suggest visible s should have a > > crudely-calculated default position, and it'd be up to the user to > > specify a different position if they want. > > > > Giuliano has raised a related concern. He wrote yesterday that > > > > "[N]ot only something like for arbitrary non-lyric text is > > needed, but also some arbitrary segmentation, to encapsulate > > portions of music and/or lyric/non-lyric text where things happen > > (such as, lyric text loosely connected with a portion of music, or > > passages where the mensuration is uncertain...). > > > > "If I understand correctly, most of the problem with > > originates from the missing level in the hierarchy (at > > least this creates problems with Verovio), so I was wondering > > whether the introduction of a tag at that level could be > > useful. The latter, contrary to would be totally optional, > > and contrary to or
would be used without any > > structural meaning. > > > > "This is the point where we felt the need that the discussion > > escalates on MEI-L. Non-structural segmentation is something that > > TEI introduced lately in their schema (they call it when the > > portion of text is shorter than a paragraph, and when an > > 'anonymous block' of text is found that escapes from the paragraph > > structure). In my experience this is one of the most useful features > > when dealing with complex documents, and in past projects I used it > > also to provide annotations. I wonder whether there are any reasons > > for not having a -like tag available at any level." > > > > Giuliano's ideas make sense to me, but I don't feel very well > > qualified to evaluate them. > > > > I'm looking forward to hearing people's thoughts on all of this! > > > > --Don > > > > > > --- > > Donald Byrd > > Woodrow Wilson Indiana Teaching Fellow > > Adjunct Associate Professor of Informatics > > Visiting Scientist, Research Technologies > > Indiana University Bloomington > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 From donbyrd at indiana.edu Tue Mar 7 01:25:33 2017 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Tue, 7 Mar 2017 00:25:33 +0000 Subject: [MEI-L] Annotations visible on the music... In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <92AF24E3-17E9-4EE2-9AB4-1666857DDF31@indiana.edu> Message-ID: On Mar 6, 2017, at 5:50 PM, "Roland, Perry D. (pdr4h)" wrote: > Don, > > There's no reason to abuse verse/syl to attach non-sung text to a note. Abuse instead. :-) I'd be (reasonably) happy to do that, but doesn't work on mensural notation; as Laurent put it, "There is.. an issue with in mensural mode." By "mensural mode", I assume he means on staves with notation.type mensural, but I'm not sure. And he says making it work within will be really tricky. Laurent? > Or better yet, suggest a new element for holding such text. I just suggested an old element -- -- with a new attribute -- @visible -- and I thought you thought that was a good idea! No? --DAB > Using @tstamp on to make the association is appropriate for CMN but not for mensural notation, so use @startid. The element doesn't have to go inside or . Since there's only one note with the xml:id of "n1", can be placed anywhere in the field, although inside is probably the best location -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > black > colored > testing > > > -- > p. > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, >> Donald A. >> Sent: Monday, March 06, 2017 4:44 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Annotations visible on the music... >> >> My original message mentioned two related issues: as the subject line said, >> "annotations visible on the music and arbitrary segmentation". But the >> discussion here has focused almost entirely on the latter, so let me say more >> about the annotations issue. >> >> My personal interest in this has nothing to do with the "arbitrary ([or] 'non >> standard') placement of text underlay (alignment of chunks of text in >> with s)" that Giuliano and Daniel have been talking about. I've attached >> the MEI file and corresponding SVG (from my experimental version of Verovio; >> you won't get this from anything public!) that brought the issue up for me in >> the first place. Of course, this isn't real music, just my test file. But I simply >> wanted to put labels on the music to say what type of mensural notation -- >> black, black colored, white, or white colored -- each part of the example >> showed, and, to my surprise, I couldn't find anything better than to do it >> with. NB that I ran this with the "--even-note-spacing" argument, so the wide >> spacing after the maximas has nothing to do with their duration; it's just >> because Verovio understandably thought the s were lyrics, requiring their >> own space before the next note. >> >> I actually think this is a pretty simple question. As I said when I started this >> thread, s "are currently only for annotating the encoding, not the >> music, and they're not displayed in the SVG. We could add a @visible attribute >> to , but the problem then is _where_ on the music should they >> appear? But it seems to me this is only a serious problem if you expect the >> notation engine to position everything automatically, and I think expecting >> good results from that is completely unrealistic for complex music regardless of >> annotation. I suggest visible s should have a crudely-calculated default >> position, and it'd be up to the user to specify a different position if they want." >> I think Perry agreed in one of his recent messages, though I can't find it now. >> While the attached example is what led _me_ to think about this, it was Craig >> who opened Issue #389, where much of the previous discussion occurred. He >> suggested visible "would function in a very similar manner to the >> current implementation, but both should add horizontal collision >> avoidance between adjacent and entries (similar to the >> current implementation of ." But there was much more discussion on >> the Issue #389 page ( (https://github.com/rism-ch/verovio/issues/389), which I >> won't try to summarize here. I strongly recommend that anyone interested >> read that. >> >> --DAB >> >> >>> Zitat von Andrew Hankinson : >>> >>>> Could someone boil down the decisions that need to be made, even just in >> point form, for those of us who haven't been part of the discussion? >>>> >>>> I'm afraid I don't quite understand what we're supposed to be commenting >> on. >>>> >>>> -Andrew >>>> >>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) >> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Text underlay doesn't have anything to do with or . >>>>> >>>>> I apologize for the confusion created by the definition of -- it was >> too short and too cryptic. In the version of MEI currently under development, >> verse is defined as "Division of a poem or song lyrics; a stanza." >>>>> >>>>> The verse/syl construct is only applicable at the note level. For musical >> material which is repeated, but with different words/lyrics/sung text, >> provides a method of recording which words belong with each repetition. >>>>> >>>>> >>>>> >>>>> Ooh >>>>> >>>>> >>>>> Ah >>>>> >>>>> >>>>> >>>>> For text not directly associated with individual notes, lyrics/lg should be >> used instead. occurs outside the stream of notated events; that is, >> inside and , although not within or as >> might be required for mensural notation. I'll correct this oversight soon. The >> element is, of course, borrowed from TEI. >>>>> >>>>> For those situations where the sung text is visually separate from >>>>> the musical material, one can use -- >>>>> >>>>> >>>>> >>>>> Oh, say can you see >>>>> >>>>> >>>>> >>>>> To associate each syllable of these words with the notes, one can >>>>> add elements -- >>>>> >>>>> >>>>> >>>>> >>>>> Oh, >>>>> say >>>>> can >>>>> >you >>>>> see >>>>> >>>>> >>>>> >>>>> One may object to calling the text of a 15th century motet "lyrics", but the >> same markup applies. >>>>> >>>>> -- >>>>> p. >>>>> >>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >>>>> Of Giuliano Di Bacco >>>>> Sent: Saturday, March 04, 2017 6:28 AM >>>>> To: Byrd, Donald A.; Music Encoding Initiative >>>>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary >>>>> segmentation >>>>> >>>>> Thanks, Don: >>>>> >>>>> I swear that I am not trying to complicate the issue further, but I should >> recall that it was another moving part of the mechanism that originated this >> discussions on MEI-Mens, that is, . That is, also arbitrary >> segmentation/alignment of... non-arbitrary text (!) deserves attention: >>>>> >>>>> 1 - about its use, as regard to the issue described by Don: how best to >> record arbitrary (I prefer: "non standard") placement of text underlay >> (alignment of chunks of text in with s), when not possible/easy >> to do it with . >>>>> >>>>> 2- about its definition. This may be slightly off-topic, but important: >> discussion on MEI-Mens reveals that there may be some confusion about what >> is supposed to be used for. The specifications say that this is for "lyric >> verse". Period. First, I am not sure whether "verse" has to be intended as "a >> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a "single >> line of a metrical writing" -- definitions in major Brit+American dictionaries (and >> people's opinions) fluctuate between these poles. Second, I am not sure >> whether "lyric" stands for the genre (lyric poetry as opposed to narrative, epic, >> didactic poetry) or generically for "the words of a song". Admittedly, in >> romance languages both terms are less ambiguous than in English, so I suppose >> that we just need to clarify, through a more generous description, if is >> "whatever poetic text underlay" (my best guess) or what. It would be very >> useful to clarify this point while we talk about "text". The next step would be >> to decide if we need/want to represent poetical structures of lower (or higher) >> order (it would seem logical to me if we borrowed stuff from TEI), and how to >> distinguish text underlay proper from text-that-goes-with-these-notes but not- >> laid-under-the-notes, that is, written/printed somewhere else in the page >> (introducing some tag/att like "underlay" and "displaced" perhaps). But this is >> really off-topic (premature) for now. >>>>> >>>>> As usual, please don't hesitate to correct me if I >> misunderstood/misrepresented anything -- it would be helpful. >>>>> >>>>> Best, >>>>> >>>>> Giuliano >>>>> >>>>> >>>>> >>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: >>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, >>>>> Perry and I, plus other members of the mensural IG -- have been >>>>> discussing the need for annotations with arbitrary text that are >>>>> displayed on the music. Unfortunately, the discussion so far has >>>>> been scattered among several places, including the mensural IG >>>>> mailing list and Verovio GitHub issues #248 ("Directives in mensural >>>>> notation aren't drawn"), 388 ("@n for "), and especially 389 >>>>> ("implement display"). You can read #389 at >>>>> >>>>> https://github.com/rism-ch/verovio/issues/389 >>>>> >>>>> >>>>> and similarly for the other Verovio issues. Anyway, I'll try to summarize the >> issues here. >>>>> >>>>> We've talked about using one of two existing tags for these annotations, >> namely and . It seems clear that is not what we want >> because it's specifically intended for performance directions. As for s, >> of course they are currently only for annotating the encoding, not the music, >> and they're not displayed in the SVG. We could add a @visible attribute to >> , but the problem then is _where_ on the music should they appear? >> But it seems to me this is only a serious problem if you expect the notation >> engine to position everything automatically, and that's something that I think >> is completely unrealistic for complex music regardless of annotation. I suggest >> visible s should have a crudely-calculated default position, and it'd be >> up to the user to specify a different position if they want. >>>>> >>>>> Giuliano has raised a related concern. He wrote yesterday that >>>>> >>>>> "[N]ot only something like for arbitrary non-lyric text is needed, but >> also some arbitrary segmentation, to encapsulate portions of music and/or >> lyric/non-lyric text where things happen (such as, lyric text loosely connected >> with a portion of music, or passages where the mensuration is uncertain...). >>>>> >>>>> "If I understand correctly, most of the problem with originates from >> the missing level in the hierarchy (at least this creates problems >> with Verovio), so I was wondering whether the introduction of a tag >> at that level could be useful. The latter, contrary to >> would be totally optional, and contrary to or
would be >> used without any structural meaning. >>>>> >>>>> "This is the point where we felt the need that the discussion escalates on >> MEI-L. Non-structural segmentation is something that TEI introduced lately in >> their schema (they call it when the portion of text is shorter than a >> paragraph, and when an 'anonymous block' of text is found that escapes >> from the paragraph structure). In my experience this is one of the most useful >> features when dealing with complex documents, and in past projects I used it >> also to provide annotations. I wonder whether there are any reasons for not >> having a -like tag available at any level." >>>>> >>>>> Giuliano's ideas make sense to me, but I don't feel very well qualified to >> evaluate them. >>>>> >>>>> I'm looking forward to hearing people's thoughts on all of this! >>>>> >>>>> --Don >>>>> >>>>> >>>>> >>>>> >>> >>> >> >> >> > > _______________________________________________ > 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 From esfield at stanford.edu Tue Mar 7 02:08:58 2017 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Tue, 7 Mar 2017 01:08:58 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: Hi, All, Sorry: this message flew away mid-sentence. Here is the complete version: This topic has so many ramifications that I think it might be worth an ad hoc meeting in Tours to catalog its known aspects. It would be a reasonable goal to try to accommodate any arrangement that is currently supported by existing digital approaches. Otherwise we lose the possibility of interchange with them. To mention a few examples: (1) CMME (cmme.org) has a toggle for "cluster" text, synchronized with the music in whatever way it is presented in the source (Attachment); (2) The one case I know of in which EsAC (Essen associative code) hit an impasse was in arranging Polish lyrics to monophonic folksongs. EsAC assumes a note:lyrics ratio in which multiple syllables never have to be set to one note, but this need is common to other repertories including liturgical music. I workaround was devised but it was not transportable. In the polyphonic context, we have done some typesetting here (typically with SCORE) where multilingual versions of lyrics are given in Roman and non-Roman alphabets, and also with lyrics that exist in current and earlier versions of an alphabet. The most interesting question on encoding we have run across in this realm came from a German musicologist who wanted to recreate Turkish versions of Calvinist hymns. This brought up the problem of integrating conventional notation (left to right) with textual traditions read right-to-left. (This kind of thing was printable in the analog age but takes a lot of planning in the digital one.) This is outside the scope of MEI at present, but in a listing of situations that could occur in the future, it is worth a thought. Best regards, Eleanor -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Monday, March 06, 2017 8:05 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation You're right, @corresp can be used instead of @synch for generic "correspondence". But, if the goal is to render the text, then it should be associated with the notes in a more specific way. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Andrew Hankinson > Sent: Monday, March 06, 2017 10:11 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > I was thinking more semantic alignment, but maybe that’s what you were > thinking of by ‘temporal’ alignment. > > I was trying to answer Daniel’s use case where “these lyrics belong to > these notes with no specific information on which lyric belongs to which note” > would “correspond” but not necessarily “synchronise”. That is, there > is no specific time information (‘chronos’ in ’synchronise') but there > *is* a relationship between them. > > The specific case I was imagining was where a tune and lyrics were > given separately, with multiple possible realisations of the > alignment. Rather than making the statement that a given lyric is in > sync with a tune, it would be best to just say that these lyrics > ‘belong’ to this group of notes / measure / whatever. > > -Andrew > > > On 6 Mar 2017, at 14:59, Roland, Perry D. (pdr4h) > wrote: > > > > > > If temporal alignment is the objective, then @corresp is not specific enough. > Better to use @synch. The fact that these attributes are missing from > and is remediable. :-) @startid/@endid can also be added to > , as Daniel suggested, or to another still more specific element, > to indicate starting and ending points for a text string. > > > > -- > > p. > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Andrew Hankinson > >> Sent: Monday, March 06, 2017 6:51 AM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > >> segmentation > >> > >> If you’re talking about *visually* spacing the lyrics given an > >> unknown association with the notes, then this is not an MEI > >> problem, as far > as I can see. > >> This would need to be down to a particularly clever renderer, or > >> some other means of computationally deriving syllable-note relationships. > >> > >> It really comes down to whether or not you are asserting or > >> estimating. If you are asserting a relationship, you would put it > >> in MEI. If you are estimating a relationship, based on informed > >> guesses, it’s probably best to leave that to an interpretive layer > >> that sits above the encoding, and only assert the things that you know. > >> > >> Just a quick glance through the elements lyrics, lg, and l, it > >> seems that the `@corresp` attribute might be the best solution. > >> This is already available on lyrics, but not on lg or l. > >> > >> I could imagine something like: > >> > >> > >> > >> … > >> > >> > >> > >> -Andrew > >> > >>> On 6 Mar 2017, at 07:57, Daniel Alles > >>> > >> wrote: > >>> > >>> Dear all, > >>> > >>> I think one of the problems (at least one of my problems while > >>> encoding MN) > >> is the spacing of the lyrics. It is not always clear, which > >> syllable belongs where, so a connection of syllables to notes is > >> not always given. The possibility to encode the lyrics separately > >> and then attach them to a staff seems unlikely too, as the > >> syllables would be spaced according to the rhythm off the staff > >> (the lyrics would only appear at the beginning of the staff, as > >> there normally are more notes then > syllables). > >>> > >>> A possibility to connect not only syllables but also whole phrases > >>> of text to > >> phrases of notes would be really nice; something like "this text > >> starts on that note and ends on that note". As it is not clear in > >> all the cases how the underlayed text is to be sung and therefore a > >> spacing of the lyrics would be an editorial intervention, a > >> solution like @startid and @endid (or something else) would at > >> least represent the > source material the best. > >>> > >>> Best, > >>> Daniel > >>> > >>> > >>> > >>> > >>> Zitat von Andrew Hankinson : > >>> > >>>> Could someone boil down the decisions that need to be made, even > >>>> just in > >> point form, for those of us who haven't been part of the discussion? > >>>> > >>>> I'm afraid I don't quite understand what we're supposed to be > >>>> commenting > >> on. > >>>> > >>>> -Andrew > >>>> > >>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > >> wrote: > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> Text underlay doesn't have anything to do with or . > >>>>> > >>>>> I apologize for the confusion created by the definition of > >>>>> > >>>>> -- it was > >> too short and too cryptic. In the version of MEI currently under > >> development, verse is defined as "Division of a poem or song > >> lyrics; a > stanza." > >>>>> > >>>>> The verse/syl construct is only applicable at the note level. > >>>>> For musical > >> material which is repeated, but with different words/lyrics/sung > >> text, provides a method of recording which words belong > >> with each > repetition. > >>>>> > >>>>> > >>>>> > >>>>> Ooh > >>>>> > >>>>> > >>>>> Ah > >>>>> > >>>>> > >>>>> > >>>>> For text not directly associated with individual notes, > >>>>> lyrics/lg should be > >> used instead. occurs outside the stream of notated > >> events; that is, inside and , although not > >> within or as might be required for mensural > >> notation. I'll correct this oversight soon. The element is, of course, borrowed from TEI. > >>>>> > >>>>> For those situations where the sung text is visually separate > >>>>> from the musical material, one can use -- > >>>>> > >>>>> > >>>>> > >>>>> Oh, say can you see > >>>>> > >>>>> > >>>>> > >>>>> To associate each syllable of these words with the notes, one > >>>>> can add elements -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Oh, > >>>>> say > >>>>> can > >>>>> >you > >>>>> see > >>>>> > >>>>> > >>>>> > >>>>> One may object to calling the text of a 15th century motet > >>>>> "lyrics", but the > >> same markup applies. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On > >>>>> Behalf Of Giuliano Di Bacco > >>>>> Sent: Saturday, March 04, 2017 6:28 AM > >>>>> To: Byrd, Donald A.; Music Encoding Initiative > >>>>> Subject: Re: [MEI-L] Annotations visible on the music and > >>>>> arbitrary segmentation > >>>>> > >>>>> Thanks, Don: > >>>>> > >>>>> I swear that I am not trying to complicate the issue further, > >>>>> but I should > >> recall that it was another moving part of the mechanism that > >> originated this discussions on MEI-Mens, that is, . That is, > >> also arbitrary segmentation/alignment of... non-arbitrary text (!) > >> deserves > attention: > >>>>> > >>>>> 1 - about its use, as regard to the issue described by Don: how > >>>>> best to > >> record arbitrary (I prefer: "non standard") placement of text > >> underlay (alignment of chunks of text in with s), > >> when not possible/easy to do it with . > >>>>> > >>>>> 2- about its definition. This may be slightly off-topic, but important: > >> discussion on MEI-Mens reveals that there may be some confusion > >> about what is supposed to be used for. The specifications > >> say that this is for "lyric verse". Period. First, I am not sure > >> whether "verse" has to be intended as "a body of metrical > >> writing/poetry" or a "stanza/strophe of poetry" or a "single line of a metrical writing" > >> -- definitions in major Brit+American dictionaries (and people's > >> opinions) fluctuate between these poles. Second, I am not sure > >> whether "lyric" stands for the genre (lyric poetry as opposed to > >> narrative, epic, didactic poetry) or generically for "the words of > >> a song". Admittedly, in romance languages both terms are less > >> ambiguous than in English, so I suppose that we just need to > >> clarify, through a more generous description, if is > >> "whatever poetic text underlay" (my best guess) or what. It would > >> be very useful to clarify this point while we talk about "text". > >> The next step would be to decide if we need/want to represent > >> poetical structures of lower (or > >> higher) order (it would seem logical to me if we borrowed stuff > >> from TEI), and how to distinguish text underlay proper from > >> text-that-goes-with-these-notes but not- laid-under-the-notes, that > >> is, > written/printed somewhere else in the page (introducing some tag/att > like "underlay" and "displaced" perhaps). But this is really off-topic > (premature) for now. > >>>>> > >>>>> As usual, please don't hesitate to correct me if I > >> misunderstood/misrepresented anything -- it would be helpful. > >>>>> > >>>>> Best, > >>>>> > >>>>> Giuliano > >>>>> > >>>>> > >>>>> > >>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: > >>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > >>>>> Perry and I, plus other members of the mensural IG -- have been > >>>>> discussing the need for annotations with arbitrary text that are > >>>>> displayed on the music. Unfortunately, the discussion so far has > >>>>> been scattered among several places, including the mensural IG > >>>>> mailing list and Verovio GitHub issues #248 ("Directives in > >>>>> mensural notation aren't drawn"), 388 ("@n for "), and > >>>>> especially 389 ("implement display"). You can read #389 > >>>>> at > >>>>> > >>>>> https://github.com/rism-ch/verovio/issues/389 > >>>>> > >>>>> > >>>>> and similarly for the other Verovio issues. Anyway, I'll try to > >>>>> summarize the > >> issues here. > >>>>> > >>>>> We've talked about using one of two existing tags for these > >>>>> annotations, > >> namely and . It seems clear that is not what we > >> want because it's specifically intended for performance directions. > >> As for s, of course they are currently only for annotating > >> the encoding, not the music, and they're not displayed in the SVG. > >> We could add a @visible attribute to , but the problem then > >> is _where_ > on the music should they appear? > >> But it seems to me this is only a serious problem if you expect the > >> notation engine to position everything automatically, and that's > >> something that I think is completely unrealistic for complex music > >> regardless of annotation. I suggest visible s should have a > >> crudely-calculated default position, and it'd be up to the user to > >> specify a > different position if they want. > >>>>> > >>>>> Giuliano has raised a related concern. He wrote yesterday that > >>>>> > >>>>> "[N]ot only something like for arbitrary non-lyric text is > >>>>> needed, but > >> also some arbitrary segmentation, to encapsulate portions of music > >> and/or lyric/non-lyric text where things happen (such as, lyric > >> text loosely connected with a portion of music, or passages where > >> the > mensuration is uncertain...). > >>>>> > >>>>> "If I understand correctly, most of the problem with > >>>>> originates from > >> the missing level in the hierarchy (at least this creates > >> problems with Verovio), so I was wondering whether the introduction > >> of a tag at that level could be useful. The latter, > >> contrary to would be totally optional, and contrary to > >> or
would be used without any structural meaning. > >>>>> > >>>>> "This is the point where we felt the need that the discussion > >>>>> escalates on > >> MEI-L. Non-structural segmentation is something that TEI > >> introduced lately in their schema (they call it when the > >> portion of text is shorter than a paragraph, and when an > >> 'anonymous block' of text is found that escapes from the paragraph > >> structure). In my experience this is one of the most useful > >> features when dealing with complex documents, and in past projects > >> I used it also to provide annotations. I wonder whether there are > >> any reasons for not having a > -like tag available at any level." > >>>>> > >>>>> Giuliano's ideas make sense to me, but I don't feel very well > >>>>> qualified to > >> evaluate them. > >>>>> > >>>>> I'm looking forward to hearing people's thoughts on all of this! > >>>>> > >>>>> --Don > >>>>> > >>>>> > >>>>> --- > >>>>> Donald Byrd > >>>>> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate > >>>>> Professor of Informatics Visiting Scientist, Research > >>>>> Technologies Indiana University Bloomington > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 _______________________________________________ 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: cmme-cluster.PNG Type: image/png Size: 35195 bytes Desc: cmme-cluster.PNG URL: From lxpugin at gmail.com Tue Mar 7 14:28:26 2017 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 7 Mar 2017 14:28:26 +0100 Subject: [MEI-L] Annotations visible on the music... In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <92AF24E3-17E9-4EE2-9AB4-1666857DDF31@indiana.edu> Message-ID: Hi Don, I was indeed not very convinced by the use of within , but this not an issue anymore since we can have them within now (See https://github.com/music-encoding/music-encoding/issues/329) as Perry just suggested. Laurent On Tue, Mar 7, 2017 at 1:25 AM, Byrd, Donald A. wrote: > On Mar 6, 2017, at 5:50 PM, "Roland, Perry D. (pdr4h)" < > pdr4h at eservices.virginia.edu> > wrote: > > Don, > > > > There's no reason to abuse verse/syl to attach non-sung text to a note. > Abuse instead. :-) > > I'd be (reasonably) happy to do that, but doesn't work on mensural > notation; as Laurent put it, "There is.. an issue with in mensural > mode." By "mensural mode", I assume he means on staves with notation.type > mensural, but I'm not sure. And he says making it work within will > be really tricky. Laurent? > > > Or better yet, suggest a new element for holding such text. > > I just suggested an old element -- -- with a new attribute -- > @visible -- and I thought you thought that was a good idea! No? > > --DAB > > > > Using @tstamp on to make the association is appropriate for CMN > but not for mensural notation, so use @startid. The element doesn't > have to go inside or . Since there's only one note with the > xml:id of "n1", can be placed anywhere in the field, although inside > is probably the best location -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > black > > colored > > testing > > > > > > -- > > p. > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Byrd, > >> Donald A. > >> Sent: Monday, March 06, 2017 4:44 PM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] Annotations visible on the music... > >> > >> My original message mentioned two related issues: as the subject line > said, > >> "annotations visible on the music and arbitrary segmentation". But the > >> discussion here has focused almost entirely on the latter, so let me > say more > >> about the annotations issue. > >> > >> My personal interest in this has nothing to do with the "arbitrary > ([or] 'non > >> standard') placement of text underlay (alignment of chunks of text in > > >> with s)" that Giuliano and Daniel have been talking about. I've > attached > >> the MEI file and corresponding SVG (from my experimental version of > Verovio; > >> you won't get this from anything public!) that brought the issue up for > me in > >> the first place. Of course, this isn't real music, just my test file. > But I simply > >> wanted to put labels on the music to say what type of mensural notation > -- > >> black, black colored, white, or white colored -- each part of the > example > >> showed, and, to my surprise, I couldn't find anything better than > to do it > >> with. NB that I ran this with the "--even-note-spacing" argument, so > the wide > >> spacing after the maximas has nothing to do with their duration; it's > just > >> because Verovio understandably thought the s were lyrics, > requiring their > >> own space before the next note. > >> > >> I actually think this is a pretty simple question. As I said when I > started this > >> thread, s "are currently only for annotating the encoding, not > the > >> music, and they're not displayed in the SVG. We could add a @visible > attribute > >> to , but the problem then is _where_ on the music should they > >> appear? But it seems to me this is only a serious problem if you expect > the > >> notation engine to position everything automatically, and I think > expecting > >> good results from that is completely unrealistic for complex music > regardless of > >> annotation. I suggest visible s should have a crudely-calculated > default > >> position, and it'd be up to the user to specify a different position if > they want." > >> I think Perry agreed in one of his recent messages, though I can't find > it now. > >> While the attached example is what led _me_ to think about this, it was > Craig > >> who opened Issue #389, where much of the previous discussion occurred. > He > >> suggested visible "would function in a very similar manner to > the > >> current implementation, but both should add horizontal collision > >> avoidance between adjacent and entries (similar to the > >> current implementation of ." But there was much more discussion > on > >> the Issue #389 page ( (https://github.com/rism-ch/verovio/issues/389), > which I > >> won't try to summarize here. I strongly recommend that anyone interested > >> read that. > >> > >> --DAB > >> > >> > >>> Zitat von Andrew Hankinson : > >>> > >>>> Could someone boil down the decisions that need to be made, even just > in > >> point form, for those of us who haven't been part of the discussion? > >>>> > >>>> I'm afraid I don't quite understand what we're supposed to be > commenting > >> on. > >>>> > >>>> -Andrew > >>>> > >>>>> On Mar 4, 2017, at 4:04 PM, Roland, Perry D. (pdr4h) > >> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Text underlay doesn't have anything to do with or . > >>>>> > >>>>> I apologize for the confusion created by the definition of > -- it was > >> too short and too cryptic. In the version of MEI currently under > development, > >> verse is defined as "Division of a poem or song lyrics; a stanza." > >>>>> > >>>>> The verse/syl construct is only applicable at the note level. For > musical > >> material which is repeated, but with different words/lyrics/sung text, > > >> provides a method of recording which words belong with each repetition. > >>>>> > >>>>> > >>>>> > >>>>> Ooh > >>>>> > >>>>> > >>>>> Ah > >>>>> > >>>>> > >>>>> > >>>>> For text not directly associated with individual notes, lyrics/lg > should be > >> used instead. occurs outside the stream of notated events; > that is, > >> inside and , although not within or > as > >> might be required for mensural notation. I'll correct this oversight > soon. The > >> element is, of course, borrowed from TEI. > >>>>> > >>>>> For those situations where the sung text is visually separate from > >>>>> the musical material, one can use -- > >>>>> > >>>>> > >>>>> > >>>>> Oh, say can you see > >>>>> > >>>>> > >>>>> > >>>>> To associate each syllable of these words with the notes, one can > >>>>> add elements -- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Oh, > >>>>> say > >>>>> can > >>>>> >you > >>>>> see > >>>>> > >>>>> > >>>>> > >>>>> One may object to calling the text of a 15th century motet "lyrics", > but the > >> same markup applies. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >>>>> Of Giuliano Di Bacco > >>>>> Sent: Saturday, March 04, 2017 6:28 AM > >>>>> To: Byrd, Donald A.; Music Encoding Initiative > >>>>> Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > >>>>> segmentation > >>>>> > >>>>> Thanks, Don: > >>>>> > >>>>> I swear that I am not trying to complicate the issue further, but I > should > >> recall that it was another moving part of the mechanism that originated > this > >> discussions on MEI-Mens, that is, . That is, also arbitrary > >> segmentation/alignment of... non-arbitrary text (!) deserves attention: > >>>>> > >>>>> 1 - about its use, as regard to the issue described by Don: how best > to > >> record arbitrary (I prefer: "non standard") placement of text underlay > >> (alignment of chunks of text in with s), when not > possible/easy > >> to do it with . > >>>>> > >>>>> 2- about its definition. This may be slightly off-topic, but > important: > >> discussion on MEI-Mens reveals that there may be some confusion about > what > >> is supposed to be used for. The specifications say that this is > for "lyric > >> verse". Period. First, I am not sure whether "verse" has to be intended > as "a > >> body of metrical writing/poetry" or a "stanza/strophe of poetry" or a > "single > >> line of a metrical writing" -- definitions in major Brit+American > dictionaries (and > >> people's opinions) fluctuate between these poles. Second, I am not sure > >> whether "lyric" stands for the genre (lyric poetry as opposed to > narrative, epic, > >> didactic poetry) or generically for "the words of a song". Admittedly, > in > >> romance languages both terms are less ambiguous than in English, so I > suppose > >> that we just need to clarify, through a more generous description, if > is > >> "whatever poetic text underlay" (my best guess) or what. It would be > very > >> useful to clarify this point while we talk about "text". The next step > would be > >> to decide if we need/want to represent poetical structures of lower (or > higher) > >> order (it would seem logical to me if we borrowed stuff from TEI), and > how to > >> distinguish text underlay proper from text-that-goes-with-these-notes > but not- > >> laid-under-the-notes, that is, written/printed somewhere else in the > page > >> (introducing some tag/att like "underlay" and "displaced" perhaps). But > this is > >> really off-topic (premature) for now. > >>>>> > >>>>> As usual, please don't hesitate to correct me if I > >> misunderstood/misrepresented anything -- it would be helpful. > >>>>> > >>>>> Best, > >>>>> > >>>>> Giuliano > >>>>> > >>>>> > >>>>> > >>>>> Byrd, Donald A. wrote on 04/03/2017 01:36: > >>>>> For quite awhile, some of us -- mostly Laurent, Giuliano, Craig, > >>>>> Perry and I, plus other members of the mensural IG -- have been > >>>>> discussing the need for annotations with arbitrary text that are > >>>>> displayed on the music. Unfortunately, the discussion so far has > >>>>> been scattered among several places, including the mensural IG > >>>>> mailing list and Verovio GitHub issues #248 ("Directives in mensural > >>>>> notation aren't drawn"), 388 ("@n for "), and especially 389 > >>>>> ("implement display"). You can read #389 at > >>>>> > >>>>> https://github.com/rism-ch/verovio/issues/389 > >>>>> > >>>>> > >>>>> and similarly for the other Verovio issues. Anyway, I'll try to > summarize the > >> issues here. > >>>>> > >>>>> We've talked about using one of two existing tags for these > annotations, > >> namely and . It seems clear that is not what we want > >> because it's specifically intended for performance directions. As for > s, > >> of course they are currently only for annotating the encoding, not the > music, > >> and they're not displayed in the SVG. We could add a @visible attribute > to > >> , but the problem then is _where_ on the music should they > appear? > >> But it seems to me this is only a serious problem if you expect the > notation > >> engine to position everything automatically, and that's something that > I think > >> is completely unrealistic for complex music regardless of annotation. I > suggest > >> visible s should have a crudely-calculated default position, and > it'd be > >> up to the user to specify a different position if they want. > >>>>> > >>>>> Giuliano has raised a related concern. He wrote yesterday that > >>>>> > >>>>> "[N]ot only something like for arbitrary non-lyric text is > needed, but > >> also some arbitrary segmentation, to encapsulate portions of music > and/or > >> lyric/non-lyric text where things happen (such as, lyric text loosely > connected > >> with a portion of music, or passages where the mensuration is > uncertain...). > >>>>> > >>>>> "If I understand correctly, most of the problem with > originates from > >> the missing level in the hierarchy (at least this creates > problems > >> with Verovio), so I was wondering whether the introduction of a tag > >> at that level could be useful. The latter, contrary to > > >> would be totally optional, and contrary to or
would > be > >> used without any structural meaning. > >>>>> > >>>>> "This is the point where we felt the need that the discussion > escalates on > >> MEI-L. Non-structural segmentation is something that TEI introduced > lately in > >> their schema (they call it when the portion of text is shorter > than a > >> paragraph, and when an 'anonymous block' of text is found that > escapes > >> from the paragraph structure). In my experience this is one of the most > useful > >> features when dealing with complex documents, and in past projects I > used it > >> also to provide annotations. I wonder whether there are any reasons for > not > >> having a -like tag available at any level." > >>>>> > >>>>> Giuliano's ideas make sense to me, but I don't feel very well > qualified to > >> evaluate them. > >>>>> > >>>>> I'm looking forward to hearing people's thoughts on all of this! > >>>>> > >>>>> --Don > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >> > >> > >> > > > > _______________________________________________ > > 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 > > > > > > > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Tue Mar 7 22:45:28 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 7 Mar 2017 21:45:28 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: Looking at the CMME schema and a very limited set of instance documents, it seems that text can be specified at the note or staff level, as in the following example -- Brevis 4 1 F 3 o hostium The syllable "o" is directly associated with this breve, while the text "hostium" appears to be associated with the staff/voice at the point where this note occurs. MEI's is more advanced than CMME's in that both the start and end points of the text can be identified. The issue remains, however, that is not specific enough with regard to text underlay. Again, I'd like to encourage the mensural community to provide a semantic description and element name for this kind of text. Adding it to MEI and Verovio doesn't present a great challenge. I also don't anticipate any difficulties mapping this yet-unnamed element to CMME or other similar schemes. Unlike EsAC, MEI doesn't assume a one-to-one correspondence between notes and syllables. Multiple syllables on a note are fine, as are differing numbers of syllables, say in a translation of French to Polish -- mot sło wo MEI has no character encoding issues, since it uses Unicode. Note the "funny" l (el) in the Polish word above. Right-to-left alphabets present no problem for MEI as long as the words are broken into syllables (which read RTL) that are arranged from left to right; that is, associated with the note to which they belong. The presentation of the music notation from right to left is outside the scope of MEI, but then actually so is all presentation. :-) -- p. From pdr4h at eservices.virginia.edu Tue Mar 7 23:01:21 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 7 Mar 2017 22:01:21 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: I've just been looking at some music with (mostly) Western notation and Arabic lyrics. I don't know if it's typical, but the song at http://www.classicalarabicmusic.com/Added%20Music%20Notations/Popular%20Traditional%20-1/asl_elgharam.html provides the notation first, followed by the lyrics. This is precisely the situation that the lyrics/lg/l construct was designed for. Association of each syllable with the note that it starts on via @synch is sufficient for rendition of the lyrics and notation together. -- p. From annplaksin at gmx.net Wed Mar 8 13:56:09 2017 From: annplaksin at gmx.net (Anna Plaksin) Date: Wed, 8 Mar 2017 13:56:09 +0100 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> Message-ID: <009501d2980b$5bb4e650$131eb2f0$@gmx.net> Hi all, I was also one of the participants of the discussion on the MEI mensural list and very happy to see this topic is getting solved. I'm also sorry for popping into this discussion here that late, but I didn't have a computer in reach within the last days and feel now a little bit overwhelmed, also my inbox does right now. On that point, I try to summarize the results and add some of my remarks, I wanted to. - 1: Lyrics - The revision of the content of , which is done in the development version as far as is see, uses line groups and lines for the organization; also is allowed within, but not mixing plain text and . Also, the use of @startid, @endid, and @plist should be allowed within and the introduction of for grouping was mentioned. Am I right with that? I was also one of those persons struggling with the text handling of mensural sources and this approach seems very useful to me. There is only one thing, I want to ask, just to get a clear idea. is meant to be used for a line of a poem or also for a visible line of text below a staff? It would be good to know because in the case of my attached example those two different understandings of would lead to different encodings. If is meant as a poetic line, I could divide each chunk of text with line, and the two lines sung on that repeated part of music would be attached to the same part of music: Sub cuius patula coma & phebi lira blandius & vox blandius insonat [...] In that case, is it possible to give the information of two underlying lines of lyrics below a chunk of music? If is meant to represent a visual line of underlying lyrics, the encoding would need to look like that, as it seems to me: Sub cuius patula coma & vox blandius insonat ">& phebi lira blandius In that case, the encoding seems logically very confusing to me, but the visual organization of the lyrics is given. So, for giving me a better understanding I would welcome a clarification on that issue. And I can also be sure that one of my examples is now able to encoded properly. - 2: control events - Also, control events, e.g. , are meant to be put directly into and not anymore within in mensural notation? But, where should be put in, still within ? I'm just asking because in cmn it is also one of those elements to be put directly into . - 3: non-sung text - I also want to come back on the topic of non-sung text. Unlike Don I'm not thinking about visible annotations by the encoder, instead I'm thinking about text directives within the source itself. My second example is in my opinion a problematic one because I'm not sure how to solve I right now. Because it is meant as the directive, that the Tenor voice should keep silent, I would encode it as "Tenor Laurus tacet.". My problem is, that needs to have a pointing attribute to be valid. In cmn I would use @tstamp="0" to point at the left barline, but within mensural music only @startid and @endid are valid pointing attributes. But on what should I point in that case? While I try to explain the problem, my only idea would be like that: [...] Tenor Laurus tacet. Is that solution appropriate? I would welcome any comments and suggestions. Again, I have to apologize for answering that late and arguing about things which seemed to be solved already. It seems to me, that discussion was spread on a lot of places, MEI mensural list, github and Verovio, and about a lot of related issues, what makes me feeling in need of a clear summarization. Another short question: When are the changes already made in the development version planned to be released in a stable version? Best wishes, Anna -----Ursprüngliche Nachricht----- Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Dienstag, 7. März 2017 23:01 An: Music Encoding Initiative Betreff: Re: [MEI-L] Annotations visible on the music and arbitrary segmentation I've just been looking at some music with (mostly) Western notation and Arabic lyrics. I don't know if it's typical, but the song at http://www.classicalarabicmusic.com/Added%20Music%20Notations/Popular%20Traditional%20-1/asl_elgharam.html provides the notation first, followed by the lyrics. This is precisely the situation that the lyrics/lg/l construct was designed for. Association of each syllable with the note that it starts on via @synch is sufficient for rendition of the lyrics and notation together. -- p. _______________________________________________ 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: lyrics-example.jpg Type: image/jpeg Size: 321413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tacet-example.JPG Type: image/jpeg Size: 275593 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Wed Mar 8 16:50:07 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 8 Mar 2017 15:50:07 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation In-Reply-To: <009501d2980b$5bb4e650$131eb2f0$@gmx.net> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> Message-ID: Comments inline below -- -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Anna > Plaksin > Sent: Wednesday, March 08, 2017 7:57 AM > To: 'Music Encoding Initiative' > Subject: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > Hi all, > > I was also one of the participants of the discussion on the MEI mensural list > and very happy to see this topic is getting solved. I'm also sorry for popping > into this discussion here that late, but I didn't have a computer in reach within > the last days and feel now a little bit overwhelmed, also my inbox does right > now. > On that point, I try to summarize the results and add some of my remarks, I > wanted to. > > - 1: Lyrics - > The revision of the content of , which is done in the development > version as far as is see, uses line groups and lines for the organization; also > is allowed within, but not mixing plain text and . Also, the use of > @startid, @endid, and @plist should be allowed within and the > introduction of for grouping was mentioned. > Am I right with that? [PR: ] Yes, the reorganization of is available only within the development version. The addition of @startid, @endid, and @plist on and the introduction of within have been proposed, but I don't think there's agreement yet that these changes are the optimal solution. Once again, I'd prefer that the mensural group propose an alternative to that would appear within and encode *performed text, the syllables of which are not directly associated with notes*, your "Sub cuius patula coma" for example. This element is analogous to CMME's element. This element would carry @startid, @endid, @plist and other attributes found on other controlEventLike elements. Adding it would make a clear distinction between the functions of (for poetic lines) and this element (text visible above/below a staff). > I was also one of those persons struggling with the text handling of mensural > sources and this approach seems very useful to me. There is only one thing, I > want to ask, just to get a clear idea. is meant to be used for a line of a poem > or also for a visible line of text below a staff? It would be good to know > because in the case of my attached example those two different > understandings of would lead to different encodings. If is meant as a > poetic line, I could divide each chunk of text with line, and the two lines sung > on that repeated part of music would be attached to the same part of music: > > > Sub cuius patula coma > & phebi lira blandius > & vox blandius insonat > [...] > > > In that case, is it possible to give the information of two underlying lines of > lyrics below a chunk of music? > If is meant to represent a visual line of underlying lyrics, the encoding > would need to look like that, as it seems to me: > > > > Sub cuius patula > coma > & vox blandius > insonat > > > ">& phebi lira > blandius > > > > In that case, the encoding seems logically very confusing to me, but the visual > organization of the lyrics is given. So, for giving me a better understanding I > would welcome a clarification on that issue. And I can also be sure that one of > my examples is now able to encoded properly. [PR: ] Indeed, the markup becomes "fuzzy" because there's too much "overloading of the semantics" of going on here. Better to use different elements for different functions -- for lines of poetry, a new element for mensural notation text strings. In this new element, one may encode explicit line breaks -- Sub cuius patula coma& phebi lira blandius to position the 2nd line or break the text across multiple newElements -- Sub cuius patula coma & phebi lira blandius The usual behavior of Verovio is such that two staff-attached elements like this occurring at the same time (i.e., associated with the same event) will be displayed vertically, one atop the other. The choice between using a single element or multiple elements is likely to be influenced by how much (visual?) control one needs to have over each chunk of text. > - 2: control events - > Also, control events, e.g. , are meant to be put directly into and > not anymore within in mensural notation? > But, where should be put in, still within ? I'm just asking > because in cmn it is also one of those elements to be put directly into > . [PR: ] At present, can occur in or in order to accommodate a wider variety of source material. In other words, I'm not knowledgeable enough about mensural sources to definitively say that a chunk of poetry can never occur in a layer. It seems unlikely, but I don't know for sure. Also, allowing in may provide some processing benefits; that is, a closer association of the poetry and the voice. This seems unlikely as well. In both cases, I'm waiting for experts to tell me to take it out. :-) The opposite approach is also valid -- leave it out until the experts say it needs to be there. I'm open to either method. > - 3: non-sung text - > I also want to come back on the topic of non-sung text. Unlike Don I'm not > thinking about visible annotations by the encoder, instead I'm thinking about > text directives within the source itself. My second example is in my opinion a > problematic one because I'm not sure how to solve I right now. > Because it is meant as the directive, that the Tenor voice should keep silent, I > would encode it as "Tenor Laurus tacet.". > My problem is, that needs to have a pointing attribute to be valid. In cmn > I would use @tstamp="0" to point at the left barline, but within mensural > music only @startid and @endid are valid pointing attributes. But on what > should I point in that case? While I try to explain the problem, my only idea > would be like that: > > > > [...] > > Tenor Laurus tacet. > Is that solution appropriate? I would welcome any comments and > suggestions. [PR: ] represents *time-filling space*, similar to push codes in DARMS. Its typical use is to fill the time preceding material that doesn't begin at the start of a measure, for instance, in pianistic writing where a "voice" suddenly materializes out of thin air in the middle of a measure. Here, is more appropriate. It encodes *visual space*. It has no duration, its extent expressed only in virtual units (where half the distance between staff lines equals one vu). So, I'd amend your encoding to be -- Tenor Laurus tacet. As far as I know, however, Verovio doesn't yet do anything with elements. > Again, I have to apologize for answering that late and arguing about things > which seemed to be solved already. It seems to me, that discussion was spread > on a lot of places, MEI mensural list, github and Verovio, and about a lot of > related issues, what makes me feeling in need of a clear summarization. > Another short question: When are the changes already made in the > development version planned to be released in a stable version? [PR: ] This discussion has indeed spread over many forums. At this point, the best place to follow discussion of a technical nature is in the Github repositories for MEI and Verovio. The release date for v. 4.0 is not yet determined. My original plan was to make it around the time of the conference in Tours, but now I think it's best to delay it until the end of the year. This will give us time to - consider broader changes, esp. those necessary for mensural and neume notation, - tackle small but important issues related to CMN display, - plan and begin to implement MEI Go!, and -handle other administrative stuff (conferences, workshops, web site updates, etc.). > Best wishes, > Anna > > -----Ursprüngliche Nachricht----- > Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von > Roland, Perry D. (pdr4h) > Gesendet: Dienstag, 7. März 2017 23:01 > An: Music Encoding Initiative > Betreff: Re: [MEI-L] Annotations visible on the music and arbitrary > segmentation > > > I've just been looking at some music with (mostly) Western notation and > Arabic lyrics. I don't know if it's typical, but the song at > http://www.classicalarabicmusic.com/Added%20Music%20Notations/Popular > %20Traditional%20-1/asl_elgharam.html provides the notation first, followed > by the lyrics. This is precisely the situation that the lyrics/lg/l construct was > designed for. Association of each syllable with the note that it starts on via > @synch is sufficient for rendition of the lyrics and notation together. > > -- > p. > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From DanielAlles at stud.uni-frankfurt.de Thu Mar 9 13:08:10 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 09 Mar 2017 13:08:10 +0100 Subject: [MEI-L] Place text on staves In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> Message-ID: <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> Dear all, in my source, there often appears the playing instruction "Tacet" written directly on a staff (see attachment). How can I reproduce that in MEI? I always try to reproduce the source as accurately as possible, but couldn't find a possibility to put this text on the staff. Is that possible at all? seems not to work, as there are no notes in that staff. Best, Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: Tacet.PNG Type: image/png Size: 120466 bytes Desc: not available URL: From raffaeleviglianti at gmail.com Thu Mar 9 15:24:18 2017 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 9 Mar 2017 09:24:18 -0500 Subject: [MEI-L] Place text on staves In-Reply-To: <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> Message-ID: Hello, I think is the most appropriate element given that the text gives an instruction. You can use @tstamp to position it based on time. Raff On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles < DanielAlles at stud.uni-frankfurt.de> wrote: > Dear all, > > in my source, there often appears the playing instruction "Tacet" written > directly on a staff (see attachment). How can I reproduce that in MEI? I > always try to reproduce the source as accurately as possible, but couldn't > find a possibility to put this text on the staff. Is that possible at all? > seems not to work, as there are no notes in that staff. > > Best, Daniel > > _______________________________________________ > 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: From pdr4h at eservices.virginia.edu Thu Mar 9 16:23:05 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 9 Mar 2017 15:23:05 +0000 Subject: [MEI-L] Place text on staves In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> Message-ID: Since this is mensural notation, @tstamp won't work. Instead, use as a placeholder in the 2nd staff and associate the text with the space via @startid -- ... Tacet -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Thursday, March 09, 2017 9:25 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Place text on staves Hello, I think is the most appropriate element given that the text gives an instruction. You can use @tstamp to position it based on time. Raff On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles > wrote: Dear all, in my source, there often appears the playing instruction "Tacet" written directly on a staff (see attachment). How can I reproduce that in MEI? I always try to reproduce the source as accurately as possible, but couldn't find a possibility to put this text on the staff. Is that possible at all? seems not to work, as there are no notes in that staff. Best, Daniel _______________________________________________ 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: From annplaksin at gmx.net Thu Mar 9 17:04:52 2017 From: annplaksin at gmx.net (Anna Plaksin) Date: Thu, 9 Mar 2017 17:04:52 +0100 Subject: [MEI-L] Place text on staves In-Reply-To: References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> Message-ID: <001f01d298ee$e35877f0$aa0967d0$@gmx.net> Hi Perry, according to your mail yesterday, wouldn’t here also be more appropriate, because Daniel wants to reproduce the source? In fact, my example displayed a similar situation. There is a visual padding and a text directive “Tacet” which intends logically time, where that particular voice remains silent while the others are singing. The difference is, that in my example the directive is followed by notes and in Daniel’s it is vice versa. As it seems to me, we have to decide here whether we want to encode the visual information or the logical. But the question is: which decision fits better to the encoding approach of “representing a source”? Best wishes, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Donnerstag, 9. März 2017 16:23 An: Music Encoding Initiative Betreff: Re: [MEI-L] Place text on staves Since this is mensural notation, @tstamp won't work. Instead, use as a placeholder in the 2nd staff and associate the text with the space via @startid -- ... Tacet -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Thursday, March 09, 2017 9:25 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Place text on staves Hello, I think is the most appropriate element given that the text gives an instruction. You can use @tstamp to position it based on time. Raff On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles > wrote: Dear all, in my source, there often appears the playing instruction "Tacet" written directly on a staff (see attachment). How can I reproduce that in MEI? I always try to reproduce the source as accurately as possible, but couldn't find a possibility to put this text on the staff. Is that possible at all? seems not to work, as there are no notes in that staff. Best, Daniel _______________________________________________ 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: From pdr4h at eservices.virginia.edu Thu Mar 9 20:52:09 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 9 Mar 2017 19:52:09 +0000 Subject: [MEI-L] Place text on staves In-Reply-To: <001f01d298ee$e35877f0$aa0967d0$@gmx.net> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> <001f01d298ee$e35877f0$aa0967d0$@gmx.net> Message-ID: Hi Anna, No, I think is the appropriate markup in this case. It captures the fact that the 2nd staff is filled with emptiness. This is the logical approach. The is attached to the nothingness just to give it an anchor point. If the exact placement of the is required, then its attributes should be used, e.g., @place, @ho, etc. MEI allows for the capture of both logical and visual information, but the logical should usually be given precedence. i don't think "reproducing the source" means replicating every detail. If you want an exact replica of the source, use page images and @facs. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Anna Plaksin Sent: Thursday, March 09, 2017 11:05 AM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] Place text on staves Hi Perry, according to your mail yesterday, wouldn’t here also be more appropriate, because Daniel wants to reproduce the source? In fact, my example displayed a similar situation. There is a visual padding and a text directive “Tacet” which intends logically time, where that particular voice remains silent while the others are singing. The difference is, that in my example the directive is followed by notes and in Daniel’s it is vice versa. As it seems to me, we have to decide here whether we want to encode the visual information or the logical. But the question is: which decision fits better to the encoding approach of “representing a source”? Best wishes, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Donnerstag, 9. März 2017 16:23 An: Music Encoding Initiative > Betreff: Re: [MEI-L] Place text on staves Since this is mensural notation, @tstamp won't work. Instead, use as a placeholder in the 2nd staff and associate the text with the space via @startid -- ... Tacet -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Thursday, March 09, 2017 9:25 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Place text on staves Hello, I think is the most appropriate element given that the text gives an instruction. You can use @tstamp to position it based on time. Raff On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles > wrote: Dear all, in my source, there often appears the playing instruction "Tacet" written directly on a staff (see attachment). How can I reproduce that in MEI? I always try to reproduce the source as accurately as possible, but couldn't find a possibility to put this text on the staff. Is that possible at all? seems not to work, as there are no notes in that staff. Best, Daniel _______________________________________________ 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: From DanielAlles at stud.uni-frankfurt.de Thu Mar 9 20:53:48 2017 From: DanielAlles at stud.uni-frankfurt.de (Daniel Alles) Date: Thu, 09 Mar 2017 20:53:48 +0100 Subject: [MEI-L] Place text on staves In-Reply-To: <001f01d298ee$e35877f0$aa0967d0$@gmx.net> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> <001f01d298ee$e35877f0$aa0967d0$@gmx.net> Message-ID: <20170309205348.Horde.2nOrOHl_I4LZpPOCEQPz8Nf@webmail.server.uni-frankfurt.de> In fact, my "tacet" is also followed by notes on the next page. Until now I did not encode line breaks because I encoded each of the six parts of each Magnificat as
, the lines only separated optically using . But thinking about reproducing the source - wouldn't it be better to encode all the lines at once, without
, but with line breaks? I don't get the difference between and , could please someone explain that a little bit? Thank you and good night, Daniel Zitat von Anna Plaksin : > Hi Perry, > > > > according to your mail yesterday, wouldn’t here also be more > appropriate, because Daniel wants to reproduce the source? > > In fact, my example displayed a similar situation. There is a visual > padding and a text directive “Tacet” which intends logically time, > where that particular voice remains silent while the others are > singing. The difference is, that in my example the directive is > followed by notes and in Daniel’s it is vice versa. > > As it seems to me, we have to decide here whether we want to encode > the visual information or the logical. But the question is: which > decision fits better to the encoding approach of “representing a > source”? > > > > Best wishes, > > Anna > > > > Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag > von Roland, Perry D. (pdr4h) > Gesendet: Donnerstag, 9. März 2017 16:23 > An: Music Encoding Initiative > Betreff: Re: [MEI-L] Place text on staves > > > > > > Since this is mensural notation, @tstamp won't work. Instead, use > as a placeholder in the 2nd staff and associate the text > with the space via @startid -- > > > > > > > > > > > > > > > > > > > > > > ... Tacet > > > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > Of Raffaele Viglianti > Sent: Thursday, March 09, 2017 9:25 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Place text on staves > > > > Hello, > > > > I think is the most appropriate element given > that the text gives an instruction. You can use @tstamp to position > it based on time. > > > > Raff > > > > On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles > > wrote: > > Dear all, > > in my source, there often appears the playing instruction "Tacet" > written directly on a staff (see attachment). How can I reproduce > that in MEI? I always try to reproduce the source as accurately as > possible, but couldn't find a possibility to put this text on the > staff. Is that possible at all? seems not to work, as there > are no notes in that staff. > > Best, Daniel > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Thu Mar 9 21:16:14 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 9 Mar 2017 20:16:14 +0000 Subject: [MEI-L] Place text on staves In-Reply-To: <20170309205348.Horde.2nOrOHl_I4LZpPOCEQPz8Nf@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> <001f01d298ee$e35877f0$aa0967d0$@gmx.net> <20170309205348.Horde.2nOrOHl_I4LZpPOCEQPz8Nf@webmail.server.uni-frankfurt.de> Message-ID: > But thinking about reproducing the source - wouldn't it be better to encode all > the lines at once, without
, but with line breaks? By "line breaks", I presume you mean "system breaks". "[R]eproducing the source" can have different dimensions.
defines a logical segment, the contents of which are connected in a logical way. marks "accidents" of the writing process. For example, if one marks each section of a minuet, mm. 3 and 4 are logically "part of" the minuet. The stuff occurring on a single system just happens to be written that way -- just because m. 3 and m. 4 are "on the same line" doesn't mean much because they could just as easily have been written on different "lines". Which is better to capture? Capturing the logical information, then the layout info is the best approach. That being said, MEI supports both and leaves the decision to the encoder. > I don't get the difference between and , could please someone > explain that a little bit? fills up time; i.e., it has duration. has visual size, but doesn't have duration. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Daniel > Alles > Sent: Thursday, March 09, 2017 2:54 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Place text on staves > > In fact, my "tacet" is also followed by notes on the next page. Until now I did > not encode line breaks because I encoded each of the six parts of each > Magnificat as
, the lines only separated optically using . > But thinking about reproducing the source - wouldn't it be better to encode all > the lines at once, without
, but with line breaks? > > I don't get the difference between and , could please someone > explain that a little bit? > > Thank you and good night, > Daniel > > > > Zitat von Anna Plaksin : > > > Hi Perry, > > > > > > > > according to your mail yesterday, wouldn’t here also be more > > appropriate, because Daniel wants to reproduce the source? > > > > In fact, my example displayed a similar situation. There is a visual > > padding and a text directive “Tacet” which intends logically time, > > where that particular voice remains silent while the others are > > singing. The difference is, that in my example the directive is > > followed by notes and in Daniel’s it is vice versa. > > > > As it seems to me, we have to decide here whether we want to encode > > the visual information or the logical. But the question is: which > > decision fits better to the encoding approach of “representing a > > source”? > > > > > > > > Best wishes, > > > > Anna > > > > > > > > Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag > > von Roland, Perry D. (pdr4h) > > Gesendet: Donnerstag, 9. März 2017 16:23 > > An: Music Encoding Initiative > > Betreff: Re: [MEI-L] Place text on staves > > > > > > > > > > > > Since this is mensural notation, @tstamp won't work. Instead, use > > as a placeholder in the 2nd staff and associate the text with > > the space via @startid -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ... Tacet > > > > > > > > > > > > -- > > > > p. > > > > > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > > Of Raffaele Viglianti > > Sent: Thursday, March 09, 2017 9:25 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Place text on staves > > > > > > > > Hello, > > > > > > > > I think is the most appropriate element given > > that the text gives an instruction. You can use @tstamp to position > > it based on time. > > > > > > > > Raff > > > > > > > > On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles > > > > wrote: > > > > Dear all, > > > > in my source, there often appears the playing instruction "Tacet" > > written directly on a staff (see attachment). How can I reproduce > > that in MEI? I always try to reproduce the source as accurately as > > possible, but couldn't find a possibility to put this text on the > > staff. Is that possible at all? seems not to work, as there > > are no notes in that staff. > > > > Best, Daniel > > > > _______________________________________________ > > 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 From craigsapp at gmail.com Thu Mar 9 21:44:39 2017 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 9 Mar 2017 12:44:39 -0800 Subject: [MEI-L] Place text on staves In-Reply-To: <20170309205348.Horde.2nOrOHl_I4LZpPOCEQPz8Nf@webmail.server.uni-frankfurt.de> References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> <20170309130810.Horde.ybUtJahCkvITTbtvl4BYxRm@webmail.server.uni-frankfurt.de> <001f01d298ee$e35877f0$aa0967d0$@gmx.net> <20170309205348.Horde.2nOrOHl_I4LZpPOCEQPz8Nf@webmail.server.uni-frankfurt.de> Message-ID: Hello Daniel, How you encode the Tacet will depend on the purpose of the encoding, i.e., what you plan to do with the encoding after you have finished encoding it. If you want a photocopy of the score, then you can encode in a way that says there is a blank staff in the music that happens to have some text on it. If you want to manipulate the data afterward to generate a modern style score, render a MIDI file, etc., then this "Tacet" text represents rests at a deeper structural level than the visible content and so should be encoded to reflect that. Perry Says: > No, I think is the appropriate markup in this case. > fills up time; i.e., it has duration. has visual size, but doesn't have duration. "Tacet" is a shorthand for the part resting for an entire section of the music, however, @dur/@dots for a are limited to printable rhythms. It is not possible to represent "20 breves" with those attributes. Could @dur.ges be used to represent the duration of 20 breves? This is closer to , although there are no measures (or technically there is one measure?). In other words, the "Tacet" text represents a duration in this case, so it should be given a duration or used in parallel with something that has duration. The element possessing the duration is "invisible". The tacet line should be encoded in its own or at least
as well. If you want it both ways, then this music should be encoded in rather than , and the part version can be more literal, while the score encoding could be more structural by accounting for the rests. Take this page of music from a trumpet part from an orchestral work for a modern equivalent: [image: Inline images 1] page 10 of http://scores.ccarh.org/mendelssohn/elijah/parts/current/mendelssohn-elijah-trpt1.pdf if the image does not get through the mailing system. Notice that the truplet is "tacet" in movements/sections 23, 24, 25, 27, 28, and 29. The trumpet will not immediately start playing the music for no. 30 after they have finished playing no. 26 (otherwise they will be fired). -=+Craig On 9 March 2017 at 11:53, Daniel Alles wrote: > In fact, my "tacet" is also followed by notes on the next page. Until now > I did not encode line breaks because I encoded each of the six parts of > each Magnificat as
, the lines only separated optically using . But thinking about reproducing the source - wouldn't it be > better to encode all the lines at once, without
, but with line > breaks? > > I don't get the difference between and , could please someone > explain that a little bit? > > Thank you and good night, > Daniel > > > > Zitat von Anna Plaksin : > > Hi Perry, >> >> >> >> according to your mail yesterday, wouldn’t here also be more >> appropriate, because Daniel wants to reproduce the source? >> >> In fact, my example displayed a similar situation. There is a visual >> padding and a text directive “Tacet” which intends logically time, where >> that particular voice remains silent while the others are singing. The >> difference is, that in my example the directive is followed by notes and in >> Daniel’s it is vice versa. >> >> As it seems to me, we have to decide here whether we want to encode the >> visual information or the logical. But the question is: which decision fits >> better to the encoding approach of “representing a source”? >> >> >> >> Best wishes, >> >> Anna >> >> >> >> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von >> Roland, Perry D. (pdr4h) >> Gesendet: Donnerstag, 9. März 2017 16:23 >> An: Music Encoding Initiative >> Betreff: Re: [MEI-L] Place text on staves >> >> >> >> >> >> Since this is mensural notation, @tstamp won't work. Instead, use >> as a placeholder in the 2nd staff and associate the text with the >> space via @startid -- >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ... Tacet >> >> >> >> >> >> -- >> >> p. >> >> >> >> >> >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Raffaele Viglianti >> Sent: Thursday, March 09, 2017 9:25 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Place text on staves >> >> >> >> Hello, >> >> >> >> I think is the most appropriate element given that >> the text gives an instruction. You can use @tstamp to position it based on >> time. >> >> >> >> Raff >> >> >> >> On Thu, Mar 9, 2017 at 7:08 AM, Daniel Alles < >> DanielAlles at stud.uni-frankfurt.de > rankfurt.de> > wrote: >> >> Dear all, >> >> in my source, there often appears the playing instruction "Tacet" written >> directly on a staff (see attachment). How can I reproduce that in MEI? I >> always try to reproduce the source as accurately as possible, but couldn't >> find a possibility to put this text on the staff. Is that possible at all? >> seems not to work, as there are no notes in that staff. >> >> Best, Daniel >> >> _______________________________________________ >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-03-09 at 11.59.22 AM.png Type: image/png Size: 304384 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Thu Mar 9 21:46:27 2017 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 9 Mar 2017 20:46:27 +0000 Subject: [MEI-L] Annotations visible on the music and arbitrary segmentation References: <8BF15016-F7B9-44B0-BB91-88D74E59E84D@indiana.edu> <92d7fe76-c0a2-0b40-593a-686501942f4e@indiana.edu> <14713_1488643535_58BAE5CF_14713_104_1_BBCC497C40D85642B90E9F94FC30343DDC032831@REAGAN1.eservices.virginia.edu> <25162_1488787526_58BD1846_25162_99_1_20170306085755.Horde.RcHr08cttuft6FA-uw7hXce@webmail.server.uni-frankfurt.de> <2946F3F8-0F85-4927-BD55-4E27E9E9AF3A@mail.mcgill.ca> <21269_1488812394_58BD7969_21269_65_20_BBCC497C40D85642B90E9F94FC30343DDC0329BF@REAGAN1.eservices.virginia.edu> <728895A0-BA85-493C-BD26-078367B1CE60@mail.mcgill.ca> <009501d2980b$5bb4e650$131eb2f0$@gmx.net> Message-ID: Returning to the problems surrounding sung and non/un-sung text -- I've finally realized that the presence of within , etc. (anywhere other than as a descendant of
) doesn't help to resolve the issue of the capture of vocal text presented as part of the notation, but not written directly under the notes. It's better to create an additional element (or elements) for this purpose. In fact, several similar elements already exist (dir, tempo, dynam, annot, etc.). The difference between these and the new element(s) is not their behavior -- they're all just text displayed on/around the staff. The difference is semantic -- they have different meanings/functions. I'm asking that those familiar with mensural suggest names for the new element(s). At first thought, "label" might be a good choice for a new element. But,