From christopher at antila.ca Mon Jan 12 20:20:46 2015 From: christopher at antila.ca (Christopher Antila) Date: Mon, 12 Jan 2015 14:20:46 -0500 Subject: [MEI-L] New music21 Release Supports MEI! Message-ID: <54B41E8E.8020405@antila.ca> Dear MEI-List Members: With the release of music21 version 2.0, the renowned Python toolkit for musicology is now capable of importing MEI files! For this initial release, we focussed on implementing the features required for CMN scores, though we hope to expand this in the future. To learn whether your favourite elements and attributes are supported, you may consult the music21.mei module documentation directly: http://web.mit.edu/music21/doc/moduleReference/moduleMeiBase.html Also note that music21 2.0 incorporates significant improvements in other areas too. For a longer discussion of new capabilities, refer to the release announcement: https://groups.google.com/forum/#!topic/music21list/t0MALRUnsgI While the module was primarily written by me, I would like to show my appreciation for the advice and wisdom of Andrew Hankinson, Ichiro Fujinaga, Myke Cuthbert, and the MEI-List itself. Funding for this project was provided by Canada's SSHRC as part of the SIMSSA grant (refer to http://simssa.ca for more information). You may send questions, comments, bug reports, and feature requests to me, Andrew Hankinson, the MEI-L, or the music21 list. Thank you, Christopher Antila From pdr4h at eservices.virginia.edu Mon Jan 12 21:48:40 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 12 Jan 2015 20:48:40 +0000 Subject: [MEI-L] New music21 Release Supports MEI! In-Reply-To: <54B41E8E.8020405@antila.ca> References: <54B41E8E.8020405@antila.ca> Message-ID: Hi Christopher, While I'm not a Python-er myself, I'm certainly glad to hear that music21 is now importing MEI. Thanks for your work on this important and useful addition to the set of tools reading/writing MEI. I look forward to the great things that this will lead to. One question: Will you also implement an exporter? Best wishes, -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Christopher Antila > Sent: Monday, January 12, 2015 2:21 PM > To: mei-l at lists.uni-paderborn.de > Subject: [MEI-L] New music21 Release Supports MEI! > > Dear MEI-List Members: > > With the release of music21 version 2.0, the renowned Python toolkit for > musicology is now capable of importing MEI files! For this initial > release, we focussed on implementing the features required for CMN > scores, though we hope to expand this in the future. To learn whether > your favourite elements and attributes are supported, you may consult > the music21.mei module documentation directly: > > http://web.mit.edu/music21/doc/moduleReference/moduleMeiBase.html > > Also note that music21 2.0 incorporates significant improvements in > other areas too. For a longer discussion of new capabilities, refer to > the release announcement: > > https://groups.google.com/forum/#!topic/music21list/t0MALRUnsgI > > While the module was primarily written by me, I would like to show my > appreciation for the advice and wisdom of Andrew Hankinson, Ichiro > Fujinaga, Myke Cuthbert, and the MEI-List itself. Funding for this > project was provided by Canada's SSHRC as part of the SIMSSA grant > (refer to http://simssa.ca for more information). > > You may send questions, comments, bug reports, and feature requests to > me, Andrew Hankinson, the MEI-L, or the music21 list. > > > Thank you, > Christopher Antila > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From christopher at antila.ca Mon Jan 12 23:54:08 2015 From: christopher at antila.ca (Christopher Antila) Date: Mon, 12 Jan 2015 17:54:08 -0500 Subject: [MEI-L] New music21 Release Supports MEI! In-Reply-To: References: <54B41E8E.8020405@antila.ca> Message-ID: <54B45090.2080903@antila.ca> Hi Perry: On 01/12/2015 03:48 PM, Roland, Perry D. (pdr4h) wrote: > While I'm not a Python-er myself, I'm certainly glad to hear that music21 is now importing MEI. Thanks for your work on this important and useful addition to the set of tools reading/writing MEI. I look forward to the great things that this will lead to. > > One question: Will you also implement an exporter? I do believe a music21-to-MEI export module is also on the "to-do" list at McGill, though I don't about the planned schedule for completion. Thanks for your support! Christopher From andrew.hankinson at mail.mcgill.ca Wed Jan 14 18:11:13 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 14 Jan 2015 17:11:13 +0000 Subject: [MEI-L] New MEI Customization web service Message-ID: Hi all, The MEI Technical team has been working on a new version of the MEI Custom(e)ization service. This service provides a user-friendly face to the process of generating customized versions of MEI using the TEI Stylesheets and Roma tools. The service is available here: http://custom.music-encoding.org Using this you can generate custom RelaxNG schemas for the latest development version of MEI, for the latest ?stable? versions, or you may use your own source and customization files. Some improvements over the previous version include: 1. A more reliable method of running the TEI tools on the server process 2. Better error reporting when something does go wrong 3. Automatic updates to the development source code as new commits are made to the MEI source. ? and a few more surprises. Of course, this is an open-source project, and the source is available here: https://github.com/music-encoding/customeization. Improvements, by way of bug reports, feature requests, or pull requests are always welcome. For the technical team, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From veit at weber-gesamtausgabe.de Thu Jan 15 22:41:09 2015 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Thu, 15 Jan 2015 22:41:09 +0100 Subject: [MEI-L] Announcement In-Reply-To: References: Message-ID: <54B833F5.1040008@weber-gesamtausgabe.de> Dear all, with best wishes for the new year (which already runs for half a month again...) I append here the announcement of a new position at our university in Paderborn concerning a professorship for Musicology / Digital Music Edition / Digital Humanities. We very much hope that there will be several interested persons from our list!! ... With best greetings, Joachim -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : Ausschreibung_Akademieprofessur_englisch.pdf Dateityp : application/x-pdf Dateigr??e : 155582 bytes Beschreibung: nicht verf?gbar URL : -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : veit.vcf Dateityp : text/x-vcard Dateigr??e : 364 bytes Beschreibung: nicht verf?gbar URL : From kepper at edirom.de Fri Jan 23 14:19:50 2015 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 23 Jan 2015 14:19:50 +0100 Subject: [MEI-L] Terms and roles for inaugural MEI Board Message-ID: <75BACC97-0AC1-40C5-9F94-3A3EAB3707F2@edirom.de> Dear MEI-Community, Last week, the recently elected MEI Board held its first virtual meeting. The main purpose of this meeting was to determine the term for each Board member. According to our by-laws, we elected three Board members to serve for two, three and four years respectively. Starting two years from now, we will have annual elections, where we fill three out of the nine seats. Throughout the whole meeting, the Board succeeded in reaching consensus for all decisions. During our discussions, we agreed on the following terms: * Johannes Kepper, Eleanor Selfridge-Field and Axel Teich Geertinger will serve for two years (2015-2016). * Giuliano Di Bacco, Laurent Pugin and Kristina Richts will serve for three years (2015-2017). * Benjamin Bohl, Ichiro Fujinaga and Perry Roland will serve for four years (2015-2018). Additionally, the Board has agreed on the following responsibilities: * Laurent Pugin and Perry Roland will act as Technical Co-Chairs of the Board. * Johannes Kepper will function as the Administrative Chair of the Board. The Board has agreed that these roles should be re-examined after each election, which means after two years for this first round, and annually thereafter. While this is not covered in the by-laws yet, the Board will not immediately pursue an amendment to the by-laws addressing this issue, but after about a year - well ahead of the next elections, but with the opportunity to identify and address other minor issues at the same time. The whole Board was very enthusiastic about our first meeting, and we're looking forward to our work both within the Board and with the Community in general. Best regards, Johannes -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From ul at openlilylib.org Tue Jan 27 23:43:12 2015 From: ul at openlilylib.org (Urs Liska) Date: Tue, 27 Jan 2015 23:43:12 +0100 Subject: [MEI-L] Introducing ScholarLY Message-ID: <54C81480.6080001@openlilylib.org> Dear MEI users, in general I wouldn't advertise blog posts on mailing lists like this , but today it is important for me to reach potential users or collaborators that may not read the lilypond-user mailing list. So if you're not interested in LilyPond at all please pardon this shameless plug and simply discard it. Otherwise please have a look at http://lilypondblog.org/2015/01/introducing-scholarly/. I have just released a first version of ScholarLY, a toolkit for scholarly edition with LilyPond and LaTeX, starting with tools that allow to maintain all kinds of annotations (from general questions to final critical remarks) within the music definitions. This is not directly MEI related (yet) but an example of LilyPond's recent embracing of a scholarly perspective. It is also part of what we will be presenting in Florence in May. But the main reason for advertising here is that this is also meant as a call for collaboration. I'd be glad about anyone getting in touch with contributions, but also with ideas, issues and discussion. Regards Urs Liska From bohl at edirom.de Fri Jan 30 14:13:40 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Fri, 30 Jan 2015 14:13:40 +0100 Subject: [MEI-L] slur and @curvedir Message-ID: <8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, Benjamin -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : 319371e8-a889-11e4-9a4c-7fe5cc246dfe.png Dateityp : image/png Dateigr??e : 69500 bytes Beschreibung: nicht verf?gbar URL : From F.Wiering at uu.nl Sat Jan 31 13:15:46 2015 From: F.Wiering at uu.nl (Frans Wiering) Date: Sat, 31 Jan 2015 13:15:46 +0100 Subject: [MEI-L] Announcement In-Reply-To: <54B833F5.1040008@weber-gesamtausgabe.de> References: <54B833F5.1040008@weber-gesamtausgabe.de> Message-ID: <54CCC772.1090201@uu.nl> Dear Joachim, Thanks for circulating this announcement, I'm quite interested! I was looking for the German version of the job description, which should be at http://muwi-detmold-paderborn.de/freie-stellen.html , but unfortunately what I see is an empty page... Could you please send me the German text? (The reason I'm asking is that I want to feel absolutely sure about what is asked froom the applicant.) Many thanks for your help, Frans On 15-01-15 22:41, Joachim Veit wrote: > Dear all, > with best wishes for the new year (which already runs for half a month > again...) I append here the announcement of a new position at our > university in Paderborn concerning a professorship for Musicology / > Digital Music Edition / Digital Humanities. > We very much hope that there will be several interested persons from our > list!! ... > With best greetings, > Joachim > -- --------------------------------------------------------------------- dr. Frans Wiering e-mail: F.Wiering at uu.nl --------------------------------------------------------------------- Utrecht University Department of Information and Computing Sciences (ICS) Buys Ballot Building, office 482 Princetonplein 5, De Uithof PO Box 80.089 NL-3508 TB Utrecht tel: +31-30-2536335 www: http://www.uu.nl/medewerkers/FWiering --------------------------------------------------------------------- From F.Wiering at uu.nl Sat Jan 31 13:17:53 2015 From: F.Wiering at uu.nl (Frans Wiering) Date: Sat, 31 Jan 2015 13:17:53 +0100 Subject: [MEI-L] Announcement In-Reply-To: <54CCC772.1090201@uu.nl> References: <54B833F5.1040008@weber-gesamtausgabe.de> <54CCC772.1090201@uu.nl> Message-ID: <54CCC7F1.1060107@uu.nl> Please forget about the preceding message, it was not meant for the list at all!!! Many apologies, Frans On 31-01-15 13:15, Frans Wiering wrote: > Dear Joachim, > > Thanks for circulating this announcement, I'm quite interested! > I was looking for the German version of the job description, which > should be at http://muwi-detmold-paderborn.de/freie-stellen.html , but > unfortunately what I see is an empty page... Could you please send me > the German text? (The reason I'm asking is that I want to feel > absolutely sure about what is asked froom the applicant.) > > Many thanks for your help, > > Frans > > On 15-01-15 22:41, Joachim Veit wrote: >> Dear all, >> with best wishes for the new year (which already runs for half a month >> again...) I append here the announcement of a new position at our >> university in Paderborn concerning a professorship for Musicology / >> Digital Music Edition / Digital Humanities. >> We very much hope that there will be several interested persons from our >> list!! ... >> With best greetings, >> Joachim >> > -- --------------------------------------------------------------------- dr. Frans Wiering e-mail: F.Wiering at uu.nl --------------------------------------------------------------------- Utrecht University Department of Information and Computing Sciences (ICS) Buys Ballot Building, office 482 Princetonplein 5, De Uithof PO Box 80.089 NL-3508 TB Utrecht tel: +31-30-2536335 www: http://www.uu.nl/medewerkers/FWiering --------------------------------------------------------------------- From T.Crawford at gold.ac.uk Sat Jan 31 16:25:27 2015 From: T.Crawford at gold.ac.uk (Tim Crawford) Date: Sat, 31 Jan 2015 15:25:27 +0000 Subject: [MEI-L] Announcement In-Reply-To: <54CCC7F1.1060107@uu.nl> References: <54B833F5.1040008@weber-gesamtausgabe.de> <54CCC772.1090201@uu.nl> <54CCC7F1.1060107@uu.nl> Message-ID: Oh dear! :-( I'm sure no-one is surprised, though! Tim On 31 Jan 2015, at 12:17, Frans Wiering wrote: > Please forget about the preceding message, it was not meant for the list at all!!! > > Many apologies, > > Frans > > On 31-01-15 13:15, Frans Wiering wrote: >> Dear Joachim, >> >> Thanks for circulating this announcement, I'm quite interested! >> I was looking for the German version of the job description, which >> should be at http://muwi-detmold-paderborn.de/freie-stellen.html , but >> unfortunately what I see is an empty page... Could you please send me >> the German text? (The reason I'm asking is that I want to feel >> absolutely sure about what is asked froom the applicant.) >> >> Many thanks for your help, >> >> Frans >> >> On 15-01-15 22:41, Joachim Veit wrote: >>> Dear all, >>> with best wishes for the new year (which already runs for half a month >>> again...) I append here the announcement of a new position at our >>> university in Paderborn concerning a professorship for Musicology / >>> Digital Music Edition / Digital Humanities. >>> We very much hope that there will be several interested persons from our >>> list!! ... >>> With best greetings, >>> Joachim >>> >> > > -- > --------------------------------------------------------------------- > dr. Frans Wiering > e-mail: F.Wiering at uu.nl > --------------------------------------------------------------------- > Utrecht University > Department of Information and Computing Sciences (ICS) > Buys Ballot Building, office 482 > Princetonplein 5, De Uithof > PO Box 80.089 > NL-3508 TB Utrecht > tel: +31-30-2536335 > www: http://www.uu.nl/medewerkers/FWiering > --------------------------------------------------------------------- > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From laurent at music.mcgill.ca Sun Feb 1 14:27:16 2015 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Sun, 1 Feb 2015 14:27:16 +0100 Subject: [MEI-L] slur and @curvedir In-Reply-To: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Message-ID: Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > Dear MEI-L, > Fresch?tz has a question concerning encoding mixed direction slurs. > > > [image: bildschirmfoto 2015-01-30 um 14 05 39] > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using @bezier > is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / > 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > This is no "special", rather quite often in printed music from the 19th > century. > > All the best, > Benjamin > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: -------------- section suivante -------------- Une pi?ce jointe autre que texte a ?t? nettoy?e... Nom: 319371e8-a889-11e4-9a4c-7fe5cc246dfe.png Type: image/png Taille: 69500 octets Desc: non disponible URL: From pdr4h at eservices.virginia.edu Sun Feb 1 18:04:15 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sun, 1 Feb 2015 17:04:15 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de>, Message-ID: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, Benjamin _______________________________________________ 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: 319371e8-a889-11e4-9a4c-7fe5cc246dfe.png Type: image/png Size: 69500 bytes Desc: 319371e8-a889-11e4-9a4c-7fe5cc246dfe.png URL: From zolaemil at gmail.com Mon Feb 2 07:08:28 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 2 Feb 2015 06:08:28 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Message-ID: Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu>: > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in > general terms. For phrase marks and slurs, it also generically describes > the curvature of the mark, and therefore functions as short hand for a more > detailed description given by the bulge or bezier attributes. It would be > possible to add a value to @place for slurs/phrases with multiple > inflection points, such as "mixed" or perhaps "complex", but this would > only fulfill a classification purpose -- it wouldn't provide any > information regarding how to draw the slur/phrase. So, one would still > need to use @bulge or @bezier for rendering. > > Another complicating factor is that @place is used by a number of > elements other than slur and phrase. Adding "mixed" directly to @place > would introduce the possibility of nonsense in the case of, say, or > . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [laurent at music.mcgill.ca] > *Sent:* Sunday, February 01, 2015 8:27 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: > http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so I > am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > >> Dear MEI-L, >> Fresch?tz has a question concerning encoding mixed direction slurs. >> >> >> [image: bildschirmfoto 2015-01-30 um 14 05 39] >> >> In case the picture doesn't come through, please see: >> https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >> >> This slur may not be properly encoded in MEI using @curvedir that only >> allows 'above' or 'below' as values. Nevertheless, using @bezier >> is much more verbose than needed? >> >> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / >> 'alternating' would be applicable? Of course the schema would have to be >> modified to allow this. Are there any comparable values in other parts of >> the schema? >> >> This is no "special", rather quite often in printed music from the 19th >> century. >> >> All the best, >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 319371e8-a889-11e4-9a4c-7fe5cc246dfe.png Type: image/png Size: 69500 bytes Desc: not available URL: From atge at kb.dk Mon Feb 2 09:29:16 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Mon, 2 Feb 2015 08:29:16 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From gdibacco at indiana.edu Mon Feb 2 14:07:23 2015 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Mon, 02 Feb 2015 08:07:23 -0500 Subject: [MEI-L] MEC 2015 Message-ID: <54CF768B.2070603@indiana.edu> An HTML attachment was scrubbed... URL: From klaus.rettinghaus at gmail.com Mon Feb 2 18:00:12 2015 From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus) Date: Mon, 02 Feb 2015 18:00:12 +0100 Subject: [MEI-L] slur and @curvedir In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> Message-ID: <1422896412.3010.1@smtp.gmail.com> Hi there, the example given by Benni is indeed a typical situation and I can imagine some more complex. What if this example would be repeated with an uninterrupted slur. Would that one be "above-below-above-below"? As I see it, there are simply two slurs connected. So perhaps it could be coded in two elements with appropriate @tstamp and @dur and maybe an additional @rend="connected" or something on the second one. Klaus Am Mo, 2. Feb, 2015 um 9:29 schrieb Axel Teich Geertinger : > Hi all > > Just out of curiosity: None of the solutions I have seen (@bulge, > @bezier, or @curvedir=?above below?) do indicate explicitly where > the slur changes position from above the notes to below ? that is, > where the slur intersects the melodic line, so to speak. I guess that > the use of @bezier will give the desired result in most situations, > but as the actual rendering of the slur must be dependent to some > degree on other factors such as the note spacing or system breaks, I > wonder how we can be sure that it will always cross the melodic line > at the desired place. With @bulge or @curvedir (with extended values > as suggested by Zoltan) this must be even more uncertain, right? In > principle, a rendering algorithm may draw the slur in Benni?s > example above the first three groups of notes and below only the last > group when using @bulge or @curvedir. How do we avoid that? > > One more question about @bulge, again just out of curiosity: Should > it be defined that a sequence of values for @bulge must an > alternating sequence of positive and negative values, either in the > guidelines or the schema? Or would a sequence like the one in the > guidelines example (@bulge=?2 1?) make any sense in any situation? > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > I think extending the data type of @curvedir attribute could be > justified simply base on the argument of classification: @curvdir > provides a classification mechanism, but this classification is > rather incomplete, the current values of @curvedir do not cover all > the cases that are out there (see Benni's example: nor "above" > neither "below" is appropriate, and the omission of the attribute > surely cannot imply what we want to convey, that is the curve goes > also above and below). This has nothing to do with rendering, since > in order to render a slur or phrase mark, the actual curve needs to > be calculated anyway, even when "above" or "below" is applied. > > Out of Benni's suggestions I quite like "above-below" / > "below-above". (Note that his question concerns @curvedir not > @place.) In fact, it occurs to me, we could even allow an alternating > sequence of the values "below" and "above". Benni's example would be > encoded as . This, beside conveying the > fact that the curve goes first below, then above, could also be > applied to curves with multiple inflection points. I have no literary > example for this at hand, but wouldn't be surprised if there was some > in existence. > > Best > Zoltan > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) > : > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in > general terms. For phrase marks and slurs, it also generically > describes the curvature of the mark, and therefore functions as short > hand for a more detailed description given by the bulge or bezier > attributes. It would be possible to add a value to @place for > slurs/phrases with multiple inflection points, such as "mixed" or > perhaps "complex", but this would only fulfill a classification > purpose -- it wouldn't provide any information regarding how to draw > the slur/phrase. So, one would still need to use @bulge or @bezier > for rendering. > > Another complicating factor is that @place is used by a number of > elements other than slur and phrase. Adding "mixed" directly to > @place would introduce the possibility of nonsense in the case of, > say, or . Of course, a specialized form of @place > for slur/phrase is a possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: > http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so > I am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that > only allows 'above' or 'below' as values. Nevertheless, using @bezier > is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / > 'changing' / 'alternating' would be applicable? Of course the schema > would have to be modified to allow this. Are there any comparable > values in other parts of the schema? > > > This is no "special", rather quite often in printed music from the > 19th century. > > > All the best, > 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 > > -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From pdr4h at eservices.virginia.edu Mon Feb 2 20:13:32 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 2 Feb 2015 19:13:32 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> , <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From drizovalero at gmail.com Mon Feb 2 20:17:40 2015 From: drizovalero at gmail.com (David Rizo Valero (gmail)) Date: Mon, 2 Feb 2015 20:17:40 +0100 Subject: [MEI-L] MEI: Spanish mensural notation In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Message-ID: Dear Laurent, I?m David Rizo, from the University of Alicante (grfia.dlsi.ua.es/cm). I think we met in Mainz two years ago in the RISM conference or in the Mainz MEI conference. I?ve been forwarded to you by Tim Crawford. He told me last week in a musical similarity workshop in Leiden that you were working with mensural notation in MEI. I?m working with manuscript editions of Spanish mensural music with Antonio Ezquerro, the head of RISM Spain. We are working in an application to represent the specifics of spanish manuscript mensural notation. We presented it in a notation workshop past June in Queen Mary in London. We?ve already implemented a new font and the rendering of scores and now I?m beginning to encode it in MEI. I have three little questions: 1. Is there any UML like description of the schema? 2. I?m using the MEI guidelines in the web but I?ve found in the page describing mensural notation several empty sections like coloration and custos empty. This is because is still unimplemented in MEI? 3. Besides, there are some specific elements not present yet in MEI that we may want to add. How we should proceed? Best wishes, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Mon Feb 2 20:29:52 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 2 Feb 2015 19:29:52 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: <1422896412.3010.1@smtp.gmail.com> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk>, <1422896412.3010.1@smtp.gmail.com> Message-ID: Hi Klaus, There is already a @join attribute provided on slur (and phrase) for this purpose -- sort of. @join contains ID references to the other slurs that form a single entity. But, this is more for analytical purposes than for rendering. The assumption is that slurs that are broken over system or page boundaries need relating to each other. However, I leave it to Benni to decide if this solution fits his slur markup problem. I'm not sure that @join could be used for rendering unless the point(s) at which the different slurs join are specified very precisely. In addition, two independently drawn slurs may not achieve the same (beautiful?) effect as one smooth, undulating curve. Of course, this could be renderer-dependent. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Klaus Rettinghaus [klaus.rettinghaus at gmail.com] Sent: Monday, February 02, 2015 12:00 PM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi there, the example given by Benni is indeed a typical situation and I can imagine some more complex. What if this example would be repeated with an uninterrupted slur. Would that one be "above-below-above-below"? As I see it, there are simply two slurs connected. So perhaps it could be coded in two elements with appropriate @tstamp and @dur and maybe an additional @rend="connected" or something on the second one. Klaus Am Mo, 2. Feb, 2015 um 9:29 schrieb Axel Teich Geertinger : Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drizovalero at gmail.com Mon Feb 2 20:46:49 2015 From: drizovalero at gmail.com (David Rizo Valero (gmail)) Date: Mon, 2 Feb 2015 20:46:49 +0100 Subject: [MEI-L] MEI: Spanish mensural notation In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> Message-ID: Hi, I?m sorry, I wanted to send this mail just to Laurent :( David. > El 2/2/2015, a las 20:17, David Rizo Valero (gmail) escribi?: > > Dear Laurent, > > I?m David Rizo, from the University of Alicante (grfia.dlsi.ua.es/cm ). I think we met in Mainz two years ago in the RISM conference or in the Mainz MEI conference?.. ?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Tue Feb 3 11:22:46 2015 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 3 Feb 2015 11:22:46 +0100 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk>, <1422896412.3010.1@smtp.gmail.com> Message-ID: <793FA69B-C853-4B7C-9615-731FDEBCDF7C@edirom.de> Dear all, I think Perry is right in pointing out the different use cases that result in different solutions. For rendering, @bezier is probably the first choice, but it doesn't help much for analytical purposes. Here, I would probably follow Perry's advice, that is, split up the slur into two (or more, depending on the example) separate slur elements with a clear @curvedir, and then use @join to recombine them. Even though I would probably take this path, there are some caveats I'm not completely settled with yet. First, it seems like our encodings are incompatible ? we can't have the rendering-specific @bezier on one element, and two elements for the "analytical" aspect. Splitting @bezier also into two separate curves on the two slur elements is probably impossible, since @bezier doesn't control the width of the curve, and thus not the tips where our two slurs connect ? the visual result would be different than what we want to achieve (but I may be perfectly wrong about this). In essence, the graphical precision would suffer from being combined with the analytical information. The other issue I can see is that @join would be used in a slightly different way than in other occasions. The main purpose of @join (at least for me) is to indicate that two measures are actually one, that is, not all beats of a measure are written before a system or page break. While MEI allows to insert and in every layer, I prefer to close the measure instead, insert one break that doesn't have to be coordinated with others, open the next measure, and indicate that this new measure is a continuation of the one before the break. In this setup, @join is used to indicate that two separate graphical entities form one logical entity. In Benni's slur example, we would use it the other way round, that is, we split up one graphical entity into multiple logical entities. I wonder what this means and have to admit that I'm not even decided if that's a problem or not. Opinions? Johannes we have to be very clear about the different intentions an encoder may have. If the task is to preserve a specific rendering, there seems no way around @bezier. However, @bezier is of little help for analytical purposes. Here, I believe Axel's question about the "turning points" seems very important. Am 02.02.2015 um 20:29 schrieb Roland, Perry D. (pdr4h) : > > Hi Klaus, > > There is already a @join attribute provided on slur (and phrase) for this purpose -- sort of. @join contains ID references to the other slurs that form a single entity. But, this is more for analytical purposes than for rendering. The assumption is that slurs that are broken over system or page boundaries need relating to each other. However, I leave it to Benni to decide if this solution fits his slur markup problem. > > I'm not sure that @join could be used for rendering unless the point(s) at which the different slurs join are specified very precisely. In addition, two independently drawn slurs may not achieve the same (beautiful?) effect as one smooth, undulating curve. Of course, this could be renderer-dependent. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Klaus Rettinghaus [klaus.rettinghaus at gmail.com] > Sent: Monday, February 02, 2015 12:00 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi there, > > the example given by Benni is indeed a typical situation and I can imagine some more complex. What if this example would be repeated with an uninterrupted slur. Would that one be "above-below-above-below"? > As I see it, there are simply two slurs connected. So perhaps it could be coded in two elements with appropriate @tstamp and @dur and maybe an additional @rend="connected" or something on the second one. > > Klaus > > > Am Mo, 2. Feb, 2015 um 9:29 schrieb Axel Teich Geertinger : >> Hi all >> >> Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? >> >> One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? >> >> Best, >> Axel >> >> >> Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n >> Sendt: 2. februar 2015 07:08 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] slur and @curvedir >> >> Hi Perry, >> >> I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. >> >> Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. >> >> Best >> Zoltan >> >> >> >> 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : >> >> Laurent is correct, the values in the example should be -2 and 1. >> >> The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. >> >> Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. >> >> -- >> p. >> >> >> __________________________ >> Perry Roland >> Music Library >> University of Virginia >> P. O. Box 400175 >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] >> Sent: Sunday, February 01, 2015 8:27 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] slur and @curvedir >> >> Hi Benni, >> >> Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 >> >> I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. >> >> Laurent >> >> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: >> Dear MEI-L, >> >> Fresch?tz has a question concerning encoding mixed direction slurs. >> >> >> In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >> >> This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? >> >> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? >> >> >> This is no "special", rather quite often in printed music from the 19th century. >> >> >> All the best, >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From atge at kb.dk Tue Feb 3 11:27:10 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Tue, 3 Feb 2015 10:27:10 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> , <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Hi Perry Thanks for your elaborate reply. As always I wasn't aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir="above below") do indicate explicitly where the slur changes position from above the notes to below - that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni's example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge="2 1") make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed... Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From raffaeleviglianti at gmail.com Tue Feb 3 15:29:07 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 3 Feb 2015 09:29:07 -0500 Subject: [MEI-L] slur and @curvedir In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms > involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects > but is also aesthetically satisfying can be quite a challenge. My deepest > respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to > get it right. But recording the corrections also means that they will have > to be encodable somehow, that is, in more detail than possible with > @bezier, for instance. I have no immediate ideas about how to solve this in > a medium as fluid as music notation. > > > > Best, > > Axel > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *P? vegne af *Roland, > Perry D. (pdr4h) > *Sendt:* 2. februar 2015 20:14 > > *Til:* Music Encoding Initiative > *Emne:* Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of worms > for which it seems there can never be a single, universally satisfying > answer. > > > > @curvedir only provides minimal information about the slur so a renderer > must "figure out" the rest. This is the easiest method for the encoder, but > requires a lot more intelligence on the part of the rendering engine, for > example with regard to collision avoidance. From another angle, however, it > provides the greatest amount of flexibility for the renderer to arrive at > the final shape of the slur. Like I said before, aside from providing a > more detailed classification purpose, allowing curvdir="above below above > below (and so on)" doesn't really provide much rendering help because, just > as you've observed, it says nothing about the location of the points where > the slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating distance > from an imaginary line between the end points of the slur. Providing two > values means the distance between the end points should be halved and a > curve drawn that passes through the starting point, the point indicated by > the 1st value in @bulge, the mid-point of the line, the point indicated by > the 2nd value, and the ending point. Three values would mean dividing the > distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary > line) can be drawn with @bulge by supplying only a single value or by > giving only positive or only negative values. Doing this, instead of using > @curvedir, places the shape of the slur in the control of the encoder > instead of the rendering engine, but puts the burden of "scribing" the > shape on the encoder. The ability to draw "simple" slurs is why @bulge > can't be constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. > The diagram is also misleading in that the lines connecting the curve with > the imaginary line should divide their respective sections of the curve > into equal parts; that is, the line illustrating point 1 should be drawn at > the "highest" point of the curve, mid-way between the mid-point of the > imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. > But unless the control points of the curve are expressed as offsets from > some musical feature (like a note, for instance), then re-flowing the > notation will "disconnect" the slur from it and the slur will end up in the > wrong place on the page. So, the bezier control points have to be > *offsets* from something, presumably from the features pointed at by the > @startid and @endid attributes, as long as the notation is expected to be > "edit-able". The @startid, @endid, @bezier combination will move the > slur with the notation. The problem with bezier control points is the same > as with @bulge values -- it's nearly impossible for one to create them > without the aid of some kind of drawing environment or iterative > "code/view/code" workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed > the Guidelines. But, there may also be better ways of recording the > information necessary for drawing slurs than what is provided by the > current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > Teich Geertinger [atge at kb.dk] > *Sent:* Monday, February 02, 2015 3:29 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, > or @curvedir=?above below?) do indicate explicitly where the slur changes > position from above the notes to below ? that is, where the slur intersects > the melodic line, so to speak. I guess that the use of @bezier will give > the desired result in most situations, but as the actual rendering of the > slur must be dependent to some degree on other factors such as the note > spacing or system breaks, I wonder how we can be sure that it will always > cross the melodic line at the desired place. With @bulge or @curvedir (with > extended values as suggested by Zoltan) this must be even more uncertain, > right? In principle, a rendering algorithm may draw the slur in Benni?s > example above the first three groups of notes and below only the last group > when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be > defined that a sequence of values for @bulge must an alternating sequence > of positive and negative values, either in the guidelines or the schema? Or > would a sequence like the one in the guidelines example (@bulge=?2 1?) make > any sense in any situation? > > > > Best, > > Axel > > > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *P? vegne af *Kom?ves Zolt?n > *Sendt:* 2. februar 2015 07:08 > *Til:* Music Encoding Initiative > *Emne:* Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified > simply base on the argument of classification: @curvdir provides a > classification mechanism, but this classification is rather incomplete, the > current values of @curvedir do not cover all the cases that are out there > (see Benni's example: nor "above" neither "below" is appropriate, and the > omission of the attribute surely cannot imply what we want to convey, that > is the curve goes also above and below). This has nothing to do with > rendering, since in order to render a slur or phrase mark, the actual curve > needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". > (Note that his question concerns @curvedir not @place.) In fact, it occurs > to me, we could even allow an alternating sequence of the values "below" > and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, > then above, could also be applied to curves with multiple inflection > points. I have no literary example for this at hand, but wouldn't be > surprised if there was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in > general terms. For phrase marks and slurs, it also generically describes > the curvature of the mark, and therefore functions as short hand for a more > detailed description given by the bulge or bezier attributes. It would be > possible to add a value to @place for slurs/phrases with multiple > inflection points, such as "mixed" or perhaps "complex", but this would > only fulfill a classification purpose -- it wouldn't provide any > information regarding how to draw the slur/phrase. So, one would still > need to use @bulge or @bezier for rendering. > > > > Another complicating factor is that @place is used by a number of elements > other than slur and phrase. Adding "mixed" directly to @place would > introduce the possibility of nonsense in the case of, say, or > . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [laurent at music.mcgill.ca] > *Sent:* Sunday, February 01, 2015 8:27 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: > http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am > not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > [image: bildschirmfoto 2015-01-30 um 14 05 39] > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using *@bezier* > is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / > 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > > > This is no "special", rather quite often in printed music from the 19th > century. > > > > All the best, > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Tue Feb 3 15:30:51 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 3 Feb 2015 14:30:51 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: <793FA69B-C853-4B7C-9615-731FDEBCDF7C@edirom.de> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk>, <1422896412.3010.1@smtp.gmail.com> , <793FA69B-C853-4B7C-9615-731FDEBCDF7C@edirom.de> Message-ID: Hi Johannes, First, I didn't intend to endorse the idea of breaking a single slur with multiple inflection points into multiple slurs, only to indicate that it might be a possibility worthy of discussion. :-) I think you've demonstrated the problems that might be created by taking this approach. However, I'm confused by what appears to be a postscript to your comments -- "we have to be very clear about the different intentions an encoder may have. If the task is to preserve a specific rendering, there seems no way around @bezier. However, @bezier is of little help for analytical purposes. Here, I believe Axel's question about the "turning points" seems very important." Obviously, @bezier addresses only the visual qualities of the slur. But, what are the analytical purposes you mention? What do the so-called "turning points" have to do with analysis? Is the shape of the slur meaningful, say across sources? If so, assuming that @bezier accurately captures the slur's shape, then why not compare the values in @bezier for the same slur in the two sources? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Tuesday, February 03, 2015 5:22 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Dear all, I think Perry is right in pointing out the different use cases that result in different solutions. For rendering, @bezier is probably the first choice, but it doesn't help much for analytical purposes. Here, I would probably follow Perry's advice, that is, split up the slur into two (or more, depending on the example) separate slur elements with a clear @curvedir, and then use @join to recombine them. Even though I would probably take this path, there are some caveats I'm not completely settled with yet. First, it seems like our encodings are incompatible ? we can't have the rendering-specific @bezier on one element, and two elements for the "analytical" aspect. Splitting @bezier also into two separate curves on the two slur elements is probably impossible, since @bezier doesn't control the width of the curve, and thus not the tips where our two slurs connect ? the visual result would be different than what we want to achieve (but I may be perfectly wrong about this). In essence, the graphical precision would suffer from being combined with the analytical information. The other issue I can see is that @join would be used in a slightly different way than in other occasions. The main purpose of @join (at least for me) is to indicate that two measures are actually one, that is, not all beats of a measure are written before a system or page break. While MEI allows to insert and in every layer, I prefer to close the measure instead, insert one break that doesn't have to be coordinated with others, open the next measure, and indicate that this new measure is a continuation of the one before the break. In this setup, @join is used to indicate that two separate graphical entities form one logical entity. In Benni's slur example, we would use it the other way round, that is, we split up one graphical entity into multiple logical entities. I wonder what this means and have to admit that I'm not even decided if that's a problem or not. Opinions? Johannes we have to be very clear about the different intentions an encoder may have. If the task is to preserve a specific rendering, there seems no way around @bezier. However, @bezier is of little help for analytical purposes. Here, I believe Axel's question about the "turning points" seems very important. Am 02.02.2015 um 20:29 schrieb Roland, Perry D. (pdr4h) : > > Hi Klaus, > > There is already a @join attribute provided on slur (and phrase) for this purpose -- sort of. @join contains ID references to the other slurs that form a single entity. But, this is more for analytical purposes than for rendering. The assumption is that slurs that are broken over system or page boundaries need relating to each other. However, I leave it to Benni to decide if this solution fits his slur markup problem. > > I'm not sure that @join could be used for rendering unless the point(s) at which the different slurs join are specified very precisely. In addition, two independently drawn slurs may not achieve the same (beautiful?) effect as one smooth, undulating curve. Of course, this could be renderer-dependent. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Klaus Rettinghaus [klaus.rettinghaus at gmail.com] > Sent: Monday, February 02, 2015 12:00 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi there, > > the example given by Benni is indeed a typical situation and I can imagine some more complex. What if this example would be repeated with an uninterrupted slur. Would that one be "above-below-above-below"? > As I see it, there are simply two slurs connected. So perhaps it could be coded in two elements with appropriate @tstamp and @dur and maybe an additional @rend="connected" or something on the second one. > > Klaus > > > Am Mo, 2. Feb, 2015 um 9:29 schrieb Axel Teich Geertinger : >> Hi all >> >> Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? >> >> One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? >> >> Best, >> Axel >> >> >> Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n >> Sendt: 2. februar 2015 07:08 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] slur and @curvedir >> >> Hi Perry, >> >> I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. >> >> Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. >> >> Best >> Zoltan >> >> >> >> 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : >> >> Laurent is correct, the values in the example should be -2 and 1. >> >> The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. >> >> Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. >> >> -- >> p. >> >> >> __________________________ >> Perry Roland >> Music Library >> University of Virginia >> P. O. Box 400175 >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] >> Sent: Sunday, February 01, 2015 8:27 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] slur and @curvedir >> >> Hi Benni, >> >> Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 >> >> I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. >> >> Laurent >> >> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: >> Dear MEI-L, >> >> Fresch?tz has a question concerning encoding mixed direction slurs. >> >> >> In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >> >> This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? >> >> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? >> >> >> This is no "special", rather quite often in printed music from the 19th century. >> >> >> All the best, >> 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 pdr4h at eservices.virginia.edu Tue Feb 3 15:50:48 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 3 Feb 2015 14:50:48 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk>, Message-ID: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From pdr4h at eservices.virginia.edu Tue Feb 3 16:00:55 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 3 Feb 2015 15:00:55 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk>, , Message-ID: I meant to say that if @bezier can't contain relative coordinates, then our only mechanism for *relative positioning of a slur, allowing for re-flowing of the notation while providing some control over its shape* is through the use of @bulge. Even then, other factors, such as a decrease in the space between staves, can impact the results. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Tuesday, February 03, 2015 9:50 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From lxpugin at gmail.com Tue Feb 3 16:05:30 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 3 Feb 2015 16:05:30 +0100 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are > specified as absolute page coordinates. If they're given as offsets from > something else, such as a particular note, then the rendition of the slur > is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier > control points (even if they're moved relative to everything else) will > change the shape of the curve. If that's true, then our only mechanism for > controlling a slur is through the use of @bulge. For automatic layout > without any user intervention, the only mechanism is @curvedir -- > remembering that values in @curvedir cannot possibly result in a perfect > rendition every time. It seems there truly is no way to have the cake and > eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff > can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Raffaele Viglianti [raffaeleviglianti at gmail.com] > *Sent:* Tuesday, February 03, 2015 9:29 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly > concerning the the sharing of responsibilities between the encoder and the > renderer. Encoding @bezier before rendering locks the encoding into only > one possible rendering, which is not great for the reflowing that a truly > dynamic score should allow. Unless the aim of the encoder is to > represent/document the curvature of one specific written source, which is a > totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to > me: there is only one slur and no real XML overlapping (or other > limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > >> Hi Perry >> >> >> >> Thanks for your elaborate reply. As always I wasn?t aware of any worms >> involved, but I did realize that there is no single or easy answer :-) >> >> >> >> Drawing a complex slur that not only avoids collisions with other objects >> but is also aesthetically satisfying can be quite a challenge. My deepest >> respect for people working on rendering slurs! >> >> As you say, it almost always requires visual control and corrections to >> get it right. But recording the corrections also means that they will have >> to be encodable somehow, that is, in more detail than possible with >> @bezier, for instance. I have no immediate ideas about how to solve this in >> a medium as fluid as music notation. >> >> >> >> Best, >> >> Axel >> >> >> >> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *P? vegne af *Roland, >> Perry D. (pdr4h) >> *Sendt:* 2. februar 2015 20:14 >> >> *Til:* Music Encoding Initiative >> *Emne:* Re: [MEI-L] slur and @curvedir >> >> >> >> Hi Axel, >> >> >> >> One comment before I answer your questions -- This is a huge can of worms >> for which it seems there can never be a single, universally satisfying >> answer. >> >> >> >> @curvedir only provides minimal information about the slur so a renderer >> must "figure out" the rest. This is the easiest method for the encoder, but >> requires a lot more intelligence on the part of the rendering engine, for >> example with regard to collision avoidance. From another angle, however, it >> provides the greatest amount of flexibility for the renderer to arrive at >> the final shape of the slur. Like I said before, aside from providing a >> more detailed classification purpose, allowing curvdir="above below above >> below (and so on)" doesn't really provide much rendering help because, just >> as you've observed, it says nothing about the location of the points where >> the slur is supposed to bend back on itself. >> >> >> >> @bulge attempts to provide this missing information by indicating >> distance from an imaginary line between the end points of the slur. >> Providing two values means the distance between the end points should be >> halved and a curve drawn that passes through the starting point, the point >> indicated by the 1st value in @bulge, the mid-point of the line, the point >> indicated by the 2nd value, and the ending point. Three values would mean >> dividing the distance between the end points by thirds, etc. >> >> >> >> "Simple" slurs (i.e., ones that don't alternate sides of the imaginary >> line) can be drawn with @bulge by supplying only a single value or by >> giving only positive or only negative values. Doing this, instead of using >> @curvedir, places the shape of the slur in the control of the encoder >> instead of the rendering engine, but puts the burden of "scribing" the >> shape on the encoder. The ability to draw "simple" slurs is why @bulge >> can't be constrained to alternating positive and negative values. >> >> >> >> The example provided in the Guidelines should use the values -2 and 1. >> The diagram is also misleading in that the lines connecting the curve with >> the imaginary line should divide their respective sections of the curve >> into equal parts; that is, the line illustrating point 1 should be drawn at >> the "highest" point of the curve, mid-way between the mid-point of the >> imaginary line and the end point of the slur. >> >> >> >> @bezier provides the most encoder control over the rendition of the >> slur. But unless the control points of the curve are expressed as offsets >> from some musical feature (like a note, for instance), then re-flowing the >> notation will "disconnect" the slur from it and the slur will end up in the >> wrong place on the page. So, the bezier control points have to be >> *offsets* from something, presumably from the features pointed at by the >> @startid and @endid attributes, as long as the notation is expected to be >> "edit-able". The @startid, @endid, @bezier combination will move the >> slur with the notation. The problem with bezier control points is the same >> as with @bulge values -- it's nearly impossible for one to create them >> without the aid of some kind of drawing environment or iterative >> "code/view/code" workflow. >> >> >> >> Without a doubt, a better explanation of this stuff is desperately needed >> the Guidelines. But, there may also be better ways of recording the >> information necessary for drawing slurs than what is provided by the >> current set of attributes. I welcome contributions on either front. >> >> >> >> -- >> >> p. >> >> >> >> __________________________ >> Perry Roland >> Music Library >> >> University of Virginia >> >> P. O. Box 400175 >> >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> ------------------------------ >> >> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel >> Teich Geertinger [atge at kb.dk] >> *Sent:* Monday, February 02, 2015 3:29 AM >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] slur and @curvedir >> >> Hi all >> >> >> >> Just out of curiosity: None of the solutions I have seen (@bulge, >> @bezier, or @curvedir=?above below?) do indicate explicitly where the slur >> changes position from above the notes to below ? that is, where the slur >> intersects the melodic line, so to speak. I guess that the use of @bezier >> will give the desired result in most situations, but as the actual >> rendering of the slur must be dependent to some degree on other factors >> such as the note spacing or system breaks, I wonder how we can be sure that >> it will always cross the melodic line at the desired place. With @bulge or >> @curvedir (with extended values as suggested by Zoltan) this must be even >> more uncertain, right? In principle, a rendering algorithm may draw the >> slur in Benni?s example above the first three groups of notes and below >> only the last group when using @bulge or @curvedir. How do we avoid that? >> >> >> >> One more question about @bulge, again just out of curiosity: Should it be >> defined that a sequence of values for @bulge must an alternating sequence >> of positive and negative values, either in the guidelines or the schema? Or >> would a sequence like the one in the guidelines example (@bulge=?2 1?) make >> any sense in any situation? >> >> >> >> Best, >> >> Axel >> >> >> >> >> >> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de >> ] *P? vegne af *Kom?ves Zolt?n >> *Sendt:* 2. februar 2015 07:08 >> *Til:* Music Encoding Initiative >> *Emne:* Re: [MEI-L] slur and @curvedir >> >> >> >> Hi Perry, >> >> >> >> I think extending the data type of @curvedir attribute could be justified >> simply base on the argument of classification: @curvdir provides a >> classification mechanism, but this classification is rather incomplete, the >> current values of @curvedir do not cover all the cases that are out there >> (see Benni's example: nor "above" neither "below" is appropriate, and the >> omission of the attribute surely cannot imply what we want to convey, that >> is the curve goes also above and below). This has nothing to do with >> rendering, since in order to render a slur or phrase mark, the actual curve >> needs to be calculated anyway, even when "above" or "below" is applied. >> >> >> >> Out of Benni's suggestions I quite like "above-below" / "below-above". >> (Note that his question concerns @curvedir not @place.) In fact, it occurs >> to me, we could even allow an alternating sequence of the values "below" >> and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, >> then above, could also be applied to curves with multiple inflection >> points. I have no literary example for this at hand, but wouldn't be >> surprised if there was some in existence. >> >> >> >> Best >> >> Zoltan >> >> >> >> >> >> >> >> 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) < >> pdr4h at eservices.virginia.edu>: >> >> >> >> Laurent is correct, the values in the example should be -2 and 1. >> >> >> >> The place attribute is for describing the placement of an entity in >> general terms. For phrase marks and slurs, it also generically describes >> the curvature of the mark, and therefore functions as short hand for a more >> detailed description given by the bulge or bezier attributes. It would be >> possible to add a value to @place for slurs/phrases with multiple >> inflection points, such as "mixed" or perhaps "complex", but this would >> only fulfill a classification purpose -- it wouldn't provide any >> information regarding how to draw the slur/phrase. So, one would still >> need to use @bulge or @bezier for rendering. >> >> >> >> Another complicating factor is that @place is used by a number of >> elements other than slur and phrase. Adding "mixed" directly to @place >> would introduce the possibility of nonsense in the case of, say, or >> . Of course, a specialized form of @place for slur/phrase is a >> possibility, but would need careful handling. >> >> >> >> -- >> >> p. >> >> >> >> >> __________________________ >> Perry Roland >> Music Library >> >> University of Virginia >> >> P. O. Box 400175 >> >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> ------------------------------ >> >> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Laurent Pugin [laurent at music.mcgill.ca] >> *Sent:* Sunday, February 01, 2015 8:27 AM >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] slur and @curvedir >> >> Hi Benni, >> >> >> >> Have you looked at @bulge? There is an example in the guidelines: >> http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 >> >> >> >> I would have expected the values to be -2 1 for the given example, so I >> am not sure I understand it correctly. >> >> >> >> Laurent >> >> >> >> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl >> wrote: >> >> Dear MEI-L, >> >> Fresch?tz has a question concerning encoding mixed direction slurs. >> >> >> >> [image: bildschirmfoto 2015-01-30 um 14 05 39] >> >> >> In case the picture doesn't come through, please see: >> https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >> >> >> >> This slur may not be properly encoded in MEI using @curvedir that only >> allows 'above' or 'below' as values. Nevertheless, using *@bezier* >> is much more verbose than needed? >> >> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / >> 'alternating' would be applicable? Of course the schema would have to be >> modified to allow this. Are there any comparable values in other parts of >> the schema? >> >> >> >> This is no "special", rather quite often in printed music from the 19th >> century. >> >> >> >> All the best, >> >> 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: not available URL: From donbyrd at indiana.edu Tue Feb 3 16:39:45 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Tue, 3 Feb 2015 15:39:45 +0000 Subject: [MEI-L] slur and @curvedir; exx with multiple inflection points In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: It's not surprising this is a difficult question: slurs are surely _the_ most graphically complex symbols in CWMN. I like Laurent's idea; it allows a more abstract way to describe slurs while keeping the generality of bezier curves. The question has been raised of actual examples of slurs with multiple inflection points. The most complex slur I know of -- it has 10 inflection points, spans three systems, and repeatedly crosses three staves! -- appears in my "Gallery of Interesting Music Notation", at http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html It's in a huge piano piece by Sorabji. But there's an impressive runner-up in a far better-known piece: the Minuet in Ravel's Tombeau de Couperin has a slur with 7 inflection points. There are even _ties_ with multiple inflection points, e.g., in the Goldberg Variations, no. 16, Kirkpatrick/Schirmer edition. All of these examples and several more appear in the list of Extremes of Conventional Music Notation that I've been working for several decades :-) . At http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm --Don On Feb 3, 2015, at 10:05 AM, Laurent Pugin wrote: > Hi Perry, > > One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > > > Best, > > Axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > > This is no "special", rather quite often in printed music from the 19th century. > > > > All the best, > > Benjamin > > > > _______________________________________________ > 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 bohl at edirom.de Thu Feb 5 14:47:15 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 05 Feb 2015 14:47:15 +0100 Subject: [MEI-L] slur and @curvedir; exx with multiple inflection points In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: <54D37463.2020405@edirom.de> Dear all, many thanks for your replies to my initial question, I never thought could result in such great discussion! Excuse my silence, but I had to catch up with the discussion after a couple of days of absence ;-) My problem is much simpler than any thought about rendering... I simply would like to state, there's a slur from note A to note Y, and in terms of source diplomatics, indicate, that there's a special type of rendition. As we're not intending to go into the very details of rendering and precise description of the curvature (because I'd like to handle all slurs equally and I don't want to give @bulge or @bezier for all of them) I thought some statement classifying the speciality at this point might be interesting. I'll have to investigate how often we have special cases and think about your hints! (thanks again) In the end I need but a most simplistic solution ;-) Cheers, Benni *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 03.02.2015 um 16:39 schrieb Byrd, Donald A.: > It's not surprising this is a difficult question: slurs are surely _the_ most graphically complex symbols in CWMN. > > I like Laurent's idea; it allows a more abstract way to describe slurs while keeping the generality of bezier curves. > > The question has been raised of actual examples of slurs with multiple inflection points. The most complex slur I know of -- it has 10 inflection points, spans three systems, and repeatedly crosses three staves! -- appears in my "Gallery of Interesting Music Notation", at > > http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html > > It's in a huge piano piece by Sorabji. But there's an impressive runner-up in a far better-known piece: the Minuet in Ravel's Tombeau de Couperin has a slur with 7 inflection points. There are even _ties_ with multiple inflection points, e.g., in the Goldberg Variations, no. 16, Kirkpatrick/Schirmer edition. All of these examples and several more appear in the list of Extremes of Conventional Music Notation that I've been working for several decades :-) . At > > http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm > > --Don > > > On Feb 3, 2015, at 10:05 AM, Laurent Pugin > wrote: > >> Hi Perry, >> >> One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. >> >> Laurent >> >> PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? >> >> On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: >> Hi Raffaele, >> >> Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. >> >> This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. >> >> Of course, only those with more knowledge and experience with this stuff can say for sure. >> Laurent? Craig? Zoltan? Want to join in? >> >> -- >> p. >> >> __________________________ >> Perry Roland >> Music Library >> University of Virginia >> P. O. Box 400175 >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] >> Sent: Tuesday, February 03, 2015 9:29 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] slur and @curvedir >> >> Hi all, >> >> I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). >> >> Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. >> >> Raff >> >> On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: >> Hi Perry >> >> >> >> Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) >> >> >> >> Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! >> >> As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. >> >> >> >> Best, >> >> Axel >> >> >> >> Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) >> Sendt: 2. februar 2015 20:14 >> >> >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] slur and @curvedir >> >> >> >> Hi Axel, >> >> >> >> One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. >> >> >> >> @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. >> >> >> >> @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. >> >> >> >> "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. >> >> >> >> The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. >> >> >> >> @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. >> >> >> >> Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. >> >> >> >> -- >> >> p. >> >> >> >> __________________________ >> Perry Roland >> Music Library >> >> University of Virginia >> >> P. O. Box 400175 >> >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> >> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] >> Sent: Monday, February 02, 2015 3:29 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] slur and @curvedir >> >> Hi all >> >> >> >> Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? >> >> >> >> One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? >> >> >> >> Best, >> >> Axel >> >> >> >> >> >> Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n >> Sendt: 2. februar 2015 07:08 >> Til: Music Encoding Initiative >> Emne: Re: [MEI-L] slur and @curvedir >> >> >> >> Hi Perry, >> >> >> >> I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. >> >> >> >> Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. >> >> >> >> Best >> >> Zoltan >> >> >> >> >> >> >> >> 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : >> >> >> >> Laurent is correct, the values in the example should be -2 and 1. >> >> >> >> The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. >> >> >> >> Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. >> >> >> >> -- >> >> p. >> >> >> >> >> __________________________ >> Perry Roland >> Music Library >> >> University of Virginia >> >> P. O. Box 400175 >> >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> >> From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] >> Sent: Sunday, February 01, 2015 8:27 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] slur and @curvedir >> >> Hi Benni, >> >> >> >> Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 >> >> >> >> I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. >> >> >> >> Laurent >> >> >> >> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: >> >> Dear MEI-L, >> >> Fresch?tz has a question concerning encoding mixed direction slurs. >> >> >> >> >> >> In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >> >> >> >> This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? >> >> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? >> >> >> >> This is no "special", rather quite often in printed music from the 19th century. >> >> >> >> All the best, >> >> Benjamin >> >> >> >> _______________________________________________ >> 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 From lxpugin at gmail.com Fri Feb 6 18:08:27 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Fri, 6 Feb 2015 18:08:27 +0100 Subject: [MEI-L] Technical team Message-ID: Dear all, During the first online meeting of the newly elected MEI board, Perry and I were appointed co-chairs of the MEI technical team. We are both very much looking forward to these new roles and to working with all those who have contributed to MEI development in the past and those who would like to be involved in its future. As in the past, and according to the recently approved by-laws, the technical team gathers people willing to contribute to the development of the MEI schema, Guidelines, and associated software with no election requirement. Despite the name of the team, specific technical knowledge is not required for participation and no one should feel excluded, even those who don't write computer programs. Many aspects have to be considered in the development of MEI and a wide range of expertise is highly desirable. Our initial tasks will include organization of the technical team itself and workflows for continued development. If you are interested in participating in these discussions and contributing to MEI development, please contact one of us (Laurent at lxpugin at gmail.com or Perry at pdr4h at virginia.edu). Plans are already underway for a new version of MEI to be released sometime after the conference in Florence. In order to demonstrate solutions to issues already raised and serve as a springboard for additional discussion, an ODD customization is being prepared, which we hope to make available before the conference. In addition to online discussions, we think that it would be a good idea to hold at least two meetings a year, for example a face-to-face meeting in conjunction with the conference in May and a virtual meeting in the Fall. In keeping with this plan, we will hold our first meeting during the conference in Florence, most likely during the un-conference day on Thursday, May 21st. Looking forward to your participation, Laurent and Perry -------------- next part -------------- An HTML attachment was scrubbed... URL: From zolaemil at gmail.com Tue Feb 10 19:30:21 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 10 Feb 2015 18:30:21 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: Hi Perry, 1. >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: and in the first measure of the following system after figure 9: (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) 3. >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? Best Zoltan 2015-02-03 15:05 GMT+00:00 Laurent Pugin : > Hi Perry, > > One option I think could be interesting to add for providing more > flexibility is the possibility to specify the bezier points with a > percentage for the horizontal position of the intermediate points (0 to > 100) and vertical units (as in @bulge) for vertical positions. This would > be much easier to draw on a black-board. I'll try to prepare a couple of > example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and > Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> Hi Raffaele, >> >> Using @bezier only "locks" the rendering if the control points are >> specified as absolute page coordinates. If they're given as offsets from >> something else, such as a particular note, then the rendition of the slur >> is dependent on the position of that thing. >> >> This is how I envision it working. It's possible that moving the >> bezier control points (even if they're moved relative to everything else) >> will change the shape of the curve. If that's true, then our only >> mechanism for controlling a slur is through the use of @bulge. For >> automatic layout without any user intervention, the only mechanism is >> @curvedir -- remembering that values in @curvedir cannot possibly result in >> a perfect rendition every time. It seems there truly is no way to have the >> cake and eat it too, hence the comment which began my initial response to >> Benni. >> >> Of course, only those with more knowledge and experience with this >> stuff can say for sure. >> Laurent? Craig? Zoltan? Want to join in? >> >> -- >> p. >> >> __________________________ >> Perry Roland >> Music Library >> University of Virginia >> P. O. Box 400175 >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> ------------------------------ >> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Raffaele Viglianti [raffaeleviglianti at gmail.com] >> *Sent:* Tuesday, February 03, 2015 9:29 AM >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] slur and @curvedir >> >> Hi all, >> >> I find Perry's explanation really helpful and interesting, particularly >> concerning the the sharing of responsibilities between the encoder and the >> renderer. Encoding @bezier before rendering locks the encoding into only >> one possible rendering, which is not great for the reflowing that a truly >> dynamic score should allow. Unless the aim of the encoder is to >> represent/document the curvature of one specific written source, which is a >> totally legitimate approach (and might be what Benni is after?). >> >> Having two slurs and joining them, instead, seems conceptually wrong to >> me: there is only one slur and no real XML overlapping (or other >> limitation) that would justify, arguably, splitting the element in two. >> >> Raff >> >> On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: >> >>> Hi Perry >>> >>> >>> >>> Thanks for your elaborate reply. As always I wasn?t aware of any worms >>> involved, but I did realize that there is no single or easy answer :-) >>> >>> >>> >>> Drawing a complex slur that not only avoids collisions with other >>> objects but is also aesthetically satisfying can be quite a challenge. My >>> deepest respect for people working on rendering slurs! >>> >>> As you say, it almost always requires visual control and corrections to >>> get it right. But recording the corrections also means that they will have >>> to be encodable somehow, that is, in more detail than possible with >>> @bezier, for instance. I have no immediate ideas about how to solve this in >>> a medium as fluid as music notation. >>> >>> >>> >>> Best, >>> >>> Axel >>> >>> >>> >>> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *P? vegne af >>> *Roland, Perry D. (pdr4h) >>> *Sendt:* 2. februar 2015 20:14 >>> >>> *Til:* Music Encoding Initiative >>> *Emne:* Re: [MEI-L] slur and @curvedir >>> >>> >>> >>> Hi Axel, >>> >>> >>> >>> One comment before I answer your questions -- This is a huge can of >>> worms for which it seems there can never be a single, universally >>> satisfying answer. >>> >>> >>> >>> @curvedir only provides minimal information about the slur so a renderer >>> must "figure out" the rest. This is the easiest method for the encoder, but >>> requires a lot more intelligence on the part of the rendering engine, for >>> example with regard to collision avoidance. From another angle, however, it >>> provides the greatest amount of flexibility for the renderer to arrive at >>> the final shape of the slur. Like I said before, aside from providing a >>> more detailed classification purpose, allowing curvdir="above below above >>> below (and so on)" doesn't really provide much rendering help because, just >>> as you've observed, it says nothing about the location of the points where >>> the slur is supposed to bend back on itself. >>> >>> >>> >>> @bulge attempts to provide this missing information by indicating >>> distance from an imaginary line between the end points of the slur. >>> Providing two values means the distance between the end points should be >>> halved and a curve drawn that passes through the starting point, the point >>> indicated by the 1st value in @bulge, the mid-point of the line, the point >>> indicated by the 2nd value, and the ending point. Three values would mean >>> dividing the distance between the end points by thirds, etc. >>> >>> >>> >>> "Simple" slurs (i.e., ones that don't alternate sides of the imaginary >>> line) can be drawn with @bulge by supplying only a single value or by >>> giving only positive or only negative values. Doing this, instead of using >>> @curvedir, places the shape of the slur in the control of the encoder >>> instead of the rendering engine, but puts the burden of "scribing" the >>> shape on the encoder. The ability to draw "simple" slurs is why @bulge >>> can't be constrained to alternating positive and negative values. >>> >>> >>> >>> The example provided in the Guidelines should use the values -2 and 1. >>> The diagram is also misleading in that the lines connecting the curve with >>> the imaginary line should divide their respective sections of the curve >>> into equal parts; that is, the line illustrating point 1 should be drawn at >>> the "highest" point of the curve, mid-way between the mid-point of the >>> imaginary line and the end point of the slur. >>> >>> >>> >>> @bezier provides the most encoder control over the rendition of the >>> slur. But unless the control points of the curve are expressed as offsets >>> from some musical feature (like a note, for instance), then re-flowing the >>> notation will "disconnect" the slur from it and the slur will end up in the >>> wrong place on the page. So, the bezier control points have to be >>> *offsets* from something, presumably from the features pointed at by the >>> @startid and @endid attributes, as long as the notation is expected to be >>> "edit-able". The @startid, @endid, @bezier combination will move the >>> slur with the notation. The problem with bezier control points is the same >>> as with @bulge values -- it's nearly impossible for one to create them >>> without the aid of some kind of drawing environment or iterative >>> "code/view/code" workflow. >>> >>> >>> >>> Without a doubt, a better explanation of this stuff is desperately >>> needed the Guidelines. But, there may also be better ways of recording the >>> information necessary for drawing slurs than what is provided by the >>> current set of attributes. I welcome contributions on either front. >>> >>> >>> >>> -- >>> >>> p. >>> >>> >>> >>> __________________________ >>> Perry Roland >>> Music Library >>> >>> University of Virginia >>> >>> P. O. Box 400175 >>> >>> Charlottesville, VA 22904 >>> 434-982-2702 (w) >>> pdr4h (at) virginia (dot) edu >>> ------------------------------ >>> >>> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel >>> Teich Geertinger [atge at kb.dk] >>> *Sent:* Monday, February 02, 2015 3:29 AM >>> *To:* Music Encoding Initiative >>> *Subject:* Re: [MEI-L] slur and @curvedir >>> >>> Hi all >>> >>> >>> >>> Just out of curiosity: None of the solutions I have seen (@bulge, >>> @bezier, or @curvedir=?above below?) do indicate explicitly where the slur >>> changes position from above the notes to below ? that is, where the slur >>> intersects the melodic line, so to speak. I guess that the use of @bezier >>> will give the desired result in most situations, but as the actual >>> rendering of the slur must be dependent to some degree on other factors >>> such as the note spacing or system breaks, I wonder how we can be sure that >>> it will always cross the melodic line at the desired place. With @bulge or >>> @curvedir (with extended values as suggested by Zoltan) this must be even >>> more uncertain, right? In principle, a rendering algorithm may draw the >>> slur in Benni?s example above the first three groups of notes and below >>> only the last group when using @bulge or @curvedir. How do we avoid that? >>> >>> >>> >>> One more question about @bulge, again just out of curiosity: Should it >>> be defined that a sequence of values for @bulge must an alternating >>> sequence of positive and negative values, either in the guidelines or the >>> schema? Or would a sequence like the one in the guidelines example >>> (@bulge=?2 1?) make any sense in any situation? >>> >>> >>> >>> Best, >>> >>> Axel >>> >>> >>> >>> >>> >>> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de >>> ] *P? vegne af *Kom?ves Zolt?n >>> *Sendt:* 2. februar 2015 07:08 >>> *Til:* Music Encoding Initiative >>> *Emne:* Re: [MEI-L] slur and @curvedir >>> >>> >>> >>> Hi Perry, >>> >>> >>> >>> I think extending the data type of @curvedir attribute could be >>> justified simply base on the argument of classification: @curvdir provides >>> a classification mechanism, but this classification is rather incomplete, >>> the current values of @curvedir do not cover all the cases that are out >>> there (see Benni's example: nor "above" neither "below" is appropriate, and >>> the omission of the attribute surely cannot imply what we want to convey, >>> that is the curve goes also above and below). This has nothing to do with >>> rendering, since in order to render a slur or phrase mark, the actual curve >>> needs to be calculated anyway, even when "above" or "below" is applied. >>> >>> >>> >>> Out of Benni's suggestions I quite like "above-below" / "below-above". >>> (Note that his question concerns @curvedir not @place.) In fact, it occurs >>> to me, we could even allow an alternating sequence of the values "below" >>> and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, >>> then above, could also be applied to curves with multiple inflection >>> points. I have no literary example for this at hand, but wouldn't be >>> surprised if there was some in existence. >>> >>> >>> >>> Best >>> >>> Zoltan >>> >>> >>> >>> >>> >>> >>> >>> 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) < >>> pdr4h at eservices.virginia.edu>: >>> >>> >>> >>> Laurent is correct, the values in the example should be -2 and 1. >>> >>> >>> >>> The place attribute is for describing the placement of an entity in >>> general terms. For phrase marks and slurs, it also generically describes >>> the curvature of the mark, and therefore functions as short hand for a more >>> detailed description given by the bulge or bezier attributes. It would be >>> possible to add a value to @place for slurs/phrases with multiple >>> inflection points, such as "mixed" or perhaps "complex", but this would >>> only fulfill a classification purpose -- it wouldn't provide any >>> information regarding how to draw the slur/phrase. So, one would still >>> need to use @bulge or @bezier for rendering. >>> >>> >>> >>> Another complicating factor is that @place is used by a number of >>> elements other than slur and phrase. Adding "mixed" directly to @place >>> would introduce the possibility of nonsense in the case of, say, or >>> . Of course, a specialized form of @place for slur/phrase is a >>> possibility, but would need careful handling. >>> >>> >>> >>> -- >>> >>> p. >>> >>> >>> >>> >>> __________________________ >>> Perry Roland >>> Music Library >>> >>> University of Virginia >>> >>> P. O. Box 400175 >>> >>> Charlottesville, VA 22904 >>> 434-982-2702 (w) >>> pdr4h (at) virginia (dot) edu >>> ------------------------------ >>> >>> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >>> Laurent Pugin [laurent at music.mcgill.ca] >>> *Sent:* Sunday, February 01, 2015 8:27 AM >>> *To:* Music Encoding Initiative >>> *Subject:* Re: [MEI-L] slur and @curvedir >>> >>> Hi Benni, >>> >>> >>> >>> Have you looked at @bulge? There is an example in the guidelines: >>> http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 >>> >>> >>> >>> I would have expected the values to be -2 1 for the given example, so I >>> am not sure I understand it correctly. >>> >>> >>> >>> Laurent >>> >>> >>> >>> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl >>> wrote: >>> >>> Dear MEI-L, >>> >>> Fresch?tz has a question concerning encoding mixed direction slurs. >>> >>> >>> >>> [image: bildschirmfoto 2015-01-30 um 14 05 39] >>> >>> >>> In case the picture doesn't come through, please see: >>> https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 >>> >>> >>> >>> This slur may not be properly encoded in MEI using @curvedir that only >>> allows 'above' or 'below' as values. Nevertheless, using *@bezier* >>> is much more verbose than needed? >>> >>> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' >>> / 'alternating' would be applicable? Of course the schema would have to be >>> modified to allow this. Are there any comparable values in other parts of >>> the schema? >>> >>> >>> >>> This is no "special", rather quite often in printed music from the 19th >>> century. >>> >>> >>> >>> All the best, >>> >>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2015-02-10 17:33:03.png Type: image/png Size: 65035 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Tue Feb 10 22:16:09 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 10 Feb 2015 21:16:09 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: There?s no single answer to this. Whether one chooses to encode a single slur or chooses to create two depends on the purpose for the encoding -- a single slur is better for analytical purposes, but two may be better for rendering. To fit both simultaneously, one can use , for example -- The @join attribute on slur exists to indicate that multiple slurs are conceptually one, not to provide rendering info. I contend that @curvedir *can* provide a so-called ?rendering hint?, but I agree that the rendering engine has to be pretty intelligent to make use of it -- Mup seems to do a reasonable job with only this much information. I have no problem extending the values permitted in @curvedir, but I think over-specification there is not likely to be of much help. A value of ?complex? is about as far as I think we can go down that path. -- p. From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] Sent: Tuesday, February 10, 2015 1:30 PM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] slur and @curvedir Hi Perry, 1. >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: and in the first measure of the following system after figure 9: (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) 3. >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? Best Zoltan 2015-02-03 15:05 GMT+00:00 Laurent Pugin >: Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From atge at kb.dk Wed Feb 11 09:54:02 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 11 Feb 2015 08:54:02 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> There is something that has been puzzling me: I don?t think I have completely grasped the idea of @join when used with slurs (I haven?t really thought about other uses, though). It seems to me to be redundant. In which situation would it be necessary to explicitly encode that a slur needs to be interrupted at a system break? Doesn?t the system break itself provide all information necessary, leaving the actual division into two half-slurs to the rendering engine? Is there any thinkable situation where an encoded or an automatically generated system break would not imply the splitting of the slur at that point? Or the other way around: would it be necessary to split one (that is, logically one) slur into two (that is, graphically two) parts in any other situation? On editing or rendering a score (not necessarily following the exact layout of a particular source), the system break may change position. I that case, I would even have to update the endpoint of the first and the starting point of the second (half-)slur, right? What is the benefit from this operation? I agree with Zoltan that a slur should be encoded as one element, even when it has to be rendered as two distinct graphical objects _in some situations_. It makes me wonder whether an attribute like @join would be more useful to indicate the location of the points where a complex slur changes direction of bending (the joints, in terms of joined slurs with alternating curve direction). Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 10. februar 2015 22:16 Til: Music Encoding Initiative Cc: zoltan.komives at gmail.com Emne: Re: [MEI-L] slur and @curvedir There?s no single answer to this. Whether one chooses to encode a single slur or chooses to create two depends on the purpose for the encoding -- a single slur is better for analytical purposes, but two may be better for rendering. To fit both simultaneously, one can use , for example -- The @join attribute on slur exists to indicate that multiple slurs are conceptually one, not to provide rendering info. I contend that @curvedir *can* provide a so-called ?rendering hint?, but I agree that the rendering engine has to be pretty intelligent to make use of it -- Mup seems to do a reasonable job with only this much information. I have no problem extending the values permitted in @curvedir, but I think over-specification there is not likely to be of much help. A value of ?complex? is about as far as I think we can go down that path. -- p. From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] Sent: Tuesday, February 10, 2015 1:30 PM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] slur and @curvedir Hi Perry, 1. >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: and in the first measure of the following system after figure 9: (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) 3. >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? Best Zoltan 2015-02-03 15:05 GMT+00:00 Laurent Pugin >: Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From donbyrd at indiana.edu Wed Feb 11 14:01:33 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Wed, 11 Feb 2015 13:01:33 +0000 Subject: [MEI-L] slur and @curvedir; moving Bezier control points In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: A belated comment on Perry's message of a week ago, just below. I don't see how moving the Bezier control points "along with everything else" can possibly change the shape of the curve. If you move everything 5.347 mm to the right and 2.718 mm down, the curve will have exactly the same shape; it'll just be 5.347 mm to the right and 2.718 mm down, and in precisely the same position relative to the rest of the notation. Nightingale stores Bezier control points as offsets from note heads. If you move the note heads, of course the curve follows along; the coordinates actually used to draw the curve are the new coordinates of the note heads plus the offsets. Or am I misunderstanding? --Don > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > > > Best, > > Axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > > This is no "special", rather quite often in printed music from the 19th century. > > > > All the best, > > Benjamin > > > > _______________________________________________ > 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 pdr4h at eservices.virginia.edu Wed Feb 11 16:53:40 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Feb 2015 15:53:40 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, You?re absolutely right when you say that a rendering engine ought to be smart enough to intelligently break a slur across a system or page break. BUT, there might be situations where the software you?re using simply isn?t. Or where it wants to break the slur in a way that you feel isn?t exactly right. How can one ?regain control? from the ?rendering engine overlord? run amok? One possibility is not give control to it in the first place; that is, specify *exactly* how you want the slur to be broken up by breaking it yourself and specifying where the pieces should be drawn. Once you?ve done that, however, you want to leave a breadcrumb trail indicating how to get back to the generic single-slur state. That?s the purpose of @join. Obviously, once you?ve split the slur, performing additional changes, such as moving the system or page break, means your carefully crafted slurs will be in the wrong place. So, this procedure isn?t recommended for material that could change. But it?s essential, I think, when you?ve placed everything ?just so? (say for printing on paper) and you don?t want anything to move. In this case, MEI is functioning as an intermediate format for printing that comes at the end of processing chain. Bezier control points remove the need to specify the inflection points of a curve. Moving the control points also moves the inflection points. Using Bezier curves is more efficient, hence their adoption in a lot of graphical editing environments @bulge already does something similar to what you?re suggesting, but by specifying the points at which the curve ?crests?, rather than where it changes direction. I admit it?s a fairly blunt instrument, but sometimes that?s all that?s required. The bulge concept is borrowed from Mup, which aims to achieve what I?d call ?pass-able? rendering more-or-less automatically without a lot of user input. @bulge gives a moderate amount of control over the shape of the curve without the aid of a GUI environment. It?s in the middle of the continuum of control from ?fully automatic? () to ?fully user-controlled? (). Which is also a continuum from ?most flexible? to ?most stable/fixed?. ? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, February 11, 2015 3:54 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir There is something that has been puzzling me: I don?t think I have completely grasped the idea of @join when used with slurs (I haven?t really thought about other uses, though). It seems to me to be redundant. In which situation would it be necessary to explicitly encode that a slur needs to be interrupted at a system break? Doesn?t the system break itself provide all information necessary, leaving the actual division into two half-slurs to the rendering engine? Is there any thinkable situation where an encoded or an automatically generated system break would not imply the splitting of the slur at that point? Or the other way around: would it be necessary to split one (that is, logically one) slur into two (that is, graphically two) parts in any other situation? On editing or rendering a score (not necessarily following the exact layout of a particular source), the system break may change position. I that case, I would even have to update the endpoint of the first and the starting point of the second (half-)slur, right? What is the benefit from this operation? I agree with Zoltan that a slur should be encoded as one element, even when it has to be rendered as two distinct graphical objects _in some situations_. It makes me wonder whether an attribute like @join would be more useful to indicate the location of the points where a complex slur changes direction of bending (the joints, in terms of joined slurs with alternating curve direction). Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 10. februar 2015 22:16 Til: Music Encoding Initiative Cc: zoltan.komives at gmail.com Emne: Re: [MEI-L] slur and @curvedir There?s no single answer to this. Whether one chooses to encode a single slur or chooses to create two depends on the purpose for the encoding -- a single slur is better for analytical purposes, but two may be better for rendering. To fit both simultaneously, one can use , for example -- The @join attribute on slur exists to indicate that multiple slurs are conceptually one, not to provide rendering info. I contend that @curvedir *can* provide a so-called ?rendering hint?, but I agree that the rendering engine has to be pretty intelligent to make use of it -- Mup seems to do a reasonable job with only this much information. I have no problem extending the values permitted in @curvedir, but I think over-specification there is not likely to be of much help. A value of ?complex? is about as far as I think we can go down that path. -- p. From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] Sent: Tuesday, February 10, 2015 1:30 PM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] slur and @curvedir Hi Perry, 1. >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: and in the first measure of the following system after figure 9: (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) 3. >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? Best Zoltan 2015-02-03 15:05 GMT+00:00 Laurent Pugin >: Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From donbyrd at indiana.edu Wed Feb 11 22:04:37 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Wed, 11 Feb 2015 21:04:37 +0000 Subject: [MEI-L] slur and @curvedir: exact control & joins In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> Message-ID: Perry is right about the need, sometimes, for exact control of slur shape. I predict it'll be many years before any music rendering engine consistently does a really good job breaking slurs. What if the slur changes staff at the system break? Take a look at http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html How well would any existing rendering engine determine shape automatically do with the Sorabji slur? That's a very extreme case, but in the (more reasonable) example from Ravel's Scarbo, how well would any rendering engine do automatically at the system break at the end of the example? Answer: Not well enough for, say, Barenreiter. HOWEVER, it's also highly desirable that it be possible to encode slurs with multiple inflection points as single objects. Yes, you could encode them as separate curves that happen to coincide or overlap, but you'll never get the proper tapering at the joins that way. --Don On Feb 11, 2015, at 10:53 AM, "Roland, Perry D. (pdr4h)" wrote: > > Hi Axel, > > You?re absolutely right when you say that a rendering engine ought to be smart enough to intelligently break a slur across a system or page break. BUT, there might be situations where the software you?re using simply isn?t. Or where it wants to break the slur in a way that you feel isn?t exactly right. How can one ?regain control? from the ?rendering engine overlord? run amok? One possibility is not give control to it in the first place; that is, specify *exactly* how you want the slur to be broken up by breaking it yourself and specifying where the pieces should be drawn. Once you?ve done that, however, you want to leave a breadcrumb trail indicating how to get back to the generic single-slur state. That?s the purpose of @join. > > Obviously, once you?ve split the slur, performing additional changes, such as moving the system or page break, means your carefully crafted slurs will be in the wrong place. So, this procedure isn?t recommended for material that could change. But it?s essential, I think, when you?ve placed everything ?just so? (say for printing on paper) and you don?t want anything to move. In this case, MEI is functioning as an intermediate format for printing that comes at the end of processing chain. > > Bezier control points remove the need to specify the inflection points of a curve. Moving the control points also moves the inflection points. Using Bezier curves is more efficient, hence their adoption in a lot of graphical editing environments > > @bulge already does something similar to what you?re suggesting, but by specifying the points at which the curve ?crests?, rather than where it changes direction. I admit it?s a fairly blunt instrument, but sometimes that?s all that?s required. The bulge concept is borrowed from Mup, which aims to achieve what I?d call ?pass-able? rendering more-or-less automatically without a lot of user input. @bulge gives a moderate amount of control over the shape of the curve without the aid of a GUI environment. It?s in the middle of the continuum of control from ?fully automatic? () to ?fully user-controlled? (). Which is also a continuum from ?most flexible? to ?most stable/fixed?. J > > -- > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Wednesday, February 11, 2015 3:54 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > There is something that has been puzzling me: I don?t think I have completely grasped the idea of @join when used with slurs (I haven?t really thought about other uses, though). It seems to me to be redundant. In which situation would it be necessary to explicitly encode that a slur needs to be interrupted at a system break? Doesn?t the system break itself provide all information necessary, leaving the actual division into two half-slurs to the rendering engine? Is there any thinkable situation where an encoded or an automatically generated system break would not imply the splitting of the slur at that point? Or the other way around: would it be necessary to split one (that is, logically one) slur into two (that is, graphically two) parts in any other situation? > > On editing or rendering a score (not necessarily following the exact layout of a particular source), the system break may change position. I that case, I would even have to update the endpoint of the first and the starting point of the second (half-)slur, right? What is the benefit from this operation? > > I agree with Zoltan that a slur should be encoded as one element, even when it has to be rendered as two distinct graphical objects _in some situations_. It makes me wonder whether an attribute like @join would be more useful to indicate the location of the points where a complex slur changes direction of bending (the joints, in terms of joined slurs with alternating curve direction). > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 10. februar 2015 22:16 > Til: Music Encoding Initiative > Cc: zoltan.komives at gmail.com > Emne: Re: [MEI-L] slur and @curvedir > > > There?s no single answer to this. Whether one chooses to encode a single slur or chooses to create two depends on the purpose for the encoding -- a single slur is better for analytical purposes, but two may be better for rendering. To fit both simultaneously, one can use , for example -- > > > > > > > > > > > > > > The @join attribute on slur exists to indicate that multiple slurs are conceptually one, not to provide rendering info. > > I contend that @curvedir *can* provide a so-called ?rendering hint?, but I agree that the rendering engine has to be pretty intelligent to make use of it -- Mup seems to do a reasonable job with only this much information. I have no problem extending the values permitted in @curvedir, but I think over-specification there is not likely to be of much help. A value of ?complex? is about as far as I think we can go down that path. > > -- > p. > > > From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] > Sent: Tuesday, February 10, 2015 1:30 PM > To: Music Encoding Initiative > Cc: Roland, Perry D. (pdr4h) > Subject: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > 1. > >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. > > 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. > > Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: > > and in the first measure of the following system after figure 9: > (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) > > I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) > > 3. > >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir > * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? > > Best > Zoltan > > 2015-02-03 15:05 GMT+00:00 Laurent Pugin : > Hi Perry, > > One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne afRoland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Axel, > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > Best > Zoltan > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > This is no "special", rather quite often in printed music from the 19th century. > > > All the best, > Benjamin > > _______________________________________________ > 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 pdr4h at eservices.virginia.edu Wed Feb 11 22:37:49 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Feb 2015 21:37:49 +0000 Subject: [MEI-L] slur and @curvedir: exact control & joins In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> Message-ID: Don's right -- this level of complexity of slurs can't be dealt with automatically. Human intervention is required. BUT, that intervention comes with a cost -- not unlike the case with Heisenberg uncertainty principle, one can't represent the Sorabji as a single entity and still have a high degree of control over its shape. To have maximum control over the shape, the single slur (I presume it even continues on the next system/page) must be broken into at least two separate entities, each with their own set of control points. I recognize that this is not ideal, but I believe it's the best that can be achieved at present. If multiple curves are used, are there mathematical functions / smoothing algorithms for "easing" one slur into another when they have a shared end/start point? Just for fun and/or extra credit, how would one handle this slur/these slurs in Finale, Sibelius, or (God help me asking) SCORE? It looks to me like the slur/slurs in the Sorabji example have actually been "drawn in" by hand, but it's pretty hard to do that with a digital file. :-) Well, unless you print it and then draw the slurs on the paper. :-( -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni- > paderborn.de] On Behalf Of Byrd, Donald A. > Sent: Wednesday, February 11, 2015 4:05 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir: exact control & joins > > Perry is right about the need, sometimes, for exact control of slur shape. I > predict it'll be many years before any music rendering engine consistently > does a really good job breaking slurs. What if the slur changes staff at the > system break? Take a look at > > http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html > > How well would any existing rendering engine determine shape > automatically do with the Sorabji slur? That's a very extreme case, but in > the (more reasonable) example from Ravel's Scarbo, how well would any > rendering engine do automatically at the system break at the end of the > example? Answer: Not well enough for, say, Barenreiter. > > HOWEVER, it's also highly desirable that it be possible to encode slurs with > multiple inflection points as single objects. Yes, you could encode them as > separate curves that happen to coincide or overlap, but you'll never get the > proper tapering at the joins that way. > > --Don > > > On Feb 11, 2015, at 10:53 AM, "Roland, Perry D. (pdr4h)" > wrote: > > > > > Hi Axel, > > > > You?re absolutely right when you say that a rendering engine ought to be > smart enough to intelligently break a slur across a system or page break. > BUT, there might be situations where the software you?re using simply isn?t. > Or where it wants to break the slur in a way that you feel isn?t exactly right. > How can one ?regain control? from the ?rendering engine overlord? run > amok? One possibility is not give control to it in the first place; that is, > specify *exactly* how you want the slur to be broken up by breaking it > yourself and specifying where the pieces should be drawn. Once you?ve > done that, however, you want to leave a breadcrumb trail indicating how to > get back to the generic single-slur state. That?s the purpose of @join. > > > > Obviously, once you?ve split the slur, performing additional changes, such > as moving the system or page break, means your carefully crafted slurs will > be in the wrong place. So, this procedure isn?t recommended for material > that could change. But it?s essential, I think, when you?ve placed everything > ?just so? (say for printing on paper) and you don?t want anything to move. > In this case, MEI is functioning as an intermediate format for printing that > comes at the end of processing chain. > > > > Bezier control points remove the need to specify the inflection points of a > curve. Moving the control points also moves the inflection points. Using > Bezier curves is more efficient, hence their adoption in a lot of graphical > editing environments > > > > @bulge already does something similar to what you?re suggesting, but by > specifying the points at which the curve ?crests?, rather than where it > changes direction. I admit it?s a fairly blunt instrument, but sometimes > that?s all that?s required. The bulge concept is borrowed from Mup, which > aims to achieve what I?d call ?pass-able? rendering more-or-less > automatically without a lot of user input. @bulge gives a moderate amount > of control over the shape of the curve without the aid of a GUI > environment. It?s in the middle of the continuum of control from ?fully > automatic? () to ?fully user-controlled? > (). Which is also a > continuum from ?most flexible? to ?most stable/fixed?. J > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Axel Teich Geertinger > > Sent: Wednesday, February 11, 2015 3:54 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > There is something that has been puzzling me: I don?t think I have > completely grasped the idea of @join when used with slurs (I haven?t really > thought about other uses, though). It seems to me to be redundant. In > which situation would it be necessary to explicitly encode that a slur needs > to be interrupted at a system break? Doesn?t the system break itself provide > all information necessary, leaving the actual division into two half-slurs to > the rendering engine? Is there any thinkable situation where an encoded > or an automatically generated system break would not imply the > splitting of the slur at that point? Or the other way around: would it be > necessary to split one (that is, logically one) slur into two (that is, > graphically two) parts in any other situation? > > > > On editing or rendering a score (not necessarily following the exact layout > of a particular source), the system break may change position. I that case, I > would even have to update the endpoint of the first and the starting point > of the second (half-)slur, right? What is the benefit from this operation? > > > > I agree with Zoltan that a slur should be encoded as one element, even > when it has to be rendered as two distinct graphical objects _in some > situations_. It makes me wonder whether an attribute like @join would be > more useful to indicate the location of the points where a complex slur > changes direction of bending (the joints, in terms of joined slurs with > alternating curve direction). > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Roland, Perry D. (pdr4h) > > Sendt: 10. februar 2015 22:16 > > Til: Music Encoding Initiative > > Cc: zoltan.komives at gmail.com > > Emne: Re: [MEI-L] slur and @curvedir > > > > > > There?s no single answer to this. Whether one chooses to encode a single > slur or chooses to create two depends on the purpose for the encoding -- a > single slur is better for analytical purposes, but two may be better for > rendering. To fit both simultaneously, one can use , for example -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > The @join attribute on slur exists to indicate that multiple slurs are > conceptually one, not to provide rendering info. > > > > I contend that @curvedir *can* provide a so-called ?rendering hint?, but I > agree that the rendering engine has to be pretty intelligent to make use of it > -- Mup seems to do a reasonable job with only this much information. I > have no problem extending the values permitted in @curvedir, but I think > over-specification there is not likely to be of much help. A value of > ?complex? is about as far as I think we can go down that path. > > > > -- > > p. > > > > > > From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] > > Sent: Tuesday, February 10, 2015 1:30 PM > > To: Music Encoding Initiative > > Cc: Roland, Perry D. (pdr4h) > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > 1. > > >[Raff]: Having two slurs and joining them, instead, seems conceptually > wrong to me: there is only one slur and no real XML overlapping (or other > limitation) that would justify, arguably, splitting the element in two. > > *I agree. The proposed solutions of joining or splitting them makes > complete sense when one need to render them. > > > > 2. As Laurent points out, relative positioning of the bezier points (end > points being relative, say, to the starting and ending note heads, the control > points being relative to these points) results in a "reflowable" slur - bezier > curves stretch very nicely, maintaining their shape. However, it only helps as > long as the slur isn't broken by a system break... In which case no single > bezier will describe how to draw two curves. > > > > Talking about which, consider the attached example. How would you > encode the pharse/slur mark starting at figure 9? I think one fairly natural > encoding is , but I can see how one > could argue that splitting it into two slur elements are equally valid: > > > > and in the first measure of the following system after figure 9: > > (even though I would not encourage the > use of tstamp values less than 1. I'm sure there's a better way of encoding of > the starting point of the second slur!) > > > > I personally feel that encoding the slur as one element is better, even if > there are two graphical objects that represent it. (Following this logic, > whenever possible, I would probably try to avoid splitting measures into > when the system breaks in the middle of the measure, even if it makes life a > little harder when processing.) > > > > 3. > > >[Perry]: For automatic layout without any user intervention, the only > mechanism is @curvedir > > * Given the difficulties, it seems to me that @curvedir alone does not > provide sufficient control over curvature for truly automated rendering of > slurs, even in the simpler cases. Furthermore, seeing the number of issues > arising as soon as we mention @bezier, @bulge or curvature in general, I > would say that a pure _classification_ mechanism would be useful. Perhaps > this is a bit of a conceptual change, but maybe @curvedir could be regarded > as such a classification (and extend its values to cover s-shaped and perhaps > even more craziness)? Or perhaps a new attribute would fit the job better? > > > > Best > > Zoltan > > > > 2015-02-03 15:05 GMT+00:00 Laurent Pugin : > > Hi Perry, > > > > One option I think could be interesting to add for providing more > flexibility is the possibility to specify the bezier points with a percentage for > the horizontal position of the intermediate points (0 to 100) and vertical > units (as in @bulge) for vertical positions. This would be much easier to > draw on a black-board. I'll try to prepare a couple of example images. > > > > Laurent > > > > PS For some reason, I have not received the messages from Axel and > Raffaele. Is anything wrong with my subscription to the list? > > > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: > > Hi Raffaele, > > > > Using @bezier only "locks" the rendering if the control points are specified > as absolute page coordinates. If they're given as offsets from something > else, such as a particular note, then the rendition of the slur is dependent > on the position of that thing. > > > > This is how I envision it working. It's possible that moving the bezier > control points (even if they're moved relative to everything else) will change > the shape of the curve. If that's true, then our only mechanism for > controlling a slur is through the use of @bulge. For automatic layout > without any user intervention, the only mechanism is @curvedir -- > remembering that values in @curvedir cannot possibly result in a perfect > rendition every time. It seems there truly is no way to have the cake and > eat it too, hence the comment which began my initial response to Benni. > > > > Of course, only those with more knowledge and experience with this stuff > can say for sure. > > Laurent? Craig? Zoltan? Want to join in? > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele > Viglianti [raffaeleviglianti at gmail.com] > > Sent: Tuesday, February 03, 2015 9:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all, > > > > I find Perry's explanation really helpful and interesting, particularly > concerning the the sharing of responsibilities between the encoder and the > renderer. Encoding @bezier before rendering locks the encoding into only > one possible rendering, which is not great for the reflowing that a truly > dynamic score should allow. Unless the aim of the encoder is to > represent/document the curvature of one specific written source, which is a > totally legitimate approach (and might be what Benni is after?). > > > > Having two slurs and joining them, instead, seems conceptually wrong to > me: there is only one slur and no real XML overlapping (or other limitation) > that would justify, arguably, splitting the element in two. > > > > Raff > > > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: > > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms > involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects > but is also aesthetically satisfying can be quite a challenge. My deepest > respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to get > it right. But recording the corrections also means that they will have to be > encodable somehow, that is, in more detail than possible with @bezier, for > instance. I have no immediate ideas about how to solve this in a medium as > fluid as music notation. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne > afRoland, Perry D. (pdr4h) > > Sendt: 2. februar 2015 20:14 > > > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of > worms for which it seems there can never be a single, universally satisfying > answer. > > > > @curvedir only provides minimal information about the slur so a renderer > must "figure out" the rest. This is the easiest method for the encoder, but > requires a lot more intelligence on the part of the rendering engine, for > example with regard to collision avoidance. From another angle, however, it > provides the greatest amount of flexibility for the renderer to arrive at the > final shape of the slur. Like I said before, aside from providing a more > detailed classification purpose, allowing curvdir="above below above below > (and so on)" doesn't really provide much rendering help because, just as > you've observed, it says nothing about the location of the points where the > slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating > distance from an imaginary line between the end points of the slur. > Providing two values means the distance between the end points should be > halved and a curve drawn that passes through the starting point, the point > indicated by the 1st value in @bulge, the mid-point of the line, the point > indicated by the 2nd value, and the ending point. Three values would mean > dividing the distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) > can be drawn with @bulge by supplying only a single value or by giving only > positive or only negative values. Doing this, instead of using @curvedir, > places the shape of the slur in the control of the encoder instead of the > rendering engine, but puts the burden of "scribing" the shape on the > encoder. The ability to draw "simple" slurs is why @bulge can't be > constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. > The diagram is also misleading in that the lines connecting the curve with > the imaginary line should divide their respective sections of the curve into > equal parts; that is, the line illustrating point 1 should be drawn at the > "highest" point of the curve, mid-way between the mid-point of the > imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. > But unless the control points of the curve are expressed as offsets from > some musical feature (like a note, for instance), then re-flowing the > notation will "disconnect" the slur from it and the slur will end up in the > wrong place on the page. So, the bezier control points have to be *offsets* > from something, presumably from the features pointed at by the @startid > and @endid attributes, as long as the notation is expected to be "edit- > able". The @startid, @endid, @bezier combination will move the slur with > the notation. The problem with bezier control points is the same as with > @bulge values -- it's nearly impossible for one to create them without the > aid of some kind of drawing environment or iterative "code/view/code" > workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed > the Guidelines. But, there may also be better ways of recording the > information necessary for drawing slurs than what is provided by the > current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > Teich Geertinger [atge at kb.dk] > > Sent: Monday, February 02, 2015 3:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, > or @curvedir=?above below?) do indicate explicitly where the slur changes > position from above the notes to below ? that is, where the slur intersects > the melodic line, so to speak. I guess that the use of @bezier will give the > desired result in most situations, but as the actual rendering of the slur > must be dependent to some degree on other factors such as the note > spacing or system breaks, I wonder how we can be sure that it will always > cross the melodic line at the desired place. With @bulge or @curvedir (with > extended values as suggested by Zoltan) this must be even more uncertain, > right? In principle, a rendering algorithm may draw the slur in Benni?s > example above the first three groups of notes and below only the last group > when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be > defined that a sequence of values for @bulge must an alternating sequence > of positive and negative values, either in the guidelines or the schema? Or > would a sequence like the one in the guidelines example (@bulge=?2 1?) > make any sense in any situation? > > > > Best, > > Axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Kom?ves Zolt?n > > Sendt: 2. februar 2015 07:08 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified > simply base on the argument of classification: @curvdir provides a > classification mechanism, but this classification is rather incomplete, the > current values of @curvedir do not cover all the cases that are out there > (see Benni's example: nor "above" neither "below" is appropriate, and the > omission of the attribute surely cannot imply what we want to convey, that > is the curve goes also above and below). This has nothing to do with > rendering, since in order to render a slur or phrase mark, the actual curve > needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". > (Note that his question concerns @curvedir not @place.) In fact, it occurs to > me, we could even allow an alternating sequence of the values "below" and > "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, > then above, could also be applied to curves with multiple inflection points. I > have no literary example for this at hand, but wouldn't be surprised if there > was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) > : > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in general > terms. For phrase marks and slurs, it also generically describes the > curvature of the mark, and therefore functions as short hand for a more > detailed description given by the bulge or bezier attributes. It would be > possible to add a value to @place for slurs/phrases with multiple inflection > points, such as "mixed" or perhaps "complex", but this would only fulfill a > classification purpose -- it wouldn't provide any information regarding how > to draw the slur/phrase. So, one would still need to use @bulge or @bezier > for rendering. > > > > Another complicating factor is that @place is used by a number of > elements other than slur and phrase. Adding "mixed" directly to @place > would introduce the possibility of nonsense in the case of, say, or > . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [laurent at music.mcgill.ca] > > Sent: Sunday, February 01, 2015 8:27 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: > http://music- > encoding.org/documentation/guidelines2013/userSymbols#index.xml- > body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am > not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > > Dear MEI-L, > > > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > > > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using @bezier is much > more verbose than needed? > > > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / > 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > > > > > This is no "special", rather quite often in printed music from the 19th > century. > > > > > > All the best, > > Benjamin > > > > _______________________________________________ > > 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 From esfield at stanford.edu Wed Feb 11 23:57:08 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Wed, 11 Feb 2015 14:57:08 -0800 (PST) Subject: [MEI-L] slur and @curvedir; moving Bezier control points In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: <0b65d775.00002330.00000013@MUS-MJ00MNV8.stanford.edu> This is such an interesting discussion with, as Perry suggests, no perfect solution. I am attaching two pertinent examples from Computing in Musicology (Vol. 7, 1991) that show (a) the famous but unlikely beam/slur crossings in Ravel's "Scarbo" unlikely slur crossings and (b) Grieg's requirements for beams of unusual length. The beam example becomes more cumbersome when the width of the layout (particularly for examples in books and articles) is inadequate to accommodate the beam and/or slur groupings shown. A significant problem in notation programs has been the book-keeping on slurs that need to continue to the next system. With beams, continuation is not always a viable option. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://web.stanford.edu/~esfield/ +1/ 650 725-9242 -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A. Sent: Wednesday, February 11, 2015 5:02 AM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] slur and @curvedir; moving Bezier control points A belated comment on Perry's message of a week ago, just below. I don't see how moving the Bezier control points "along with everything else" can possibly change the shape of the curve. If you move everything 5.347 mm to the right and 2.718 mm down, the curve will have exactly the same shape; it'll just be 5.347 mm to the right and 2.718 mm down, and in precisely the same position relative to the rest of the notation. Nightingale stores Bezier control points as offsets from note heads. If you move the note heads, of course the curve follows along; the coordinates actually used to draw the curve are the new coordinates of the note heads plus the offsets. Or am I misunderstanding? --Don > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms > involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > > > Best, > > Axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: > http://music-encoding.org/documentation/guidelines2013/userSymbols#ind > ex.xml-body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using @bezier is > much more verbose than needed > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > > This is no "special", rather quite often in printed music from the 19th century. > > > > All the best, > > Benjamin > > > > 17:33:03.png>_______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: Ravel.PNG Type: image/png Size: 63424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Greig.png Type: image/png Size: 28424 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Thu Feb 12 00:13:39 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Feb 2015 23:13:39 +0000 Subject: [MEI-L] slur and @curvedir: exact control & joins In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> Message-ID: I just found this Bezier curve primer: http://pomax.github.io/bezierinfo/. It would be better if I were more mathematically inclined, but even with my limited understanding it seems that there's a lot of really useful stuff here. Some things I get from this (not all of which may be true): - One can draw curves (i.e., slurs) using 3 or more points -- at least 2 end points and a control point. - More control points gives you, well, more control over the shape of the curve/slur. - More control points = more complex slurs - Curves/slurs can be split mathemagically! - Bounding boxes for a curve/slur can be calculated (Good for determining when a user has "clicked" on a slur). - Multiple slurs can be joined by making the end point of 1 be the start point of another (Manipulate figure 14.1 to make both p3 points coincide. The control points aren't actually editable in this figure, but you get the idea.) - There are multiple ways to create a GUI to curve-drawing (See Figures in Sections 21, 22, 24, and 25. Figures in Section 25 are particularly interesting since I presume that the curve created there could be split at one of the points on the curve indicated by the blue dots. One just needs a way to create more "break" points on the curve, right?) - Optimal placement of the slur with respect to the notes that it "covers" can be determined by using the algorithm of Section 27. - Algorithms in Sections 28 and 29 can be used to draw "true" slurs; that is, ones with "thick" middles and tapered ends. Like I said, this is just my take on this stuff after a cursory examination. "Real" programmers with both mathematical and musical knowledge will have to look at this stuff in order to say how it can inform the MEI data model. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni- > paderborn.de] On Behalf Of Byrd, Donald A. > Sent: Wednesday, February 11, 2015 4:05 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir: exact control & joins > > Perry is right about the need, sometimes, for exact control of slur shape. I > predict it'll be many years before any music rendering engine consistently > does a really good job breaking slurs. What if the slur changes staff at the > system break? Take a look at > > http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html > > How well would any existing rendering engine determine shape > automatically do with the Sorabji slur? That's a very extreme case, but in > the (more reasonable) example from Ravel's Scarbo, how well would any > rendering engine do automatically at the system break at the end of the > example? Answer: Not well enough for, say, Barenreiter. > > HOWEVER, it's also highly desirable that it be possible to encode slurs with > multiple inflection points as single objects. Yes, you could encode them as > separate curves that happen to coincide or overlap, but you'll never get the > proper tapering at the joins that way. > > --Don > > > On Feb 11, 2015, at 10:53 AM, "Roland, Perry D. (pdr4h)" > wrote: > > > > > Hi Axel, > > > > You?re absolutely right when you say that a rendering engine ought to be > smart enough to intelligently break a slur across a system or page break. > BUT, there might be situations where the software you?re using simply isn?t. > Or where it wants to break the slur in a way that you feel isn?t exactly right. > How can one ?regain control? from the ?rendering engine overlord? run > amok? One possibility is not give control to it in the first place; that is, > specify *exactly* how you want the slur to be broken up by breaking it > yourself and specifying where the pieces should be drawn. Once you?ve > done that, however, you want to leave a breadcrumb trail indicating how to > get back to the generic single-slur state. That?s the purpose of @join. > > > > Obviously, once you?ve split the slur, performing additional changes, such > as moving the system or page break, means your carefully crafted slurs will > be in the wrong place. So, this procedure isn?t recommended for material > that could change. But it?s essential, I think, when you?ve placed everything > ?just so? (say for printing on paper) and you don?t want anything to move. > In this case, MEI is functioning as an intermediate format for printing that > comes at the end of processing chain. > > > > Bezier control points remove the need to specify the inflection points of a > curve. Moving the control points also moves the inflection points. Using > Bezier curves is more efficient, hence their adoption in a lot of graphical > editing environments > > > > @bulge already does something similar to what you?re suggesting, but by > specifying the points at which the curve ?crests?, rather than where it > changes direction. I admit it?s a fairly blunt instrument, but sometimes > that?s all that?s required. The bulge concept is borrowed from Mup, which > aims to achieve what I?d call ?pass-able? rendering more-or-less > automatically without a lot of user input. @bulge gives a moderate amount > of control over the shape of the curve without the aid of a GUI > environment. It?s in the middle of the continuum of control from ?fully > automatic? () to ?fully user-controlled? > (). Which is also a > continuum from ?most flexible? to ?most stable/fixed?. J > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Axel Teich Geertinger > > Sent: Wednesday, February 11, 2015 3:54 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > There is something that has been puzzling me: I don?t think I have > completely grasped the idea of @join when used with slurs (I haven?t really > thought about other uses, though). It seems to me to be redundant. In > which situation would it be necessary to explicitly encode that a slur needs > to be interrupted at a system break? Doesn?t the system break itself provide > all information necessary, leaving the actual division into two half-slurs to > the rendering engine? Is there any thinkable situation where an encoded > or an automatically generated system break would not imply the > splitting of the slur at that point? Or the other way around: would it be > necessary to split one (that is, logically one) slur into two (that is, > graphically two) parts in any other situation? > > > > On editing or rendering a score (not necessarily following the exact layout > of a particular source), the system break may change position. I that case, I > would even have to update the endpoint of the first and the starting point > of the second (half-)slur, right? What is the benefit from this operation? > > > > I agree with Zoltan that a slur should be encoded as one element, even > when it has to be rendered as two distinct graphical objects _in some > situations_. It makes me wonder whether an attribute like @join would be > more useful to indicate the location of the points where a complex slur > changes direction of bending (the joints, in terms of joined slurs with > alternating curve direction). > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Roland, Perry D. (pdr4h) > > Sendt: 10. februar 2015 22:16 > > Til: Music Encoding Initiative > > Cc: zoltan.komives at gmail.com > > Emne: Re: [MEI-L] slur and @curvedir > > > > > > There?s no single answer to this. Whether one chooses to encode a single > slur or chooses to create two depends on the purpose for the encoding -- a > single slur is better for analytical purposes, but two may be better for > rendering. To fit both simultaneously, one can use , for example -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > The @join attribute on slur exists to indicate that multiple slurs are > conceptually one, not to provide rendering info. > > > > I contend that @curvedir *can* provide a so-called ?rendering hint?, but I > agree that the rendering engine has to be pretty intelligent to make use of it > -- Mup seems to do a reasonable job with only this much information. I > have no problem extending the values permitted in @curvedir, but I think > over-specification there is not likely to be of much help. A value of > ?complex? is about as far as I think we can go down that path. > > > > -- > > p. > > > > > > From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] > > Sent: Tuesday, February 10, 2015 1:30 PM > > To: Music Encoding Initiative > > Cc: Roland, Perry D. (pdr4h) > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > 1. > > >[Raff]: Having two slurs and joining them, instead, seems conceptually > wrong to me: there is only one slur and no real XML overlapping (or other > limitation) that would justify, arguably, splitting the element in two. > > *I agree. The proposed solutions of joining or splitting them makes > complete sense when one need to render them. > > > > 2. As Laurent points out, relative positioning of the bezier points (end > points being relative, say, to the starting and ending note heads, the control > points being relative to these points) results in a "reflowable" slur - bezier > curves stretch very nicely, maintaining their shape. However, it only helps as > long as the slur isn't broken by a system break... In which case no single > bezier will describe how to draw two curves. > > > > Talking about which, consider the attached example. How would you > encode the pharse/slur mark starting at figure 9? I think one fairly natural > encoding is , but I can see how one > could argue that splitting it into two slur elements are equally valid: > > > > and in the first measure of the following system after figure 9: > > (even though I would not encourage the > use of tstamp values less than 1. I'm sure there's a better way of encoding of > the starting point of the second slur!) > > > > I personally feel that encoding the slur as one element is better, even if > there are two graphical objects that represent it. (Following this logic, > whenever possible, I would probably try to avoid splitting measures into > when the system breaks in the middle of the measure, even if it makes life a > little harder when processing.) > > > > 3. > > >[Perry]: For automatic layout without any user intervention, the only > mechanism is @curvedir > > * Given the difficulties, it seems to me that @curvedir alone does not > provide sufficient control over curvature for truly automated rendering of > slurs, even in the simpler cases. Furthermore, seeing the number of issues > arising as soon as we mention @bezier, @bulge or curvature in general, I > would say that a pure _classification_ mechanism would be useful. Perhaps > this is a bit of a conceptual change, but maybe @curvedir could be regarded > as such a classification (and extend its values to cover s-shaped and perhaps > even more craziness)? Or perhaps a new attribute would fit the job better? > > > > Best > > Zoltan > > > > 2015-02-03 15:05 GMT+00:00 Laurent Pugin : > > Hi Perry, > > > > One option I think could be interesting to add for providing more > flexibility is the possibility to specify the bezier points with a percentage for > the horizontal position of the intermediate points (0 to 100) and vertical > units (as in @bulge) for vertical positions. This would be much easier to > draw on a black-board. I'll try to prepare a couple of example images. > > > > Laurent > > > > PS For some reason, I have not received the messages from Axel and > Raffaele. Is anything wrong with my subscription to the list? > > > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: > > Hi Raffaele, > > > > Using @bezier only "locks" the rendering if the control points are specified > as absolute page coordinates. If they're given as offsets from something > else, such as a particular note, then the rendition of the slur is dependent > on the position of that thing. > > > > This is how I envision it working. It's possible that moving the bezier > control points (even if they're moved relative to everything else) will change > the shape of the curve. If that's true, then our only mechanism for > controlling a slur is through the use of @bulge. For automatic layout > without any user intervention, the only mechanism is @curvedir -- > remembering that values in @curvedir cannot possibly result in a perfect > rendition every time. It seems there truly is no way to have the cake and > eat it too, hence the comment which began my initial response to Benni. > > > > Of course, only those with more knowledge and experience with this stuff > can say for sure. > > Laurent? Craig? Zoltan? Want to join in? > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele > Viglianti [raffaeleviglianti at gmail.com] > > Sent: Tuesday, February 03, 2015 9:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all, > > > > I find Perry's explanation really helpful and interesting, particularly > concerning the the sharing of responsibilities between the encoder and the > renderer. Encoding @bezier before rendering locks the encoding into only > one possible rendering, which is not great for the reflowing that a truly > dynamic score should allow. Unless the aim of the encoder is to > represent/document the curvature of one specific written source, which is a > totally legitimate approach (and might be what Benni is after?). > > > > Having two slurs and joining them, instead, seems conceptually wrong to > me: there is only one slur and no real XML overlapping (or other limitation) > that would justify, arguably, splitting the element in two. > > > > Raff > > > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: > > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms > involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects > but is also aesthetically satisfying can be quite a challenge. My deepest > respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to get > it right. But recording the corrections also means that they will have to be > encodable somehow, that is, in more detail than possible with @bezier, for > instance. I have no immediate ideas about how to solve this in a medium as > fluid as music notation. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne > afRoland, Perry D. (pdr4h) > > Sendt: 2. februar 2015 20:14 > > > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of > worms for which it seems there can never be a single, universally satisfying > answer. > > > > @curvedir only provides minimal information about the slur so a renderer > must "figure out" the rest. This is the easiest method for the encoder, but > requires a lot more intelligence on the part of the rendering engine, for > example with regard to collision avoidance. From another angle, however, it > provides the greatest amount of flexibility for the renderer to arrive at the > final shape of the slur. Like I said before, aside from providing a more > detailed classification purpose, allowing curvdir="above below above below > (and so on)" doesn't really provide much rendering help because, just as > you've observed, it says nothing about the location of the points where the > slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating > distance from an imaginary line between the end points of the slur. > Providing two values means the distance between the end points should be > halved and a curve drawn that passes through the starting point, the point > indicated by the 1st value in @bulge, the mid-point of the line, the point > indicated by the 2nd value, and the ending point. Three values would mean > dividing the distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) > can be drawn with @bulge by supplying only a single value or by giving only > positive or only negative values. Doing this, instead of using @curvedir, > places the shape of the slur in the control of the encoder instead of the > rendering engine, but puts the burden of "scribing" the shape on the > encoder. The ability to draw "simple" slurs is why @bulge can't be > constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. > The diagram is also misleading in that the lines connecting the curve with > the imaginary line should divide their respective sections of the curve into > equal parts; that is, the line illustrating point 1 should be drawn at the > "highest" point of the curve, mid-way between the mid-point of the > imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. > But unless the control points of the curve are expressed as offsets from > some musical feature (like a note, for instance), then re-flowing the > notation will "disconnect" the slur from it and the slur will end up in the > wrong place on the page. So, the bezier control points have to be *offsets* > from something, presumably from the features pointed at by the @startid > and @endid attributes, as long as the notation is expected to be "edit- > able". The @startid, @endid, @bezier combination will move the slur with > the notation. The problem with bezier control points is the same as with > @bulge values -- it's nearly impossible for one to create them without the > aid of some kind of drawing environment or iterative "code/view/code" > workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed > the Guidelines. But, there may also be better ways of recording the > information necessary for drawing slurs than what is provided by the > current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > Teich Geertinger [atge at kb.dk] > > Sent: Monday, February 02, 2015 3:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, > or @curvedir=?above below?) do indicate explicitly where the slur changes > position from above the notes to below ? that is, where the slur intersects > the melodic line, so to speak. I guess that the use of @bezier will give the > desired result in most situations, but as the actual rendering of the slur > must be dependent to some degree on other factors such as the note > spacing or system breaks, I wonder how we can be sure that it will always > cross the melodic line at the desired place. With @bulge or @curvedir (with > extended values as suggested by Zoltan) this must be even more uncertain, > right? In principle, a rendering algorithm may draw the slur in Benni?s > example above the first three groups of notes and below only the last group > when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be > defined that a sequence of values for @bulge must an alternating sequence > of positive and negative values, either in the guidelines or the schema? Or > would a sequence like the one in the guidelines example (@bulge=?2 1?) > make any sense in any situation? > > > > Best, > > Axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > Kom?ves Zolt?n > > Sendt: 2. februar 2015 07:08 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified > simply base on the argument of classification: @curvdir provides a > classification mechanism, but this classification is rather incomplete, the > current values of @curvedir do not cover all the cases that are out there > (see Benni's example: nor "above" neither "below" is appropriate, and the > omission of the attribute surely cannot imply what we want to convey, that > is the curve goes also above and below). This has nothing to do with > rendering, since in order to render a slur or phrase mark, the actual curve > needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". > (Note that his question concerns @curvedir not @place.) In fact, it occurs to > me, we could even allow an alternating sequence of the values "below" and > "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, > then above, could also be applied to curves with multiple inflection points. I > have no literary example for this at hand, but wouldn't be surprised if there > was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) > : > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in general > terms. For phrase marks and slurs, it also generically describes the > curvature of the mark, and therefore functions as short hand for a more > detailed description given by the bulge or bezier attributes. It would be > possible to add a value to @place for slurs/phrases with multiple inflection > points, such as "mixed" or perhaps "complex", but this would only fulfill a > classification purpose -- it wouldn't provide any information regarding how > to draw the slur/phrase. So, one would still need to use @bulge or @bezier > for rendering. > > > > Another complicating factor is that @place is used by a number of > elements other than slur and phrase. Adding "mixed" directly to @place > would introduce the possibility of nonsense in the case of, say, or > . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [laurent at music.mcgill.ca] > > Sent: Sunday, February 01, 2015 8:27 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: > http://music- > encoding.org/documentation/guidelines2013/userSymbols#index.xml- > body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am > not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > > Dear MEI-L, > > > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > > > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using @bezier is much > more verbose than needed? > > > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / > 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > > > > > This is no "special", rather quite often in printed music from the 19th > century. > > > > > > All the best, > > Benjamin > > > > _______________________________________________ > > 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 From pdr4h at eservices.virginia.edu Thu Feb 12 00:29:05 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Feb 2015 23:29:05 +0000 Subject: [MEI-L] slur and @curvedir; moving Bezier control points In-Reply-To: <0b65d775.00002330.00000013@MUS-MJ00MNV8.stanford.edu> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0b65d775.00002330.00000013@MUS-MJ00MNV8.stanford.edu> Message-ID: Hi Eleanor, Thanks for joining the discussion. The Ravel example demonstrates, besides the wild "gyrations" of the slurs, that it's not always possible to avoid collisions between slurs and beams or between beams. This is one of those things that a mere machine, programmed to avoid collisions at all costs, would simply explode upon encountering. (Not unlike when Kirk talked the computer into destroying itself by presenting it an unsolvable problem.) So, collision avoidance is desirable, but can never be made a strict rule. I don't understand what's unusual about the length of the beams in the Grieg example. Like everyone's legs they seem to go "all the way to the ground". :-) That is, they appear to connect the stem of the first note of the beamed group to the last note of the group. Are you trying to draw attention to the spacing of the notes under the beam? Please forgive me if I'm missing something obvious. It's been a long day. -- p. > -----Original Message----- > From: Eleanor Selfridge-Field [mailto:esfield at stanford.edu] > Sent: Wednesday, February 11, 2015 5:57 PM > To: Music Encoding Initiative > Cc: Roland, Perry D. (pdr4h) > Subject: RE: [MEI-L] slur and @curvedir; moving Bezier control points > > This is such an interesting discussion with, as Perry suggests, no perfect > solution. > > I am attaching two pertinent examples from Computing in Musicology (Vol. > 7, 1991) that show (a) the famous but unlikely beam/slur crossings in > Ravel's "Scarbo" unlikely slur crossings and (b) Grieg's requirements for > beams of unusual length. > > The beam example becomes more cumbersome when the width of the > layout > (particularly for examples in books and articles) is inadequate to > accommodate the beam and/or slur groupings shown. A significant > problem > in notation programs has been the book-keeping on slurs that need to > continue to the next system. With beams, continuation is not always a > viable option. > > Eleanor > > > Eleanor Selfridge-Field > Consulting Professor, Music (and, by courtesy, Symbolic Systems) > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://web.stanford.edu/~esfield/ +1/ 650 725-9242 > > > > > > > > > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Byrd, Donald A. > Sent: Wednesday, February 11, 2015 5:02 AM > To: Music Encoding Initiative > Cc: Roland, Perry D. (pdr4h) > Subject: Re: [MEI-L] slur and @curvedir; moving Bezier control points > > A belated comment on Perry's message of a week ago, just below. I don't > see how moving the Bezier control points "along with everything else" can > possibly change the shape of the curve. If you move everything 5.347 mm to > the right and 2.718 mm down, the curve will have exactly the same shape; > it'll just be 5.347 mm to the right and 2.718 mm down, and in precisely > the same position relative to the rest of the notation. > > Nightingale stores Bezier control points as offsets from note heads. If > you move the note heads, of course the curve follows along; the > coordinates actually used to draw the curve are the new coordinates of the > note heads plus the offsets. > > Or am I misunderstanding? > > --Don > > > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: > > Hi Raffaele, > > > > Using @bezier only "locks" the rendering if the control points are > specified as absolute page coordinates. If they're given as offsets from > something else, such as a particular note, then the rendition of the slur > is dependent on the position of that thing. > > > > This is how I envision it working. It's possible that moving the bezier > control points (even if they're moved relative to everything else) will > change the shape of the curve. If that's true, then our only mechanism > for controlling a slur is through the use of @bulge. For automatic layout > without any user intervention, the only mechanism is @curvedir -- > remembering that values in @curvedir cannot possibly result in a perfect > rendition every time. It seems there truly is no way to have the cake and > eat it too, hence the comment which began my initial response to Benni. > > > > Of course, only those with more knowledge and experience with this stuff > can say for sure. > > Laurent? Craig? Zoltan? Want to join in? > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > > Raffaele Viglianti [raffaeleviglianti at gmail.com] > > Sent: Tuesday, February 03, 2015 9:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all, > > > > I find Perry's explanation really helpful and interesting, particularly > concerning the the sharing of responsibilities between the encoder and the > renderer. Encoding @bezier before rendering locks the encoding into only > one possible rendering, which is not great for the reflowing that a truly > dynamic score should allow. Unless the aim of the encoder is to > represent/document the curvature of one specific written source, which is > a totally legitimate approach (and might be what Benni is after?). > > > > Having two slurs and joining them, instead, seems conceptually wrong to > me: there is only one slur and no real XML overlapping (or other > limitation) that would justify, arguably, splitting the element in two. > > > > Raff > > > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: > > Hi Perry > > > > > > > > Thanks for your elaborate reply. As always I wasn't aware of any worms > > involved, but I did realize that there is no single or easy answer :-) > > > > > > > > Drawing a complex slur that not only avoids collisions with other > objects but is also aesthetically satisfying can be quite a challenge. My > deepest respect for people working on rendering slurs! > > > > As you say, it almost always requires visual control and corrections to > get it right. But recording the corrections also means that they will have > to be encodable somehow, that is, in more detail than possible with > @bezier, for instance. I have no immediate ideas about how to solve this > in a medium as fluid as music notation. > > > > > > > > Best, > > > > Axel > > > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > > Roland, Perry D. (pdr4h) > > Sendt: 2. februar 2015 20:14 > > > > > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > > > > > Hi Axel, > > > > > > > > One comment before I answer your questions -- This is a huge can of > worms for which it seems there can never be a single, universally > satisfying answer. > > > > > > > > @curvedir only provides minimal information about the slur so a renderer > must "figure out" the rest. This is the easiest method for the encoder, > but requires a lot more intelligence on the part of the rendering engine, > for example with regard to collision avoidance. From another angle, > however, it provides the greatest amount of flexibility for the renderer > to arrive at the final shape of the slur. Like I said before, aside from > providing a more detailed classification purpose, allowing curvdir="above > below above below (and so on)" doesn't really provide much rendering help > because, just as you've observed, it says nothing about the location of > the points where the slur is supposed to bend back on itself. > > > > > > > > @bulge attempts to provide this missing information by indicating > distance from an imaginary line between the end points of the slur. > Providing two values means the distance between the end points should be > halved and a curve drawn that passes through the starting point, the point > indicated by the 1st value in @bulge, the mid-point of the line, the point > indicated by the 2nd value, and the ending point. Three values would mean > dividing the distance between the end points by thirds, etc. > > > > > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary > line) can be drawn with @bulge by supplying only a single value or by > giving only positive or only negative values. Doing this, instead of > using @curvedir, places the shape of the slur in the control of the > encoder instead of the rendering engine, but puts the burden of "scribing" > the shape on the encoder. The ability to draw "simple" slurs is why > @bulge can't be constrained to alternating positive and negative values. > > > > > > > > The example provided in the Guidelines should use the values -2 and 1. > The diagram is also misleading in that the lines connecting the curve with > the imaginary line should divide their respective sections of the curve > into equal parts; that is, the line illustrating point 1 should be drawn > at the "highest" point of the curve, mid-way between the mid-point of the > imaginary line and the end point of the slur. > > > > > > > > @bezier provides the most encoder control over the rendition of the > slur. But unless the control points of the curve are expressed as offsets > from some musical feature (like a note, for instance), then re-flowing the > notation will "disconnect" the slur from it and the slur will end up in > the wrong place on the page. So, the bezier control points have to be > *offsets* from something, presumably from the features pointed at by the > @startid and @endid attributes, as long as the notation is expected to be > "edit-able". The @startid, @endid, @bezier combination will move the slur > with the notation. The problem with bezier control points is the same as > with @bulge values -- it's nearly impossible for one to create them > without the aid of some kind of drawing environment or iterative > "code/view/code" workflow. > > > > > > > > Without a doubt, a better explanation of this stuff is desperately > needed the Guidelines. But, there may also be better ways of recording the > information necessary for drawing slurs than what is provided by the > current set of attributes. I welcome contributions on either front. > > > > > > > > -- > > > > p. > > > > > > > > __________________________ > > Perry Roland > > Music Library > > > > University of Virginia > > > > P. O. Box 400175 > > > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > > Teich Geertinger [atge at kb.dk] > > Sent: Monday, February 02, 2015 3:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi all > > > > > > > > Just out of curiosity: None of the solutions I have seen (@bulge, > @bezier, or @curvedir="above below") do indicate explicitly where the slur > changes position from above the notes to below - that is, where the slur > intersects the melodic line, so to speak. I guess that the use of @bezier > will give the desired result in most situations, but as the actual > rendering of the slur must be dependent to some degree on other factors > such as the note spacing or system breaks, I wonder how we can be sure > that it will always cross the melodic line at the desired place. With > @bulge or @curvedir (with extended values as suggested by Zoltan) this > must be even more uncertain, right? In principle, a rendering algorithm > may draw the slur in Benni's example above the first three groups of notes > and below only the last group when using @bulge or @curvedir. How do we > avoid that? > > > > > > > > One more question about @bulge, again just out of curiosity: Should it > be defined that a sequence of values for @bulge must an alternating > sequence of positive and negative values, either in the guidelines or the > schema? Or would a sequence like the one in the guidelines example > (@bulge="2 1") make any sense in any situation? > > > > > > > > Best, > > > > Axel > > > > > > > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af > > Kom?ves Zolt?n > > Sendt: 2. februar 2015 07:08 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] slur and @curvedir > > > > > > > > Hi Perry, > > > > > > > > I think extending the data type of @curvedir attribute could be > justified simply base on the argument of classification: @curvdir provides > a classification mechanism, but this classification is rather incomplete, > the current values of @curvedir do not cover all the cases that are out > there (see Benni's example: nor "above" neither "below" is appropriate, > and the omission of the attribute surely cannot imply what we want to > convey, that is the curve goes also above and below). This has nothing to > do with rendering, since in order to render a slur or phrase mark, the > actual curve needs to be calculated anyway, even when "above" or "below" > is applied. > > > > > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". > (Note that his question concerns @curvedir not @place.) In fact, it occurs > to me, we could even allow an alternating sequence of the values "below" > and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, > then above, could also be applied to curves with multiple inflection > points. I have no literary example for this at hand, but wouldn't be > surprised if there was some in existence. > > > > > > > > Best > > > > Zoltan > > > > > > > > > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) > : > > > > > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > > > > > The place attribute is for describing the placement of an entity in > general terms. For phrase marks and slurs, it also generically describes > the curvature of the mark, and therefore functions as short hand for a > more detailed description given by the bulge or bezier attributes. It > would be possible to add a value to @place for slurs/phrases with multiple > inflection points, such as "mixed" or perhaps "complex", but this would > only fulfill a classification purpose -- it wouldn't provide any > information regarding how to draw the slur/phrase. So, one would still > need to use @bulge or @bezier for rendering. > > > > > > > > Another complicating factor is that @place is used by a number of > elements other than slur and phrase. Adding "mixed" directly to @place > would introduce the possibility of nonsense in the case of, say, > or . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > > > > > > > -- > > > > p. > > > > > > > > > > __________________________ > > Perry Roland > > Music Library > > > > University of Virginia > > > > P. O. Box 400175 > > > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > > Laurent Pugin [laurent at music.mcgill.ca] > > Sent: Sunday, February 01, 2015 8:27 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] slur and @curvedir > > > > Hi Benni, > > > > > > > > Have you looked at @bulge? There is an example in the guidelines: > > http://music- > encoding.org/documentation/guidelines2013/userSymbols#ind > > ex.xml-body.1_div.23_div.3_div.4 > > > > > > > > I would have expected the values to be -2 1 for the given example, so I > am not sure I understand it correctly. > > > > > > > > Laurent > > > > > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > > > > Dear MEI-L, > > > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > > > > > > > > In case the picture doesn't come through, please see: > > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > > > > > This slur may not be properly encoded in MEI using @curvedir that only > > allows 'above' or 'below' as values. Nevertheless, using @bezier is > > much more verbose than needed. > > > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' > / 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > > > > > > > This is no "special", rather quite often in printed music from the 19th > century. > > > > > > > > All the best, > > > > Benjamin > > > > > > > > > 17:33:03.png>_______________________________________________ > > 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 From pdr4h at eservices.virginia.edu Thu Feb 12 16:52:15 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 12 Feb 2015 15:52:15 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA56CC@EXCHANGE-02.kb.dk> Message-ID: Having consulted a little with Don off-list, I think I can see how a single slur can be represented by multiple Bezier curves. It means that the Bezier curve must be ?elevated? from attribute to element status. For example, in DTD-like lingo -- In this approach, can contain 0 or more Bezier curves, each of which must have one or more Bezier control points (bcp). The @bezier and @join attributes on can be removed, but it can keep all its other attributes. Markup example -- The element is optional and repeatable, allowing for any number of curves (physical instantiations) of a single (semantic) slur. is repeatable, permitting Bezier curves of any order. The @ho and @vo attributes record the location of the control point as offsets from the entity ?pointed to? by the URI in the @anchor attribute. This is likely to be either the first or last note of the slur, but doesn?t have to be. Because is optional, those not interested in precise, mathematical description of the slur?s curve can safely ignore it and rely on @curvedir. I think adding a new value (?complex?) is a good idea for slurs that are more complex than can be described as simply ?above? or ?below?. ?Above? and ?below? can continue to be used to provide ?quick-and-dirty? renditions when no elements are available, but rendering a satisfactory slur using the ?complex? value is unlikely. The encoding could be made less redundant by making the @anchor attribute and relying on the presence of @startid on . If there were no @startid attribute on the parent , I suppose the control points of the Bezier curve could be based on whatever occurs on @tstamp1, but these issues are best addressed by Schematron rules. It may be simpler just to require @anchor. I?m still not sure how one can get from a described by a single Bezier curve to a description with multiple curves and back again, but that really does lie in the realm of the formatter, not in MEI itself. @bulge can remain or be replaced by similar element-based markup, but I?m in favor of leaving it in place for the moment. One windmill at a time ... Of course, this is just off the top of my head this morning. It?s all subject to revision, especially the names (I?m not particularly happy with for instance). So, all feedback is appreciated. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, February 11, 2015 3:54 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir There is something that has been puzzling me: I don?t think I have completely grasped the idea of @join when used with slurs (I haven?t really thought about other uses, though). It seems to me to be redundant. In which situation would it be necessary to explicitly encode that a slur needs to be interrupted at a system break? Doesn?t the system break itself provide all information necessary, leaving the actual division into two half-slurs to the rendering engine? Is there any thinkable situation where an encoded or an automatically generated system break would not imply the splitting of the slur at that point? Or the other way around: would it be necessary to split one (that is, logically one) slur into two (that is, graphically two) parts in any other situation? On editing or rendering a score (not necessarily following the exact layout of a particular source), the system break may change position. I that case, I would even have to update the endpoint of the first and the starting point of the second (half-)slur, right? What is the benefit from this operation? I agree with Zoltan that a slur should be encoded as one element, even when it has to be rendered as two distinct graphical objects _in some situations_. It makes me wonder whether an attribute like @join would be more useful to indicate the location of the points where a complex slur changes direction of bending (the joints, in terms of joined slurs with alternating curve direction). Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 10. februar 2015 22:16 Til: Music Encoding Initiative Cc: zoltan.komives at gmail.com Emne: Re: [MEI-L] slur and @curvedir There?s no single answer to this. Whether one chooses to encode a single slur or chooses to create two depends on the purpose for the encoding -- a single slur is better for analytical purposes, but two may be better for rendering. To fit both simultaneously, one can use , for example -- The @join attribute on slur exists to indicate that multiple slurs are conceptually one, not to provide rendering info. I contend that @curvedir *can* provide a so-called ?rendering hint?, but I agree that the rendering engine has to be pretty intelligent to make use of it -- Mup seems to do a reasonable job with only this much information. I have no problem extending the values permitted in @curvedir, but I think over-specification there is not likely to be of much help. A value of ?complex? is about as far as I think we can go down that path. -- p. From: K?m?ves Zolt?n [mailto:zolaemil at gmail.com] Sent: Tuesday, February 10, 2015 1:30 PM To: Music Encoding Initiative Cc: Roland, Perry D. (pdr4h) Subject: Re: [MEI-L] slur and @curvedir Hi Perry, 1. >[Raff]: Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. *I agree. The proposed solutions of joining or splitting them makes complete sense when one need to render them. 2. As Laurent points out, relative positioning of the bezier points (end points being relative, say, to the starting and ending note heads, the control points being relative to these points) results in a "reflowable" slur - bezier curves stretch very nicely, maintaining their shape. However, it only helps as long as the slur isn't broken by a system break... In which case no single bezier will describe how to draw two curves. Talking about which, consider the attached example. How would you encode the pharse/slur mark starting at figure 9? I think one fairly natural encoding is , but I can see how one could argue that splitting it into two slur elements are equally valid: and in the first measure of the following system after figure 9: (even though I would not encourage the use of tstamp values less than 1. I'm sure there's a better way of encoding of the starting point of the second slur!) I personally feel that encoding the slur as one element is better, even if there are two graphical objects that represent it. (Following this logic, whenever possible, I would probably try to avoid splitting measures into when the system breaks in the middle of the measure, even if it makes life a little harder when processing.) 3. >[Perry]: For automatic layout without any user intervention, the only mechanism is @curvedir * Given the difficulties, it seems to me that @curvedir alone does not provide sufficient control over curvature for truly automated rendering of slurs, even in the simpler cases. Furthermore, seeing the number of issues arising as soon as we mention @bezier, @bulge or curvature in general, I would say that a pure _classification_ mechanism would be useful. Perhaps this is a bit of a conceptual change, but maybe @curvedir could be regarded as such a classification (and extend its values to cover s-shaped and perhaps even more craziness)? Or perhaps a new attribute would fit the job better? Best Zoltan 2015-02-03 15:05 GMT+00:00 Laurent Pugin >: Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: From andrew.hankinson at mail.mcgill.ca Fri Feb 13 03:06:24 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 12 Feb 2015 21:06:24 -0500 Subject: [MEI-L] Sibelius to MEI v1.3 released Message-ID: <0A50BB75-C0D6-4C9C-8BD6-0082DB36D48A@mail.mcgill.ca> Hello everyone, I've just put the finishing touches on a new release of the Sibelius to MEI Plugin. This is available for download on our GitHub Releases page: https://github.com/music-encoding/sibmei/releases/tag/v1.3 To save you a click I'll highlight some of the big changes from v1.2: Bug fixes: ? The file encoding was improperly declared. It is now declared as UTF-16. ? dis.place of 15 for clefs was improperly encoded. ? transposing clefs are now computed properly from Sibelius. ? ID references for fermatas were missing a starting '#'. New or Improved Features: ? A full suite of articulations are now encoded. ? Additional accidental types are now supported. ? Bracketed accidentals are encoded as 'supplied'. ? Square bracket symbols are now encoded as line objects. ? Dotted longs are now supported. ? Tuplets are now supported! ? Support for bTrem tremoloed notes. To Install: Visit the release page and download the attached binaries, unzip them, and place the folder in your Sibelius Plugins folder. (Instructions on how to do this are available on the Sibelius website: http://www.sibelius.com/download/plugins/index.html?help=install ) You can also check out the source code and place it in 'sibmei' folder in your plugins directory. If you're having any problems, please open an issue on the Issue Tracker or contact me directly. Cheers, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From atge at kb.dk Fri Feb 13 14:10:55 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 13 Feb 2015 13:10:55 +0000 Subject: [MEI-L] Cataloging with MEI: Workshop and Interest Group Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DBEA9A@EXCHANGE-02.kb.dk> Dear colleagues, over the last few years, MEI has been adopted for cataloging purposes in a variety of contexts, including libraries, catalog projects and editorial projects. One of the most important assets of MEI is its flexibility, which allows room for custom solutions, tailored to project-specific requirements. But as this flexibility may also cause long-term problems with regard to interoperability of data, we believe it makes sense to establish an interest group for cataloging with MEI where special requirements in dealing with MEI metadata could be brought up to discussion. An initial meeting is scheduled as one-day workshop for 21 May 2015, the unconference day of this year?s Music Encoding Conference. At the workshop we intend to analyze and discuss different data models, identify varying cataloging practices and to start working on a shared core model as well as best practice recommendations. Against this background the workshop is primarily addressed to people already working in the field, willing to share their expertise and identify potential for collaboration. It is also open to the public, but please note that a tutorial into MEI metadata won?t be offered. We would be very happy about short presentations of existing tools and use cases involving MEI metadata and kindly ask you to inform us (Kristina Richts, krichts at mail.uni-paderborn.de; or Axel Geertinger, atge at kb.dk) in the run-up to the workshop if you would like to present something. Please note, however, that the main focus will be on informal, open discussions rather than presentations. At the end of the workshop we hope to take the first steps towards forming a Cataloging Interest Group according to the new MEI by-laws (see excerpt below). Looking forward to seeing you all in Florence we send our kind regards, Kristina Richts and Axel Teich Geertinger Quoted from the MEI by-laws: 8 Interest Groups An Interest Group (henceforth ?IG?) is composed of any number of members of the MEI community with an interest in a certain music encoding topic or problem. The topic of interest should be reflected in the group?s name. Individual membership in multiple groups is allowed. In order to form a new IG, a proposal shall be made to the Board, containing the group?s name, goals, and a list of founding members. The Board is responsible for reviewing the application in a timely fashion and granting or withholding official recognition to the new group. Each interest group must: ? select an administrative chair ? produce regular activity reports (annual reports due 1 month prior to the annual Board meeting) A single person may not be administrative chair of multiple IGs. The IG?s administrative chair takes responsibility for acting as contact person for the IG, ensuring regular activity, submitting reports to the Board, and organizing the group?s work, e.g. calling for meetings and coordinating development efforts. Each IG will be self-organizing; that is, there will be no formal regulations on how any other responsibilities are to be divided amongst its members. In addition, the IG may establish decision-making processes as necessary; however, it should rely on consensus rather than majority rule whenever possible. 8.1 Interest Group privileges All Interest Groups will be listed on the MEI-website and are eligible to other benefits as the Board may determine from time to time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Sat Feb 14 01:07:46 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sat, 14 Feb 2015 00:07:46 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: I can?t be certain, but I think the attached (really, REALLY crude) illustration depicts what Laurent was getting at. Forgive me if I?ve gotten it wrong. The ?crest? or ?trough? of each undulation of the curve is specified by 2 values: the point along an imaginary line connecting the end points of the curve to which the crest is perpendicular and the ?height/depth? of the crest/trough. The distance from the imaginary line to the crest/trough of the curve is expressed in units allowed by data.MEASUREMENT (cm|mm|in|pt|pc|vu) with ?vu? being the default. Negative values indicate curvature to the right of the imaginary line (a trough), positive values to the left (a crest). The point along the imaginary line where the crest/trough occurs is expressed as a percentage of the length of the line. In the first slur, the trough occurs at a point that is 25% of the distance between the line?s end points with a ?depth? of -2. The crest occurs at 85% of the length of the line with a ?height? of 2. In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90% with heights and depths of -2, 2, -3, 2. I haven?t yet worked out the data model for a that behaves this way, but I believe mimicking the one I presented yesterday using Bezier curves is the right direction. My question at this point is, Is this a species of Bezier curve that could be accommodated using the element introduced yesterday? For example -- where @rise = height/depth of the crest/trough and @run = distance along the imaginary line. What isn?t addressed here yet is the specification of the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and @endid? You may ask why is this needed. As I?ve said before, Bezier curves are fine if you?re working in a GUI environment, but if not then this provides a convenient way of specifying the curve that can be accomplished in a text editor. -- p. From: Laurent Pugin [mailto:lxpugin at gmail.com] Sent: Tuesday, February 03, 2015 10:06 AM To: Roland, Perry D. (pdr4h) Cc: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Perry, One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. Laurent PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. Of course, only those with more knowledge and experience with this stuff can say for sure. Laurent? Craig? Zoltan? Want to join in? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Tuesday, February 03, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all, I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. Raff On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger > wrote: Hi Perry Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. februar 2015 20:14 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Axel, One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Monday, February 02, 2015 3:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi all Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n Sendt: 2. februar 2015 07:08 Til: Music Encoding Initiative Emne: Re: [MEI-L] slur and @curvedir Hi Perry, I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. Best Zoltan 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) >: Laurent is correct, the values in the example should be -2 and 1. The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, February 01, 2015 8:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Hi Benni, Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. Laurent On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: Dear MEI-L, Fresch?tz has a question concerning encoding mixed direction slurs. [bildschirmfoto 2015-01-30 um 14 05 39] In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? This is no "special", rather quite often in printed music from the 19th century. All the best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bulgeIllustration.png Type: image/png Size: 14896 bytes Desc: bulgeIllustration.png URL: From donbyrd at indiana.edu Sun Feb 15 12:45:45 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sun, 15 Feb 2015 11:45:45 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: Offhand, Perry, I think that's the general idea of what Laurent was suggesting, if not the details. (Though he might disagree:-) .) And I think this kind of representation is worthwhile, not just because you can do it with a text editor, but also because it's more abstract than Bezier control points -- and that's desirable because, for one thing, Bezier curves aren't the only way of drawing nice smooth slur-like curves! One thing, though. The horizontal-position numbers on the lower illustration are all 15's. Surely you meant 15, 45, 75, 90!? --Don On Feb 13, 2015, at 7:07 PM, "Roland, Perry D. (pdr4h)" wrote: I can?t be certain, but I think the attached (really, REALLY crude) illustration depicts what Laurent was getting at. Forgive me if I?ve gotten it wrong. > > The ?crest? or ?trough? of each undulation of the curve is specified by 2 values: the point along an imaginary line connecting the end points of the curve to which the crest is perpendicular and the ?height/depth? of the crest/trough. The distance from the imaginary line to the crest/trough of the curve is expressed in units allowed by data.MEASUREMENT (cm|mm|in|pt|pc|vu) with ?vu? being the default. Negative values indicate curvature to the right of the imaginary line (a trough), positive values to the left (a crest). The point along the imaginary line where the crest/trough occurs is expressed as a percentage of the length of the line. > > In the first slur, the trough occurs at a point that is 25% of the distance between the line?s end points with a ?depth? of -2. The crest occurs at 85% of the length of the line with a ?height? of 2. > > In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90% with heights and depths of -2, 2, -3, 2. > > I haven?t yet worked out the data model for a that behaves this way, but I believe mimicking the one I presented yesterday using Bezier curves is the right direction. > > My question at this point is, Is this a species of Bezier curve that could be accommodated using the element introduced yesterday? > For example -- > > > > > rise decimal REQUIRED > run decimal REQUIRED> > > where @rise = height/depth of the crest/trough and @run = distance along the imaginary line. What isn?t addressed here yet is the specification of the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and @endid? > > You may ask why is this needed. As I?ve said before, Bezier curves are fine if you?re working in a GUI environment, but if not then this provides a convenient way of specifying the curve that can be accomplished in a text editor. > > -- > p. > > > From: Laurent Pugin [mailto:lxpugin at gmail.com] > Sent: Tuesday, February 03, 2015 10:06 AM > To: Roland, Perry D. (pdr4h) > Cc: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Axel, > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > Best > Zoltan > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > This is no "special", rather quite often in printed music from the 19th century. > > > All the best, > 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 --- Donald Byrd Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies Indiana University Bloomington From pdr4h at eservices.virginia.edu Sun Feb 15 15:23:18 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sun, 15 Feb 2015 14:23:18 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> , Message-ID: Sorry about the numbers in the lower illustration. Yes, I meant something like 15, 45, 75, 90. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd at indiana.edu] Sent: Sunday, February 15, 2015 6:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Offhand, Perry, I think that's the general idea of what Laurent was suggesting, if not the details. (Though he might disagree:-) .) And I think this kind of representation is worthwhile, not just because you can do it with a text editor, but also because it's more abstract than Bezier control points -- and that's desirable because, for one thing, Bezier curves aren't the only way of drawing nice smooth slur-like curves! One thing, though. The horizontal-position numbers on the lower illustration are all 15's. Surely you meant 15, 45, 75, 90!? --Don On Feb 13, 2015, at 7:07 PM, "Roland, Perry D. (pdr4h)" wrote: I can?t be certain, but I think the attached (really, REALLY crude) illustration depicts what Laurent was getting at. Forgive me if I?ve gotten it wrong. > > The ?crest? or ?trough? of each undulation of the curve is specified by 2 values: the point along an imaginary line connecting the end points of the curve to which the crest is perpendicular and the ?height/depth? of the crest/trough. The distance from the imaginary line to the crest/trough of the curve is expressed in units allowed by data.MEASUREMENT (cm|mm|in|pt|pc|vu) with ?vu? being the default. Negative values indicate curvature to the right of the imaginary line (a trough), positive values to the left (a crest). The point along the imaginary line where the crest/trough occurs is expressed as a percentage of the length of the line. > > In the first slur, the trough occurs at a point that is 25% of the distance between the line?s end points with a ?depth? of -2. The crest occurs at 85% of the length of the line with a ?height? of 2. > > In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90% with heights and depths of -2, 2, -3, 2. > > I haven?t yet worked out the data model for a that behaves this way, but I believe mimicking the one I presented yesterday using Bezier curves is the right direction. > > My question at this point is, Is this a species of Bezier curve that could be accommodated using the element introduced yesterday? > For example -- > > > > > rise decimal REQUIRED > run decimal REQUIRED> > > where @rise = height/depth of the crest/trough and @run = distance along the imaginary line. What isn?t addressed here yet is the specification of the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and @endid? > > You may ask why is this needed. As I?ve said before, Bezier curves are fine if you?re working in a GUI environment, but if not then this provides a convenient way of specifying the curve that can be accomplished in a text editor. > > -- > p. > > > From: Laurent Pugin [mailto:lxpugin at gmail.com] > Sent: Tuesday, February 03, 2015 10:06 AM > To: Roland, Perry D. (pdr4h) > Cc: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Axel, > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > Best > Zoltan > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > This is no "special", rather quite often in printed music from the 19th century. > > > All the best, > 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 --- 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 From pdr4h at eservices.virginia.edu Sun Feb 15 16:31:53 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Sun, 15 Feb 2015 15:31:53 +0000 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> , , Message-ID: Actually, "not something like", but *exactly*, 15, 45, 75, and 90. :-) -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Sunday, February 15, 2015 9:23 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Sorry about the numbers in the lower illustration. Yes, I meant something like 15, 45, 75, 90. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd at indiana.edu] Sent: Sunday, February 15, 2015 6:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] slur and @curvedir Offhand, Perry, I think that's the general idea of what Laurent was suggesting, if not the details. (Though he might disagree:-) .) And I think this kind of representation is worthwhile, not just because you can do it with a text editor, but also because it's more abstract than Bezier control points -- and that's desirable because, for one thing, Bezier curves aren't the only way of drawing nice smooth slur-like curves! One thing, though. The horizontal-position numbers on the lower illustration are all 15's. Surely you meant 15, 45, 75, 90!? --Don On Feb 13, 2015, at 7:07 PM, "Roland, Perry D. (pdr4h)" wrote: I can?t be certain, but I think the attached (really, REALLY crude) illustration depicts what Laurent was getting at. Forgive me if I?ve gotten it wrong. > > The ?crest? or ?trough? of each undulation of the curve is specified by 2 values: the point along an imaginary line connecting the end points of the curve to which the crest is perpendicular and the ?height/depth? of the crest/trough. The distance from the imaginary line to the crest/trough of the curve is expressed in units allowed by data.MEASUREMENT (cm|mm|in|pt|pc|vu) with ?vu? being the default. Negative values indicate curvature to the right of the imaginary line (a trough), positive values to the left (a crest). The point along the imaginary line where the crest/trough occurs is expressed as a percentage of the length of the line. > > In the first slur, the trough occurs at a point that is 25% of the distance between the line?s end points with a ?depth? of -2. The crest occurs at 85% of the length of the line with a ?height? of 2. > > In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90% with heights and depths of -2, 2, -3, 2. > > I haven?t yet worked out the data model for a that behaves this way, but I believe mimicking the one I presented yesterday using Bezier curves is the right direction. > > My question at this point is, Is this a species of Bezier curve that could be accommodated using the element introduced yesterday? > For example -- > > > > > rise decimal REQUIRED > run decimal REQUIRED> > > where @rise = height/depth of the crest/trough and @run = distance along the imaginary line. What isn?t addressed here yet is the specification of the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and @endid? > > You may ask why is this needed. As I?ve said before, Bezier curves are fine if you?re working in a GUI environment, but if not then this provides a convenient way of specifying the curve that can be accomplished in a text editor. > > -- > p. > > > From: Laurent Pugin [mailto:lxpugin at gmail.com] > Sent: Tuesday, February 03, 2015 10:06 AM > To: Roland, Perry D. (pdr4h) > Cc: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > One option I think could be interesting to add for providing more flexibility is the possibility to specify the bezier points with a percentage for the horizontal position of the intermediate points (0 to 100) and vertical units (as in @bulge) for vertical positions. This would be much easier to draw on a black-board. I'll try to prepare a couple of example images. > > Laurent > > PS For some reason, I have not received the messages from Axel and Raffaele. Is anything wrong with my subscription to the list? > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) wrote: > Hi Raffaele, > > Using @bezier only "locks" the rendering if the control points are specified as absolute page coordinates. If they're given as offsets from something else, such as a particular note, then the rendition of the slur is dependent on the position of that thing. > > This is how I envision it working. It's possible that moving the bezier control points (even if they're moved relative to everything else) will change the shape of the curve. If that's true, then our only mechanism for controlling a slur is through the use of @bulge. For automatic layout without any user intervention, the only mechanism is @curvedir -- remembering that values in @curvedir cannot possibly result in a perfect rendition every time. It seems there truly is no way to have the cake and eat it too, hence the comment which began my initial response to Benni. > > Of course, only those with more knowledge and experience with this stuff can say for sure. > Laurent? Craig? Zoltan? Want to join in? > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Tuesday, February 03, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly concerning the the sharing of responsibilities between the encoder and the renderer. Encoding @bezier before rendering locks the encoding into only one possible rendering, which is not great for the reflowing that a truly dynamic score should allow. Unless the aim of the encoder is to represent/document the curvature of one specific written source, which is a totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to me: there is only one slur and no real XML overlapping (or other limitation) that would justify, arguably, splitting the element in two. > > Raff > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > Hi Perry > > Thanks for your elaborate reply. As always I wasn?t aware of any worms involved, but I did realize that there is no single or easy answer :-) > > Drawing a complex slur that not only avoids collisions with other objects but is also aesthetically satisfying can be quite a challenge. My deepest respect for people working on rendering slurs! > As you say, it almost always requires visual control and corrections to get it right. But recording the corrections also means that they will have to be encodable somehow, that is, in more detail than possible with @bezier, for instance. I have no immediate ideas about how to solve this in a medium as fluid as music notation. > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) > Sendt: 2. februar 2015 20:14 > > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Axel, > > One comment before I answer your questions -- This is a huge can of worms for which it seems there can never be a single, universally satisfying answer. > > @curvedir only provides minimal information about the slur so a renderer must "figure out" the rest. This is the easiest method for the encoder, but requires a lot more intelligence on the part of the rendering engine, for example with regard to collision avoidance. From another angle, however, it provides the greatest amount of flexibility for the renderer to arrive at the final shape of the slur. Like I said before, aside from providing a more detailed classification purpose, allowing curvdir="above below above below (and so on)" doesn't really provide much rendering help because, just as you've observed, it says nothing about the location of the points where the slur is supposed to bend back on itself. > > @bulge attempts to provide this missing information by indicating distance from an imaginary line between the end points of the slur. Providing two values means the distance between the end points should be halved and a curve drawn that passes through the starting point, the point indicated by the 1st value in @bulge, the mid-point of the line, the point indicated by the 2nd value, and the ending point. Three values would mean dividing the distance between the end points by thirds, etc. > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary line) can be drawn with @bulge by supplying only a single value or by giving only positive or only negative values. Doing this, instead of using @curvedir, places the shape of the slur in the control of the encoder instead of the rendering engine, but puts the burden of "scribing" the shape on the encoder. The ability to draw "simple" slurs is why @bulge can't be constrained to alternating positive and negative values. > > The example provided in the Guidelines should use the values -2 and 1. The diagram is also misleading in that the lines connecting the curve with the imaginary line should divide their respective sections of the curve into equal parts; that is, the line illustrating point 1 should be drawn at the "highest" point of the curve, mid-way between the mid-point of the imaginary line and the end point of the slur. > > @bezier provides the most encoder control over the rendition of the slur. But unless the control points of the curve are expressed as offsets from some musical feature (like a note, for instance), then re-flowing the notation will "disconnect" the slur from it and the slur will end up in the wrong place on the page. So, the bezier control points have to be *offsets* from something, presumably from the features pointed at by the @startid and @endid attributes, as long as the notation is expected to be "edit-able". The @startid, @endid, @bezier combination will move the slur with the notation. The problem with bezier control points is the same as with @bulge values -- it's nearly impossible for one to create them without the aid of some kind of drawing environment or iterative "code/view/code" workflow. > > Without a doubt, a better explanation of this stuff is desperately needed the Guidelines. But, there may also be better ways of recording the information necessary for drawing slurs than what is provided by the current set of attributes. I welcome contributions on either front. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] > Sent: Monday, February 02, 2015 3:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi all > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, or @curvedir=?above below?) do indicate explicitly where the slur changes position from above the notes to below ? that is, where the slur intersects the melodic line, so to speak. I guess that the use of @bezier will give the desired result in most situations, but as the actual rendering of the slur must be dependent to some degree on other factors such as the note spacing or system breaks, I wonder how we can be sure that it will always cross the melodic line at the desired place. With @bulge or @curvedir (with extended values as suggested by Zoltan) this must be even more uncertain, right? In principle, a rendering algorithm may draw the slur in Benni?s example above the first three groups of notes and below only the last group when using @bulge or @curvedir. How do we avoid that? > > One more question about @bulge, again just out of curiosity: Should it be defined that a sequence of values for @bulge must an alternating sequence of positive and negative values, either in the guidelines or the schema? Or would a sequence like the one in the guidelines example (@bulge=?2 1?) make any sense in any situation? > > Best, > Axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Kom?ves Zolt?n > Sendt: 2. februar 2015 07:08 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] slur and @curvedir > > Hi Perry, > > I think extending the data type of @curvedir attribute could be justified simply base on the argument of classification: @curvdir provides a classification mechanism, but this classification is rather incomplete, the current values of @curvedir do not cover all the cases that are out there (see Benni's example: nor "above" neither "below" is appropriate, and the omission of the attribute surely cannot imply what we want to convey, that is the curve goes also above and below). This has nothing to do with rendering, since in order to render a slur or phrase mark, the actual curve needs to be calculated anyway, even when "above" or "below" is applied. > > Out of Benni's suggestions I quite like "above-below" / "below-above". (Note that his question concerns @curvedir not @place.) In fact, it occurs to me, we could even allow an alternating sequence of the values "below" and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, then above, could also be applied to curves with multiple inflection points. I have no literary example for this at hand, but wouldn't be surprised if there was some in existence. > > Best > Zoltan > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) : > > Laurent is correct, the values in the example should be -2 and 1. > > The place attribute is for describing the placement of an entity in general terms. For phrase marks and slurs, it also generically describes the curvature of the mark, and therefore functions as short hand for a more detailed description given by the bulge or bezier attributes. It would be possible to add a value to @place for slurs/phrases with multiple inflection points, such as "mixed" or perhaps "complex", but this would only fulfill a classification purpose -- it wouldn't provide any information regarding how to draw the slur/phrase. So, one would still need to use @bulge or @bezier for rendering. > > Another complicating factor is that @place is used by a number of elements other than slur and phrase. Adding "mixed" directly to @place would introduce the possibility of nonsense in the case of, say, or . Of course, a specialized form of @place for slur/phrase is a possibility, but would need careful handling. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] > Sent: Sunday, February 01, 2015 8:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] slur and @curvedir > > Hi Benni, > > Have you looked at @bulge? There is an example in the guidelines: http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > I would have expected the values to be -2 1 for the given example, so I am not sure I understand it correctly. > > Laurent > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl wrote: > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > > In case the picture doesn't come through, please see: https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > This slur may not be properly encoded in MEI using @curvedir that only allows 'above' or 'below' as values. Nevertheless, using @bezier is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / 'alternating' would be applicable? Of course the schema would have to be modified to allow this. Are there any comparable values in other parts of the schema? > > > This is no "special", rather quite often in printed music from the 19th century. > > > All the best, > 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 --- 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 lxpugin at gmail.com Mon Feb 16 23:38:14 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Mon, 16 Feb 2015 23:38:14 +0100 Subject: [MEI-L] slur and @curvedir In-Reply-To: References: <2681_1422623654_54CB83A5_2681_215_1_8A2E82EE-21E7-4F22-84EC-83C787EB440F@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10118DA1841@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DA305F@EXCHANGE-02.kb.dk> Message-ID: Hi Perry, Yes, this is what I had in mind. Even if turning this into bezier points is not trivial, it would still be useful in some cases. Especially since, as Don pointed out, there are other ways to generate curves. Laurent On Sat, Feb 14, 2015 at 1:07 AM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > I can?t be certain, but I think the attached (really, REALLY crude) > illustration depicts what Laurent was getting at. Forgive me if I?ve > gotten it wrong. > > > > The ?crest? or ?trough? of each undulation of the curve is specified by 2 > values: the point along an imaginary line connecting the end points of the > curve to which the crest is perpendicular and the ?height/depth? of the > crest/trough. The distance from the imaginary line to the crest/trough of > the curve is expressed in units allowed by data.MEASUREMENT > (cm|mm|in|pt|pc|vu) with ?vu? being the default. Negative values indicate > curvature to the right of the imaginary line (a trough), positive values to > the left (a crest). The point along the imaginary line where the > crest/trough occurs is expressed as a percentage of the length of the line. > > > > In the first slur, the trough occurs at a point that is 25% of the > distance between the line?s end points with a ?depth? of -2. The crest > occurs at 85% of the length of the line with a ?height? of 2. > > > > In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90% > with heights and depths of -2, 2, -3, 2. > > > > I haven?t yet worked out the data model for a that behaves this > way, but I believe mimicking the one I presented yesterday using Bezier > curves is the right direction. > > > > My question at this point is, Is this a species of Bezier curve that could > be accommodated using the element introduced yesterday? > > For example -- > > > > > > > > > > > rise decimal REQUIRED > > run decimal REQUIRED> > > > > where @rise = height/depth of the crest/trough and @run = distance along > the imaginary line. What isn?t addressed here yet is the specification of > the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and > @endid? > > > > You may ask why is this needed. As I?ve said before, Bezier curves are > fine if you?re working in a GUI environment, but if not then this provides > a convenient way of specifying the curve that can be accomplished in a text > editor. > > > > -- > > p. > > > > > > *From:* Laurent Pugin [mailto:lxpugin at gmail.com] > *Sent:* Tuesday, February 03, 2015 10:06 AM > *To:* Roland, Perry D. (pdr4h) > *Cc:* Music Encoding Initiative > > *Subject:* Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > One option I think could be interesting to add for providing more > flexibility is the possibility to specify the bezier points with a > percentage for the horizontal position of the intermediate points (0 to > 100) and vertical units (as in @bulge) for vertical positions. This would > be much easier to draw on a black-board. I'll try to prepare a couple of > example images. > > > > Laurent > > > > PS For some reason, I have not received the messages from Axel and > Raffaele. Is anything wrong with my subscription to the list? > > > > On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > Hi Raffaele, > > > > Using @bezier only "locks" the rendering if the control points are > specified as absolute page coordinates. If they're given as offsets from > something else, such as a particular note, then the rendition of the slur > is dependent on the position of that thing. > > > > This is how I envision it working. It's possible that moving the bezier > control points (even if they're moved relative to everything else) will > change the shape of the curve. If that's true, then our only mechanism for > controlling a slur is through the use of @bulge. For automatic layout > without any user intervention, the only mechanism is @curvedir -- > remembering that values in @curvedir cannot possibly result in a perfect > rendition every time. It seems there truly is no way to have the cake and > eat it too, hence the comment which began my initial response to Benni. > > > > Of course, only those with more knowledge and experience with this stuff > can say for sure. > > Laurent? Craig? Zoltan? Want to join in? > > > > -- > > p. > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Raffaele Viglianti [raffaeleviglianti at gmail.com] > *Sent:* Tuesday, February 03, 2015 9:29 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi all, > > I find Perry's explanation really helpful and interesting, particularly > concerning the the sharing of responsibilities between the encoder and the > renderer. Encoding @bezier before rendering locks the encoding into only > one possible rendering, which is not great for the reflowing that a truly > dynamic score should allow. Unless the aim of the encoder is to > represent/document the curvature of one specific written source, which is a > totally legitimate approach (and might be what Benni is after?). > > Having two slurs and joining them, instead, seems conceptually wrong to > me: there is only one slur and no real XML overlapping (or other > limitation) that would justify, arguably, splitting the element in two. > > Raff > > > > On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger wrote: > > Hi Perry > > > > Thanks for your elaborate reply. As always I wasn?t aware of any worms > involved, but I did realize that there is no single or easy answer :-) > > > > Drawing a complex slur that not only avoids collisions with other objects > but is also aesthetically satisfying can be quite a challenge. My deepest > respect for people working on rendering slurs! > > As you say, it almost always requires visual control and corrections to > get it right. But recording the corrections also means that they will have > to be encodable somehow, that is, in more detail than possible with > @bezier, for instance. I have no immediate ideas about how to solve this in > a medium as fluid as music notation. > > > > Best, > > Axel > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *P? vegne af *Roland, > Perry D. (pdr4h) > *Sendt:* 2. februar 2015 20:14 > > > *Til:* Music Encoding Initiative > *Emne:* Re: [MEI-L] slur and @curvedir > > > > Hi Axel, > > > > One comment before I answer your questions -- This is a huge can of worms > for which it seems there can never be a single, universally satisfying > answer. > > > > @curvedir only provides minimal information about the slur so a renderer > must "figure out" the rest. This is the easiest method for the encoder, but > requires a lot more intelligence on the part of the rendering engine, for > example with regard to collision avoidance. From another angle, however, it > provides the greatest amount of flexibility for the renderer to arrive at > the final shape of the slur. Like I said before, aside from providing a > more detailed classification purpose, allowing curvdir="above below above > below (and so on)" doesn't really provide much rendering help because, just > as you've observed, it says nothing about the location of the points where > the slur is supposed to bend back on itself. > > > > @bulge attempts to provide this missing information by indicating distance > from an imaginary line between the end points of the slur. Providing two > values means the distance between the end points should be halved and a > curve drawn that passes through the starting point, the point indicated by > the 1st value in @bulge, the mid-point of the line, the point indicated by > the 2nd value, and the ending point. Three values would mean dividing the > distance between the end points by thirds, etc. > > > > "Simple" slurs (i.e., ones that don't alternate sides of the imaginary > line) can be drawn with @bulge by supplying only a single value or by > giving only positive or only negative values. Doing this, instead of using > @curvedir, places the shape of the slur in the control of the encoder > instead of the rendering engine, but puts the burden of "scribing" the > shape on the encoder. The ability to draw "simple" slurs is why @bulge > can't be constrained to alternating positive and negative values. > > > > The example provided in the Guidelines should use the values -2 and 1. > The diagram is also misleading in that the lines connecting the curve with > the imaginary line should divide their respective sections of the curve > into equal parts; that is, the line illustrating point 1 should be drawn at > the "highest" point of the curve, mid-way between the mid-point of the > imaginary line and the end point of the slur. > > > > @bezier provides the most encoder control over the rendition of the slur. > But unless the control points of the curve are expressed as offsets from > some musical feature (like a note, for instance), then re-flowing the > notation will "disconnect" the slur from it and the slur will end up in the > wrong place on the page. So, the bezier control points have to be > *offsets* from something, presumably from the features pointed at by the > @startid and @endid attributes, as long as the notation is expected to be > "edit-able". The @startid, @endid, @bezier combination will move the > slur with the notation. The problem with bezier control points is the same > as with @bulge values -- it's nearly impossible for one to create them > without the aid of some kind of drawing environment or iterative > "code/view/code" workflow. > > > > Without a doubt, a better explanation of this stuff is desperately needed > the Guidelines. But, there may also be better ways of recording the > information necessary for drawing slurs than what is provided by the > current set of attributes. I welcome contributions on either front. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel > Teich Geertinger [atge at kb.dk] > *Sent:* Monday, February 02, 2015 3:29 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi all > > > > Just out of curiosity: None of the solutions I have seen (@bulge, @bezier, > or @curvedir=?above below?) do indicate explicitly where the slur changes > position from above the notes to below ? that is, where the slur intersects > the melodic line, so to speak. I guess that the use of @bezier will give > the desired result in most situations, but as the actual rendering of the > slur must be dependent to some degree on other factors such as the note > spacing or system breaks, I wonder how we can be sure that it will always > cross the melodic line at the desired place. With @bulge or @curvedir (with > extended values as suggested by Zoltan) this must be even more uncertain, > right? In principle, a rendering algorithm may draw the slur in Benni?s > example above the first three groups of notes and below only the last group > when using @bulge or @curvedir. How do we avoid that? > > > > One more question about @bulge, again just out of curiosity: Should it be > defined that a sequence of values for @bulge must an alternating sequence > of positive and negative values, either in the guidelines or the schema? Or > would a sequence like the one in the guidelines example (@bulge=?2 1?) make > any sense in any situation? > > > > Best, > > Axel > > > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *P? vegne af *Kom?ves Zolt?n > *Sendt:* 2. februar 2015 07:08 > *Til:* Music Encoding Initiative > *Emne:* Re: [MEI-L] slur and @curvedir > > > > Hi Perry, > > > > I think extending the data type of @curvedir attribute could be justified > simply base on the argument of classification: @curvdir provides a > classification mechanism, but this classification is rather incomplete, the > current values of @curvedir do not cover all the cases that are out there > (see Benni's example: nor "above" neither "below" is appropriate, and the > omission of the attribute surely cannot imply what we want to convey, that > is the curve goes also above and below). This has nothing to do with > rendering, since in order to render a slur or phrase mark, the actual curve > needs to be calculated anyway, even when "above" or "below" is applied. > > > > Out of Benni's suggestions I quite like "above-below" / "below-above". > (Note that his question concerns @curvedir not @place.) In fact, it occurs > to me, we could even allow an alternating sequence of the values "below" > and "above". Benni's example would be encoded as . This, beside conveying the fact that the curve goes first below, > then above, could also be applied to curves with multiple inflection > points. I have no literary example for this at hand, but wouldn't be > surprised if there was some in existence. > > > > Best > > Zoltan > > > > > > > > 2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > Laurent is correct, the values in the example should be -2 and 1. > > > > The place attribute is for describing the placement of an entity in > general terms. For phrase marks and slurs, it also generically describes > the curvature of the mark, and therefore functions as short hand for a more > detailed description given by the bulge or bezier attributes. It would be > possible to add a value to @place for slurs/phrases with multiple > inflection points, such as "mixed" or perhaps "complex", but this would > only fulfill a classification purpose -- it wouldn't provide any > information regarding how to draw the slur/phrase. So, one would still > need to use @bulge or @bezier for rendering. > > > > Another complicating factor is that @place is used by a number of elements > other than slur and phrase. Adding "mixed" directly to @place would > introduce the possibility of nonsense in the case of, say, or > . Of course, a specialized form of @place for slur/phrase is a > possibility, but would need careful handling. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [laurent at music.mcgill.ca] > *Sent:* Sunday, February 01, 2015 8:27 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] slur and @curvedir > > Hi Benni, > > > > Have you looked at @bulge? There is an example in the guidelines: > http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4 > > > > I would have expected the values to be -2 1 for the given example, so I am > not sure I understand it correctly. > > > > Laurent > > > > On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl > wrote: > > Dear MEI-L, > > Fresch?tz has a question concerning encoding mixed direction slurs. > > > > [image: bildschirmfoto 2015-01-30 um 14 05 39] > > > In case the picture doesn't come through, please see: > https://github.com/Freischuetz-Digital/proofMEIdata/issues/25 > > > > This slur may not be properly encoded in MEI using @curvedir that only > allows 'above' or 'below' as values. Nevertheless, using *@bezier* > is much more verbose than needed? > > Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' / > 'alternating' would be applicable? Of course the schema would have to be > modified to allow this. Are there any comparable values in other parts of > the schema? > > > > This is no "special", rather quite often in printed music from the 19th > century. > > > > All the best, > > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 69500 bytes Desc: not available URL: From lxpugin at gmail.com Wed Feb 18 15:43:30 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 18 Feb 2015 15:43:30 +0100 Subject: [MEI-L] App within verse Message-ID: Hi, Is there any particular reason why /app is not allowed within /verse? I could do: /app /rdg /verse /syl /rdg /verse /syl But since the verse is the same in my case, I would instinctively do: /verse /app /rdg /syl /rdg /syl Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Wed Feb 18 21:50:34 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 18 Feb 2015 20:50:34 +0000 Subject: [MEI-L] App within verse In-Reply-To: References: Message-ID: Briefly -- Not necessarily good reasons, but considerations nonetheless -- 1. no one asked, 2. difficult to translate for current (non-MEI-supporting) software, 3. avoidance of making and ?catch-all? containers -- that is, allowing to appear nearly everywhere and letting contain nearly everything. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, February 18, 2015 9:44 AM To: MEI-list Subject: [MEI-L] App within verse Hi, Is there any particular reason why /app is not allowed within /verse? I could do: /app /rdg /verse /syl /rdg /verse /syl But since the verse is the same in my case, I would instinctively do: /verse /app /rdg /syl /rdg /syl Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxpugin at gmail.com Thu Feb 19 15:43:11 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Thu, 19 Feb 2015 15:43:11 +0100 Subject: [MEI-L] App within verse In-Reply-To: References: Message-ID: Hi Perry, Thanks for the reply. None of them seem to be a good reason to me ;-) However, I can still see your points and I can leave without it. Laurent On Wed, Feb 18, 2015 at 9:50 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Briefly -- > > > > Not necessarily good reasons, but considerations nonetheless -- > > > > 1. no one asked, > > 2. difficult to translate for current (non-MEI-supporting) software, > > 3. avoidance of making and ?catch-all? containers -- that is, > allowing to appear nearly everywhere and letting contain nearly > everything. > > > > -- > > p. > > > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Wednesday, February 18, 2015 9:44 AM > *To:* MEI-list > *Subject:* [MEI-L] App within verse > > > > Hi, > > > > Is there any particular reason why /app is not allowed within /verse? I > could do: > > > > /app > > /rdg > > /verse > > /syl > > /rdg > > /verse > > /syl > > > > But since the verse is the same in my case, I would instinctively do: > > > > /verse > > /app > > /rdg > > /syl > > /rdg > > /syl > > > > Laurent > > _______________________________________________ > 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 Feb 19 15:56:34 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 19 Feb 2015 14:56:34 +0000 Subject: [MEI-L] App within verse In-Reply-To: References: Message-ID: Like I said, these are not necessarily good reasons for not allowing it and I didn?t intend to imply that your suggestion for change is not a good one. I was simply providing some background while trying to keep my response short. Feel free to create a ticket in the Google Code repo. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Thursday, February 19, 2015 9:43 AM To: Music Encoding Initiative Subject: Re: [MEI-L] App within verse Hi Perry, Thanks for the reply. None of them seem to be a good reason to me ;-) However, I can still see your points and I can leave without it. Laurent On Wed, Feb 18, 2015 at 9:50 PM, Roland, Perry D. (pdr4h) > wrote: Briefly -- Not necessarily good reasons, but considerations nonetheless -- 1. no one asked, 2. difficult to translate for current (non-MEI-supporting) software, 3. avoidance of making and ?catch-all? containers -- that is, allowing to appear nearly everywhere and letting contain nearly everything. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, February 18, 2015 9:44 AM To: MEI-list Subject: [MEI-L] App within verse Hi, Is there any particular reason why /app is not allowed within /verse? I could do: /app /rdg /verse /syl /rdg /verse /syl But since the verse is the same in my case, I would instinctively do: /verse /app /rdg /syl /rdg /syl Laurent _______________________________________________ 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 kepper at edirom.de Thu Feb 19 17:51:58 2015 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 19 Feb 2015 17:51:58 +0100 Subject: [MEI-L] App within verse In-Reply-To: References: Message-ID: <57D69DAF-12E4-49BE-A854-D538C7B7A8D3@edirom.de> I think Laurent's request is perfectly reasonable. We cannot prevent abuse of app/rdg and annot in the regular schema. If we really want to do that, it has to be done with Schematron anyway. I strongly support to include app within verse, and have thus opened a ticket for it. Johannes Am 19.02.2015 um 15:56 schrieb Roland, Perry D. (pdr4h) : > > Like I said, these are not necessarily good reasons for not allowing it and I didn?t intend to imply that your suggestion for change is not a good one. I was simply providing some background while trying to keep my response short. Feel free to create a ticket in the Google Code repo. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin > Sent: Thursday, February 19, 2015 9:43 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] App within verse > > Hi Perry, > > Thanks for the reply. None of them seem to be a good reason to me ;-) However, I can still see your points and I can leave without it. > > Laurent > > On Wed, Feb 18, 2015 at 9:50 PM, Roland, Perry D. (pdr4h) wrote: > > Briefly -- > > Not necessarily good reasons, but considerations nonetheless -- > > 1. no one asked, > 2. difficult to translate for current (non-MEI-supporting) software, > 3. avoidance of making and ?catch-all? containers -- that is, allowing to appear nearly everywhere and letting contain nearly everything. > > -- > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin > Sent: Wednesday, February 18, 2015 9:44 AM > To: MEI-list > Subject: [MEI-L] App within verse > > Hi, > > Is there any particular reason why /app is not allowed within /verse? I could do: > > /app > /rdg > /verse > /syl > /rdg > /verse > /syl > > But since the verse is the same in my case, I would instinctively do: > > /verse > /app > /rdg > /syl > /rdg > /syl > > Laurent > > _______________________________________________ > 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 siegert at udk-berlin.de Fri Feb 20 23:14:52 2015 From: siegert at udk-berlin.de (Christine Siegert) Date: Fri, 20 Feb 2015 23:14:52 +0100 Subject: [MEI-L] App within verse In-Reply-To: <57D69DAF-12E4-49BE-A854-D538C7B7A8D3@edirom.de> References: <57D69DAF-12E4-49BE-A854-D538C7B7A8D3@edirom.de> Message-ID: <4B0EC74CEF464EAEB6D21E1175510FF9@PC> I would like to support the idea to allow within , simply because of logical reasons. In most cases, it won't be the verse that differs, but the syllable within the verse. Christine Prof. Dr. Christine Siegert Universit?t der K?nste Berlin Fakult?t Musik, Musikwissenschaft Fasanenstra?e 1B D-10623 Berlin Tel.: +49 (0)30 3185 2318 siegert at udk-berlin.de -----Urspr?ngliche Nachricht----- From: Johannes Kepper Sent: Thursday, February 19, 2015 5:51 PM To: Music Encoding Initiative Subject: Re: [MEI-L] App within verse I think Laurent's request is perfectly reasonable. We cannot prevent abuse of app/rdg and annot in the regular schema. If we really want to do that, it has to be done with Schematron anyway. I strongly support to include app within verse, and have thus opened a ticket for it. Johannes Am 19.02.2015 um 15:56 schrieb Roland, Perry D. (pdr4h) : > > Like I said, these are not necessarily good reasons for not allowing it > and I didn?t intend to imply that your suggestion for change is not a good > one. I was simply providing some background while trying to keep my > response short. Feel free to create a ticket in the Google Code repo. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Laurent Pugin > Sent: Thursday, February 19, 2015 9:43 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] App within verse > > Hi Perry, > > Thanks for the reply. None of them seem to be a good reason to me ;-) > However, I can still see your points and I can leave without it. > > Laurent > > On Wed, Feb 18, 2015 at 9:50 PM, Roland, Perry D. (pdr4h) > wrote: > > Briefly -- > > Not necessarily good reasons, but considerations nonetheless -- > > 1. no one asked, > 2. difficult to translate for current (non-MEI-supporting) software, > 3. avoidance of making and ?catch-all? containers -- that is, > allowing to appear nearly everywhere and letting contain > nearly everything. > > -- > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Laurent Pugin > Sent: Wednesday, February 18, 2015 9:44 AM > To: MEI-list > Subject: [MEI-L] App within verse > > Hi, > > Is there any particular reason why /app is not allowed within /verse? I > could do: > > /app > /rdg > /verse > /syl > /rdg > /verse > /syl > > But since the verse is the same in my case, I would instinctively do: > > /verse > /app > /rdg > /syl > /rdg > /syl > > Laurent > > _______________________________________________ > 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 jane.hatter at mcgill.ca Sat Feb 21 21:00:24 2015 From: jane.hatter at mcgill.ca (Jane Daphne Hatter, Ms) Date: Sat, 21 Feb 2015 20:00:24 +0000 Subject: [MEI-L] MEI Postdoc at McGill Message-ID: Hi All, The SIMSSA team at McGill University is looking to hire a postdoctoral fellow to work on the Analysis axis. We will begin reviewing applications on March 30th. The details are below and please feel free to circulate this to call to anyone you think might be interested and qualified. All the the best, Jane -- Jane Daphne Hatter, PhD SIMSSA Project Manager Schulich School of Music, McGill University Postdoctoral Fellowship at McGill University in Music Information Retrieval The Single Interface for Music Score Searching and Analysis (SIMSSA) project at McGill University seeks a Postdoctoral Fellow in music information retrieval with a demonstrable interest and strengths in developing software for musical searching and analysis. SIMSSA is a seven-year research partnership grant funded by the Social Sciences and Humanities Research Council of Canada (SSHRC), headed by Ichiro Fujinaga, Primary Investigator and Julie Cumming, Co-investigator (for more information visit http://simssa.ca/). The goal of this project is to make digital images of musical notation searchable and analyzable. The team brings together cutting-edge researchers with the digital musical resources and expertise of partner institutions, including DIAMM, the Biblioth?que nationale de France, the British Library, and the Archives of the New York Philharmonic. The research team is divided into two axes?Content, headed by Ichiro Fujinaga, which is addressing the process of creating OMR (optical music recognition) systems for transforming digital images of music into searchable symbolic notation; and Analysis, headed by Julie Cumming, which is creating various tools for large-scale search and analysis. The Fellow will work with Julie Cumming on the Analysis axis, supervising a research group of graduate and undergraduate students, and also in close collaboration with the Content team. PREFERRED QUALIFICATIONS: ? PhD in Computer Science, Electrical Engineering, Music Technology, Music Theory or Musicology, Information Science, or related fields ? Knowledge of music theory and analysis, especially for early music ? Fluency in programming and scripting ? Familiarity with music analysis toolkits, such as music21 or Humdrum ? Experience with designing and managing websites and databases ? Track record of publications in relevant conferences and journals (e.g. ISMIR, SMT) PRACTICALITIES: The fellowship stipend is $38,000 per annum with a health and dental plan. The one-year position will begin May 1, 2015 or as soon as the candidate is available; there is a possibility of a 1-year renewal. Adjudication will begin March 30, 2015 and continue until the position is filled. Applications should consist of: ? a cover letter ? Curriculum vitae ? a writing sample ? evidence of programming skills Materials should be addressed to Ichiro Fujinaga and Julie Cumming, but sent to Jane Hatter, SIMSSA Project Manager, at jane.hatter at mcgill.ca. Please arrange to have three letters of reference sent over e-mail to the same address; ask that referees to include the name of the candidate in the subject line of their emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jane.hatter at mcgill.ca Sat Feb 21 21:08:15 2015 From: jane.hatter at mcgill.ca (Jane Daphne Hatter, Ms) Date: Sat, 21 Feb 2015 20:08:15 +0000 Subject: [MEI-L] MEI Postdoc at McGill In-Reply-To: References: Message-ID: Oops, the subject should just be "Postdoc at McGill." Best, Jane -- Jane Daphne Hatter, PhD SIMSSA Project Manager Schulich School of Music, McGill University From: "", Jane Daphne Hatter > Date: Saturday, February 21, 2015 3:00 PM To: "mei-l at lists.uni-paderborn.de" > Subject: MEI Postdoc at McGill Hi All, The SIMSSA team at McGill University is looking to hire a postdoctoral fellow to work on the Analysis axis. We will begin reviewing applications on March 30th. The details are below and please feel free to circulate this to call to anyone you think might be interested and qualified. All the the best, Jane -- Jane Daphne Hatter, PhD SIMSSA Project Manager Schulich School of Music, McGill University Postdoctoral Fellowship at McGill University in Music Information Retrieval The Single Interface for Music Score Searching and Analysis (SIMSSA) project at McGill University seeks a Postdoctoral Fellow in music information retrieval with a demonstrable interest and strengths in developing software for musical searching and analysis. SIMSSA is a seven-year research partnership grant funded by the Social Sciences and Humanities Research Council of Canada (SSHRC), headed by Ichiro Fujinaga, Primary Investigator and Julie Cumming, Co-investigator (for more information visit http://simssa.ca/). The goal of this project is to make digital images of musical notation searchable and analyzable. The team brings together cutting-edge researchers with the digital musical resources and expertise of partner institutions, including DIAMM, the Biblioth?que nationale de France, the British Library, and the Archives of the New York Philharmonic. The research team is divided into two axes?Content, headed by Ichiro Fujinaga, which is addressing the process of creating OMR (optical music recognition) systems for transforming digital images of music into searchable symbolic notation; and Analysis, headed by Julie Cumming, which is creating various tools for large-scale search and analysis. The Fellow will work with Julie Cumming on the Analysis axis, supervising a research group of graduate and undergraduate students, and also in close collaboration with the Content team. PREFERRED QUALIFICATIONS: ? PhD in Computer Science, Electrical Engineering, Music Technology, Music Theory or Musicology, Information Science, or related fields ? Knowledge of music theory and analysis, especially for early music ? Fluency in programming and scripting ? Familiarity with music analysis toolkits, such as music21 or Humdrum ? Experience with designing and managing websites and databases ? Track record of publications in relevant conferences and journals (e.g. ISMIR, SMT) PRACTICALITIES: The fellowship stipend is $38,000 per annum with a health and dental plan. The one-year position will begin May 1, 2015 or as soon as the candidate is available; there is a possibility of a 1-year renewal. Adjudication will begin March 30, 2015 and continue until the position is filled. Applications should consist of: ? a cover letter ? Curriculum vitae ? a writing sample ? evidence of programming skills Materials should be addressed to Ichiro Fujinaga and Julie Cumming, but sent to Jane Hatter, SIMSSA Project Manager, at jane.hatter at mcgill.ca. Please arrange to have three letters of reference sent over e-mail to the same address; ask that referees to include the name of the candidate in the subject line of their emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Thu Feb 26 21:13:27 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 26 Feb 2015 15:13:27 -0500 Subject: [MEI-L] Closed/Plus encoding symbol Message-ID: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> Hi all, I'm trying to encode a "+" articulation mark on a note, and don't seem to be able to find anything in @artic that matches up with it. I could be looking in the wrong place, though. You can see an example of this symbol in action in Gould's "Behind Bars" on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've consulted the Unicode Western notation guide (from which @artic seems to take its inspiration) and it also seems to be lacking there. Any clues? Thanks, -Andrew From craigsapp at gmail.com Thu Feb 26 21:33:50 2015 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 26 Feb 2015 12:33:50 -0800 Subject: [MEI-L] Closed/Plus encoding symbol In-Reply-To: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> References: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> Message-ID: Hi Andrew, Technically it will depend on the semantics of the symbol, as a '+' sign will most likely have different meanings for different repertories/instruments. For French Horns, the "+" sign is used to indicate a stopped note (or the start of a sequence of stopped notes that would be cancelled by an "o" above a note, meaning "open".). In the MEI articulation list: http://music-encoding.org/documentation/guidelines2013/data.ARTICULATION I see an entry called "stop", so that is the most likely thing to start with. -=+Craig On 26 February 2015 at 12:13, Andrew Hankinson wrote: > Hi all, > > I'm trying to encode a "+" articulation mark on a note, and don't seem to be able to find anything in @artic that matches up with it. I could be looking in the wrong place, though. > > You can see an example of this symbol in action in Gould's "Behind Bars" on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've consulted the Unicode Western notation guide (from which @artic seems to take its inspiration) and it also seems to be lacking there. > > Any clues? > > Thanks, > -Andrew > > > > _______________________________________________ > 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 Thu Feb 26 21:44:51 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Thu, 26 Feb 2015 15:44:51 -0500 Subject: [MEI-L] Closed/Plus encoding symbol In-Reply-To: <20602_1424982862_54EF834D_20602_249_3_CAPcjuFepYjX_auvs7RAOVPvpqhF9BdjyVruXU-4depoo9NYyuw@mail.gmail.com> References: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> <20602_1424982862_54EF834D_20602_249_3_CAPcjuFepYjX_auvs7RAOVPvpqhF9BdjyVruXU-4depoo9NYyuw@mail.gmail.com> Message-ID: Thanks, Craig. The trick is that this is coming out of Sibelius so I don't really have the luxury of encoding it semantically -- I just need to indicate the most likely semantics, since it may be "overloaded" in some contexts by people who just want the symbol, not the meaning. "Stop" looks good to me, though -- and you're backed up by Wikipedia on this. http://en.wikipedia.org/wiki/List_of_musical_symbols#Articulation_marks Thanks! -Andrew > On Feb 26, 2015, at 3:33 PM, Craig Sapp wrote: > > Hi Andrew, > > Technically it will depend on the semantics of the symbol, as a '+' > sign will most likely have different meanings for different > repertories/instruments. > > For French Horns, the "+" sign is used to indicate a stopped note (or > the start of a sequence of stopped notes that would be cancelled by an > "o" above a note, meaning "open".). > > In the MEI articulation list: > http://music-encoding.org/documentation/guidelines2013/data.ARTICULATION > > I see an entry called "stop", so that is the most likely thing to start with. > > -=+Craig > > > > > On 26 February 2015 at 12:13, Andrew Hankinson > wrote: >> Hi all, >> >> I'm trying to encode a "+" articulation mark on a note, and don't seem to be able to find anything in @artic that matches up with it. I could be looking in the wrong place, though. >> >> You can see an example of this symbol in action in Gould's "Behind Bars" on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've consulted the Unicode Western notation guide (from which @artic seems to take its inspiration) and it also seems to be lacking there. >> >> Any clues? >> >> Thanks, >> -Andrew >> >> >> >> _______________________________________________ >> 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 esfield at stanford.edu Fri Feb 27 01:08:51 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Thu, 26 Feb 2015 16:08:51 -0800 (PST) Subject: [MEI-L] Closed/Plus encoding symbol In-Reply-To: References: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> Message-ID: <7fda657c.0000173c.00000007@MUS-MJ00MNV8.stanford.edu> It's also an ornament in SOME English harpsichord/clavichord music. Eleanor -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp Sent: Thursday, February 26, 2015 12:34 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Closed/Plus encoding symbol Hi Andrew, Technically it will depend on the semantics of the symbol, as a '+' sign will most likely have different meanings for different repertories/instruments. For French Horns, the "+" sign is used to indicate a stopped note (or the start of a sequence of stopped notes that would be cancelled by an "o" above a note, meaning "open".). In the MEI articulation list: http://music-encoding.org/documentation/guidelines2013/data.ARTICULATION I see an entry called "stop", so that is the most likely thing to start with. -=+Craig On 26 February 2015 at 12:13, Andrew Hankinson wrote: > Hi all, > > I'm trying to encode a "+" articulation mark on a note, and don't seem to be able to find anything in @artic that matches up with it. I could be looking in the wrong place, though. > > You can see an example of this symbol in action in Gould's "Behind Bars" on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've consulted the Unicode Western notation guide (from which @artic seems to take its inspiration) and it also seems to be lacking there. > > Any clues? > > Thanks, > -Andrew > > > > _______________________________________________ > 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 raffaeleviglianti at gmail.com Fri Feb 27 19:54:49 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 27 Feb 2015 13:54:49 -0500 Subject: [MEI-L] Music Addressability Service (alpha) Message-ID: Dear List, As part of the Enhancing Music Notation Addressability (EMA) project, we've been working on a service that implements the Music Addressability API for MEI. (I sent an update about that back in November ). The idea behind EMA is to make it possible to link to specific parts of a music document available online. A demo interface to the MEI service is available here: http://umd-mith.github.io/ema/ It allows you to: - obtain file information useful to make a selection (e.g. number of measures and stave, beat changes, etc.) - make a selection via a form - retrieve the MEI selection and obtain the selection URL The interface simply builds a URL for the service, which is hosted at http://ema.mith.org/. You can send GET requests directly to the service, for example:[1] http://ema.mith.org/http%3A%2F%2Fmusic-encoding.org%2FsampleCollection%2Fencodings%2Fattribute_syl.xml/1-1/1,3/1-1 This will give you a selection of the file attribute_syl.xml, specifically the first beat of measure one, first and third staves. Some quick tech info: the service is a Flask-based RESTful service that uses DDMAL's libmei python bindings to operate on MEI files. Please consider this to be in *alpha*, I would expect a few glitches, and I wouldn't rule out major catastrophes :) In fact, I would very much appreciate your feedback so that we can catch some bugs. One way of testing the service could be trying it out with your MEI files published online and see if you get back the selections that you'd expect. Many thanks! Best wishes, Raff NOTES [1]: NB this is a proof-of-concept so the service at ema.mith.org is not meant to be permanent, at least for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donbyrd at indiana.edu Fri Feb 27 22:13:53 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Fri, 27 Feb 2015 21:13:53 +0000 Subject: [MEI-L] Closed/Plus encoding symbol: other meanings In-Reply-To: <7fda657c.0000173c.00000007@MUS-MJ00MNV8.stanford.edu> References: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> <7fda657c.0000173c.00000007@MUS-MJ00MNV8.stanford.edu> Message-ID: <0676ED59-9B27-4D7F-AD4D-C97514C44C0D@indiana.edu> And it's often used for left-hand pizzicato in music for bowed strings, hard key slaps for flute, and probably five another things in music for five other instruments. --Don On Feb 26, 2015, at 7:08 PM, Eleanor Selfridge-Field wrote: > It's also an ornament in SOME English harpsichord/clavichord music. > > Eleanor > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Craig Sapp > Sent: Thursday, February 26, 2015 12:34 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Closed/Plus encoding symbol > > Hi Andrew, > > Technically it will depend on the semantics of the symbol, as a '+' > sign will most likely have different meanings for different > repertories/instruments. > > For French Horns, the "+" sign is used to indicate a stopped note (or the > start of a sequence of stopped notes that would be cancelled by an "o" > above a note, meaning "open".). > > In the MEI articulation list: > > http://music-encoding.org/documentation/guidelines2013/data.ARTICULATION > > I see an entry called "stop", so that is the most likely thing to start > with. > > -=+Craig > > > > On 26 February 2015 at 12:13, Andrew Hankinson > wrote: >> Hi all, >> >> I'm trying to encode a "+" articulation mark on a note, and don't seem > to be able to find anything in @artic that matches up with it. I could be > looking in the wrong place, though. >> >> You can see an example of this symbol in action in Gould's "Behind Bars" > on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've > consulted the Unicode Western notation guide (from which @artic seems to > take its inspiration) and it also seems to be lacking there. >> >> Any clues? >> >> Thanks, >> -Andrew >> >> >> >> _______________________________________________ >> 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 pdr4h at eservices.virginia.edu Fri Feb 27 22:52:30 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 27 Feb 2015 21:52:30 +0000 Subject: [MEI-L] Closed/Plus encoding symbol: other meanings In-Reply-To: <0676ED59-9B27-4D7F-AD4D-C97514C44C0D@indiana.edu> References: <84423D32-D3F1-4D3A-B909-C93B55283034@mail.mcgill.ca> <7fda657c.0000173c.00000007@MUS-MJ00MNV8.stanford.edu>, <0676ED59-9B27-4D7F-AD4D-C97514C44C0D@indiana.edu> Message-ID: And MEI encodes the meaning, not the look of the symbol. Both "stop" and "lhpizz" are available in the list of articulations even though they both use the same "+" symbol. The list provided by data.ARTICULATION can be expanded to include the flute key slap and other meanings if anyone is interested in compiling a list of possible additions. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Byrd, Donald A. [donbyrd at indiana.edu] Sent: Friday, February 27, 2015 4:13 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Closed/Plus encoding symbol: other meanings And it's often used for left-hand pizzicato in music for bowed strings, hard key slaps for flute, and probably five another things in music for five other instruments. --Don On Feb 26, 2015, at 7:08 PM, Eleanor Selfridge-Field wrote: > It's also an ornament in SOME English harpsichord/clavichord music. > > Eleanor > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Craig Sapp > Sent: Thursday, February 26, 2015 12:34 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Closed/Plus encoding symbol > > Hi Andrew, > > Technically it will depend on the semantics of the symbol, as a '+' > sign will most likely have different meanings for different > repertories/instruments. > > For French Horns, the "+" sign is used to indicate a stopped note (or the > start of a sequence of stopped notes that would be cancelled by an "o" > above a note, meaning "open".). > > In the MEI articulation list: > > http://music-encoding.org/documentation/guidelines2013/data.ARTICULATION > > I see an entry called "stop", so that is the most likely thing to start > with. > > -=+Craig > > > > On 26 February 2015 at 12:13, Andrew Hankinson > wrote: >> Hi all, >> >> I'm trying to encode a "+" articulation mark on a note, and don't seem > to be able to find anything in @artic that matches up with it. I could be > looking in the wrong place, though. >> >> You can see an example of this symbol in action in Gould's "Behind Bars" > on pp. 281, 297-8 (closed hi-hat) and 263 (Horn hand-stopping). I've > consulted the Unicode Western notation guide (from which @artic seems to > take its inspiration) and it also seems to be lacking there. >> >> Any clues? >> >> Thanks, >> -Andrew >> >> >> >> _______________________________________________ >> 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 From Jason.Stoessel at une.edu.au Mon Mar 2 12:45:12 2015 From: Jason.Stoessel at une.edu.au (Jason Stoessel) Date: Mon, 2 Mar 2015 11:45:12 +0000 Subject: [MEI-L] Music Addressability Service (alpha) In-Reply-To: References: Message-ID: <4760D2CB-E60D-4CF5-816B-562E58BD2FB4@une.edu.au> Bravo! A excellent step in a very promising direction for MEI. > On 28 Feb 2015, at 5:54 am, Raffaele Viglianti wrote: > > Dear List, > > As part of the Enhancing Music Notation Addressability (EMA) project, we've been working on a service that implements the Music Addressability API for MEI. (I sent an update about that back in November). > > The idea behind EMA is to make it possible to link to specific parts of a music document available online. > > A demo interface to the MEI service is available here: http://umd-mith.github.io/ema/ > > It allows you to: > > - obtain file information useful to make a selection (e.g. number of measures and stave, beat changes, etc.) > - make a selection via a form > - retrieve the MEI selection and obtain the selection URL > > The interface simply builds a URL for the service, which is hosted at http://ema.mith.org/. You can send GET requests directly to the service, for example:[1] > > http://ema.mith.org/http%3A%2F%2Fmusic-encoding.org%2FsampleCollection%2Fencodings%2Fattribute_syl.xml/1-1/1,3/1-1 > > This will give you a selection of the file attribute_syl.xml, specifically the first beat of measure one, first and third staves. > > Some quick tech info: the service is a Flask-based RESTful service that uses DDMAL's libmei python bindings to operate on MEI files. > > Please consider this to be in *alpha*, I would expect a few glitches, and I wouldn't rule out major catastrophes :) In fact, I would very much appreciate your feedback so that we can catch some bugs. One way of testing the service could be trying it out with your MEI files published online and see if you get back the selections that you'd expect. > > Many thanks! > > Best wishes, > Raff > > NOTES > [1]: NB this is a proof-of-concept so the service at ema.mith.org is not meant to be permanent, at least for now. > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -- Dr Jason Stoessel, BMus/BA, BA Hons, PhD Adjunct Research Fellow School of Arts Faculty of Arts and Sciences University of New England ARMIDALE NSW 2351 AUSTRALIA jason.stoessel at une.edu.au Skype ID: jjstoessel FaceTime: jason.stoessel at gmail.com une-au.academia.edu/JasonStoessel -- Chief Investigator, ARC Discovery Project (DP150102135) ?Canonic techniques and musical change, c.1330?c.1530" -- 2014?2015 Associate Investigator ARC Centre of Excellence for the History of Emotions (CE110001011) -- From zolaemil at gmail.com Mon Mar 2 14:43:23 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 2 Mar 2015 13:43:23 +0000 Subject: [MEI-L] Music Addressability Service (alpha) In-Reply-To: <4760D2CB-E60D-4CF5-816B-562E58BD2FB4@une.edu.au> References: <4760D2CB-E60D-4CF5-816B-562E58BD2FB4@une.edu.au> Message-ID: Bravo indeed! Looks very promising! I gave it a go only one file so far and the Request Info worked, but getting no response from the actual selection. Perhaps my mei isn't valid against your application ODD, or perhaps one of those little glitches. I'll get back to you with details off-list. It's very exciting seeing it in action! Z 2015-03-02 11:45 GMT+00:00 Jason Stoessel : > Bravo! A excellent step in a very promising direction for MEI. > > > On 28 Feb 2015, at 5:54 am, Raffaele Viglianti < > raffaeleviglianti at gmail.com> wrote: > > > > Dear List, > > > > As part of the Enhancing Music Notation Addressability (EMA) project, > we've been working on a service that implements the Music Addressability > API for MEI. (I sent an update about that back in November). > > > > The idea behind EMA is to make it possible to link to specific parts of > a music document available online. > > > > A demo interface to the MEI service is available here: > http://umd-mith.github.io/ema/ > > > > It allows you to: > > > > - obtain file information useful to make a selection (e.g. number of > measures and stave, beat changes, etc.) > > - make a selection via a form > > - retrieve the MEI selection and obtain the selection URL > > > > The interface simply builds a URL for the service, which is hosted at > http://ema.mith.org/. You can send GET requests directly to the service, > for example:[1] > > > > > http://ema.mith.org/http%3A%2F%2Fmusic-encoding.org%2FsampleCollection%2Fencodings%2Fattribute_syl.xml/1-1/1,3/1-1 > > > > This will give you a selection of the file attribute_syl.xml, > specifically the first beat of measure one, first and third staves. > > > > Some quick tech info: the service is a Flask-based RESTful service that > uses DDMAL's libmei python bindings to operate on MEI files. > > > > Please consider this to be in *alpha*, I would expect a few glitches, > and I wouldn't rule out major catastrophes :) In fact, I would very much > appreciate your feedback so that we can catch some bugs. One way of testing > the service could be trying it out with your MEI files published online and > see if you get back the selections that you'd expect. > > > > Many thanks! > > > > Best wishes, > > Raff > > > > NOTES > > [1]: NB this is a proof-of-concept so the service at ema.mith.org is > not meant to be permanent, at least for now. > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -- > Dr Jason Stoessel, BMus/BA, BA Hons, PhD > Adjunct Research Fellow > School of Arts > Faculty of Arts and Sciences > University of New England > ARMIDALE NSW 2351 > AUSTRALIA > jason.stoessel at une.edu.au > Skype ID: jjstoessel > FaceTime: jason.stoessel at gmail.com > une-au.academia.edu/JasonStoessel > -- > Chief Investigator, ARC Discovery Project (DP150102135) > ?Canonic techniques and musical change, c.1330?c.1530" > -- > 2014?2015 Associate Investigator > ARC Centre of Excellence for the History of Emotions (CE110001011) > -- > > _______________________________________________ > 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 2 17:43:03 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 2 Mar 2015 16:43:03 +0000 Subject: [MEI-L] within ? Message-ID: There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there's a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I'm inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at rjlewis.me.uk Mon Mar 2 18:33:34 2015 From: richard at rjlewis.me.uk (Richard Lewis) Date: Mon, 02 Mar 2015 17:33:34 +0000 Subject: [MEI-L] Software Engineer for Transforming Musicology Message-ID: <87d24ruwwh.wl%richard@rjlewis.me.uk> JOB ADVERTISEMENT Research Assistant / Software Engineer Salary: ?36,009 to ?40,161 pa, incl. LW Contract: Fixed term, part- or full-time Location: New Cross, London, UK Closing date: 27 March 2015 Reference: COM000059 Details: The Transforming Musicology project is seeking a research programmer to join the research team in the Department of Computing at Goldsmiths College . THE ROLE As a research programmer, you will be a skilled software engineer with experience of the full software development lifecycle. You will understand the open source development model, be able to work with existing code-bases as easily as designing from scratch, and have experience of working in collaboration with other developers and with academic researchers. You will be responsible for independent development of tools prototyped as part of the research activities, with a view to making them usable by and accessible to the wider academic and potential user community, including especially musicologists and musicians. You will mix working on state-of-the art algorithms for multimedia search and retrieval with developing APIs for other programmers, and producing innovative user interfaces targeted at focused user groups and at a variety of interactive platforms. You will be joining a lively and challenging research culture in the Department of Computing and you will be expected to engage with that culture and contribute to the research activities of the project. You will take a leading role in dissemination of the project's research including documenting your own work and presenting tools and results at conferences and workshops. THE PROJECT The Transforming Musicology project is funded in the AHRC's Digital Transformations theme for three years from October 2013. It includes partners at Goldsmiths' College, Queen Mary University of London, Oxford University (Faculty of Music and Oxford e-Research Centre), Lancaster University, and Utrecht University. The project takes tools and methods from music information retrieval and applies them to problems in musicology. As case studies, it explores three areas of music research: sixteenth century lute and vocal music, the leitmotive technique of Richard Wagner, and the musicology of the social media. Each of these case studies makes use of a variety of digital techniques including Linked Data and advanced audio search techniques. The project therefore incorporates a number of work packages aimed at developing tools applicable for these techniques. The project team at Goldsmiths comprises the principal investigator Prof. Tim Crawford, two co-investigators including Dr. Christophe Rhodes to whom you will be reporting, three research associates and a Ph.D student. APPLICATION Applications should be made by following the link to Goldsmiths HR on the project website . The closing date is Friday 27 March 2015. Informal enquiries may be made to Richard Lewis , the Transforming Musicology project manager. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From esfield at stanford.edu Mon Mar 2 23:50:38 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 2 Mar 2015 14:50:38 -0800 (PST) Subject: [MEI-L] within ? In-Reply-To: References: Message-ID: <1590829324.1829059.1425336638969.JavaMail.zimbra@stanford.edu> Perry's proposal makes sense to me. Eleanor ----- Original Message ----- From: "Perry D. Roland (pdr4h)" To: mei-l at lists.uni-paderborn.de Sent: Monday, March 2, 2015 8:43:03 AM Subject: [MEI-L] within ? There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there?s a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I?m inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu _______________________________________________ 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 stadler at edirom.de Tue Mar 3 14:42:32 2015 From: stadler at edirom.de (Peter Stadler) Date: Tue, 3 Mar 2015 14:42:32 +0100 Subject: [MEI-L] Cataloging with MEI: Workshop and Interest Group In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DBEA9A@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DBEA9A@EXCHANGE-02.kb.dk> Message-ID: <49516531-1B9F-4846-BAAA-6EDF82B1FDBA@edirom.de> Hi Kristina, hi Axel, just a short notice that I?m very interested in your initiative! Kristina and I will present our paper "A Digital Thematic Catalogue of Carl Maria von Weber?s Works? which seems to fit well into the goals of the IG. Best Peter > Am 13.02.2015 um 14:10 schrieb Axel Teich Geertinger : > > Dear colleagues, > over the last few years, MEI has been adopted for cataloging purposes in a variety of contexts, including libraries, catalog projects and editorial projects. > One of the most important assets of MEI is its flexibility, which allows room for custom solutions, tailored to project-specific requirements. But as this flexibility may also cause long-term problems with regard to interoperability of data, we believe it makes sense to establish an interest group for cataloging with MEI where special requirements in dealing with MEI metadata could be brought up to discussion. > An initial meeting is scheduled as one-day workshop for 21 May 2015, the unconference day of this year?s Music Encoding Conference. At the workshop we intend to analyze and discuss different data models, identify varying cataloging practices and to start working on a shared core model as well as best practice recommendations. Against this background the workshop is primarily addressed to people already working in the field, willing to share their expertise and identify potential for collaboration. It is also open to the public, but please note that a tutorial into MEI metadata won?t be offered. > We would be very happy about short presentations of existing tools and use cases involving MEI metadata and kindly ask you to inform us (Kristina Richts, krichts at mail.uni-paderborn.de; or Axel Geertinger, atge at kb.dk) in the run-up to the workshop if you would like to present something. Please note, however, that the main focus will be on informal, open discussions rather than presentations. > At the end of the workshop we hope to take the first steps towards forming a Cataloging Interest Group according to the new MEI by-laws (see excerpt below). > Looking forward to seeing you all in Florence we send our kind regards, > Kristina Richts and Axel Teich Geertinger > > > Quoted from the MEI by-laws: > 8 Interest Groups > An Interest Group (henceforth ?IG?) is composed of any number of members of the MEI community with an interest in a certain music encoding topic or problem. The topic of interest should be reflected in the group?s name. Individual membership in multiple groups is allowed. > > In order to form a new IG, a proposal shall be made to the Board, containing the group?s name, goals, and a list of founding members. The Board is responsible for reviewing the application in a timely fashion and granting or withholding official recognition to the new group. > > Each interest group must: > > ? select an administrative chair > > ? produce regular activity reports > (annual reports due 1 month prior to the annual Board meeting) > > A single person may not be administrative chair of multiple IGs. The IG?s administrative chair takes responsibility for acting as contact person for the IG, ensuring regular activity, submitting reports to the Board, and organizing the group?s work, e.g. calling for meetings and coordinating development efforts. > > Each IG will be self-organizing; that is, there will be no formal regulations on how any other responsibilities are to be divided amongst its members. In addition, the IG may establish decision-making processes as necessary; however, it should rely on consensus rather than majority rule whenever possible. > > 8.1 Interest Group privileges > All Interest Groups will be listed on the MEI-website and are eligible to other benefits as the Board may determine from time to time. > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From gdibacco at indiana.edu Sun Mar 8 00:47:13 2015 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Sat, 07 Mar 2015 18:47:13 -0500 Subject: [MEI-L] MEC Florence 2015 Provisional Schedule Message-ID: <54FB8E01.4040607@indiana.edu> An HTML attachment was scrubbed... URL: From stadler at edirom.de Fri Mar 13 11:14:59 2015 From: stadler at edirom.de (Peter Stadler) Date: Fri, 13 Mar 2015 11:14:59 +0100 Subject: [MEI-L] Bidding farewell to Google Code Message-ID: <705EBA75-1BAD-43D0-8A81-31FE1BA69624@edirom.de> Dear all, Google code is closing down: http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html We already have the GitHub mirror but what about the issues/tickets? Best Peter -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From klaus.rettinghaus at gmail.com Fri Mar 13 11:38:00 2015 From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus) Date: Fri, 13 Mar 2015 11:38:00 +0100 Subject: [MEI-L] Bidding farewell to Google Code In-Reply-To: <705EBA75-1BAD-43D0-8A81-31FE1BA69624@edirom.de> References: <705EBA75-1BAD-43D0-8A81-31FE1BA69624@edirom.de> Message-ID: <1426243080.2619.0@smtp.gmail.com> Hi there, it is said, that the expoter tool should transfer the issues. Maybe it would be a good idea to move completely after the next release of MEI? Best Klaus Am Fr, 13. M?r, 2015 um 11:14 schrieb Peter Stadler : > Dear all, > > Google code is closing down: > http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html > We already have the GitHub mirror but what about the issues/tickets? > > Best > Peter > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From lxpugin at gmail.com Fri Mar 13 11:50:08 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Fri, 13 Mar 2015 11:50:08 +0100 Subject: [MEI-L] Bidding farewell to Google Code In-Reply-To: <1426243080.2619.0@smtp.gmail.com> References: <705EBA75-1BAD-43D0-8A81-31FE1BA69624@edirom.de> <1426243080.2619.0@smtp.gmail.com> Message-ID: Andrew has already looked at importing everything and it will not be a problem. The issues will come with it (and unfortunately won't be solved in the process), but for now I would recommend to still add them to Google Code since this is the master repository. Laurent On Fri, Mar 13, 2015 at 11:38 AM, Klaus Rettinghaus < klaus.rettinghaus at gmail.com> wrote: > Hi there, > > it is said, that the expoter tool should transfer the issues. > Maybe it would be a good idea to move completely after the next release of > MEI? > > Best > Klaus > > Am Fr, 13. M?r, 2015 um 11:14 schrieb Peter Stadler : > > Dear all, Google code is closing down: > http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html > We already have the GitHub mirror but what about the issues/tickets? Best > Peter > _______________________________________________ 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 atge at kb.dk Fri Mar 13 12:47:27 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 13 Mar 2015 11:47:27 +0000 Subject: [MEI-L] within ? In-Reply-To: References: Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> Hi Perry Sorry for the long response time, but I was hoping for others to step in first since we have had some discussion about this already. I am in favor of both changes. The latter - allowing in - would make it possible to avoid listing instruments at work or expression level which are not part of the general instrumentation of that expression, a piano for instance, if a piano reduction exists of an orchestral work. So instead of Violino 1 Violino 2 ... Pianoforte we could do: Pianoforte Violino 1 Violino 2 ... where the instrumentation in source1 could be either duplicated from or, if not indicated, understood as inherited from . The soon-to-be-established Cataloging Interest Group could discuss a recommended practice for this type of information. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. marts 2015 17:43 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] within ? There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there's a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I'm inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From stadler at edirom.de Fri Mar 13 14:23:45 2015 From: stadler at edirom.de (Peter Stadler) Date: Fri, 13 Mar 2015 14:23:45 +0100 Subject: [MEI-L] Bidding farewell to Google Code In-Reply-To: References: <705EBA75-1BAD-43D0-8A81-31FE1BA69624@edirom.de> <1426243080.2619.0@smtp.gmail.com> Message-ID: <7798C50F-80DE-4009-92C5-0C0EA5106BAC@edirom.de> Thanks for taking care! Cheers Peter > Am 13.03.2015 um 11:50 schrieb Laurent Pugin : > > Andrew has already looked at importing everything and it will not be a problem. The issues will come with it (and unfortunately won't be solved in the process), but for now I would recommend to still add them to Google Code since this is the master repository. > > Laurent > > On Fri, Mar 13, 2015 at 11:38 AM, Klaus Rettinghaus wrote: > Hi there, > > it is said, that the expoter tool should transfer the issues. > Maybe it would be a good idea to move completely after the next release of MEI? > > Best > Klaus > > Am Fr, 13. M?r, 2015 um 11:14 schrieb Peter Stadler : >> Dear all, >> >> Google code is closing down: >> http://google-opensource.blogspot.de/2015/03/farewell-to-google-code.html >> >> We already have the GitHub mirror but what about the issues/tickets? >> >> Best >> Peter >> >> _______________________________________________ >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Mon Mar 23 20:26:30 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 23 Mar 2015 19:26:30 +0000 Subject: [MEI-L] within ? In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, I can certainly see the practicality in this change, but if I may play the devil's advocate for a moment -- According to basic FRBR tenets, doesn't a change in medium signal a different expression? If so, then allowing in and treating the differently-instrumented sources as a single expression seems to be a contradiction of basic FRBR. Following this "different medium=different expression" idea, the following markup seems appropriate. The versions for orchestra are grouped as embodiments of the same expression, while the piano reduction is treated as a separate expression due to its change of instrumentation -- If, however, one believes that a change in *content* (but not enough to be considered a new work) signals a change of expression, then the following markup could be used. The (first) version of the full score and its piano reduction are grouped as belonging to the same expression and the other full score is a different expression (due perhaps to structural, not instrumentation changes). In both cases, the source and the expression markup remain essentially unchanged, only the relationships defined within are modified. An advantage here is that no data is actually moved. In other words, the performance medium information can always be found in the same place. In the 2nd case, however, I'm not sure how one would describe the performing forces without allowing either or to be repeatable. I don't believe that Violino 1 Violino 2 ... Pianoforte is the best way to go. The intention of @source on is to allow one to say that there are 2 sources, one of which includes the piano in its orchestration, the other of which does not, which this appears to do. For the situation you're describing, I think it's much clearer to allow to be repeatable and to carry @source, resulting in Violino 1 Violino 2 ... Pianoforte Using Schematron, one could say that must either a) have content or b) use @source, but it should not allow both. Under these circumstances, I could see allowing within , but this means that could occur either within or within , which sometimes leads to criticism. Sorry for my usual long-winded explanation, but I think it's important to explain the derivation of the markup instead of offering up a solution that seems to materialize out of thin air. In any case, I recognize that this is a tough problem, so I look forward to the formation of the cataloging IG (although I'd recommend calling it the "metadata IG") and its recommendations. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, March 13, 2015 7:47 AM To: Music Encoding Initiative Subject: Re: [MEI-L] within ? Hi Perry Sorry for the long response time, but I was hoping for others to step in first since we have had some discussion about this already. I am in favor of both changes. The latter - allowing in - would make it possible to avoid listing instruments at work or expression level which are not part of the general instrumentation of that expression, a piano for instance, if a piano reduction exists of an orchestral work. So instead of Violino 1 Violino 2 ... Pianoforte we could do: Pianoforte Violino 1 Violino 2 ... where the instrumentation in source1 could be either duplicated from or, if not indicated, understood as inherited from . The soon-to-be-established Cataloging Interest Group could discuss a recommended practice for this type of information. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. marts 2015 17:43 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] within ? There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there's a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I'm inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From F.Wiering at uu.nl Wed Mar 25 16:24:02 2015 From: F.Wiering at uu.nl (Frans Wiering) Date: Wed, 25 Mar 2015 16:24:02 +0100 Subject: [MEI-L] 2nd CFP ISMIR 2015 - 16th International Society for Music Information Retrieval Conference, 26-30 October 2015, Malaga, SPAIN In-Reply-To: <55128972.6010301@ic.uma.es> References: <55128972.6010301@ic.uma.es> Message-ID: <5512D312.8040002@uu.nl> (Apologies for any cross-postings): Call for Participation ISMIR 2015 - 16th International Society for Music Information Retrieval Conference 26-30 October 2015, Malaga, SPAIN http://ismir2015.uma.es/ The 16th International Conference on Music Information Retrieval, ISMIR 2015, will be held in Malaga, SPAIN, from Monday, October 26 to Friday, October 30 2015. The annual Conference of the International Society for Music Information Retrieval (ISMIR) is the world's leading research forum on processing, analyzing, searching, organizing and accessing music-related data. Music becomes music after being processed by the human mind and each person perceives the music in a different and complex way. Therefore, this conference embraces the complexity and diversity of music by showcasing ideas and applications that aim to enhance the way in which we interact with music. MIR is a truly interdisciplinary area, involving researchers, developers, educators, librarians, students and professionals from the disciplines of musicology, cognitive science, library and information science, computer science, electrical engineering and many others. Therefore, like previous ISMIR editions, ISMIR 2015 will provide a venue for the exchange of ideas, issues, results and perspectives among the different profiles of people working with music and computing in a broad sense. ISMIR 2015 will cover the entire area of MIR, providing ample room for diversity and new developments ISMIR 2015 will feature a great Scientific Program that includes: * Introductory and in-depth tutorials. http://ismir2015.uma.es/callfortutorials.html (Tutorial proposal deadline March 27, 2015) * Oral and poster presentation of research papers. http://ismir2015.uma.es/callforpapers.html (Paper submission deadline April 27, 2015) * Music program. http://ismir2015.uma.es/callformusic.html (Music submission deadline May 27, 2015) * Late-breaking news/demo session. http://ismir2015.uma.es/callforlatebreakingdemo.html (Late breaking and demos submission deadline October 26, 2015) * Keynote speakers. http://ismir2015.uma.es/keynotespeakers.html * Unconference session. http://ismir2015.uma.es/unconference.html Submissions for all categories are welcome. All research papers will go through a double-blind review and selection process with at least three reviewers per submission. The conference venue will be the hotel NH MALAGA located in the historical and business center of Malaga. http://ismir2015.uma.es/venue.html ISMIR 2015 will not only offer interesting papers, posters, tutorials, etc., it also aims at giving the participants an unforgettable stay. The social program will provide participants with an opportunity to relax after meetings, to experience Malaga, and to network with other ISMIR participants. http://ismir2015.uma.es/socialprogram.html Hope to see you all in Malaga! Isabel Barbancho ISMIR 2015 General Chair From F.Wiering at uu.nl Wed Mar 25 16:31:00 2015 From: F.Wiering at uu.nl (Frans Wiering) Date: Wed, 25 Mar 2015 16:31:00 +0100 Subject: [MEI-L] 2nd CFP ISMIR 2015 - 16th International Society for Music Information Retrieval Conference, 26-30 October 2015, Malaga, SPAIN In-Reply-To: <55128972.6010301@ic.uma.es> References: <55128972.6010301@ic.uma.es> Message-ID: <5512D4B4.80106@uu.nl> (Apologies for any cross-postings): Call for Participation ISMIR 2015 - 16th International Society for Music Information Retrieval Conference 26-30 October 2015, Malaga, SPAIN http://ismir2015.uma.es/ The 16th International Conference on Music Information Retrieval, ISMIR 2015, will be held in Malaga, SPAIN, from Monday, October 26 to Friday, October 30 2015. The annual Conference of the International Society for Music Information Retrieval (ISMIR) is the world's leading research forum on processing, analyzing, searching, organizing and accessing music-related data. Music becomes music after being processed by the human mind and each person perceives the music in a different and complex way. Therefore, this conference embraces the complexity and diversity of music by showcasing ideas and applications that aim to enhance the way in which we interact with music. MIR is a truly interdisciplinary area, involving researchers, developers, educators, librarians, students and professionals from the disciplines of musicology, cognitive science, library and information science, computer science, electrical engineering and many others. Therefore, like previous ISMIR editions, ISMIR 2015 will provide a venue for the exchange of ideas, issues, results and perspectives among the different profiles of people working with music and computing in a broad sense. ISMIR 2015 will cover the entire area of MIR, providing ample room for diversity and new developments ISMIR 2015 will feature a great Scientific Program that includes: * Introductory and in-depth tutorials. http://ismir2015.uma.es/callfortutorials.html (Tutorial proposal deadline March 27, 2015) * Oral and poster presentation of research papers. http://ismir2015.uma.es/callforpapers.html (Paper submission deadline April 27, 2015) * Music program. http://ismir2015.uma.es/callformusic.html (Music submission deadline May 27, 2015) * Late-breaking news/demo session. http://ismir2015.uma.es/callforlatebreakingdemo.html (Late breaking and demos submission deadline October 26, 2015) * Keynote speakers. http://ismir2015.uma.es/keynotespeakers.html * Unconference session. http://ismir2015.uma.es/unconference.html Submissions for all categories are welcome. All research papers will go through a double-blind review and selection process with at least three reviewers per submission. The conference venue will be the hotel NH MALAGA located in the historical and business center of Malaga. http://ismir2015.uma.es/venue.html ISMIR 2015 will not only offer interesting papers, posters, tutorials, etc., it also aims at giving the participants an unforgettable stay. The social program will provide participants with an opportunity to relax after meetings, to experience Malaga, and to network with other ISMIR participants. http://ismir2015.uma.es/socialprogram.html Hope to see you all in Malaga! Isabel Barbancho ISMIR 2015 General Chair From atge at kb.dk Wed Mar 25 17:29:38 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 25 Mar 2015 16:29:38 +0000 Subject: [MEI-L] within ? In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DDE67C@EXCHANGE-02.kb.dk> Hi Perry I largely agree with what you say. I have added my comments inline below. Any other opinions? Klaus, Kristina, ...? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 23. marts 2015 20:26 Til: Music Encoding Initiative Emne: Re: [MEI-L] within ? Hi Axel, I can certainly see the practicality in this change, but if I may play the devil's advocate for a moment -- According to basic FRBR tenets, doesn't a change in medium signal a different expression? If so, then allowing in and treating the differently-instrumented sources as a single expression seems to be a contradiction of basic FRBR. Yes, indeed. As I have argued elsewhere, however, in some situations there is apparently a need for either another level of grouping between FRBR's work and expression levels or a less restrictive definition of the expression level. The FRBR recommendation says that Inasmuch as the form of expression is an inherent characteristic of the expression, any change in form (e.g., from alpha-numeric notation to spoken word) results in a new expression. Similarly, changes in the intellectual conventions or instruments that are employed to express a work (e.g., translation from one language to another) result in the production of a new expression. If a text is revised or modified, the resulting expression is considered to be a new expression. Minor changes, such as corrections of spelling and punctuation, etc., may be considered as variations within the same expression. I am aware that grouping a piano reduction and a full score as belonging to the same expression clearly violates this recommendation. But my problem is that FRBR makes no distinction between changes in medium (instrumentation; or language, if dealing with texts) and content; both do result in a new expression. However, at least as seen from cataloging point of view, there is a need for a hierarchy placing changes in content closer to the work level than changes in medium. An example: A composer's revision of his work may leave us two versions, both of which may exist in full score as well as piano reductions. According to FRBR this would generate four expressions, and I see no way of grouping these into embodiments of the early version in one group as opposed to those of the revised version just by means of the FRBR relations I can define between them. Even if I could somehow describe this with relations, it would not offer me any obvious place to describe each of the two versions as a whole. The same problem would arise with, for instance, books in various versions, translated into a number of other languages: All versions in the original language and all translations of any of these versions would be expressions at exactly the same level, even if there is a fundamental difference between different versions of a work within the same medium and the translation of a version into a new medium. I tried to illustrate this in the paper that Kristina and I presented in Mainz two years ago. My approach is - as always, and you are probably right to criticize it - rather pragmatic. I want the encoding to be productive. And I believe that in this particular matter FRBR is not, because there is too little room for variation at expression level. So what I am after is a way to handle this without violating FRBR recommendations more than absolutely necessary. Following this "different medium=different expression" idea, the following markup seems appropriate. The versions for orchestra are grouped as embodiments of the same expression, while the piano reduction is treated as a separate expression due to its change of instrumentation -- Yes, this would be the "group by medium"-choice. Theoretically possible, but not very useful, as I see it: There is no place to describe the distinct versions. If, however, one believes that a change in *content* (but not enough to be considered a new work) signals a change of expression, then the following markup could be used. The (first) version of the full score and its piano reduction are grouped as belonging to the same expression and the other full score is a different expression (due perhaps to structural, not instrumentation changes). Yes, this is the other possibility: group by version. In both cases, the source and the expression markup remain essentially unchanged, only the relationships defined within are modified. An advantage here is that no data is actually moved. In other words, the performance medium information can always be found in the same place. In the 2nd case, however, I'm not sure how one would describe the performing forces without allowing either or to be repeatable. I don't believe that Violino 1 Violino 2 ... Pianoforte is the best way to go. I agree. I may not have been very clear about this: I certainly didn't mean to recommend this; it's what I tried to avoid. The intention of @source on is to allow one to say that there are 2 sources, one of which includes the piano in its orchestration, the other of which does not, which this appears to do. For the situation you're describing, I think it's much clearer to allow to be repeatable and to carry @source, resulting in Violino 1 Violino 2 ... Pianoforte Yes, this is much better. Actually I think that this is the best solution so far. It appears to be a more gentle way of widening the definition of "expression" than allowing in , and it also avoids the ambiguity of my last example in which some of the sources do indicate an instrumentation while others don't. Using Schematron, one could say that must either a) have content or b) use @source, but it should not allow both. Under these circumstances, I could see allowing within , but this means that could occur either within or within , which sometimes leads to criticism. You are right. Things are much harder to handle if the same information may appear in different places. Sorry for my usual long-winded explanation, but I think it's important to explain the derivation of the markup instead of offering up a solution that seems to materialize out of thin air. In any case, I recognize that this is a tough problem, so I look forward to the formation of the cataloging IG (although I'd recommend calling it the "metadata IG") and its recommendations. I see your point. "Metadata IG" is fine with me :-) But let's discuss that in Florence. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, March 13, 2015 7:47 AM To: Music Encoding Initiative Subject: Re: [MEI-L] within ? Hi Perry Sorry for the long response time, but I was hoping for others to step in first since we have had some discussion about this already. I am in favor of both changes. The latter - allowing in - would make it possible to avoid listing instruments at work or expression level which are not part of the general instrumentation of that expression, a piano for instance, if a piano reduction exists of an orchestral work. So instead of Violino 1 Violino 2 ... Pianoforte we could do: Pianoforte Violino 1 Violino 2 ... where the instrumentation in source1 could be either duplicated from or, if not indicated, understood as inherited from . The soon-to-be-established Cataloging Interest Group could discuss a recommended practice for this type of information. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. marts 2015 17:43 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] within ? There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there's a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I'm inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From zolaemil at gmail.com Thu Mar 26 11:23:10 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 26 Mar 2015 10:23:10 +0000 Subject: [MEI-L] cross-staff beams sample encoding Message-ID: Hello, Looking at the cross-staff beam sample encoding, a number of things occur to me: 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be e4, not e3). 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? ** ** ** Best Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Fri Mar 27 10:51:34 2015 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 27 Mar 2015 10:51:34 +0100 Subject: [MEI-L] Reminder: Early-bird Registration for MEC2015 Message-ID: <77832B9F-3E0C-469E-AC8A-B9DF6E9D2441@edirom.de> Dear all, this is friendly reminder that the early-bird rate for registering for the Music Encoding Conference on May 18-21 will run out by the end of the month. Registration will be possible for another month, but only at an increased rate. So if you really want to support MEI, you should delay your registration until Wednesday :-) Best, Johannes From donbyrd at indiana.edu Sat Mar 28 04:11:13 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sat, 28 Mar 2015 03:11:13 +0000 Subject: [MEI-L] [fill up time to complete layers in] cross-staff beams sample encoding In-Reply-To: References: Message-ID: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> I'm concerned about issue #3 below. In much idiomatic piano music from Chopin and Schumann on, if not earlier, I don't think it makes sense to try to complete voices by encoding anything to fill the space between notes (or explicit rests). Voices disappear and reappear anywhere, sometimes several times in one measure! We humans deduce the timing by finding notes in other voices the offending notes align with. That's just the "sameas" idea. There's a measure in a Chopin Ballade in which one voice disappears and reappears five times; see my Extremes of Conventional Music Notation (http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm). (Okay, it's just isolated second stems on notes, so arguably not a "real" voice, but that doesn't help!) Filling in that voice would make the encoding pretty messy, and I'd say would make it harder -- not easier -- to see what's really going on. Disclaimer: I realize my objection isn't applicable to a lot of music, but I can't find Zolt?n's example in http://music-encoding.org/documentation, either in Sample Encodings or via MEI Search, so I can't easily see if my objection applies to it. Where is "the cross-staff beam sample encoding?? --Don On Mar 26, 2015, at 6:23 AM, K?m?ves Zolt?n wrote: > Hello, > > Looking at the cross-staff beam sample encoding, a number of things occur to me: > > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. > > 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be e4, not e3). > > 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: > Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? > > > > num.visible="true" num.place="above"> > > > stem.pos="right" xml:id="m1e1" staff="2"/> > xml:id="m1e2"/> > > > bracket.visible="true" bracket.place="above"> > > xml:id="m1e3"/> > xml:id="m1e4"/> > > > > > > > xml:id="m1s1l2e1"/> > xml:id="m1s1l2e2"/> > stem.pos="right" xml:id="m1s1l2e3" staff="2"/> > > > > > > > > > stem.pos="left" stem.dir="down"/> > > stem.pos="left"/> > > > > > num.place="below" numbase="2"> > > xml:id="m1s2l2e1"/> > xml:id="m1s2l2e2"/> > xml:id="m1s2l2e3"/> > > > > > > > > Best > Zoltan > _______________________________________________ > 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 zolaemil at gmail.com Sat Mar 28 18:41:48 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Sat, 28 Mar 2015 17:41:48 +0000 Subject: [MEI-L] [fill up time to complete layers in] cross-staff beams sample encoding In-Reply-To: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> References: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> Message-ID: Sorry, I forgot to link the example: http://music-encoding.org/sampleCollection/encodings/beamSpans.pdf http://music-encoding.org/sampleCollection/encodings/beamSpans.xml Zoltan 2015-03-28 3:11 GMT+00:00 Byrd, Donald A. : > I'm concerned about issue #3 below. In much idiomatic piano music from > Chopin and Schumann on, if not earlier, I don't think it makes sense to try > to complete voices by encoding anything to fill the space between notes (or > explicit rests). Voices disappear and reappear anywhere, sometimes several > times in one measure! We humans deduce the timing by finding notes in other > voices the offending notes align with. That's just the "sameas" idea. > > There's a measure in a Chopin Ballade in which one voice disappears and > reappears five times; see my Extremes of Conventional Music Notation ( > http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm). (Okay, it's just > isolated second stems on notes, so arguably not a "real" voice, but that > doesn't help!) Filling in that voice would make the encoding pretty messy, > and I'd say would make it harder -- not easier -- to see what's really > going on. > > Disclaimer: I realize my objection isn't applicable to a lot of music, but > I can't find Zolt?n's example in http://music-encoding.org/documentation, > either in Sample Encodings or via MEI Search, so I can't easily see if my > objection applies to it. Where is "the cross-staff beam sample encoding?? > > --Don > > > On Mar 26, 2015, at 6:23 AM, K?m?ves Zolt?n wrote: > > > Hello, > > > > Looking at the cross-staff beam sample encoding, a number of things > occur to me: > > > > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this > more than a little confusing: the information that there is a triplet > containing one 16th-rest and two 16th-note seems to have been lost. > Additionally, the sum of the total duration in the layer adds up to more > than the measure duration defined by the time signature. > > > > 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be > e4, not e3). > > > > 3. The first note on staff 2/layer 1 is the dotted g, which is > rhythmically at the 2nd 16th triplet position. I understand that this can > be derived from the fact that this note is "sameas" the 2nd note of the > displaced triplet on the first staff, but it strikes me that this leaves > the layer "incomplete"; I would expect a to fill up the time before > the first note; I think the following encoding would clearer: > > Or do you think this is already too interpretative (interpreting the > dotted 8th note as part of a sixtuplet over the entire measure, that is)? > > > > > > > > bracket.place="above" num="3" > > num.visible="true" > num.place="above"> > > staff="2"/> > > > > dur="16" stem.dir="up" > > stem.pos="right" > xml:id="m1e1" staff="2"/> > > dur="16" stem.dir="up" staff="1" > > xml:id="m1e2"/> > > > > > > num.place="above" > > bracket.visible="true" > bracket.place="above"> > > > > dur="8" stem.dir="up" staff="1" > > xml:id="m1e3"/> > > dur="16" stem.dir="up" staff="1" > > xml:id="m1e4"/> > > > > > > > > > > > > > > stem.dir="down" > > xml:id="m1s1l2e1"/> > > stem.dir="down" > > xml:id="m1s1l2e2"/> > > stem.dir="up" > > stem.pos="right" > xml:id="m1s1l2e3" staff="2"/> > > > > > > > > > > > > dur.visible="false" num.visible="false" dur="2"> > > > > > > sameas="#m1e1" dur="8" > > stem.pos="left" > stem.dir="down"/> > > > > sameas="#m1s1l2e3" stem.dir="down" dur="16" > > stem.pos="left"/> > > > > > > > > > > bracket.visible="true" bracket.place="below" > > num.place="below" numbase="2"> > > > > dur="16" stem.dir="down" > > xml:id="m1s2l2e1"/> > > dur="16" stem.dir="down" > > xml:id="m1s2l2e2"/> > > dur="16" stem.dir="down" > > xml:id="m1s2l2e3"/> > > > > loc="0"/> > > > > > > > > > > > > Best > > Zoltan > > _______________________________________________ > > 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 donbyrd at indiana.edu Sun Mar 29 20:25:37 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sun, 29 Mar 2015 18:25:37 +0000 Subject: [MEI-L] [Sample collection(s); WAS fill up time to complete layers in] cross-staff beams sample encoding In-Reply-To: References: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> Message-ID: <06257494-ACDA-4E37-BD6F-110D3F7D6104@indiana.edu> No wonder I couldn't find it. This "sampleCollection" directory seems to have nothing to do with the "Sample Encodings" available under the Documentation tab, i.e., http://music-encoding.org/documentation/samples. And if there's a way to get to sampleCollection/encodings from music-encoding.org, it's not exactly obvious -- unless I'm overlooking the obvious :-) . Can someone clarify this, preferably including clarifying the website? --Don On Mar 28, 2015, at 1:41 PM, K?m?ves Zolt?n wrote: > Sorry, I forgot to link the example: > http://music-encoding.org/sampleCollection/encodings/beamSpans.pdf > http://music-encoding.org/sampleCollection/encodings/beamSpans.xml > > Zoltan > > > > 2015-03-28 3:11 GMT+00:00 Byrd, Donald A. : > I'm concerned about issue #3 below. In much idiomatic piano music from Chopin and Schumann on, if not earlier, I don't think it makes sense to try to complete voices by encoding anything to fill the space between notes (or explicit rests). Voices disappear and reappear anywhere, sometimes several times in one measure! We humans deduce the timing by finding notes in other voices the offending notes align with. That's just the "sameas" idea. > > There's a measure in a Chopin Ballade in which one voice disappears and reappears five times; see my Extremes of Conventional Music Notation (http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm). (Okay, it's just isolated second stems on notes, so arguably not a "real" voice, but that doesn't help!) Filling in that voice would make the encoding pretty messy, and I'd say would make it harder -- not easier -- to see what's really going on. > > Disclaimer: I realize my objection isn't applicable to a lot of music, but I can't find Zolt?n's example in http://music-encoding.org/documentation, either in Sample Encodings or via MEI Search, so I can't easily see if my objection applies to it. Where is "the cross-staff beam sample encoding?? > > --Don > > > On Mar 26, 2015, at 6:23 AM, K?m?ves Zolt?n wrote: > > > Hello, > > > > Looking at the cross-staff beam sample encoding, a number of things occur to me: > > > > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. > > > > 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be e4, not e3). > > > > 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: > > Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? > > > > > > > > > num.visible="true" num.place="above"> > > > > > > > stem.pos="right" xml:id="m1e1" staff="2"/> > > > xml:id="m1e2"/> > > > > > > > bracket.visible="true" bracket.place="above"> > > > > > xml:id="m1e3"/> > > > xml:id="m1e4"/> > > > > > > > > > > > > > > > xml:id="m1s1l2e1"/> > > > xml:id="m1s1l2e2"/> > > > stem.pos="right" xml:id="m1s1l2e3" staff="2"/> > > > > > > > > > > > > > > > > > > > stem.pos="left" stem.dir="down"/> > > > > > stem.pos="left"/> > > > > > > > > > > > num.place="below" numbase="2"> > > > > > xml:id="m1s2l2e1"/> > > > xml:id="m1s2l2e2"/> > > > xml:id="m1s2l2e3"/> > > > > > > > > > > > > > > > > Best > > Zoltan > > _______________________________________________ > > 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 zolaemil at gmail.com Sun Mar 29 20:55:50 2015 From: zolaemil at gmail.com (=?utf-8?Q?Zolt=C3=A1n_K=C5=91m=C3=ADves?=) Date: Sun, 29 Mar 2015 19:55:50 +0100 Subject: [MEI-L] [Sample collection(s); WAS fill up time to completelayers in] cross-staff beams sample encoding In-Reply-To: <06257494-ACDA-4E37-BD6F-110D3F7D6104@indiana.edu> References: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> <06257494-ACDA-4E37-BD6F-110D3F7D6104@indiana.edu> Message-ID: <55184ae3.6465b40a.3fc0.ffffc9c9@mx.google.com> It's imdeed not obvious, but I linked this from the documentation/Sample Encodings page http://music-encoding.org/documentation/samples It's the item called "Example of beamSpans" Z -----Original Message----- From: "Byrd, Donald A." Sent: ?29/?03/?2015 19:25 To: "Music Encoding Initiative" Subject: Re: [MEI-L] [Sample collection(s); WAS fill up time to completelayers in] cross-staff beams sample encoding No wonder I couldn't find it. This "sampleCollection" directory seems to have nothing to do with the "Sample Encodings" available under the Documentation tab, i.e., http://music-encoding.org/documentation/samples. And if there's a way to get to sampleCollection/encodings from music-encoding.org, it's not exactly obvious -- unless I'm overlooking the obvious :-) . Can someone clarify this, preferably including clarifying the website? --Don On Mar 28, 2015, at 1:41 PM, K?m?ves Zolt?n wrote: > Sorry, I forgot to link the example: > http://music-encoding.org/sampleCollection/encodings/beamSpans.pdf > http://music-encoding.org/sampleCollection/encodings/beamSpans.xml > > Zoltan > > > > 2015-03-28 3:11 GMT+00:00 Byrd, Donald A. : > I'm concerned about issue #3 below. In much idiomatic piano music from Chopin and Schumann on, if not earlier, I don't think it makes sense to try to complete voices by encoding anything to fill the space between notes (or explicit rests). Voices disappear and reappear anywhere, sometimes several times in one measure! We humans deduce the timing by finding notes in other voices the offending notes align with. That's just the "sameas" idea. > > There's a measure in a Chopin Ballade in which one voice disappears and reappears five times; see my Extremes of Conventional Music Notation (http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm). (Okay, it's just isolated second stems on notes, so arguably not a "real" voice, but that doesn't help!) Filling in that voice would make the encoding pretty messy, and I'd say would make it harder -- not easier -- to see what's really going on. > > Disclaimer: I realize my objection isn't applicable to a lot of music, but I can't find Zolt?n's example in http://music-encoding.org/documentation, either in Sample Encodings or via MEI Search, so I can't easily see if my objection applies to it. Where is "the cross-staff beam sample encoding?? > > --Don > > > On Mar 26, 2015, at 6:23 AM, K?m?ves Zolt?n wrote: > > > Hello, > > > > Looking at the cross-staff beam sample encoding, a number of things occur to me: > > > > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. > > > > 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be e4, not e3). > > > > 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: > > Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? > > > > > > > > > num.visible="true" num.place="above"> > > > > > > > stem.pos="right" xml:id="m1e1" staff="2"/> > > > xml:id="m1e2"/> > > > > > > > bracket.visible="true" bracket.place="above"> > > > > > xml:id="m1e3"/> > > > xml:id="m1e4"/> > > > > > > > > > > > > > > > xml:id="m1s1l2e1"/> > > > xml:id="m1s1l2e2"/> > > > stem.pos="right" xml:id="m1s1l2e3" staff="2"/> > > > > > > > > > > > > > > > > > > > stem.pos="left" stem.dir="down"/> > > > > > stem.pos="left"/> > > > > > > > > > > > num.place="below" numbase="2"> > > > > > xml:id="m1s2l2e1"/> > > > xml:id="m1s2l2e2"/> > > > xml:id="m1s2l2e3"/> > > > > > > > > > > > > > > > > Best > > Zoltan > > _______________________________________________ > > 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 craigsapp at gmail.com Mon Mar 30 02:53:45 2015 From: craigsapp at gmail.com (Craig Sapp) Date: Sun, 29 Mar 2015 17:53:45 -0700 Subject: [MEI-L] cross-staff beams sample encoding In-Reply-To: References: Message-ID: Hi Zolt?n, > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this > more than a little confusing: the information that there is a triplet > containing one 16th-rest and two 16th-note seems to have been lost. > Additionally, the sum of the total duration in the layer adds up to more > than the measure duration defined by the time signature. > I would say that the rest is supposed to be a triplet 16th note, so there is a data error. 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically > at the 2nd 16th triplet position. I understand that this can be derived > from the fact that this note is "sameas" the 2nd note of the displaced > triplet on the first staff, but it strikes me that this leaves the layer > "incomplete"; I would expect a to fill up the time before the first > note; I think the following encoding would clearer: > Or do you think this is already too interpretative (interpreting the > dotted 8th note as part of a sixtuplet over the entire measure, that is)? > I would expect that the second layer of the bottom staff to have a duration of one quarter note. I have typeset this prelude in SCORE, and I give all layers on both staves the complete duration of one quarter note per measure, filling in empty spot with an invisible triplet sixteenth-note rest (i.e., I do it as you expect). Likewise for the top layer of the top staff. I would disapprove of not using a space element before the G3. Each layer should sum up to the same duration, or at worst drop/add duration only at the end of the measure (although I would also disapprove of that). Here is the first system of the music, and the four encoding layers split out onto separate staves below it: ? (Cross-staff beaming in m5 & 6 for the top layer on the bottom staff). Full score: https://github.com/craigsapp/scorelib/blob/master/data/chopin-preludes/chopin2801.pdf -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-29 at 5.15.33 PM.png Type: image/png Size: 161613 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Mon Mar 30 15:24:46 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 30 Mar 2015 13:24:46 +0000 Subject: [MEI-L] cross-staff beams sample encoding In-Reply-To: References: Message-ID: Thanks, Zoltan for catching the error. I?ll see that it gets fixed as soon as possible. Craig?s approach is one I support. We?re working on a new version of the web site that I hope will provide more clarity. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp Sent: Sunday, March 29, 2015 8:54 PM To: Music Encoding Initiative Subject: Re: [MEI-L] cross-staff beams sample encoding Hi Zolt?n, 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. I would say that the rest is supposed to be a triplet 16th note, so there is a data error. 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? I would expect that the second layer of the bottom staff to have a duration of one quarter note. I have typeset this prelude in SCORE, and I give all layers on both staves the complete duration of one quarter note per measure, filling in empty spot with an invisible triplet sixteenth-note rest (i.e., I do it as you expect). Likewise for the top layer of the top staff. I would disapprove of not using a space element before the G3. Each layer should sum up to the same duration, or at worst drop/add duration only at the end of the measure (although I would also disapprove of that). Here is the first system of the music, and the four encoding layers split out onto separate staves below it: [cid:image001.png at 01D06ACB.5CD431E0] ? (Cross-staff beaming in m5 & 6 for the top layer on the bottom staff). Full score: https://github.com/craigsapp/scorelib/blob/master/data/chopin-preludes/chopin2801.pdf -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 161613 bytes Desc: image001.png URL: From bohl at edirom.de Wed Apr 8 11:32:14 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 08 Apr 2015 11:32:14 +0200 Subject: [MEI-L] validation of chords in bTrem Message-ID: <5524F59E.30103@edirom.de> Dear MEI-L:isteners, I encountered a validation error with chords in bTrem elements and @dur in the following code: The reported (schematron) error is: "@dur must only be specified on chords, not on the notes they contain." From my perspective the above code is perfectly valid, it does not validate the stated rule. But it occurs to me, that the rule just does not respect the above case. Am I mistaken? Welcoming your thoughts, Benjamin -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** From raffaeleviglianti at gmail.com Wed Apr 8 15:36:27 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 8 Apr 2015 09:36:27 -0400 Subject: [MEI-L] validation of chords in bTrem In-Reply-To: <5524F59E.30103@edirom.de> References: <5524F59E.30103@edirom.de> Message-ID: Hi Benni, I can't find that schematron assertion in the source ODD, are you sure it's not coming from a customization ODD? Raff On Wed, Apr 8, 2015 at 5:32 AM, Benjamin Wolff Bohl wrote: > Dear MEI-L:isteners, > > I encountered a validation error with chords in bTrem elements and @dur in > the following code: > > > > > > > > > The reported (schematron) error is: > "@dur must only be specified on chords, not on the notes they contain." > > From my perspective the above code is perfectly valid, it does not > validate the stated rule. But it occurs to me, that the rule just does not > respect the above case. > Am I mistaken? > > Welcoming your thoughts, > Benjamin > > > -- > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > Fax: +49 (0) 5231 / 975-668 > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > > _______________________________________________ > 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 Sat Apr 11 18:57:36 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Sat, 11 Apr 2015 18:57:36 +0200 Subject: [MEI-L] validation of chords in bTrem In-Reply-To: References: <5524F59E.30103@edirom.de> Message-ID: <55295280.5040709@edirom.de> Hi Raffaele, you're probably right... Sorry for bothering ;-) Benni *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 08.04.2015 um 15:36 schrieb Raffaele Viglianti: > Hi Benni, > > I can't find that schematron assertion in the source ODD, are you sure > it's not coming from a customization ODD? > > Raff > > On Wed, Apr 8, 2015 at 5:32 AM, Benjamin Wolff Bohl > wrote: > > Dear MEI-L:isteners, > > I encountered a validation error with chords in bTrem elements and > @dur in the following code: > > > > > > > > > The reported (schematron) error is: > "@dur must only be specified on chords, not on the notes they > contain." > > From my perspective the above code is perfectly valid, it does not > validate the stated rule. But it occurs to me, that the rule just > does not respect the above case. > Am I mistaken? > > Welcoming your thoughts, > Benjamin > > > -- > *********************************************************** > Musikwissenschaftliches Seminar Detmold/Paderborn > BMBF-Projekt "Freisch?tz Digital" > Benjamin Wolff Bohl > Gartenstra?e 20 > D?32756 Detmold > > Tel. +49 (0) 5231 / 975-669 > > Fax: +49 (0) 5231 / 975-668 > > E-Mail: bohl at edirom.de > > http://www.freischuetz-digital.de > *********************************************************** > > > _______________________________________________ > 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From klaus.rettinghaus at gmail.com Wed Apr 15 15:57:46 2015 From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus) Date: Wed, 15 Apr 2015 15:57:46 +0200 Subject: [MEI-L] within ? In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10118DDE67C@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DDE67C@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, I brooded over this for some time now, and I'm still unable to see the necessity for allowing in , neither for edition nor cataloging purposes. Whereas a repeated within an expression seems to make sense. In some cases a single source could carry different expressions of a work by means of instrumentation. Encoding this within may be a problem, using @source on in different would be clearer. Thinking about piano reductions could be quite puzzling. We should think this over in Florence as you suggested. Best, Klaus 2015-03-25 17:29 GMT+01:00 Axel Teich Geertinger : > Hi Perry > > > > I largely agree with what you say. I have added my comments inline below. > > Any other opinions? Klaus, Kristina, ...? > > > > Best, > > Axel > > > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *P? vegne af *Roland, > Perry D. (pdr4h) > *Sendt:* 23. marts 2015 20:26 > *Til:* Music Encoding Initiative > *Emne:* Re: [MEI-L] within ? > > > > > > Hi Axel, > > > > I can certainly see the practicality in this change, but if I may play the > devil?s advocate for a moment -- > > > > According to basic FRBR tenets, doesn?t a change in medium signal a > different expression? If so, then allowing in and > treating the differently-instrumented sources as a single expression seems > to be a contradiction of basic FRBR. > > > > Yes, indeed. As I have argued elsewhere, however, in some situations there > is apparently a need for either another level of grouping between FRBR?s > work and expression levels or a less restrictive definition of the > expression level. The FRBR recommendation says that > > > > Inasmuch as the form of *expression* is an inherent characteristic of the > *expression*, any change in form (e.g., from alpha-numeric notation to > spoken word) results in a new *expression*. Similarly, changes in the > intellectual conventions or instruments that are employed to express a > *work* (e.g., translation from one language to another) result in the > production of a new *expression*. If a text is revised or modified, the > resulting *expression* is considered to be a new *expression*. Minor > changes, such as corrections of spelling and punctuation, etc., may be > considered as variations within the same *expression*. > > > > I am aware that grouping a piano reduction and a full score as belonging > to the same expression clearly violates this recommendation. But my problem > is that FRBR makes no distinction between changes in medium > (instrumentation; or language, if dealing with texts) and content; both do > result in a new expression. However, at least as seen from cataloging point > of view, there is a need for a hierarchy placing changes in content closer > to the work level than changes in medium. > > An example: A composer?s revision of his work may leave us two versions, > both of which may exist in full score as well as piano reductions. > According to FRBR this would generate four expressions, and I see no way of > grouping these into embodiments of the early version in one group as > opposed to those of the revised version just by means of the FRBR relations > I can define between them. Even if I could somehow describe this with > relations, it would not offer me any obvious place to describe each of the > two versions as a whole. The same problem would arise with, for instance, > books in various versions, translated into a number of other languages: All > versions in the original language and all translations of any of these > versions would be expressions at exactly the same level, even if there is a > fundamental difference between different versions of a work within the same > medium and the translation of a version into a new medium. I tried to > illustrate this in the paper that Kristina and I presented in Mainz two > years ago. > > My approach is ? as always, and you are probably right to criticize it ? > rather pragmatic. I want the encoding to be productive. And I believe that > in this particular matter FRBR is not, because there is too little room for > variation at expression level. So what I am after is a way to handle this > without violating FRBR recommendations more than absolutely necessary. > > > > Following this ?different medium=different expression? idea, the following > markup seems appropriate. The versions for orchestra are grouped as > embodiments of the same expression, while the piano reduction is treated as > a separate expression due to its change of instrumentation -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, this would be the ?group by medium?-choice. Theoretically possible, > but not very useful, as I see it: There is no place to describe the > distinct versions. > > > > If, however, one believes that a change in *content* (but not enough to be > considered a new work) signals a change of expression, then the following > markup could be used. The (first) version of the full score and its piano > reduction are grouped as belonging to the same expression and the other > full score is a different expression (due perhaps to structural, not > instrumentation changes). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, this is the other possibility: group by version. > > > > In both cases, the source and the expression markup remain essentially > unchanged, only the relationships defined within are > modified. An advantage here is that no data is actually moved. In other > words, the performance medium information can always be found in the same > place. In the 2nd case, however, I?m not sure how one would describe the > performing forces without allowing either or > to be repeatable. I don?t believe that > > > > > > > > > > Violino 1 > > Violino 2 > > ... > > Pianoforte > > > > > > > > > > is the best way to go. > > > > I agree. I may not have been very clear about this: I certainly didn?t > mean to recommend this; it?s what I tried to avoid. > > > > The intention of @source on is to allow one to say that there > are 2 sources, one of which includes the piano in its orchestration, the > other of which does not, which this appears to do. For the situation you?re > describing, I think it?s much clearer to allow to be > repeatable and to carry @source, resulting in > > > > > > > > > > Violino 1 > > Violino 2 > > ... > > > > > > Pianoforte > > > > > > > > > > Yes, this is much better. Actually I think that this is the best solution > so far. It appears to be a more gentle way of widening the definition of > ?expression? than allowing in , and it also avoids the > ambiguity of my last example in which some of the sources do indicate an > instrumentation while others don?t. > > > > Using Schematron, one could say that must either a) have > content or b) use @source, but it should not allow both. Under these > circumstances, I could see allowing within , but this > means that could occur either within or within > , which sometimes leads to criticism. > > > > You are right. Things are much harder to handle if the same information > may appear in different places. > > > > Sorry for my usual long-winded explanation, but I think it?s important to > explain the derivation of the markup instead of offering up a solution that > seems to materialize out of thin air. > > > > In any case, I recognize that this is a tough problem, so I look forward > to the formation of the cataloging IG (although I?d recommend calling it > the ?metadata IG?) and its recommendations. > > > > I see your point. ?Metadata IG? is fine with me :-) But let?s discuss that > in Florence. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *On Behalf Of *Axel Teich > Geertinger > *Sent:* Friday, March 13, 2015 7:47 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] within ? > > > > Hi Perry > > > > Sorry for the long response time, but I was hoping for others to step in > first since we have had some discussion about this already. I am in favor > of both changes. The latter ? allowing in ? would > make it possible to avoid listing instruments at work or expression level > which are not part of the general instrumentation of that expression, a > piano for instance, if a piano reduction exists of an orchestral work. So > instead of > > > > > > > > > > > > > > > > > > > > > > > > > > Violino 1 > > Violino 2 > > ... > > Pianoforte > > > > > > > > > > we could do: > > > > > > > > > > > > > > > > > > > > Pianoforte > > > > > > > > > > > > > > > > Violino 1 > > Violino 2 > > ... > > > > > > > > > > where the instrumentation in source1 could be either duplicated from > or, if not indicated, understood as inherited from > . The soon-to-be-established Cataloging Interest Group could > discuss a recommended practice for this type of information. > > > > Best, > > Axel > > > > > > *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > ] *P? vegne af *Roland, Perry D. > (pdr4h) > *Sendt:* 2. marts 2015 17:43 > *Til:* mei-l at lists.uni-paderborn.de > *Emne:* [MEI-L] within ? > > > > > > There has recently been some discussion on mei-devel about the markup of > instrumentation/performance medium information. To deal with missing, > incomplete, or contradictory info about instrumentation at the work level > (the only place this info is currently permitted), the current proposal is > to make and its sub-elements (instrVoice, instrVoiceGrp > and ensemble) members of att.edit. This will provide @cert, @evidence, > @resp, and @source. > > > > The second part of the effort, which may be slightly more controversial, > centers on allowing to occur not just within , but also > at the manifestation level; that is, within . Currently, > is allowed within , but not in an effort > to encourage the use of FRBR entities and to make a clear separation > between expression and manifestation data. But, a compelling case can be > made that if were allowed within , then > could take on more of a grouping role in those cases where there are > multiple manifestations of what is essentially the same expression, for > instance, when there?s a short score/sketch, a piano reduction (intended > for rehearsal) and a full score of a symphonic work. It may be more > productive to allow each of these sources to carry instrumentation info and > use to group them as one *version of the work* as opposed to a > later revision than to force instrumentation to always be recorded at the > expression level, resulting in many cases in a one-to-one relationship > between and without the possibility of grouping at a > higher level. > > > > I?m inclined to make this latter change, but would like to hear from > others before moving ahead. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From atge at kb.dk Wed Apr 15 17:41:52 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 15 Apr 2015 15:41:52 +0000 Subject: [MEI-L] within ? In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D10118DDB79A@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D10118DDE67C@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10118DF5A6D@EXCHANGE-02.kb.dk> Hi Klaus It seems we all agree, then, that in may not be a good idea, but multiple in would be useful. This also leaves room for more or less restrictive use of . In some situations or projects multiple may be the best way to go, in others multiple instrumentations within a single expression may be better. I?d be perfectly happy with that solution :-) Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Klaus Rettinghaus Sendt: 15. april 2015 15:58 Til: Music Encoding Initiative Emne: Re: [MEI-L] within ? Hi Axel, I brooded over this for some time now, and I'm still unable to see the necessity for allowing in , neither for edition nor cataloging purposes. Whereas a repeated within an expression seems to make sense. In some cases a single source could carry different expressions of a work by means of instrumentation. Encoding this within may be a problem, using @source on in different would be clearer. Thinking about piano reductions could be quite puzzling. We should think this over in Florence as you suggested. Best, Klaus 2015-03-25 17:29 GMT+01:00 Axel Teich Geertinger >: Hi Perry I largely agree with what you say. I have added my comments inline below. Any other opinions? Klaus, Kristina, ...? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 23. marts 2015 20:26 Til: Music Encoding Initiative Emne: Re: [MEI-L] within ? Hi Axel, I can certainly see the practicality in this change, but if I may play the devil?s advocate for a moment -- According to basic FRBR tenets, doesn?t a change in medium signal a different expression? If so, then allowing in and treating the differently-instrumented sources as a single expression seems to be a contradiction of basic FRBR. Yes, indeed. As I have argued elsewhere, however, in some situations there is apparently a need for either another level of grouping between FRBR?s work and expression levels or a less restrictive definition of the expression level. The FRBR recommendation says that Inasmuch as the form of expression is an inherent characteristic of the expression, any change in form (e.g., from alpha-numeric notation to spoken word) results in a new expression. Similarly, changes in the intellectual conventions or instruments that are employed to express a work (e.g., translation from one language to another) result in the production of a new expression. If a text is revised or modified, the resulting expression is considered to be a new expression. Minor changes, such as corrections of spelling and punctuation, etc., may be considered as variations within the same expression. I am aware that grouping a piano reduction and a full score as belonging to the same expression clearly violates this recommendation. But my problem is that FRBR makes no distinction between changes in medium (instrumentation; or language, if dealing with texts) and content; both do result in a new expression. However, at least as seen from cataloging point of view, there is a need for a hierarchy placing changes in content closer to the work level than changes in medium. An example: A composer?s revision of his work may leave us two versions, both of which may exist in full score as well as piano reductions. According to FRBR this would generate four expressions, and I see no way of grouping these into embodiments of the early version in one group as opposed to those of the revised version just by means of the FRBR relations I can define between them. Even if I could somehow describe this with relations, it would not offer me any obvious place to describe each of the two versions as a whole. The same problem would arise with, for instance, books in various versions, translated into a number of other languages: All versions in the original language and all translations of any of these versions would be expressions at exactly the same level, even if there is a fundamental difference between different versions of a work within the same medium and the translation of a version into a new medium. I tried to illustrate this in the paper that Kristina and I presented in Mainz two years ago. My approach is ? as always, and you are probably right to criticize it ? rather pragmatic. I want the encoding to be productive. And I believe that in this particular matter FRBR is not, because there is too little room for variation at expression level. So what I am after is a way to handle this without violating FRBR recommendations more than absolutely necessary. Following this ?different medium=different expression? idea, the following markup seems appropriate. The versions for orchestra are grouped as embodiments of the same expression, while the piano reduction is treated as a separate expression due to its change of instrumentation -- Yes, this would be the ?group by medium?-choice. Theoretically possible, but not very useful, as I see it: There is no place to describe the distinct versions. If, however, one believes that a change in *content* (but not enough to be considered a new work) signals a change of expression, then the following markup could be used. The (first) version of the full score and its piano reduction are grouped as belonging to the same expression and the other full score is a different expression (due perhaps to structural, not instrumentation changes). Yes, this is the other possibility: group by version. In both cases, the source and the expression markup remain essentially unchanged, only the relationships defined within are modified. An advantage here is that no data is actually moved. In other words, the performance medium information can always be found in the same place. In the 2nd case, however, I?m not sure how one would describe the performing forces without allowing either or to be repeatable. I don?t believe that Violino 1 Violino 2 ... Pianoforte is the best way to go. I agree. I may not have been very clear about this: I certainly didn?t mean to recommend this; it?s what I tried to avoid. The intention of @source on is to allow one to say that there are 2 sources, one of which includes the piano in its orchestration, the other of which does not, which this appears to do. For the situation you?re describing, I think it?s much clearer to allow to be repeatable and to carry @source, resulting in Violino 1 Violino 2 ... Pianoforte Yes, this is much better. Actually I think that this is the best solution so far. It appears to be a more gentle way of widening the definition of ?expression? than allowing in , and it also avoids the ambiguity of my last example in which some of the sources do indicate an instrumentation while others don?t. Using Schematron, one could say that must either a) have content or b) use @source, but it should not allow both. Under these circumstances, I could see allowing within , but this means that could occur either within or within , which sometimes leads to criticism. You are right. Things are much harder to handle if the same information may appear in different places. Sorry for my usual long-winded explanation, but I think it?s important to explain the derivation of the markup instead of offering up a solution that seems to materialize out of thin air. In any case, I recognize that this is a tough problem, so I look forward to the formation of the cataloging IG (although I?d recommend calling it the ?metadata IG?) and its recommendations. I see your point. ?Metadata IG? is fine with me :-) But let?s discuss that in Florence. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, March 13, 2015 7:47 AM To: Music Encoding Initiative Subject: Re: [MEI-L] within ? Hi Perry Sorry for the long response time, but I was hoping for others to step in first since we have had some discussion about this already. I am in favor of both changes. The latter ? allowing in ? would make it possible to avoid listing instruments at work or expression level which are not part of the general instrumentation of that expression, a piano for instance, if a piano reduction exists of an orchestral work. So instead of Violino 1 Violino 2 ... Pianoforte we could do: Pianoforte Violino 1 Violino 2 ... where the instrumentation in source1 could be either duplicated from or, if not indicated, understood as inherited from . The soon-to-be-established Cataloging Interest Group could discuss a recommended practice for this type of information. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Roland, Perry D. (pdr4h) Sendt: 2. marts 2015 17:43 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] within ? There has recently been some discussion on mei-devel about the markup of instrumentation/performance medium information. To deal with missing, incomplete, or contradictory info about instrumentation at the work level (the only place this info is currently permitted), the current proposal is to make and its sub-elements (instrVoice, instrVoiceGrp and ensemble) members of att.edit. This will provide @cert, @evidence, @resp, and @source. The second part of the effort, which may be slightly more controversial, centers on allowing to occur not just within , but also at the manifestation level; that is, within . Currently, is allowed within , but not in an effort to encourage the use of FRBR entities and to make a clear separation between expression and manifestation data. But, a compelling case can be made that if were allowed within , then could take on more of a grouping role in those cases where there are multiple manifestations of what is essentially the same expression, for instance, when there?s a short score/sketch, a piano reduction (intended for rehearsal) and a full score of a symphonic work. It may be more productive to allow each of these sources to carry instrumentation info and use to group them as one *version of the work* as opposed to a later revision than to force instrumentation to always be recorded at the expression level, resulting in many cases in a one-to-one relationship between and without the possibility of grouping at a higher level. I?m inclined to make this latter change, but would like to hear from others before moving ahead. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu _______________________________________________ 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 Apr 16 00:20:57 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 15 Apr 2015 22:20:57 +0000 Subject: [MEI-L] [Sample collection(s); WAS fill up time to completelayers in] cross-staff beams sample encoding In-Reply-To: <55184ae3.6465b40a.3fc0.ffffc9c9@mx.google.com> References: <9B960D18-C757-44B2-ADD3-8743AA01A208@indiana.edu> <06257494-ACDA-4E37-BD6F-110D3F7D6104@indiana.edu> <55184ae3.6465b40a.3fc0.ffffc9c9@mx.google.com> Message-ID: Hi everyone, After a couple of tries, I believe I fixed this example. Since the current website will go away soon, I changed the file in the *Google Code repository*, not on the website where you?ve been looking at it. The file is accessible directly at https://code.google.com/p/music-encoding/source/browse/trunk/samples/MEI2013/Musical%20features/beamSpans.mei. As you can imagine, this is a very difficult example to code by hand, so if I didn?t catch all the errors or introduced new ones, please let me know. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Zolt?n Kom?ves Sent: Sunday, March 29, 2015 2:56 PM To: Music Encoding Initiative Subject: Re: [MEI-L] [Sample collection(s); WAS fill up time to completelayers in] cross-staff beams sample encoding It's imdeed not obvious, but I linked this from the documentation/Sample Encodings page http://music-encoding.org/documentation/samples It's the item called "Example of beamSpans" Z ________________________________ From: Byrd, Donald A. Sent: ?29/?03/?2015 19:25 To: Music Encoding Initiative Subject: Re: [MEI-L] [Sample collection(s); WAS fill up time to completelayers in] cross-staff beams sample encoding No wonder I couldn't find it. This "sampleCollection" directory seems to have nothing to do with the "Sample Encodings" available under the Documentation tab, i.e., http://music-encoding.org/documentation/samples. And if there's a way to get to sampleCollection/encodings from music-encoding.org, it's not exactly obvious -- unless I'm overlooking the obvious :-) . Can someone clarify this, preferably including clarifying the website? --Don On Mar 28, 2015, at 1:41 PM, K?m?ves Zolt?n > wrote: > Sorry, I forgot to link the example: > http://music-encoding.org/sampleCollection/encodings/beamSpans.pdf > http://music-encoding.org/sampleCollection/encodings/beamSpans.xml > > Zoltan > > > > 2015-03-28 3:11 GMT+00:00 Byrd, Donald A. >: > I'm concerned about issue #3 below. In much idiomatic piano music from Chopin and Schumann on, if not earlier, I don't think it makes sense to try to complete voices by encoding anything to fill the space between notes (or explicit rests). Voices disappear and reappear anywhere, sometimes several times in one measure! We humans deduce the timing by finding notes in other voices the offending notes align with. That's just the "sameas" idea. > > There's a measure in a Chopin Ballade in which one voice disappears and reappears five times; see my Extremes of Conventional Music Notation (http://homes.soic.indiana.edu/donbyrd/CMNExtremes.htm). (Okay, it's just isolated second stems on notes, so arguably not a "real" voice, but that doesn't help!) Filling in that voice would make the encoding pretty messy, and I'd say would make it harder -- not easier -- to see what's really going on. > > Disclaimer: I realize my objection isn't applicable to a lot of music, but I can't find Zolt?n's example in http://music-encoding.org/documentation, either in Sample Encodings or via MEI Search, so I can't easily see if my objection applies to it. Where is "the cross-staff beam sample encoding?? > > --Don > > > On Mar 26, 2015, at 6:23 AM, K?m?ves Zolt?n > wrote: > > > Hello, > > > > Looking at the cross-staff beam sample encoding, a number of things occur to me: > > > > 1. note with xml:id="m1e1" encoded a dotted 8th note, but I found this more than a little confusing: the information that there is a triplet containing one 16th-rest and two 16th-note seems to have been lost. Additionally, the sum of the total duration in the layer adds up to more than the measure duration defined by the time signature. > > > > 2. note with xml:id="m1s1l2e1" encoded in the wrong octave (it should be e4, not e3). > > > > 3. The first note on staff 2/layer 1 is the dotted g, which is rhythmically at the 2nd 16th triplet position. I understand that this can be derived from the fact that this note is "sameas" the 2nd note of the displaced triplet on the first staff, but it strikes me that this leaves the layer "incomplete"; I would expect a to fill up the time before the first note; I think the following encoding would clearer: > > Or do you think this is already too interpretative (interpreting the dotted 8th note as part of a sixtuplet over the entire measure, that is)? > > > > > > > > > num.visible="true" num.place="above"> > > > > > > > stem.pos="right" xml:id="m1e1" staff="2"/> > > > xml:id="m1e2"/> > > > > > > > bracket.visible="true" bracket.place="above"> > > > > > xml:id="m1e3"/> > > > xml:id="m1e4"/> > > > > > > > > > > > > > > > xml:id="m1s1l2e1"/> > > > xml:id="m1s1l2e2"/> > > > stem.pos="right" xml:id="m1s1l2e3" staff="2"/> > > > > > > > > > > > > > > > > > > > stem.pos="left" stem.dir="down"/> > > > > > stem.pos="left"/> > > > > > > > > > > > num.place="below" numbase="2"> > > > > > xml:id="m1s2l2e1"/> > > > xml:id="m1s2l2e2"/> > > > xml:id="m1s2l2e3"/> > > > > > > > > > > > > > > > > Best > > Zoltan > > _______________________________________________ > > 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 vhennen at umail.iu.edu Fri Apr 17 06:56:33 2015 From: vhennen at umail.iu.edu (Vaughan Hennen) Date: Fri, 17 Apr 2015 00:56:33 -0400 Subject: [MEI-L] MEI and Libraries Message-ID: Hello all, This is my first time posting on the list-serv. My name is Vaughan Hennen - I am pursuing a dual masters degree in Library Science and Information Science from Indiana University Bloomington. My bachelors degree is from the University of North Texas in cello performance. The project that I am presenting, is about MEI and its application in today's music libraries. I have done reading on what MEI is and how it is applicable in music libraries, but I am still not clear on its use in music libraries. Would any of you offer some insight about how music libraries use MEI metadata or how the extensible language adds to the library? Thank you for your help. Sincerely, -Vaughan Hennen -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Fri Apr 17 20:08:09 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 17 Apr 2015 18:08:09 +0000 Subject: [MEI-L] MEI and Libraries In-Reply-To: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> References: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> Message-ID: <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> Hi Vaughan, There is a significant amount of information in the MEI guidelines about how FRBR is implemented in MEI: http://music-encoding.org/documentation/guidelines2013/FRBR The online catalogue of Carl Nielsen?s works is a great example of how libraries can use MEI to present extensive musical metadata online using MEI. See: http://www.kb.dk/dcm/cnw/navigation.xq http://www.kb.dk/dcm/cnw/download_xml.xq?doc=cnw0001.xml -Andrew On Apr 17, 2015, at 12:56 AM, Vaughan Hennen > wrote: Hello all, This is my first time posting on the list-serv. My name is Vaughan Hennen - I am pursuing a dual masters degree in Library Science and Information Science from Indiana University Bloomington. My bachelors degree is from the University of North Texas in cello performance. The project that I am presenting, is about MEI and its application in today's music libraries. I have done reading on what MEI is and how it is applicable in music libraries, but I am still not clear on its use in music libraries. Would any of you offer some insight about how music libraries use MEI metadata or how the extensible language adds to the library? Thank you for your help. Sincerely, -Vaughan Hennen _______________________________________________ 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 kristina.richts at gmx.de Sun Apr 19 10:45:37 2015 From: kristina.richts at gmx.de (Kristina Richts) Date: Sun, 19 Apr 2015 10:45:37 +0200 Subject: [MEI-L] MEI and Libraries In-Reply-To: <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> References: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> Message-ID: <74FBC647-CF5A-46C4-899B-DA87EBD1F1B1@gmx.de> Hi Vaughan, Welcome on MEI-L! MEI indeed offers promising opportunities for cataloging issues and the use in music libraries. It provides wide-ranging possibilities to encode high quality metadata in a very detailed and extensive way. But the development of using MEI in the daily work of music libraries is more or less just starting from scratch - this is why you could not find very much documentation about it (yet). The implementation of the FRBR model in 2013 was one of the first attemps to adapt MEI to the requirements of not only music libraries but also cataloguing projects. Along with the MEI Guidelines you could also have a look at the Header section of the MEI 1st Tutorials: http://music-encoding.org/support/MEI1st/exploring_the_header There are brief descriptions of the main header elements and an example of cataloging with MEI as well as a cheat sheet which represents the structure of an MEI header. Along with the mentioned catalogue of Carl Nielsen?s works, you might have a look at the metadata editor MerMEId, which was developed at the Royal Library of Copenhagen by Axel Teich Geertinger: http://www.kb.dk/en/nb/dcm/projekter/mermeid.html The Nielsen catalogue was created using this tool and is a great first example of displaying MEI metadata. Besides the Nielsen edition a lot of other editorial or cataloguing projects started to adopt MEI for cataloguing purposes, i.e. RISM or Bach Digital, to name a few. Another cooperation project with a library (the Regional Library in Detmold) is the Detmold Court Theatre Project, in which I am working. We aim at developing an MEI and TEI based model for contextual indexing of musical holdings. It is intended to use MEI for a contextual indexing of sheet music for the first time there and to demonstrate the potential of MEI as a cataloging format, including encodings of incipits and detailed descriptions of the material components. In response to the increased interest in using MEI as a cataloguing format, we are currently preparing the establishing of a cataloging interest group (including a mailing list for this topic), which will have its first meeting at this year?s Music Encoding Conference being held in Florence from 18th to 21st May. We will be glad if you decide to participate: http://music-encoding.org/conference I hope this will help you. Please let us know if you have any further questions or if you need some more material for your presentation. Best, Kristina Am 17.04.2015 um 20:08 schrieb Andrew Hankinson : > Hi Vaughan, > > There is a significant amount of information in the MEI guidelines about how FRBR is implemented in MEI: > > http://music-encoding.org/documentation/guidelines2013/FRBR > > The online catalogue of Carl Nielsen?s works is a great example of how libraries can use MEI to present extensive musical metadata online using MEI. > > See: > > http://www.kb.dk/dcm/cnw/navigation.xq > http://www.kb.dk/dcm/cnw/download_xml.xq?doc=cnw0001.xml > > -Andrew > >> On Apr 17, 2015, at 12:56 AM, Vaughan Hennen wrote: >> >> Hello all, >> >> This is my first time posting on the list-serv. >> >> My name is Vaughan Hennen - I am pursuing a dual masters degree in Library Science and Information Science from Indiana University Bloomington. My bachelors degree is from the University of North Texas in cello performance. >> >> The project that I am presenting, is about MEI and its application in today's music libraries. >> >> I have done reading on what MEI is and how it is applicable in music libraries, but I am still not clear on its use in music libraries. >> >> Would any of you offer some insight about how music libraries use MEI metadata or how the extensible language adds to the library? >> >> Thank you for your help. >> >> Sincerely, >> >> -Vaughan Hennen >> >> >> _______________________________________________ >> 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 -- Kristina Richts, M.A., MA LIS Wissenschaftliche Mitarbeiterin DFG-Projekt ?Entwicklung eines MEI- und TEI-basierten Modells kontextueller Tiefenerschlie?ung von Musikalienbest?nden am Beispiel des Detmolder Hoftheaters im 19. Jahrhundert (1825-1875)? Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D-32756 Detmold Tel.: +49 5231 975 665 E-Mail: kristina.richts at uni-paderborn.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From vhennen at umail.iu.edu Sun Apr 19 20:41:00 2015 From: vhennen at umail.iu.edu (Vaughan Hennen) Date: Sun, 19 Apr 2015 14:41:00 -0400 Subject: [MEI-L] MEI and Libraries In-Reply-To: <74FBC647-CF5A-46C4-899B-DA87EBD1F1B1@gmx.de> References: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> <74FBC647-CF5A-46C4-899B-DA87EBD1F1B1@gmx.de> Message-ID: Ms. Richts, Thank you very much for this information. I will contact you if I have any other questions. Sincerely, Vaughan Hennen On Sun, Apr 19, 2015 at 4:45 AM, Kristina Richts wrote: > Hi Vaughan, > > Welcome on MEI-L! > > MEI indeed offers promising opportunities for cataloging issues and the > use in music libraries. It provides wide-ranging possibilities to encode > high quality metadata in a very detailed and extensive way. But the > development of using MEI in the daily work of music libraries is more or > less just starting from scratch - this is why you could not find very much > documentation about it (yet). > > The implementation of the FRBR model in 2013 was one of the first attemps > to adapt MEI to the requirements of not only music libraries but also > cataloguing projects. Along with the MEI Guidelines you could also have a > look at the Header section of the MEI 1st Tutorials: > http://music-encoding.org/support/MEI1st/exploring_the_header > There are brief descriptions of the main header elements and an example of > cataloging with MEI as well as a cheat sheet which represents the structure > of an MEI header. > > Along with the mentioned catalogue of Carl Nielsen?s works, you might have > a look at the metadata editor MerMEId, which was developed at the Royal > Library of Copenhagen by Axel Teich Geertinger: > http://www.kb.dk/en/nb/dcm/projekter/mermeid.html > The Nielsen catalogue was created using this tool and is a great first > example of displaying MEI metadata. Besides the Nielsen edition a lot of > other editorial or cataloguing projects started to adopt MEI for > cataloguing purposes, i.e. RISM or Bach Digital, to name a few. > > Another cooperation project with a library (the Regional Library in > Detmold) is the Detmold Court Theatre Project, in which I am working. We > aim at developing an MEI and TEI based model for contextual indexing of > musical holdings. It is intended to use MEI for a contextual indexing of > sheet music for the first time there and to demonstrate the potential of > MEI as a cataloging format, including encodings of incipits and detailed > descriptions of the material components. > > In response to the increased interest in using MEI as a cataloguing > format, we are currently preparing the establishing of a cataloging > interest group (including a mailing list for this topic), which will have > its first meeting at this year?s Music Encoding Conference being held in > Florence from 18th to 21st May. We will be glad if you decide to > participate: http://music-encoding.org/conference > > I hope this will help you. Please let us know if you have any further > questions or if you need some more material for your presentation. > > Best, > Kristina > > > Am 17.04.2015 um 20:08 schrieb Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca>: > > Hi Vaughan, > > There is a significant amount of information in the MEI guidelines about > how FRBR is implemented in MEI: > > http://music-encoding.org/documentation/guidelines2013/FRBR > > The online catalogue of Carl Nielsen?s works is a great example of how > libraries can use MEI to present extensive musical metadata online using > MEI. > > See: > > http://www.kb.dk/dcm/cnw/navigation.xq > http://www.kb.dk/dcm/cnw/download_xml.xq?doc=cnw0001.xml > > -Andrew > > On Apr 17, 2015, at 12:56 AM, Vaughan Hennen > wrote: > > Hello all, > > This is my first time posting on the list-serv. > > My name is Vaughan Hennen - I am pursuing a dual masters degree in > Library Science and Information Science from Indiana University > Bloomington. My bachelors degree is from the University of North Texas in > cello performance. > > The project that I am presenting, is about MEI and its application in > today's music libraries. > > I have done reading on what MEI is and how it is applicable in music > libraries, but I am still not clear on its use in music libraries. > > Would any of you offer some insight about how music libraries use MEI > metadata or how the extensible language adds to the library? > > Thank you for your help. > > Sincerely, > > -Vaughan Hennen > > > _______________________________________________ > 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 > > > -- > Kristina Richts, M.A., MA LIS > > Wissenschaftliche Mitarbeiterin > DFG-Projekt ?Entwicklung eines MEI- und TEI-basierten Modells > kontextueller Tiefenerschlie?ung > von Musikalienbest?nden am Beispiel des Detmolder Hoftheaters im 19. > Jahrhundert (1825-1875)? > > Musikwissenschaftliches Seminar Detmold/Paderborn > Gartenstra?e 20 > D-32756 Detmold > > Tel.: +49 5231 975 665 > E-Mail: kristina.richts at uni-paderborn.de > > _______________________________________________ > 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 richard at rjlewis.me.uk Mon Apr 20 15:05:56 2015 From: richard at rjlewis.me.uk (Richard Lewis) Date: Mon, 20 Apr 2015 14:05:56 +0100 Subject: [MEI-L] CfP: Extended deadline: 2nd Intl. Digital Libraries for Musicology workshop (DLfM 2015), Knoxville, TN, June 2015 Message-ID: <87383vt0ej.wl%richard@rjlewis.me.uk> 3rd Call for Papers 2nd International Digital Libraries for Musicology workshop (DLfM 2015) 25th June 2015 (full day), Knoxville, TN, USA co-hosted with the ACM/IEEE Joint Conference on Digital Libraries 2015 Workshop website http://www.transforming-musicology.org/dlfm2015/ NEWS Deadline for final papers extended to Sunday 26th April; however draft papers (at least title, authors, and abstract) must be submitted to EasyChair by Wednesday 22nd April. BACKGROUND Many Digital Libraries have long offered facilities to provide multimedia content, including music. However there is now an ever more urgent need to specifically support the distinct multiple forms of music, the links between them, and the surrounding scholarly context, as required by the transformed and extended methods being applied to musicology and the wider Digital Humanities. The Digital Libraries for Musicology (DLfM) workshop presents a venue specifically for those working on, and with, Digital Library systems and content in the domain of music and musicology. This includes Music Digital Library systems, their application and use in musicology, technologies for enhanced access and organisation of musics in Digital Libraries, bibliographic and metadata for music, intersections with music Linked Data, and the challenges of working with the multiple representations of music across large-scale digital collections such as the Internet Archive and HathiTrust. IMPORTANT DATES Final paper submission deadline: 26th April 2015 (23:59 UTC-11) Draft paper submission deadline: 22nd April 2015 (23:59 UTC-11) Notification of acceptance: 22nd May 2015 Registration deadline for one author per paper: To be confirmed Camera ready submission deadline: 1st June 2015 (14:00 UTC) WORKSHOP OBJECTIVES DLfM will focus on the implications of music on Digital Libraries and Digital Libraries research when pushing the boundaries of contemporary musicology, including the application of techniques as reported in more technologically oriented fora such as ISMIR and ICMC. This will be the second edition of DLfM following a very successful and well received workshop at Digital Libraries 2014, giving an opportunity for the community to present and discuss developments in the last year that tackle the agenda that emerged in London. In particular we encourage participants to consider the theme of the main conference - "Large, Dynamic and Ubiquitous" - and how this properties are reflected in Music Digital Libraries and their application to musicology. The workshop objectives are: - to act as a forum for reporting, presenting, and evaluating this work and disseminating new approaches to advance the discipline; - to create a venue for critically and constructively evaluating and verifying the operation of Music Digital Libraries and the applications and findings that flow from them; - to consider the suitability of existing Music Digital Libraries, particularly in light of the transformative methods and applications emerging from musicology and "Large, Dynamic, and Ubiquitous" collections of both audio and music related data; - to set the agenda for work in the field to address these new challenges and opportunities. TOPICS Topics of interest for the workshop include but are not limited to: - Music Digital Libraries. - Digital Libraries in consideration of "Large, Dynamic and Ubiquitous" collections of audio and music related data. - Techniques for locating and accessing music in Very Large Digital Libraries (e.g. HathiTrust, Internet Archive). - Music data representations, including manuscripts/scores and audio - Interfaces and access mechanisms for Music Digital Libraries. - Digital Libraries in support of musicology and other scholarly study; novel requirements and methodologies therein. - Digital Libraries for combination of resources in support of musicology (e.g. combining audio, scores, bibliographic, geographic, ethnomusicology, performance, etc.) - User information needs and behaviour for Music Digital Libraries. Identification/location of music (in all forms) in generic Digital Libraries. - Mechanisms for combining multi-form music content within and between Digital Libraries and other digital resources. - Information literacies for Music Digital Libraries. - Metadata and metadata schemas for music. - Application of Linked Data and Semantic Web techniques to Music Digital Libraries, and for their access and organisation. - Optical Music Recognition. - Ontologies and categorisation of musics and music artefacts. SUBMISSIONS We invite full papers (up to 8 pages) or short and position papers (up to 4 pages). Papers will be peer reviewed by 2-3 members of the programme committee. Please produce your paper using the ACM template and submit it in draft to DLfM on EasyChair by 22nd April 2015 and the final version before 26th April 2015 (see IMPORTANT DATES above). Accepted papers will be included in our proceedings, which will be published in the ACM Digital Libraries as part of the ICPS series. The proceedings of last year's workshop, DLfM 2014, can be found in the ACM Digital Library at: http://dl.acm.org/citation.cfm?id=2660168&picked=prox&preflayout=flat All submitted papers must: - be written in English; - contain author names, affiliations, and email addresses; - be formatted according to the ACM SIG Proceedings template with a Type 1 font no smaller than 9pt; - be in PDF (make sure that the PDF can be viewed on any platform), and formatted for A4 size. It is the authors' responsibility to ensure that their submissions adhere strictly to the required format. Submissions that do not comply with the above guidelines may be rejected without review. Please note that at least one author from each accepted paper must attend the workshop to present their work, and in addition must be registered for the workshop by a date, preceding the camera ready deadline, which will be confirmed in due course (see IMPORTANT DATES above). ACM template: http://www.acm.org/sigs/publications/proceedings-templates Submissions: https://www.easychair.org/conferences/?conf=dlfm2015 Contact email: dlfm2015 at easychair.org WORKSHOP ORGANISATION Chairs Kevin Page, University of Oxford Ben Fields, Goldsmiths University of London Publicity and proceedings Richard Lewis, Goldsmiths University of London Programme Committee Richard Chesser, British Library Rachel Cowgill, University of Huddersfield Julia Craig-Mcfeely, University of Oxford Tim Crawford, Goldsmiths University of London Dave De Roure, University of Oxford J?rgen Diet, Bavarian State Library Matthew Dovey, JISC J. Stephen Downie, University of Illinois Ichiro Fujinaga, McGill University Charlie Inskip, University College London David Lewis, Goldsmiths, University of London Laurent Pugin, RISM Switzerland Carolin Rindfleisch, University of Oxford Mohamed Sordo, Music Technology Group, Universitat Pompeu Fabra Raffaele Viglianti, University of Maryland -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From diet at bsb-muenchen.de Fri Apr 24 09:10:08 2015 From: diet at bsb-muenchen.de (=?UTF-8?Q?J=C3=BCrgen=20Diet?=) Date: Fri, 24 Apr 2015 09:10:08 +0200 Subject: [MEI-L] Stellenausschreibung der Max-Weber-Stiftung in Bonn In-Reply-To: <75BACC97-0AC1-40C5-9F94-3A3EAB3707F2@edirom.de> References: <75BACC97-0AC1-40C5-9F94-3A3EAB3707F2@edirom.de> Message-ID: <553A08700200006F000906AD@gwia.bsb-muenchen.de> Liebe KollegInnen, die Max-Weber-Stiftung in Bonn sucht eine(n) Informatiker(in) f?r das von Prof. J?ger (Uni M?nster) geleitete Editionsprojekt zu vorderorientalischen Musikhandschriften: http://www.maxweberstiftung.de/aktuelles/einzelansicht-startseite/datum/2015/04/01/stellenausschreibung-wissenschaftlicher-mitarbeiterin-fuer-digital-humanities.html Viele Gr??e, J?rgen Diet **************************************************** J?rgen Diet (Projektkoordination ViFaMusik) Bayerische Staatsbibliothek Musikabteilung Ludwigstr. 16 80539 M?nchen Tel. 089/28638-2768 Fax 089/28638-2479 email: juergen.diet at bsb-muenchen.de ViFaMusik-Homepage: http://www.vifamusik.de ViFaMusik-Blog: http://vifamusik.wordpress.com ViFaMusik in Twitter: http://twitter.com/vifamusik BSB-Musikabteilung: http://musik.bsb-muenchen.de Musikdigitalisate der BSB: http://www.digitale-sammlungen.de/index.html?c=sammlungen&kategorie_sammlung=8&l=de **************************************************** From kepper at edirom.de Wed Apr 29 16:42:36 2015 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 29 Apr 2015 16:42:36 +0200 Subject: [MEI-L] Reminder: Registration for Music Encoding Conference Message-ID: Dear all, this is a final reminder that registration for the Conference in Florence is closing in little more than one day (central european midnight between April 30 and May 1st). There will be no further extension, and there won't be an on-site registration. So, if you plan to attend the conference but haven't registered yet, please do as soon as possible. Looking forward to meet you all for a great conference in Florence, Johannes -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr??e : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From richard at rjlewis.me.uk Wed Apr 29 17:57:36 2015 From: richard at rjlewis.me.uk (Richard Lewis) Date: Wed, 29 Apr 2015 16:57:36 +0100 Subject: [MEI-L] Digital Musicology workshop at DH@Ox Summer School Message-ID: <87twvz0vwv.wl%richard@rjlewis.me.uk> INVITATION TO REGISTER FOR WORKSHOP Digital Musicology Applied computational and informatics methods for enhancing musicology Dates: 20--24 July 2015 http://dhoxss.humanities.ox.ac.uk/2015/digitalmusicology.html Registration: http://dhoxss.humanities.ox.ac.uk/2015/registration.html until 29 June 2015. A wealth of music and music-related information is now available digitally, offering tantalizing possibilities for digital musicologies. These resources include large collections of audio and scores, bibliographic and biographic data, and performance ephemera -- not to mention the 'hidden' existence of these in other digital content. With such large and wide ranging opportunities come new challenges in methods, principally in adapting technological solutions to assist musicologists in identifying, studying, and disseminating scholarly insights from amongst this 'data deluge'. This workshop provides an introduction to computational and informatics methods that can be, and have been, successfully applied to musicology. Many of these techniques have their foundations in computer science, library and information science, mathematics and most recently Music Information Retrieval (MIR); sessions are delivered by expert practitioners from these fields and presented in the context of their collaborations with musicologists, and by musicologists relating their experiences of these multidisciplinary investigations. The workshop comprises of a series of lectures and hands-on sessions, supplemented with reports from musicology research exemplars. Theoretical lectures are paired with practical sessions in which attendees are guided through their own exploration of the topics and tools covered. Laptops will be loaned to attendees with the appropriate specialised software installed and preconfigured. The workshop is part of the Digital Humanities @ Oxford annual Summer School. As well as the workshop programme there are numerous events in the Summer School including keynote lectures and evening social events. Summer School site: http://dhoxss.humanities.ox.ac.uk/2015/ Contact: events at it.ox.ac.uk -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Richard Lewis Computing, Goldsmiths' College t: +44 (0)20 7078 5203 @: lewisrichard http://www.transforming-musicology.org/ 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From vhennen at umail.iu.edu Fri May 8 09:11:15 2015 From: vhennen at umail.iu.edu (Vaughan Hennen) Date: Fri, 8 May 2015 03:11:15 -0400 Subject: [MEI-L] MEI and Libraries In-Reply-To: References: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> <74FBC647-CF5A-46C4-899B-DA87EBD1F1B1@gmx.de> Message-ID: Ms. Richts, When MEI encodes cataloging information, is the purpose to have an interconnected database, or is the purpose to have an encoded record for the work? The Carl Neilson example is significant because it is 1. encoded and 2. creates an encoded record that is more thorough than most other cataloging records. Is this correct? Thank you. -Vaughan Hennen On Sun, Apr 19, 2015 at 2:41 PM, Vaughan Hennen wrote: > Ms. Richts, > > Thank you very much for this information. I will contact you if I have > any other questions. > > Sincerely, > > Vaughan Hennen > > On Sun, Apr 19, 2015 at 4:45 AM, Kristina Richts > wrote: > >> Hi Vaughan, >> >> Welcome on MEI-L! >> >> MEI indeed offers promising opportunities for cataloging issues and the >> use in music libraries. It provides wide-ranging possibilities to encode >> high quality metadata in a very detailed and extensive way. But the >> development of using MEI in the daily work of music libraries is more or >> less just starting from scratch - this is why you could not find very much >> documentation about it (yet). >> >> The implementation of the FRBR model in 2013 was one of the first attemps >> to adapt MEI to the requirements of not only music libraries but also >> cataloguing projects. Along with the MEI Guidelines you could also have a >> look at the Header section of the MEI 1st Tutorials: >> http://music-encoding.org/support/MEI1st/exploring_the_header >> There are brief descriptions of the main header elements and an example >> of cataloging with MEI as well as a cheat sheet which represents the >> structure of an MEI header. >> >> Along with the mentioned catalogue of Carl Nielsen?s works, you might >> have a look at the metadata editor MerMEId, which was developed at the >> Royal Library of Copenhagen by Axel Teich Geertinger: >> http://www.kb.dk/en/nb/dcm/projekter/mermeid.html >> The Nielsen catalogue was created using this tool and is a great first >> example of displaying MEI metadata. Besides the Nielsen edition a lot of >> other editorial or cataloguing projects started to adopt MEI for >> cataloguing purposes, i.e. RISM or Bach Digital, to name a few. >> >> Another cooperation project with a library (the Regional Library in >> Detmold) is the Detmold Court Theatre Project, in which I am working. We >> aim at developing an MEI and TEI based model for contextual indexing of >> musical holdings. It is intended to use MEI for a contextual indexing of >> sheet music for the first time there and to demonstrate the potential of >> MEI as a cataloging format, including encodings of incipits and detailed >> descriptions of the material components. >> >> In response to the increased interest in using MEI as a cataloguing >> format, we are currently preparing the establishing of a cataloging >> interest group (including a mailing list for this topic), which will have >> its first meeting at this year?s Music Encoding Conference being held in >> Florence from 18th to 21st May. We will be glad if you decide to >> participate: http://music-encoding.org/conference >> >> I hope this will help you. Please let us know if you have any further >> questions or if you need some more material for your presentation. >> >> Best, >> Kristina >> >> >> Am 17.04.2015 um 20:08 schrieb Andrew Hankinson < >> andrew.hankinson at mail.mcgill.ca>: >> >> Hi Vaughan, >> >> There is a significant amount of information in the MEI guidelines >> about how FRBR is implemented in MEI: >> >> http://music-encoding.org/documentation/guidelines2013/FRBR >> >> The online catalogue of Carl Nielsen?s works is a great example of how >> libraries can use MEI to present extensive musical metadata online using >> MEI. >> >> See: >> >> http://www.kb.dk/dcm/cnw/navigation.xq >> http://www.kb.dk/dcm/cnw/download_xml.xq?doc=cnw0001.xml >> >> -Andrew >> >> On Apr 17, 2015, at 12:56 AM, Vaughan Hennen >> wrote: >> >> Hello all, >> >> This is my first time posting on the list-serv. >> >> My name is Vaughan Hennen - I am pursuing a dual masters degree in >> Library Science and Information Science from Indiana University >> Bloomington. My bachelors degree is from the University of North Texas in >> cello performance. >> >> The project that I am presenting, is about MEI and its application in >> today's music libraries. >> >> I have done reading on what MEI is and how it is applicable in music >> libraries, but I am still not clear on its use in music libraries. >> >> Would any of you offer some insight about how music libraries use MEI >> metadata or how the extensible language adds to the library? >> >> Thank you for your help. >> >> Sincerely, >> >> -Vaughan Hennen >> >> >> _______________________________________________ >> 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 >> >> >> -- >> Kristina Richts, M.A., MA LIS >> >> Wissenschaftliche Mitarbeiterin >> DFG-Projekt ?Entwicklung eines MEI- und TEI-basierten Modells >> kontextueller Tiefenerschlie?ung >> von Musikalienbest?nden am Beispiel des Detmolder Hoftheaters im 19. >> Jahrhundert (1825-1875)? >> >> Musikwissenschaftliches Seminar Detmold/Paderborn >> Gartenstra?e 20 >> D-32756 Detmold >> >> Tel.: +49 5231 975 665 >> E-Mail: kristina.richts at uni-paderborn.de >> >> _______________________________________________ >> 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 stadler at edirom.de Fri May 8 21:27:34 2015 From: stadler at edirom.de (Peter Stadler) Date: Fri, 08 May 2015 21:27:34 +0200 Subject: [MEI-L] MEI and Libraries In-Reply-To: References: <31508_1429246620_5530929C_31508_103_1_CAHpEw3ccXHDr1qbkWM2vY_NNo2=2YyhPXEQrogg=H_T4ZoWDbw@mail.gmail.com> <2467BD27-0475-4DB5-A518-18ACC1C76E74@mail.mcgill.ca> <74FBC647-CF5A-46C4-899B-DA87EBD1F1B1@gmx.de> Message-ID: <554D0E26.1080102@edirom.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd say, the power (and beauty ;) of MEI facilitates both scenarios. In fact, I do not see any need for distinguishing here?! Cheers Peter Am 08.05.2015 um 09:11 schrieb Vaughan Hennen: > Ms. Richts, > > When MEI encodes cataloging information, is the purpose to have an > interconnected database, or is the purpose to have an encoded > record for the work? > > The Carl Neilson example is significant because it is 1. encoded > and 2. creates an encoded record that is more thorough than most > other cataloging records. Is this correct? > > Thank you. > > -Vaughan Hennen > > On Sun, Apr 19, 2015 at 2:41 PM, Vaughan Hennen > > wrote: > > Ms. Richts, > > Thank you very much for this information. I will contact you if I > have any other questions. > > Sincerely, > > Vaughan Hennen > > On Sun, Apr 19, 2015 at 4:45 AM, Kristina Richts > > wrote: > > Hi Vaughan, > > Welcome on MEI-L! > > MEI indeed offers promising opportunities for cataloging issues and > the use in music libraries. It provides wide-ranging possibilities > to encode high quality metadata in a very detailed and extensive > way. But the development of using MEI in the daily work of music > libraries is more or less just starting from scratch - this is why > you could not find very much documentation about it (yet). > > The implementation of the FRBR model in 2013 was one of the first > attemps to adapt MEI to the requirements of not only music > libraries but also cataloguing projects. Along with the MEI > Guidelines you could also have a look at the Header section of the > MEI 1st Tutorials: > http://music-encoding.org/support/MEI1st/exploring_the_header There > are brief descriptions of the main header elements and an example > of cataloging with MEI as well as a cheat sheet which represents > the structure of an MEI header. > > Along with the mentioned catalogue of Carl Nielsen?s works, you > might have a look at the metadata editor MerMEId, which was > developed at the Royal Library of Copenhagen by Axel Teich > Geertinger: http://www.kb.dk/en/nb/dcm/projekter/mermeid.html The > Nielsen catalogue was created using this tool and is a great first > example of displaying MEI metadata. Besides the Nielsen edition a > lot of other editorial or cataloguing projects started to adopt MEI > for cataloguing purposes, i.e. RISM or Bach Digital, to name a > few. > > Another cooperation project with a library (the Regional Library in > Detmold) is the Detmold Court Theatre Project, in which I am > working. We aim at developing an MEI and TEI based model for > contextual indexing of musical holdings. It is intended to use MEI > for a contextual indexing of sheet music for the first time there > and to demonstrate the potential of MEI as a cataloging format, > including encodings of incipits and detailed descriptions of the > material components. > > In response to the increased interest in using MEI as a cataloguing > format, we are currently preparing the establishing of a cataloging > interest group (including a mailing list for this topic), which > will have its first meeting at this year?s Music Encoding > Conference being held in Florence from 18th to 21st May. We will be > glad if you decide to participate: > http://music-encoding.org/conference > > I hope this will help you. Please let us know if you have any > further questions or if you need some more material for your > presentation. > > Best, Kristina > > > Am 17.04.2015 um 20:08 schrieb Andrew Hankinson > >: > >> Hi Vaughan, >> >> There is a significant amount of information in the MEI >> guidelines about how FRBR is implemented in MEI: >> >> http://music-encoding.org/documentation/guidelines2013/FRBR >> >> The online catalogue of Carl Nielsen?s works is a great example >> of how libraries can use MEI to present extensive musical >> metadata online using MEI. >> >> See: >> >> http://www.kb.dk/dcm/cnw/navigation.xq >> http://www.kb.dk/dcm/cnw/download_xml.xq?doc=cnw0001.xml >> >> -Andrew >> >>> On Apr 17, 2015, at 12:56 AM, Vaughan Hennen >>> > wrote: >>> >>> Hello all, >>> >>> This is my first time posting on the list-serv. >>> >>> My name is Vaughan Hennen - I am pursuing a dual masters degree >>> in Library Science and Information Science from Indiana >>> University Bloomington. My bachelors degree is from the >>> University of North Texas in cello performance. >>> >>> The project that I am presenting, is about MEI and its >>> application in today's music libraries. >>> >>> I have done reading on what MEI is and how it is applicable in >>> music libraries, but I am still not clear on its use in music >>> libraries. >>> >>> Would any of you offer some insight about how music libraries >>> use MEI metadata or how the extensible language adds to the >>> library? >>> >>> Thank you for your help. >>> >>> Sincerely, >>> >>> -Vaughan Hennen >>> >>> >>> _______________________________________________ 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 > > -- Kristina Richts, M.A., MA LIS > > Wissenschaftliche Mitarbeiterin DFG-Projekt ?Entwicklung eines MEI- > und TEI-basierten Modells kontextueller Tiefenerschlie?ung von > Musikalienbest?nden am Beispiel des Detmolder Hoftheaters im 19. > Jahrhundert (1825-1875)? > > Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 > D-32756 Detmold > > Tel.: +49 5231 975 665 E-Mail: > kristina.richts at uni-paderborn.de > > > _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJVTQ4mAAoJEJclm6G69Xq2x4kIAIAFM09Q2jS43tQaoja7/wcN P0suRIPd0MU96+a/4VCLk0ljs/HSGjxULNuNrm1GKO+eUKhHkUQNWtDUwY0Gyg+E tzlw09bnInasjdQ4W2sMHDOKnPDdYv7HB5gh7lV8PBWyQFYw36CcbAQZ6pweZlzk orDruOXoFjqGjAZEt20S8uRyfxFOYwik2JdWFtv0Zj0N93P7+Kc49WNCvajSAcKi M1TPGmkl3GBkbJQjup03v7WMk4oN/0TWtWJvs6uYVa/AJrsWjgXoO2JSmXG+DKS7 aTSi+1Ci9YmE+QvgjN+J+E3+7NlNXb4fyn8Paouzrjs/yymOvm7+T73IhkSnqqA= =SymR -----END PGP SIGNATURE----- From lxpugin at gmail.com Sat May 16 11:03:25 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Sat, 16 May 2015 11:03:25 +0200 Subject: [MEI-L] Verovio update Message-ID: Hello everyone, One year after the first presentation of Verovio at the MEC last year in Charlottesville, I would like to give you an update on the progress made this year. Several features have been added. Some notable ones include: - Chords (thanks to the work of Andrew Horwitz) http://www.verovio.org/features.xhtml?id=chords - Critical apparatus, including nested apparati http://www.verovio.org/features.xhtml?id=app - Lyrics, including multi-line lyrics and connectors http://www.verovio.org/features.xhtml?id=app The work-in-progress on other features (cross-staff notation, mensural notation alignment, etc.) can be seen on the features page. http://www.verovio.org/features.xhtml The MEI viewer was updated to a version that shows how Verovio can be used in a more responsive environment. In this new viewer, the layout of the music is adjusted to the screen size. The best performance is with Firefox. http://www.verovio.org/mei-viewer.xhtml Verovio is now SMuFL compliant. It includes its own font (Leipzig) but can also use the Bravura (Steinberg) or the Gootville (Musescore) fonts. Other fonts can easily be used. http://www.verovio.org/smufl.xhtml?font=Leipzig Behind the scenes: many improvements have been made to the Verovio codebase. They include the use of LibMEI for generating some of the code and the improvement of the SVG output structure. These two modifications make Verovio even closer to MEI. There is also a new Python binding for using it in scripting environments. We are aiming for release version 1.0 in the near future. It will include support for MEI timestamp events (for hairpin, dynamics, etc), basic articulations and improved slur positioning, which has not yet been taken care of. Looking forward to seeing some of you next week in Florence, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxpugin at gmail.com Sat May 16 12:00:11 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Sat, 16 May 2015 12:00:11 +0200 Subject: [MEI-L] Verovio update In-Reply-To: References: Message-ID: PS The link to the lyric feature page is obviously wrong. it should have been http://www.verovio.org/features.xhtml?id=lyrics On Sat, May 16, 2015 at 11:03 AM, Laurent Pugin wrote: > Hello everyone, > > One year after the first presentation of Verovio at the MEC last year in > Charlottesville, I would like to give you an update on the progress made > this year. > > Several features have been added. Some notable ones include: > - Chords (thanks to the work of Andrew Horwitz) > http://www.verovio.org/features.xhtml?id=chords > - Critical apparatus, including nested apparati > http://www.verovio.org/features.xhtml?id=app > - Lyrics, including multi-line lyrics and connectors > http://www.verovio.org/features.xhtml?id=app > > The work-in-progress on other features (cross-staff notation, mensural > notation alignment, etc.) can be seen on the features page. > http://www.verovio.org/features.xhtml > > The MEI viewer was updated to a version that shows how Verovio can be used > in a more responsive environment. In this new viewer, the layout of the > music is adjusted to the screen size. The best performance is with Firefox. > http://www.verovio.org/mei-viewer.xhtml > > Verovio is now SMuFL compliant. It includes its own font (Leipzig) but can > also use the Bravura (Steinberg) or the Gootville (Musescore) fonts. Other > fonts can easily be used. > http://www.verovio.org/smufl.xhtml?font=Leipzig > > Behind the scenes: many improvements have been made to the Verovio > codebase. They include the use of LibMEI for generating some of the code > and the improvement of the SVG output structure. These two modifications > make Verovio even closer to MEI. There is also a new Python binding for > using it in scripting environments. > > We are aiming for release version 1.0 in the near future. It will include > support for MEI timestamp events (for hairpin, dynamics, etc), basic > articulations and improved slur positioning, which has not yet been taken > care of. > > Looking forward to seeing some of you next week in Florence, > Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Sat May 16 13:06:48 2015 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 16 May 2015 13:06:48 +0200 Subject: [MEI-L] Verovio update In-Reply-To: References: Message-ID: <60449D2C-84A0-4303-AE1B-454329A5D68E@edirom.de> Hi Laurent, the automatic reflow to match screen size is awesome. Congratulations to everyone involved ? great work! See you soon, Johannes Am 16.05.2015 um 11:03 schrieb Laurent Pugin : > Hello everyone, > > One year after the first presentation of Verovio at the MEC last year in Charlottesville, I would like to give you an update on the progress made this year. > > Several features have been added. Some notable ones include: > - Chords (thanks to the work of Andrew Horwitz) http://www.verovio.org/features.xhtml?id=chords > - Critical apparatus, including nested apparati http://www.verovio.org/features.xhtml?id=app > - Lyrics, including multi-line lyrics and connectors http://www.verovio.org/features.xhtml?id=app > > The work-in-progress on other features (cross-staff notation, mensural notation alignment, etc.) can be seen on the features page. > http://www.verovio.org/features.xhtml > > The MEI viewer was updated to a version that shows how Verovio can be used in a more responsive environment. In this new viewer, the layout of the music is adjusted to the screen size. The best performance is with Firefox. > http://www.verovio.org/mei-viewer.xhtml > > Verovio is now SMuFL compliant. It includes its own font (Leipzig) but can also use the Bravura (Steinberg) or the Gootville (Musescore) fonts. Other fonts can easily be used. > http://www.verovio.org/smufl.xhtml?font=Leipzig > > Behind the scenes: many improvements have been made to the Verovio codebase. They include the use of LibMEI for generating some of the code and the improvement of the SVG output structure. These two modifications make Verovio even closer to MEI. There is also a new Python binding for using it in scripting environments. > > We are aiming for release version 1.0 in the near future. It will include support for MEI timestamp events (for hairpin, dynamics, etc), basic articulations and improved slur positioning, which has not yet been taken care of. > > Looking forward to seeing some of you next week in Florence, > Laurent > _______________________________________________ > 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 Mon May 18 18:26:29 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Mon, 18 May 2015 18:26:29 +0200 Subject: [MEI-L] excuses and best wishes Message-ID: <555A12B5.4020904@edirom.de> Dear MEI community, please excuse my absence from this year's Music Encoding Conference! To be honest I've got "something better" - attending to my little baby boy Moritz, born on April 24 ;-) I wish you all a most exciting and enjoyable conference. (which it already is as I can see from Twitter #MEC2015, please keep on tweeting!) This is especially true for the local organizers and all those involved in making the conference happen, many thanks! All the best wishes, Benjamin -- *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** From hans at neoscores.com Thu May 21 16:26:30 2015 From: hans at neoscores.com (Hans Vereyken) Date: Thu, 21 May 2015 16:26:30 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements Message-ID: Hi, This is my first post to the MEI mailing list. I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: and: Chopin_Etude_op.10_no.9: So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). In a dynamic music renderer, where you can switch parts on/off this is key information. How should it be done? Am I missing something? Thanks in advance! Hans Vereyken ------------- volgend deel ------------ Een HTML-bijlage is gescrubt... URL: From andrew.hankinson at mail.mcgill.ca Fri May 22 00:58:03 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 22 May 2015 00:58:03 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> Message-ID: <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> Hi Hans, Welcome to MEI! Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. -Andrew > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: > > Hi, > > This is my first post to the MEI mailing list. > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > In a dynamic music renderer, where you can switch parts on/off this is key information. > > How should it be done? Am I missing something? > > Thanks in advance! > Hans Vereyken > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From hans at neoscores.com Fri May 22 09:16:06 2015 From: hans at neoscores.com (Hans Vereyken) Date: Fri, 22 May 2015 09:16:06 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> Message-ID: Hi Andrew, I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). To be sure we are talking about the same: - staff: needed to notate music - part: music performed by a single player/instrument One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Thanks Hans Hans Vereyken *Developer* M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 00:58, Andrew Hankinson wrote: > Hi Hans, > > Welcome to MEI! > > Are you looking for the equivalent of the MIDI instrument that would > perform these parts? Or something else? > > If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts). If you have a staff that is "hidden" (for example, if you have an > instrument that does not play on certain pages) you still need to define > the staff and give it a number. This number should be constant throughout > the score. If it does not play in a specific place, it will simply not > appear in the measure (as far as I understand it). > > If you're in a renderer and you want to switch all the "n=2" parts off, > then, you would simply hide it whenever you have . The "2" > does not refer to the second staff on any given page; rather, it refers to > the second staff defined in a score, regardless of whether it appears or > not. > > -Andrew > > > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: > > > > Hi, > > > > This is my first post to the MEI mailing list. > > I'm implementing MEI into our music renderer and am having trouble > getting all the info I need about staves. > > > > I searches the documentation and mail archives for answers but wasn't > able to find what I'm looking for. > > > > So each staff is declared seperatly, with the certain groups > and there symbols are declared. Although a brace usually means that the > staves within are the same player (e.g. piano brace), it is not enough to > be sure of it. > > > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the > relevant xml: > > > > meter.sym="common" key.sig="0" key.mode="major"> > > > > > > clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> > > > > barthru="true"> > > clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" > key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> > > clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> > > label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > key.sig="4f" key.mode="minor"> > > > > clef.line="2"/> > > clef.shape="F" lines="5"/> > > > > > > > > So in both cases I have a group of staves with a brace symbol, how > should I know which staves are played by which player. > > I can try to sniff the labels and by guessing the semantic meaning of > 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the > second example this isn't possible, so this won't work (no surprise). > > In a dynamic music renderer, where you can switch parts on/off this is > key information. > > > > How should it be done? Am I missing something? > > > > Thanks in advance! > > Hans Vereyken > > _______________________________________________ > > 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 > ------------- volgend deel ------------ Een HTML-bijlage is gescrubt... URL: From andrew.hankinson at mail.mcgill.ca Fri May 22 09:54:29 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 22 May 2015 09:54:29 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> Message-ID: <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> > On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: > > Hi Andrew, > > I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. > > "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." > I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). > Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. > I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? > This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. > I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: and then in the body (for example): > > At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). I think the layerDef mechanism will help here too. > > To be sure we are talking about the same: > - staff: needed to notate music > - part: music performed by a single player/instrument > > One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). > > Thanks > Hans > > Hans Vereyken > Developer > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > On 22 May 2015 at 00:58, Andrew Hankinson > wrote: > Hi Hans, > > Welcome to MEI! > > Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? > > If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). > > If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. > > -Andrew > > > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: > > > > Hi, > > > > This is my first post to the MEI mailing list. > > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > > In a dynamic music renderer, where you can switch parts on/off this is key information. > > > > How should it be done? Am I missing something? > > > > Thanks in advance! > > Hans Vereyken > > _______________________________________________ > > 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 atge at kb.dk Fri May 22 09:56:03 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 22 May 2015 07:56:03 +0000 Subject: [MEI-L] New interest group: Metadata and Cataloging Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1011FD5FF06@EXCHANGE-03.kb.dk> Dear all Greetings from the Music Encoding Conference 2015 in Florence! I am happy to be able to officially announce the birth of the MEI "Metadata and Cataloging Interest Group". The founding meeting with about 20 participants took place here in Florence yesterday; the founding was approved by the MEI Board in the evening. The aims of the group will be, for instance, to discuss the use of MEI for the encoding of musical metadata; to make recommendations regarding the development of the element; to promote the sharing of and collaboration on tools for projects concerned with MEI metadata such as cataloging projects. 'Cataloging' in this context may include a wide range of projects such as thematic catalogues ('Werkverzeichnisse'), library catalogues, and other descriptions of musical works or sources. The group is open to all members of the MEI community (that is, subscribers to MEI-L: https://lists.uni-paderborn.de/mailman/listinfo/mei-l). One of the first tasks will be to provide some information in rather general terms about the relevance and the use of MEI for such cataloging projects, explaining different approaches and their strengths and weaknesses. The Interest Group will at some point have its own page at http://music-encoding.org where this type of information will be made available as a supplement to the general MEI Guidelines. Kristina Richts (University of Detmold/Paderborn) and I were appointed the administrative co-chairs of the group. If you have any interest in working with musical metadata and cataloging, we warmly invite you to join the group by subscribing to our mailing list: https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig See you there! Best wishes, Axel [http://support.kb.dk/images/kb_logo.jpg] Det Kongelige Bibliotek Nationalbibliotek og K?benhavns Universitetsbibliotek Axel Teich Geertinger Centerleder | Head of Centre Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 K?benhavn K tel +45 9132 4706 | Fax +45 3393 2218 | atge at kb.dk | www.kb.dk Bes?gsadresse | Visiting address | S?ren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 K?benhavn K EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14433 bytes Desc: image001.jpg URL: From hans at neoscores.com Fri May 22 10:51:53 2015 From: hans at neoscores.com (Hans Vereyken) Date: Fri, 22 May 2015 10:51:53 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> Message-ID: But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) Visually it's separate lines, but musically it's absolutely one line (again the harp as a better example). If a piano part is intended for 2 players, each player should have it's own group of staves, or a single stave. And to avoid confusion a brace shouldn't be used across both piano parts (bracket would be better, although there are examples of engravers using braces to group different parts). Calling these independent lines feels like leaving out half of an instrument. I' ielaigothl fteltesi etne (It's like leaving out half of the letters in a sentence), the one independent line is worthless without the other one. They should be more closely grouped than just a bracket/brace (in a part if you ask me). Imho this should be clear in the semantics of an MEI file. The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). Layers still give an 'on top of each other' feeling, so I don't know whether 'layer' is the way to go. But I understand why. @instr would help if it would mean that all staves within the group are played by one instrument, but if I read the specs correctly these are both ok, but the first example is played by 2 players, the second by 1... Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. Thanks for discussing this with me! Hans Vereyken *Developer* M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 09:54, Andrew Hankinson wrote: > > On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: > > Hi Andrew, > > I see, my subject title is a bit confusing, better would be: How to > distinguish different players in the and elements. > > "If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts)." > I strongly disagree on that, it is played by a single player and it is a > single part. This is even more clear if you think about harp parts, > (very often) one 'voice' (strangely called 'layers' in MEI) traveling > across 2 staves. > > > But they are independent lines. In theory, you could have two one-handed > people playing a piano and it would make no practical difference. :) The > voice/layer nomenclature in MEI comes from a desire to separate a melodic > line from any idea of "voice leading." (i.e., not wanting to confuse the > practical separation of independent instrument lines from the > music-theoretical notions of harmonic and melodic progression). > > Another problem is cross staff notes, in your opinion these are the same > as something that would be called 'cross part notes' (since each staff is a > part). Think about it, 'cross part notes'... I don't even know any > contemporary composer who did this. > I think this information should be added to the MEI format, and I think it > can be done with an attribute in the staffGrp element indicating that all > staves in that group are performed by one player/instrument (or group of > players, eg, 1st Violin). > > > Sorry, I'm still not clear on what you are asking. Have you looked at the > @instr attribute on staffGrp? Is this what you are looking for? Or is it > something else? > > This way you can keep numbering the staves top to bottom for the whole > score, but it's clear which staves are played by the same player/instrument > and should be grouped together when playing around with parts. > I agree that it needs to be possible to hide a single staff in a part with > multiple staves, but semantically spoken it's a big difference with hiding > a part. > > > Would the `layerDef` mechanism help clear this up? You can define a > specific layer to correspond to a specific voice, in the same way you can > define a specific staffDef to define a specific staff. Then you can trace a > specific layer ("voice") throughout the work, having pre-defined it in your > scoreDef/staffDef block. > > For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have > the percussion instruments on a single staff: > > lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> > > > > > > > > > and then in the body (for example): > > > > > instr="#P18-X2" pnum="61"/> > instr="#P18-X2" pnum="61"/> > > > > > > > > > At the same time it would be great to have another attribute in the > staffDef element indicating that this staff is performed by multiple > players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice > (again, called layers in MEI). This would be very helpfull in reading some > chorus score's to (in the MEI examples this would clear up different parts > in Altenburg_Macht_auf_die_Tor). > > > I think the layerDef mechanism will help here too. > > > To be sure we are talking about the same: > - staff: needed to notate music > - part: music performed by a single player/instrument > > One part can be notated on multiple staves, multiple parts can be notated > on a single staff. For me part is definitely not the same as staff. > > > Multiple parts on a single staff is pretty easy; one part on multiple > staves is a bit trickier, but can still be done. You can use the @staff and > @layer attributes on events (chords, notes, rests) to "assign" that event > to a particular staff and/or layer. > > See: http://www.verovio.org/examples/features/cross-staff.mei for an > example of how this might work (and > http://www.verovio.org/features.xhtml?id=cross-staff for a sample > rendering). > > > Thanks > Hans > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > On 22 May 2015 at 00:58, Andrew Hankinson > wrote: > >> Hi Hans, >> >> Welcome to MEI! >> >> Are you looking for the equivalent of the MIDI instrument that would >> perform these parts? Or something else? >> >> If you have two different staves, these are two different players, >> regardless of the label (a left and a right hand on a piano could be >> thought of as two different "players" since they're playing two separate >> parts). If you have a staff that is "hidden" (for example, if you have an >> instrument that does not play on certain pages) you still need to define >> the staff and give it a number. This number should be constant throughout >> the score. If it does not play in a specific place, it will simply not >> appear in the measure (as far as I understand it). >> >> If you're in a renderer and you want to switch all the "n=2" parts off, >> then, you would simply hide it whenever you have . The "2" >> does not refer to the second staff on any given page; rather, it refers to >> the second staff defined in a score, regardless of whether it appears or >> not. >> >> -Andrew >> >> > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: >> > >> > Hi, >> > >> > This is my first post to the MEI mailing list. >> > I'm implementing MEI into our music renderer and am having trouble >> getting all the info I need about staves. >> > >> > I searches the documentation and mail archives for answers but wasn't >> able to find what I'm looking for. >> > >> > So each staff is declared seperatly, with the certain groups >> and there symbols are declared. Although a brace usually means that the >> staves within are the same player (e.g. piano brace), it is not enough to >> be sure of it. >> > >> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the >> relevant xml: >> > >> > > meter.sym="common" key.sig="0" key.mode="major"> >> > >> > >> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> >> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> >> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> >> > >> > > barthru="true"> >> > > clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" >> key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> >> > > clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> >> > > label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> >> > >> > >> > >> > >> > and: Chopin_Etude_op.10_no.9: >> > >> > > key.sig="4f" key.mode="minor"> >> > >> > > lines="5" clef.line="2"/> >> > > clef.shape="F" lines="5"/> >> > >> > >> > >> > So in both cases I have a group of staves with a brace symbol, how >> should I know which staves are played by which player. >> > I can try to sniff the labels and by guessing the semantic meaning of >> 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the >> second example this isn't possible, so this won't work (no surprise). >> > In a dynamic music renderer, where you can switch parts on/off this is >> key information. >> > >> > How should it be done? Am I missing something? >> > >> > Thanks in advance! >> > Hans Vereyken >> > _______________________________________________ >> > 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 > > ------------- volgend deel ------------ Een HTML-bijlage is gescrubt... URL: From andrew.hankinson at mail.mcgill.ca Fri May 22 13:34:15 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 22 May 2015 13:34:15 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> Message-ID: > Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. > > one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. > > One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. > Follow us on: Facebook // Twitter > > On 22 May 2015 at 09:54, Andrew Hankinson > wrote: > >> On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: >> >> Hi Andrew, >> >> I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. >> >> "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." >> I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. > > But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). > >> Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. >> I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). > > Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? > >> This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. >> I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. > > Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. > > For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: > > > > > > > > > > > and then in the body (for example): > > > > > instr="#P18-X2" pnum="61"/> > instr="#P18-X2" pnum="61"/> > > > > > > > >> >> At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). > > I think the layerDef mechanism will help here too. > >> >> To be sure we are talking about the same: >> - staff: needed to notate music >> - part: music performed by a single player/instrument >> >> One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. > > Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. > > See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). > >> >> Thanks >> Hans >> >> Hans Vereyken >> Developer >> >> M hans at neoscores.com >> T +32 472 52 75 59 >> >> neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores >> ///////////////////////////////////////////////////////////////////////////////////////////////////// >> >> Follow us on: Facebook // Twitter >> >> On 22 May 2015 at 00:58, Andrew Hankinson > wrote: >> Hi Hans, >> >> Welcome to MEI! >> >> Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? >> >> If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). >> >> If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. >> >> -Andrew >> >> > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: >> > >> > Hi, >> > >> > This is my first post to the MEI mailing list. >> > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. >> > >> > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. >> > >> > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. >> > >> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > and: Chopin_Etude_op.10_no.9: >> > >> > >> > >> > >> > >> > >> > >> > >> > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. >> > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). >> > In a dynamic music renderer, where you can switch parts on/off this is key information. >> > >> > How should it be done? Am I missing something? >> > >> > Thanks in advance! >> > Hans Vereyken >> > _______________________________________________ >> > 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 hans at neoscores.com Fri May 22 14:01:33 2015 From: hans at neoscores.com (Hans Vereyken) Date: Fri, 22 May 2015 14:01:33 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> Message-ID: I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; @players is required if it's isn't default. Would this be possible? Hans Vereyken *Developer* M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 13:34, Andrew Hankinson wrote: > > Notating multiple parts on one staff can be done with the layerDef, looks > good, thanks. > > one part on multiple staves is a bit trickier, but can still be done. You > can use the @staff and @layer attributes on events (chords, notes, rests) > to "assign" that event to a particular staff and/or layer. > > One part on multiple staves is a very common thing (I'm a professional > pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading > files, not creating them. I didn't look through all the MEI examples but > this far I didn't found a single example demonstrating this technique. > Ruling out all files who don't follow this technique would be a massive > mistake. > > > I didn't mean to suggest that it's uncommon; I just meant that within the > confines of XML, dealing with overlapping or crossing hierarchies requires > a bit of extra semantics. The link I sent you to the cross-staff example > should be able to give you a start on dealing with cross-staff notation. > > > > Follow us on: Facebook // Twitter > > > On 22 May 2015 at 09:54, Andrew Hankinson > wrote: > >> >> On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: >> >> Hi Andrew, >> >> I see, my subject title is a bit confusing, better would be: How to >> distinguish different players in the and elements. >> >> "If you have two different staves, these are two different players, >> regardless of the label (a left and a right hand on a piano could be >> thought of as two different "players" since they're playing two separate >> parts)." >> I strongly disagree on that, it is played by a single player and it is a >> single part. This is even more clear if you think about harp parts, >> (very often) one 'voice' (strangely called 'layers' in MEI) traveling >> across 2 staves. >> >> >> But they are independent lines. In theory, you could have two one-handed >> people playing a piano and it would make no practical difference. :) The >> voice/layer nomenclature in MEI comes from a desire to separate a melodic >> line from any idea of "voice leading." (i.e., not wanting to confuse the >> practical separation of independent instrument lines from the >> music-theoretical notions of harmonic and melodic progression). >> >> Another problem is cross staff notes, in your opinion these are the same >> as something that would be called 'cross part notes' (since each staff is a >> part). Think about it, 'cross part notes'... I don't even know any >> contemporary composer who did this. >> I think this information should be added to the MEI format, and I think >> it can be done with an attribute in the staffGrp element indicating that >> all staves in that group are performed by one player/instrument (or group >> of players, eg, 1st Violin). >> >> >> Sorry, I'm still not clear on what you are asking. Have you looked at the >> @instr attribute on staffGrp? Is this what you are looking for? Or is it >> something else? >> >> This way you can keep numbering the staves top to bottom for the whole >> score, but it's clear which staves are played by the same player/instrument >> and should be grouped together when playing around with parts. >> I agree that it needs to be possible to hide a single staff in a part >> with multiple staves, but semantically spoken it's a big difference with >> hiding a part. >> >> >> Would the `layerDef` mechanism help clear this up? You can define a >> specific layer to correspond to a specific voice, in the same way you can >> define a specific staffDef to define a specific staff. Then you can trace a >> specific layer ("voice") throughout the work, having pre-defined it in your >> scoreDef/staffDef block. >> >> For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have >> the percussion instruments on a single staff: >> >> > lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> >> >> >> >> >> >> >> >> >> and then in the body (for example): >> >> >> >> >> > instr="#P18-X2" pnum="61"/> >> > instr="#P18-X2" pnum="61"/> >> >> >> >> >> >> >> >> >> At the same time it would be great to have another attribute in the >> staffDef element indicating that this staff is performed by multiple >> players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice >> (again, called layers in MEI). This would be very helpfull in reading some >> chorus score's to (in the MEI examples this would clear up different parts >> in Altenburg_Macht_auf_die_Tor). >> >> >> I think the layerDef mechanism will help here too. >> >> >> To be sure we are talking about the same: >> - staff: needed to notate music >> - part: music performed by a single player/instrument >> >> One part can be notated on multiple staves, multiple parts can be notated >> on a single staff. For me part is definitely not the same as staff. >> >> >> Multiple parts on a single staff is pretty easy; one part on multiple >> staves is a bit trickier, but can still be done. You can use the @staff and >> @layer attributes on events (chords, notes, rests) to "assign" that event >> to a particular staff and/or layer. >> >> See: http://www.verovio.org/examples/features/cross-staff.mei for an >> example of how this might work (and >> http://www.verovio.org/features.xhtml?id=cross-staff for a sample >> rendering). >> >> >> Thanks >> Hans >> >> Hans Vereyken >> *Developer* >> >> M hans at neoscores.com >> T +32 472 52 75 59 >> >> neoScores BVBA // Pluyseghemstraat 19, >> BE-2550 Kontich // Twitter: @neoscores >> >> ///////////////////////////////////////////////////////////////////////////////////////////////////// >> >> Follow us on: Facebook // Twitter >> >> >> On 22 May 2015 at 00:58, Andrew Hankinson < >> andrew.hankinson at mail.mcgill.ca> wrote: >> >>> Hi Hans, >>> >>> Welcome to MEI! >>> >>> Are you looking for the equivalent of the MIDI instrument that would >>> perform these parts? Or something else? >>> >>> If you have two different staves, these are two different players, >>> regardless of the label (a left and a right hand on a piano could be >>> thought of as two different "players" since they're playing two separate >>> parts). If you have a staff that is "hidden" (for example, if you have an >>> instrument that does not play on certain pages) you still need to define >>> the staff and give it a number. This number should be constant throughout >>> the score. If it does not play in a specific place, it will simply not >>> appear in the measure (as far as I understand it). >>> >>> If you're in a renderer and you want to switch all the "n=2" parts off, >>> then, you would simply hide it whenever you have . The "2" >>> does not refer to the second staff on any given page; rather, it refers to >>> the second staff defined in a score, regardless of whether it appears or >>> not. >>> >>> -Andrew >>> >>> > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: >>> > >>> > Hi, >>> > >>> > This is my first post to the MEI mailing list. >>> > I'm implementing MEI into our music renderer and am having trouble >>> getting all the info I need about staves. >>> > >>> > I searches the documentation and mail archives for answers but wasn't >>> able to find what I'm looking for. >>> > >>> > So each staff is declared seperatly, with the certain >>> groups and there symbols are declared. Although a brace usually means that >>> the staves within are the same player (e.g. piano brace), it is not enough >>> to be sure of it. >>> > >>> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the >>> relevant xml: >>> > >>> > >> meter.sym="common" key.sig="0" key.mode="major"> >>> > >>> > >> barthru="true"> >>> > >> clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> >>> > >> clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> >>> > >> clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> >>> > >>> > >> barthru="true"> >>> > >> clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" >>> key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> >>> > >> clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> >>> > >> label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> >>> > >>> > >>> > >>> > >>> > and: Chopin_Etude_op.10_no.9: >>> > >>> > >> key.sig="4f" key.mode="minor"> >>> > >>> > >> lines="5" clef.line="2"/> >>> > >> clef.shape="F" lines="5"/> >>> > >>> > >>> > >>> > So in both cases I have a group of staves with a brace symbol, how >>> should I know which staves are played by which player. >>> > I can try to sniff the labels and by guessing the semantic meaning of >>> 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the >>> second example this isn't possible, so this won't work (no surprise). >>> > In a dynamic music renderer, where you can switch parts on/off this is >>> key information. >>> > >>> > How should it be done? Am I missing something? >>> > >>> > Thanks in advance! >>> > Hans Vereyken >>> > _______________________________________________ >>> > 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 > > ------------- volgend deel ------------ Een HTML-bijlage is gescrubt... URL: From andrew.hankinson at mail.mcgill.ca Tue May 26 00:56:39 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 25 May 2015 18:56:39 -0400 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> Message-ID: <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct? I believe what you are looking for is in the , , and cluster of tags. contains @count which indicates the number of performers. http://www.music-encoding.org/documentation/guidelines2013/instrVoice Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an element, and perhaps do the same and have @instrGrp / pairs as well. That way you could do: Violin I Violin II Viola Violoncello Piano And then: ... ...treble staff... ...bass staff... The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice. Anyone else out there have any ideas? -Andrew > On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: > > I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. > The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; > @players is required if it's isn't default. > > Would this be possible? > > Hans Vereyken > Developer > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > On 22 May 2015 at 13:34, Andrew Hankinson > wrote: > >> Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. >> >> one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. >> >> One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. > > I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. > > > >> Follow us on: Facebook // Twitter >> >> On 22 May 2015 at 09:54, Andrew Hankinson > wrote: >> >>> On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: >>> >>> Hi Andrew, >>> >>> I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. >>> >>> "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." >>> I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. >> >> But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). >> >>> Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. >>> I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). >> >> Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? >> >>> This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. >>> I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. >> >> Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. >> >> For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: >> >> >> >> >> >> >> >> >> >> >> and then in the body (for example): >> >> >> >> >> > instr="#P18-X2" pnum="61"/> >> > instr="#P18-X2" pnum="61"/> >> >> >> >> >> >> >> >>> >>> At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). >> >> I think the layerDef mechanism will help here too. >> >>> >>> To be sure we are talking about the same: >>> - staff: needed to notate music >>> - part: music performed by a single player/instrument >>> >>> One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. >> >> Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. >> >> See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). >> >>> >>> Thanks >>> Hans >>> >>> Hans Vereyken >>> Developer >>> >>> M hans at neoscores.com >>> T +32 472 52 75 59 >>> >>> neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores >>> ///////////////////////////////////////////////////////////////////////////////////////////////////// >>> >>> Follow us on: Facebook // Twitter >>> >>> On 22 May 2015 at 00:58, Andrew Hankinson > wrote: >>> Hi Hans, >>> >>> Welcome to MEI! >>> >>> Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? >>> >>> If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). >>> >>> If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. >>> >>> -Andrew >>> >>> > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: >>> > >>> > Hi, >>> > >>> > This is my first post to the MEI mailing list. >>> > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. >>> > >>> > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. >>> > >>> > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. >>> > >>> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > and: Chopin_Etude_op.10_no.9: >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. >>> > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). >>> > In a dynamic music renderer, where you can switch parts on/off this is key information. >>> > >>> > How should it be done? Am I missing something? >>> > >>> > Thanks in advance! >>> > Hans Vereyken >>> > _______________________________________________ >>> > 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 > > > _______________________________________________ > 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 lxpugin at gmail.com Tue May 26 10:48:24 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 26 May 2015 10:48:24 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> Message-ID: Hi Andrew and Hans, This makes sense to me. I guess you would also need to have @instr in when there is more than one instrument represented in one staff, wouldn't you? Laurent On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > I think I know what you're trying to do: You're trying to ensure that a > part that gets extracted to the right amount of staves, correct? That, > given an ensemble work that features a piano, your software does not try to > extract two different parts for the right and left hands of the piano. > Correct? > > I believe what you are looking for is in the , > , and cluster of tags. > contains @count which indicates the number of performers. > > http://www.music-encoding.org/documentation/guidelines2013/instrVoice > > Looking this over I might suggest to move @instr out of the MIDI module > and specify that it should point to an element, and perhaps do > the same and have @instrGrp / pairs as well. That way you could > do: > > > > Violin I > Violin II > Viola > Violoncello > > Piano > > > And then: > > ... > > ...treble staff... > ...bass staff... > > > The other possibility to move instrGrp/instrDef out of the MIDI module and > have them replace instrVoiceGrp/instrVoice. > > Anyone else out there have any ideas? > > -Andrew > > On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: > > I think this problem can be tackled with an @players. @players can be an > attribute of staffGrp and means that the content is played by x > player(s)/instrument(s). It defaults to the amount of staves in the group. > The @players can also be an attribute of staffDef and means that the staff > is performed by x player(s)/instrument(s). It defaults to 1; > @players is required if it's isn't default. > > Would this be possible? > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > On 22 May 2015 at 13:34, Andrew Hankinson > wrote: > >> >> Notating multiple parts on one staff can be done with the layerDef, looks >> good, thanks. >> >> one part on multiple staves is a bit trickier, but can still be done. You >> can use the @staff and @layer attributes on events (chords, notes, rests) >> to "assign" that event to a particular staff and/or layer. >> >> One part on multiple staves is a very common thing (I'm a professional >> pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading >> files, not creating them. I didn't look through all the MEI examples but >> this far I didn't found a single example demonstrating this technique. >> Ruling out all files who don't follow this technique would be a massive >> mistake. >> >> >> I didn't mean to suggest that it's uncommon; I just meant that within the >> confines of XML, dealing with overlapping or crossing hierarchies requires >> a bit of extra semantics. The link I sent you to the cross-staff example >> should be able to give you a start on dealing with cross-staff notation. >> >> >> >> Follow us on: Facebook // Twitter >> >> >> On 22 May 2015 at 09:54, Andrew Hankinson < >> andrew.hankinson at mail.mcgill.ca> wrote: >> >>> >>> On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: >>> >>> Hi Andrew, >>> >>> I see, my subject title is a bit confusing, better would be: How to >>> distinguish different players in the and elements. >>> >>> "If you have two different staves, these are two different players, >>> regardless of the label (a left and a right hand on a piano could be >>> thought of as two different "players" since they're playing two separate >>> parts)." >>> I strongly disagree on that, it is played by a single player and it is a >>> single part. This is even more clear if you think about harp parts, >>> (very often) one 'voice' (strangely called 'layers' in MEI) traveling >>> across 2 staves. >>> >>> >>> But they are independent lines. In theory, you could have two one-handed >>> people playing a piano and it would make no practical difference. :) The >>> voice/layer nomenclature in MEI comes from a desire to separate a melodic >>> line from any idea of "voice leading." (i.e., not wanting to confuse the >>> practical separation of independent instrument lines from the >>> music-theoretical notions of harmonic and melodic progression). >>> >>> Another problem is cross staff notes, in your opinion these are the same >>> as something that would be called 'cross part notes' (since each staff is a >>> part). Think about it, 'cross part notes'... I don't even know any >>> contemporary composer who did this. >>> I think this information should be added to the MEI format, and I think >>> it can be done with an attribute in the staffGrp element indicating that >>> all staves in that group are performed by one player/instrument (or group >>> of players, eg, 1st Violin). >>> >>> >>> Sorry, I'm still not clear on what you are asking. Have you looked at >>> the @instr attribute on staffGrp? Is this what you are looking for? Or is >>> it something else? >>> >>> This way you can keep numbering the staves top to bottom for the whole >>> score, but it's clear which staves are played by the same player/instrument >>> and should be grouped together when playing around with parts. >>> I agree that it needs to be possible to hide a single staff in a part >>> with multiple staves, but semantically spoken it's a big difference with >>> hiding a part. >>> >>> >>> Would the `layerDef` mechanism help clear this up? You can define a >>> specific layer to correspond to a specific voice, in the same way you can >>> define a specific staffDef to define a specific staff. Then you can trace a >>> specific layer ("voice") throughout the work, having pre-defined it in your >>> scoreDef/staffDef block. >>> >>> For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have >>> the percussion instruments on a single staff: >>> >>> >> lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> >>> >>> >>> >>> >>> >>> >>> >>> >>> and then in the body (for example): >>> >>> >>> >>> >>> >> instr="#P18-X2" pnum="61"/> >>> >> instr="#P18-X2" pnum="61"/> >>> >>> >>> >>> >>> >>> >>> >>> >>> At the same time it would be great to have another attribute in the >>> staffDef element indicating that this staff is performed by multiple >>> players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice >>> (again, called layers in MEI). This would be very helpfull in reading some >>> chorus score's to (in the MEI examples this would clear up different parts >>> in Altenburg_Macht_auf_die_Tor). >>> >>> >>> I think the layerDef mechanism will help here too. >>> >>> >>> To be sure we are talking about the same: >>> - staff: needed to notate music >>> - part: music performed by a single player/instrument >>> >>> One part can be notated on multiple staves, multiple parts can be >>> notated on a single staff. For me part is definitely not the same as staff. >>> >>> >>> Multiple parts on a single staff is pretty easy; one part on multiple >>> staves is a bit trickier, but can still be done. You can use the @staff and >>> @layer attributes on events (chords, notes, rests) to "assign" that event >>> to a particular staff and/or layer. >>> >>> See: http://www.verovio.org/examples/features/cross-staff.mei for an >>> example of how this might work (and >>> http://www.verovio.org/features.xhtml?id=cross-staff for a sample >>> rendering). >>> >>> >>> Thanks >>> Hans >>> >>> Hans Vereyken >>> *Developer* >>> >>> M hans at neoscores.com >>> T +32 472 52 75 59 >>> >>> neoScores BVBA // Pluyseghemstraat 19, >>> BE-2550 Kontich // Twitter: @neoscores >>> >>> ///////////////////////////////////////////////////////////////////////////////////////////////////// >>> >>> Follow us on: Facebook // Twitter >>> >>> >>> On 22 May 2015 at 00:58, Andrew Hankinson < >>> andrew.hankinson at mail.mcgill.ca> wrote: >>> >>>> Hi Hans, >>>> >>>> Welcome to MEI! >>>> >>>> Are you looking for the equivalent of the MIDI instrument that would >>>> perform these parts? Or something else? >>>> >>>> If you have two different staves, these are two different players, >>>> regardless of the label (a left and a right hand on a piano could be >>>> thought of as two different "players" since they're playing two separate >>>> parts). If you have a staff that is "hidden" (for example, if you have an >>>> instrument that does not play on certain pages) you still need to define >>>> the staff and give it a number. This number should be constant throughout >>>> the score. If it does not play in a specific place, it will simply not >>>> appear in the measure (as far as I understand it). >>>> >>>> If you're in a renderer and you want to switch all the "n=2" parts off, >>>> then, you would simply hide it whenever you have . The "2" >>>> does not refer to the second staff on any given page; rather, it refers to >>>> the second staff defined in a score, regardless of whether it appears or >>>> not. >>>> >>>> -Andrew >>>> >>>> > On May 21, 2015, at 4:26 PM, Hans Vereyken >>>> wrote: >>>> > >>>> > Hi, >>>> > >>>> > This is my first post to the MEI mailing list. >>>> > I'm implementing MEI into our music renderer and am having trouble >>>> getting all the info I need about staves. >>>> > >>>> > I searches the documentation and mail archives for answers but wasn't >>>> able to find what I'm looking for. >>>> > >>>> > So each staff is declared seperatly, with the certain >>>> groups and there symbols are declared. Although a brace usually means that >>>> the staves within are the same player (e.g. piano brace), it is not enough >>>> to be sure of it. >>>> > >>>> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the >>>> relevant xml: >>>> > >>>> > >>> meter.sym="common" key.sig="0" key.mode="major"> >>>> > >>>> > >>> barthru="true"> >>>> > >>> clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> >>>> > >>> clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> >>>> > >>> clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> >>>> > >>>> > >>> barthru="true"> >>>> > >>> clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" >>>> key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> >>>> > >>> clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> >>>> > >>> label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> >>>> > >>>> > >>>> > >>>> > >>>> > and: Chopin_Etude_op.10_no.9: >>>> > >>>> > >>> key.sig="4f" key.mode="minor"> >>>> > >>>> > >>> lines="5" clef.line="2"/> >>>> > >>> clef.shape="F" lines="5"/> >>>> > >>>> > >>>> > >>>> > So in both cases I have a group of staves with a brace symbol, how >>>> should I know which staves are played by which player. >>>> > I can try to sniff the labels and by guessing the semantic meaning of >>>> 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the >>>> second example this isn't possible, so this won't work (no surprise). >>>> > In a dynamic music renderer, where you can switch parts on/off this >>>> is key information. >>>> > >>>> > How should it be done? Am I missing something? >>>> > >>>> > Thanks in advance! >>>> > Hans Vereyken >>>> > _______________________________________________ >>>> > 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 >> >> > _______________________________________________ > 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 hans at neoscores.com Tue May 26 15:57:10 2015 From: hans at neoscores.com (Hans Vereyken) Date: Tue, 26 May 2015 15:57:10 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> Message-ID: <55647BB6.7000507@neoscores.com> Hi Andrew and Laurent, @Andrew: Yes! thats what I'm after! So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data. So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff. @Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in and should be required if a part isn't one whole staff. Thanks! Hans On 2015-05-26 10:48, Laurent Pugin wrote: > Hi Andrew and Hans, > > This makes sense to me. I guess you would also need to have @instr in > when there is more than one instrument represented in one > staff, wouldn't you? > > Laurent > > On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson > > wrote: > > I think I know what you're trying to do: You're trying to ensure > that a part that gets extracted to the right amount of staves, > correct? That, given an ensemble work that features a piano, your > software does not try to extract two different parts for the right > and left hands of the piano. Correct? > > I believe what you are looking for is in the , > , and cluster of tags. > contains @count which indicates the number of > performers. > > http://www.music-encoding.org/documentation/guidelines2013/instrVoice > > Looking this over I might suggest to move @instr out of the MIDI > module and specify that it should point to an > element, and perhaps do the same and have @instrGrp / > pairs as well. That way you could do: > > > > Violin I > Violin II > Viola > Violoncello > > Piano > > > And then: > > ... > > ...treble staff... > ...bass staff... > > > The other possibility to move instrGrp/instrDef out of the MIDI > module and have them replace instrVoiceGrp/instrVoice. > > Anyone else out there have any ideas? > > -Andrew > >> On May 22, 2015, at 8:01 AM, Hans Vereyken > > wrote: >> >> I think this problem can be tackled with an @players. @players >> can be an attribute of staffGrp and means that the content is >> played by x player(s)/instrument(s). It defaults to the amount of >> staves in the group. >> The @players can also be an attribute of staffDef and means that >> the staff is performed by x player(s)/instrument(s). It defaults >> to 1; >> @players is required if it's isn't default. >> >> Would this be possible? >> >> Hans Vereyken >> *Developer* >> >> M hans at neoscores.com >> T +32 472 52 75 59 >> >> neoScores BVBA // Pluyseghemstraat 19, >> BE-2550 Kontich // Twitter: @neoscores >> ///////////////////////////////////////////////////////////////////////////////////////////////////// >> >> Follow us on: Facebook // >> Twitter >> >> On 22 May 2015 at 13:34, Andrew Hankinson >> > > wrote: >> >> >>> Notating multiple parts on one staff can be done with the >>> layerDef, looks good, thanks. >>> >>> one part on multiple staves is a bit trickier, but can >>> still be done. You can use the @staff and @layer >>> attributes on events (chords, notes, rests) to "assign" >>> that event to a particular staff and/or layer. >>> >>> One part on multiple staves is a very common thing (I'm a >>> professional pianist) and shouldn't be 'a bit trickier'. >>> Besides I'm working on reading files, not creating them. I >>> didn't look through all the MEI examples but this far I >>> didn't found a single example demonstrating this technique. >>> Ruling out all files who don't follow this technique would >>> be a massive mistake. >> >> I didn't mean to suggest that it's uncommon; I just meant >> that within the confines of XML, dealing with overlapping or >> crossing hierarchies requires a bit of extra semantics. The >> link I sent you to the cross-staff example should be able to >> give you a start on dealing with cross-staff notation. >> >> >> >>> Follow us on: Facebook >>> // Twitter >>> >>> >>> On 22 May 2015 at 09:54, Andrew Hankinson >>> >> > wrote: >>> >>> >>>> On May 22, 2015, at 9:16 AM, Hans Vereyken >>>> > wrote: >>>> >>>> Hi Andrew, >>>> >>>> I see, my subject title is a bit confusing, better >>>> would be: How to distinguish different players in >>>> the and elements. >>>> >>>> "If you have two different staves, these are two >>>> different players, regardless of the label (a left and >>>> a right hand on a piano could be thought of as two >>>> different "players" since they're playing two separate >>>> parts)." >>>> I strongly disagree on that, it is played by a single >>>> player and it is a single part. This is even more clear >>>> if you think about harp parts, (very often) one 'voice' >>>> (strangely called 'layers' in MEI) traveling across 2 >>>> staves. >>> >>> But they are independent lines. In theory, you could >>> have two one-handed people playing a piano and it would >>> make no practical difference. :) The voice/layer >>> nomenclature in MEI comes from a desire to separate a >>> melodic line from any idea of "voice leading." (i.e., >>> not wanting to confuse the practical separation of >>> independent instrument lines from the music-theoretical >>> notions of harmonic and melodic progression). >>> >>>> Another problem is cross staff notes, in your opinion >>>> these are the same as something that would be called >>>> 'cross part notes' (since each staff is a part). Think >>>> about it, 'cross part notes'... I don't even know any >>>> contemporary composer who did this. >>>> I think this information should be added to the MEI >>>> format, and I think it can be done with an attribute in >>>> the staffGrp element indicating that all staves in that >>>> group are performed by one player/instrument (or group >>>> of players, eg, 1st Violin). >>> >>> Sorry, I'm still not clear on what you are asking. Have >>> you looked at the @instr attribute on staffGrp? Is this >>> what you are looking for? Or is it something else? >>> >>>> This way you can keep numbering the staves top to >>>> bottom for the whole score, but it's clear which >>>> staves are played by the same player/instrument and >>>> should be grouped together when playing around with parts. >>>> I agree that it needs to be possible to hide a single >>>> staff in a part with multiple staves, >>>> but semantically spoken it's a big difference with >>>> hiding a part. >>> >>> Would the `layerDef` mechanism help clear this up? You >>> can define a specific layer to correspond to a specific >>> voice, in the same way you can define a specific >>> staffDef to define a specific staff. Then you can trace >>> a specific layer ("voice") throughout the work, having >>> pre-defined it in your scoreDef/staffDef block. >>> >>> For an example, see the Ponchielli_LarrivoDelRe.mei >>> file, where you have the percussion instruments on a >>> single staff: >>> >>> >> label.abbr="Batt." lines="1" clef.shape="perc" >>> key.sig="4f" key.mode="major" spacing="117"> >>> >>> >>> >>> >>> >>> >>> >>> >>> and then in the body (for example): >>> >>> >>> >>> >>> >> stem.dir="up" >>> instr="#P18-X2" pnum="61"/> >>> >> stem.dir="up" >>> instr="#P18-X2" pnum="61"/> >>> >>> >>> >>> >>> >>> >>> >>>> >>>> At the same time it would be great to have another >>>> attribute in the staffDef element indicating that this >>>> staff is performed by multiple players, for instance >>>> 1st and 2nd Violins are notated as 1st and 2nd voice >>>> (again, called layers in MEI). This would be very >>>> helpfull in reading some chorus score's to (in the MEI >>>> examples this would clear up different parts >>>> in Altenburg_Macht_auf_die_Tor). >>> >>> I think the layerDef mechanism will help here too. >>> >>>> >>>> To be sure we are talking about the same: >>>> - staff: needed to notate music >>>> - part: music performed by a single player/instrument >>>> >>>> One part can be notated on multiple staves, multiple >>>> parts can be notated on a single staff. For me part is >>>> definitely not the same as staff. >>> >>> Multiple parts on a single staff is pretty easy; one >>> part on multiple staves is a bit trickier, but can still >>> be done. You can use the @staff and @layer attributes on >>> events (chords, notes, rests) to "assign" that event to >>> a particular staff and/or layer. >>> >>> See: >>> http://www.verovio.org/examples/features/cross-staff.mei >>> for an example of how this might work (and >>> http://www.verovio.org/features.xhtml?id=cross-staff for >>> a sample rendering). >>> >>>> >>>> Thanks >>>> Hans >>>> >>>> Hans Vereyken >>>> *Developer* >>>> >>>> M hans at neoscores.com >>>> T +32 472 52 75 59 >>>> >>>> neoScores BVBA // >>>> Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores >>>> ///////////////////////////////////////////////////////////////////////////////////////////////////// >>>> >>>> Follow us on: Facebook >>>> // Twitter >>>> >>>> >>>> On 22 May 2015 at 00:58, Andrew Hankinson >>>> >>> > wrote: >>>> >>>> Hi Hans, >>>> >>>> Welcome to MEI! >>>> >>>> Are you looking for the equivalent of the MIDI >>>> instrument that would perform these parts? Or >>>> something else? >>>> >>>> If you have two different staves, these are two >>>> different players, regardless of the label (a left >>>> and a right hand on a piano could be thought of as >>>> two different "players" since they're playing two >>>> separate parts). If you have a staff that is >>>> "hidden" (for example, if you have an instrument >>>> that does not play on certain pages) you still need >>>> to define the staff and give it a number. This >>>> number should be constant throughout the score. If >>>> it does not play in a specific place, it will >>>> simply not appear in the measure (as far as I >>>> understand it). >>>> >>>> If you're in a renderer and you want to switch all >>>> the "n=2" parts off, then, you would simply hide it >>>> whenever you have . The "2" does >>>> not refer to the second staff on any given page; >>>> rather, it refers to the second staff defined in a >>>> score, regardless of whether it appears or not. >>>> >>>> -Andrew >>>> >>>> > On May 21, 2015, at 4:26 PM, Hans Vereyken >>>> > wrote: >>>> > >>>> > Hi, >>>> > >>>> > This is my first post to the MEI mailing list. >>>> > I'm implementing MEI into our music renderer and >>>> am having trouble getting all the info I need about >>>> staves. >>>> > >>>> > I searches the documentation and mail archives >>>> for answers but wasn't able to find what I'm >>>> looking for. >>>> > >>>> > So each staff is declared seperatly, with the >>>> certain groups and there symbols are >>>> declared. Although a brace usually means that the >>>> staves within are the same player (e.g. piano >>>> brace), it is not enough to be sure of it. >>>> > >>>> > In the example files I looked at >>>> 'Altenburg_Ein_feste_Burg', the relevant xml: >>>> > >>>> > >>> meter.sym="common" key.sig="0" key.mode="major"> >>>> > >>>> > >>>> > >>> key.sig="0" lines="5" label="Trompete 1" >>>> label.abbr="Tr 1"/> >>>> > >>> key.sig="0" lines="5" label="Trompete 2" >>>> label.abbr="Tr 2"/> >>>> > >>> key.sig="0" lines="5" label="Trompete 3" >>>> label.abbr="Tr 3"/> >>>> > >>>> > >>>> > >>> clef.dis.place="below" clef.line="2" label="Pos1 >>>> Tro 4" key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> >>>> > >>> lines="5" key.sig="0" label="Posaune 2" >>>> label.abbr="Pos 2"/> >>>> > >>> label.abbr="Pos 3" clef.line="4" clef.shape="F" >>>> key.sig="0" lines="5"/> >>>> > >>>> > >>>> > >>>> > >>>> > and: Chopin_Etude_op.10_no.9: >>>> > >>>> > >>> key.sig="4f" key.mode="minor"> >>>> > >>>> > >>> clef.line="2"/> >>>> > >>> lines="5"/> >>>> > >>>> > >>>> > >>>> > So in both cases I have a group of staves with a >>>> brace symbol, how should I know which staves are >>>> played by which player. >>>> > I can try to sniff the labels and by guessing the >>>> semantic meaning of 'Trompete 1,2,3' and conclude >>>> these has to be 3 different parts. In the second >>>> example this isn't possible, so this won't work (no >>>> surprise). >>>> > In a dynamic music renderer, where you can switch >>>> parts on/off this is key information. >>>> > >>>> > How should it be done? Am I missing something? >>>> > >>>> > Thanks in advance! >>>> > Hans Vereyken >>>> > _______________________________________________ >>>> > 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 >> >> >> _______________________________________________ >> 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 ------------- volgend deel ------------ Een HTML-bijlage is gescrubt... URL: From raffaeleviglianti at gmail.com Tue May 26 16:57:59 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 26 May 2015 10:57:59 -0400 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: <55647BB6.7000507@neoscores.com> References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: Hi Hans, Thanks for joining MEI-L and for starting this interesting conversation! Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid. Having said that, though, I am a bit surprised to see an element like , which groups user-defined symbols, be contained by , while is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding? Finally, it might be useful to look at as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common. Raff On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken wrote: > Hi Andrew and Laurent, > > @Andrew: Yes! thats what I'm after! > So now I can see how I can read it (if the information is there). I'm a > bit surprised by location of this information in an mei file. I think this > information shouldn't be in the meta-data part of the file, this is > content, I expected to find this info somewhere inside the 'music' element. > I clicked trough some example files and found that the @instr and @instrGrp > aren't used, so I'm still stuck. I know now how a file can be created in a > way this info is clear, but I'm interesting in reading files. And I'm still > confident this info should (also) be inside the music element, it's > semantical data, not meta-data. > > So I think it would be good to have a system to make this more clear. And > to rule out any ambiguity this system should be required for any part using > more than one staff. > > @Laurent: yes! would be great, but like I said above, I think this > actually isn't meta-data. And Also, this @instr in and > should be required if a part isn't one whole staff. > > Thanks! > Hans > > > On 2015-05-26 10:48, Laurent Pugin wrote: > > Hi Andrew and Hans, > > This makes sense to me. I guess you would also need to have @instr in > when there is more than one instrument represented in one staff, > wouldn't you? > > Laurent > > On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > >> I think I know what you're trying to do: You're trying to ensure that a >> part that gets extracted to the right amount of staves, correct? That, >> given an ensemble work that features a piano, your software does not try to >> extract two different parts for the right and left hands of the piano. >> Correct? >> >> I believe what you are looking for is in the , >> , and cluster of tags. >> contains @count which indicates the number of performers. >> >> http://www.music-encoding.org/documentation/guidelines2013/instrVoice >> >> Looking this over I might suggest to move @instr out of the MIDI module >> and specify that it should point to an element, and perhaps do >> the same and have @instrGrp / pairs as well. That way you could >> do: >> >> >> >> Violin I >> Violin II >> Viola >> Violoncello >> >> Piano >> >> >> And then: >> >> ... >> >> ...treble staff... >> ...bass staff... >> >> >> The other possibility to move instrGrp/instrDef out of the MIDI module >> and have them replace instrVoiceGrp/instrVoice. >> >> Anyone else out there have any ideas? >> >> -Andrew >> >> On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: >> >> I think this problem can be tackled with an @players. @players can be >> an attribute of staffGrp and means that the content is played by x >> player(s)/instrument(s). It defaults to the amount of staves in the group. >> The @players can also be an attribute of staffDef and means that the >> staff is performed by x player(s)/instrument(s). It defaults to 1; >> @players is required if it's isn't default. >> >> Would this be possible? >> >> Hans Vereyken >> *Developer* >> >> M hans at neoscores.com >> T +32 472 52 75 59 >> >> neoScores BVBA // Pluyseghemstraat 19, >> BE-2550 Kontich // Twitter: @neoscores >> >> ///////////////////////////////////////////////////////////////////////////////////////////////////// >> >> Follow us on: Facebook // Twitter >> >> >> On 22 May 2015 at 13:34, Andrew Hankinson < >> andrew.hankinson at mail.mcgill.ca> wrote: >> >>> >>> Notating multiple parts on one staff can be done with the layerDef, >>> looks good, thanks. >>> >>> one part on multiple staves is a bit trickier, but can still be >>> done. You can use the @staff and @layer attributes on events (chords, >>> notes, rests) to "assign" that event to a particular staff and/or layer. >>> >>> One part on multiple staves is a very common thing (I'm a >>> professional pianist) and shouldn't be 'a bit trickier'. Besides I'm >>> working on reading files, not creating them. I didn't look through all the >>> MEI examples but this far I didn't found a single example demonstrating >>> this technique. Ruling out all files who don't follow this technique would >>> be a massive mistake. >>> >>> >>> I didn't mean to suggest that it's uncommon; I just meant that within >>> the confines of XML, dealing with overlapping or crossing hierarchies >>> requires a bit of extra semantics. The link I sent you to the cross-staff >>> example should be able to give you a start on dealing with cross-staff >>> notation. >>> >>> >>> >>> Follow us on: Facebook // Twitter >>> >>> >>> On 22 May 2015 at 09:54, Andrew Hankinson < >>> andrew.hankinson at mail.mcgill.ca> wrote: >>> >>>> >>>> On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: >>>> >>>> Hi Andrew, >>>> >>>> I see, my subject title is a bit confusing, better would be: How to >>>> distinguish different players in the and elements. >>>> >>>> "If you have two different staves, these are two different players, >>>> regardless of the label (a left and a right hand on a piano could be >>>> thought of as two different "players" since they're playing two separate >>>> parts)." >>>> I strongly disagree on that, it is played by a single player and it >>>> is a single part. This is even more clear if you think about harp parts, >>>> (very often) one 'voice' (strangely called 'layers' in MEI) traveling >>>> across 2 staves. >>>> >>>> >>>> But they are independent lines. In theory, you could have two >>>> one-handed people playing a piano and it would make no practical >>>> difference. :) The voice/layer nomenclature in MEI comes from a desire to >>>> separate a melodic line from any idea of "voice leading." (i.e., not >>>> wanting to confuse the practical separation of independent instrument lines >>>> from the music-theoretical notions of harmonic and melodic progression). >>>> >>>> Another problem is cross staff notes, in your opinion these are the >>>> same as something that would be called 'cross part notes' (since each staff >>>> is a part). Think about it, 'cross part notes'... I don't even know any >>>> contemporary composer who did this. >>>> I think this information should be added to the MEI format, and I think >>>> it can be done with an attribute in the staffGrp element indicating that >>>> all staves in that group are performed by one player/instrument (or group >>>> of players, eg, 1st Violin). >>>> >>>> >>>> Sorry, I'm still not clear on what you are asking. Have you looked at >>>> the @instr attribute on staffGrp? Is this what you are looking for? Or is >>>> it something else? >>>> >>>> This way you can keep numbering the staves top to bottom for the >>>> whole score, but it's clear which staves are played by the same >>>> player/instrument and should be grouped together when playing around with >>>> parts. >>>> I agree that it needs to be possible to hide a single staff in a part >>>> with multiple staves, but semantically spoken it's a big difference with >>>> hiding a part. >>>> >>>> >>>> Would the `layerDef` mechanism help clear this up? You can define a >>>> specific layer to correspond to a specific voice, in the same way you can >>>> define a specific staffDef to define a specific staff. Then you can trace a >>>> specific layer ("voice") throughout the work, having pre-defined it in your >>>> scoreDef/staffDef block. >>>> >>>> For an example, see the Ponchielli_LarrivoDelRe.mei file, where you >>>> have the percussion instruments on a single staff: >>>> >>>> >>> lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> and then in the body (for example): >>>> >>>> >>>> >>>> >>>> >>> instr="#P18-X2" pnum="61"/> >>>> >>> instr="#P18-X2" pnum="61"/> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> At the same time it would be great to have another attribute in the >>>> staffDef element indicating that this staff is performed by multiple >>>> players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice >>>> (again, called layers in MEI). This would be very helpfull in reading some >>>> chorus score's to (in the MEI examples this would clear up different parts >>>> in Altenburg_Macht_auf_die_Tor). >>>> >>>> >>>> I think the layerDef mechanism will help here too. >>>> >>>> >>>> To be sure we are talking about the same: >>>> - staff: needed to notate music >>>> - part: music performed by a single player/instrument >>>> >>>> One part can be notated on multiple staves, multiple parts can be >>>> notated on a single staff. For me part is definitely not the same as staff. >>>> >>>> >>>> Multiple parts on a single staff is pretty easy; one part on multiple >>>> staves is a bit trickier, but can still be done. You can use the @staff and >>>> @layer attributes on events (chords, notes, rests) to "assign" that event >>>> to a particular staff and/or layer. >>>> >>>> See: http://www.verovio.org/examples/features/cross-staff.mei for an >>>> example of how this might work (and >>>> http://www.verovio.org/features.xhtml?id=cross-staff for a sample >>>> rendering). >>>> >>>> >>>> Thanks >>>> Hans >>>> >>>> Hans Vereyken >>>> *Developer* >>>> >>>> M hans at neoscores.com >>>> T +32 472 52 75 59 >>>> >>>> neoScores BVBA // Pluyseghemstraat 19, >>>> BE-2550 Kontich // Twitter: @neoscores >>>> >>>> ///////////////////////////////////////////////////////////////////////////////////////////////////// >>>> >>>> Follow us on: Facebook // Twitter >>>> >>>> >>>> On 22 May 2015 at 00:58, Andrew Hankinson < >>>> andrew.hankinson at mail.mcgill.ca> wrote: >>>> >>>>> Hi Hans, >>>>> >>>>> Welcome to MEI! >>>>> >>>>> Are you looking for the equivalent of the MIDI instrument that would >>>>> perform these parts? Or something else? >>>>> >>>>> If you have two different staves, these are two different players, >>>>> regardless of the label (a left and a right hand on a piano could be >>>>> thought of as two different "players" since they're playing two separate >>>>> parts). If you have a staff that is "hidden" (for example, if you have an >>>>> instrument that does not play on certain pages) you still need to define >>>>> the staff and give it a number. This number should be constant throughout >>>>> the score. If it does not play in a specific place, it will simply not >>>>> appear in the measure (as far as I understand it). >>>>> >>>>> If you're in a renderer and you want to switch all the "n=2" parts >>>>> off, then, you would simply hide it whenever you have . >>>>> The "2" does not refer to the second staff on any given page; rather, it >>>>> refers to the second staff defined in a score, regardless of whether it >>>>> appears or not. >>>>> >>>>> -Andrew >>>>> >>>>> > On May 21, 2015, at 4:26 PM, Hans Vereyken >>>>> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > This is my first post to the MEI mailing list. >>>>> > I'm implementing MEI into our music renderer and am having trouble >>>>> getting all the info I need about staves. >>>>> > >>>>> > I searches the documentation and mail archives for answers but >>>>> wasn't able to find what I'm looking for. >>>>> > >>>>> > So each staff is declared seperatly, with the certain >>>>> groups and there symbols are declared. Although a brace usually means that >>>>> the staves within are the same player (e.g. piano brace), it is not enough >>>>> to be sure of it. >>>>> > >>>>> > In the example files I looked at 'Altenburg_Ein_feste_Burg', the >>>>> relevant xml: >>>>> > >>>>> > >>>> meter.sym="common" key.sig="0" key.mode="major"> >>>>> > >>>>> > >>>> barthru="true"> >>>>> > >>>> clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> >>>>> > >>>> clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> >>>>> > >>>> clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> >>>>> > >>>>> > >>>> barthru="true"> >>>>> > >>>> clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" >>>>> key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> >>>>> > >>>> clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > and: Chopin_Etude_op.10_no.9: >>>>> > >>>>> > >>>> key.sig="4f" key.mode="minor"> >>>>> > >>>>> > >>>> lines="5" clef.line="2"/> >>>>> > >>>> clef.shape="F" lines="5"/> >>>>> > >>>>> > >>>>> > >>>>> > So in both cases I have a group of staves with a brace symbol, how >>>>> should I know which staves are played by which player. >>>>> > I can try to sniff the labels and by guessing the semantic meaning >>>>> of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the >>>>> second example this isn't possible, so this won't work (no surprise). >>>>> > In a dynamic music renderer, where you can switch parts on/off this >>>>> is key information. >>>>> > >>>>> > How should it be done? Am I missing something? >>>>> > >>>>> > Thanks in advance! >>>>> > Hans Vereyken >>>>> > _______________________________________________ >>>>> > 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 >>> >>> >> _______________________________________________ >> 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 listmei-l at lists.uni-paderborn.dehttps://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 Wed May 27 00:39:15 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 26 May 2015 22:39:15 +0000 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: Hi, There is no ?promotion? or ?demotion? between what is considered data and what is thought of as metadata -- there is only ?separation?. exists within in order to allow differing sets of symbols to be associated at multiple points within the tree. For example, movements of a multi-movement work need not refer to a single set of symbol definitions. This makes it possible for a movement (or similar segment) to be more independent (i.e., separable) and permit software to load/track/account for only those symbols necessary to process/render the symbols associated with the segment. While the data captured by is intended to be transcriptional in nature, is placed within the header (as a child of ) because it primarily serves a documentary purpose. Its data model is based on metadata standards (mainly MARC) and it is a member of attribute classes that place it squarely in the bibliographic realm. The blending of instrVoice, etc. and staffGrp, etc. would blur the distinction (a useful one, I believe) between these 2 functions. I second Raffaele?s suggestion of exploring the potential of the element. If the conceptual model of the ?score? is a collection of parts, then instead of trying to extract the part-level information from data within , why not store the data using elements in the first place? So that physically-separate and logical parts can be distinguished, it would be useful to add an attribute on to capture whether the parts are physical or logical. While MEI can be used as a format for notation editors (and I sincerely hope it will be), I urge caution not to focus on this particular application of it too much. Requirements for this (and other applications) are good candidates for Schematron assertions applied on top of the baseline rules. Requiring @instr is a good example of the kind of contextual constraint that Schematron is designed for. It is fitting that attention also be given to the tradition/convention that staves joined by a bracket are independent instruments, while those joined by a brace represent a single instrument. A group of staves joined by a brace (such as those for the piano) should be considered a single "part". A group of staves joined by a bracket (unless there's a further sub-grouping using a brace) represents separate parts. (The major exception is the organ, where the staff for the pedals is not included in the brace that joins the staves for the manuals. Manuscript notation might also violate the traditional "rule" regarding the function of brackets and braces.) The issue of separate parts written on a single staff can be handled, as Andrew has suggested, by using elements. The generation of parts from a score could also be thought of as an interactive/transformative process that doesn?t need to be explicitly marked in the XML. For example, why shouldn?t software offer the possibility of creating a ?part? from any combination of staves/layers the user selects? I believe a user interested in creating a piano or organ part would select the appropriate staves. And the user might even want to create specialized parts, for example, combining the flute and tuba staves because these two players are expected to sit next to each other. ? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, May 26, 2015 10:58 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Hans, Thanks for joining MEI-L and for starting this interesting conversation! Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid. Having said that, though, I am a bit surprised to see an element like , which groups user-defined symbols, be contained by , while is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding? Finally, it might be useful to look at as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common. Raff On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken > wrote: Hi Andrew and Laurent, @Andrew: Yes! thats what I'm after! So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data. So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff. @Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in and should be required if a part isn't one whole staff. Thanks! Hans On 2015-05-26 10:48, Laurent Pugin wrote: Hi Andrew and Hans, This makes sense to me. I guess you would also need to have @instr in when there is more than one instrument represented in one staff, wouldn't you? Laurent On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson > wrote: I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct? I believe what you are looking for is in the , , and cluster of tags. contains @count which indicates the number of performers. http://www.music-encoding.org/documentation/guidelines2013/instrVoice Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an element, and perhaps do the same and have @instrGrp / pairs as well. That way you could do: Violin I Violin II Viola Violoncello Piano And then: ... ...treble staff... ...bass staff... The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice. Anyone else out there have any ideas? -Andrew On May 22, 2015, at 8:01 AM, Hans Vereyken > wrote: I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; @players is required if it's isn't default. Would this be possible? Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 13:34, Andrew Hankinson > wrote: Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. Follow us on: Facebook // Twitter On 22 May 2015 at 09:54, Andrew Hankinson > wrote: On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: Hi Andrew, I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: and then in the body (for example): At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). I think the layerDef mechanism will help here too. To be sure we are talking about the same: - staff: needed to notate music - part: music performed by a single player/instrument One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). Thanks Hans Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 00:58, Andrew Hankinson > wrote: Hi Hans, Welcome to MEI! Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. -Andrew > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: > > Hi, > > This is my first post to the MEI mailing list. > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > In a dynamic music renderer, where you can switch parts on/off this is key information. > > How should it be done? Am I missing something? > > Thanks in advance! > Hans Vereyken > _______________________________________________ > 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 _______________________________________________ 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 lxpugin at gmail.com Wed May 27 09:27:52 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 27 May 2015 09:27:52 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: Hi Perry, I am not sure I understand what you think of Andrew's proposal to take @instr out of the MIDI module. Does this seem a valid approach to you? I think it would be nice to have a way to encode parts in a score-based organization in more precise way than we can now. This might serve parts extraction but other purposes. The use of seems to serve a different purpose to me, which is to encode material in parts when no score is available/desired. As you pointed out, we cannot rely on brackets and braces for this, so I also have the impression we need something more. What Hans pointed out is that currently it would not be easy to extract a piano part (by itself or with another one) precisely because what the piano part is not clearly specified. Laurent On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Hi, > > > > There is no ?promotion? or ?demotion? between what is considered data and > what is thought of as metadata -- there is only ?separation?. > > > > exists within in order to allow differing sets of > symbols to be associated at multiple points within the tree. For > example, movements of a multi-movement work need not refer to a single set > of symbol definitions. This makes it possible for a movement (or similar > segment) to be more independent (i.e., separable) and permit software to > load/track/account for only those symbols necessary to process/render the > symbols associated with the segment. > > > > While the data captured by is intended to be transcriptional in > nature, is placed within the header (as a child of > ) because it primarily serves a documentary purpose. Its data > model is based on metadata standards (mainly MARC) and it is a member of > attribute classes that place it squarely in the bibliographic realm. The > blending of instrVoice, etc. and staffGrp, etc. would blur the distinction > (a useful one, I believe) between these 2 functions. > > > > I second Raffaele?s suggestion of exploring the potential of the > element. If the conceptual model of the ?score? is a collection of parts, > then instead of trying to extract the part-level information from data > within , why not store the data using elements in the first > place? So that physically-separate and logical parts can be distinguished, > it would be useful to add an attribute on to capture whether the > parts are physical or logical. > > > > While MEI can be used as a format for notation editors (and I sincerely > hope it will be), I urge caution not to focus on this particular > application of it too much. Requirements for this (and other applications) > are good candidates for Schematron assertions applied on top of the > baseline rules. Requiring @instr is a good example of the kind of > contextual constraint that Schematron is designed for. > > > > It is fitting that attention also be given to the tradition/convention > that staves joined by a bracket are independent instruments, while those > joined by a brace represent a single instrument. A group of staves joined > by a brace (such as those for the piano) should be considered a single > "part". A group of staves joined by a bracket (unless there's a further > sub-grouping using a brace) represents separate parts. (The major > exception is the organ, where the staff for the pedals is not included in > the brace that joins the staves for the manuals. Manuscript notation might > also violate the traditional "rule" regarding the function of brackets and > braces.) The issue of separate parts written on a single staff can be > handled, as Andrew has suggested, by using elements. > > > > The generation of parts from a score could also be thought of as an > interactive/transformative process that doesn?t need to be explicitly > marked in the XML. For example, why shouldn?t software offer the > possibility of creating a ?part? from any combination of staves/layers the > user selects? I believe a user interested in creating a piano or organ > part would select the appropriate staves. And the user might even want to > create specialized parts, for example, combining the flute and tuba staves > because these two players are expected to sit next to each other. J > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, May 26, 2015 10:58 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > Hi Hans, > > Thanks for joining MEI-L and for starting this interesting conversation! > > > Andrew, I think your solution is the correct answer. I agree that this is > "musical" information and may seem to not be appropriately located in the > header. However, the header is not just metadata, it is also a useful place > to define information that is re-used throughout the score. The header is > fundamental to parse the music content of an MEI file, which is why it is > required for an MEI file to be valid. > > Having said that, though, I am a bit surprised to see an element like > , which groups user-defined symbols, be contained by > , while is in the header. I would have expected > symbols to be defined in the header too - why are they promoted (or > demoted?) to the score definition? Why do instrument and symbol definition > belong to different areas of the encoding? > > Finally, it might be useful to look at as well, a powerful element > that is underused at the moment, IMO. It allows to re-define the score from > the perspective of one performer (or group of performers) and it allows to > do some nifty things when it comes to adjusting parts when going from an > orchestral score to separate parts. But maybe this is a different > discussion since you're interested in reading MEI and use of this element > is not common. > > > > Raff > > > > > > On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken wrote: > > Hi Andrew and Laurent, > > @Andrew: Yes! thats what I'm after! > So now I can see how I can read it (if the information is there). I'm a > bit surprised by location of this information in an mei file. I think this > information shouldn't be in the meta-data part of the file, this is > content, I expected to find this info somewhere inside the 'music' element. > I clicked trough some example files and found that the @instr and @instrGrp > aren't used, so I'm still stuck. I know now how a file can be created in a > way this info is clear, but I'm interesting in reading files. And I'm still > confident this info should (also) be inside the music element, it's > semantical data, not meta-data. > > So I think it would be good to have a system to make this more clear. And > to rule out any ambiguity this system should be required for any part using > more than one staff. > > @Laurent: yes! would be great, but like I said above, I think this > actually isn't meta-data. And Also, this @instr in and > should be required if a part isn't one whole staff. > > Thanks! > Hans > > > > On 2015-05-26 10:48, Laurent Pugin wrote: > > Hi Andrew and Hans, > > > > This makes sense to me. I guess you would also need to have @instr in > when there is more than one instrument represented in one staff, > wouldn't you? > > > > Laurent > > > > On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > > I think I know what you're trying to do: You're trying to ensure that a > part that gets extracted to the right amount of staves, correct? That, > given an ensemble work that features a piano, your software does not try to > extract two different parts for the right and left hands of the piano. > Correct? > > > > I believe what you are looking for is in the , > , and cluster of tags. > contains @count which indicates the number of performers. > > > > http://www.music-encoding.org/documentation/guidelines2013/instrVoice > > > > Looking this over I might suggest to move @instr out of the MIDI module > and specify that it should point to an element, and perhaps do > the same and have @instrGrp / pairs as well. That way you could > do: > > > > > > > Violin I > Violin II > Viola > Violoncello > > > > Piano > > > > > And then: > > > > ... > > > > ...treble staff... > > ...bass staff... > > > > > > The other possibility to move instrGrp/instrDef out of the MIDI module and > have them replace instrVoiceGrp/instrVoice. > > > > Anyone else out there have any ideas? > > > > -Andrew > > > > On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: > > > > I think this problem can be tackled with an @players. @players can be an > attribute of staffGrp and means that the content is played by x > player(s)/instrument(s). It defaults to the amount of staves in the group. > > The @players can also be an attribute of staffDef and means that the staff > is performed by x player(s)/instrument(s). It defaults to 1; > > @players is required if it's isn't default. > > > > Would this be possible? > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 13:34, Andrew Hankinson > wrote: > > > > Notating multiple parts on one staff can be done with the layerDef, > looks good, thanks. > > > > one part on multiple staves is a bit trickier, but can still be done. > You can use the @staff and @layer attributes on events (chords, notes, > rests) to "assign" that event to a particular staff and/or layer. > > > > One part on multiple staves is a very common thing (I'm a professional > pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading > files, not creating them. I didn't look through all the MEI examples but > this far I didn't found a single example demonstrating this technique. > Ruling out all files who don't follow this technique would be a massive > mistake. > > > > I didn't mean to suggest that it's uncommon; I just meant that within the > confines of XML, dealing with overlapping or crossing hierarchies requires > a bit of extra semantics. The link I sent you to the cross-staff example > should be able to give you a start on dealing with cross-staff notation. > > > > > > > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 09:54, Andrew Hankinson > wrote: > > > > On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: > > > > Hi Andrew, > > > > I see, my subject title is a bit confusing, better would be: How to > distinguish different players in the and elements. > > > > "If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts)." > > I strongly disagree on that, it is played by a single player and it is a > single part. This is even more clear if you think about harp parts, > (very often) one 'voice' (strangely called 'layers' in MEI) traveling > across 2 staves. > > > > But they are independent lines. In theory, you could have two one-handed > people playing a piano and it would make no practical difference. :) The > voice/layer nomenclature in MEI comes from a desire to separate a melodic > line from any idea of "voice leading." (i.e., not wanting to confuse the > practical separation of independent instrument lines from the > music-theoretical notions of harmonic and melodic progression). > > > > Another problem is cross staff notes, in your opinion these are the > same as something that would be called 'cross part notes' (since each staff > is a part). Think about it, 'cross part notes'... I don't even know any > contemporary composer who did this. > > I think this information should be added to the MEI format, and I think it > can be done with an attribute in the staffGrp element indicating that all > staves in that group are performed by one player/instrument (or group of > players, eg, 1st Violin). > > > > Sorry, I'm still not clear on what you are asking. Have you looked at the > @instr attribute on staffGrp? Is this what you are looking for? Or is it > something else? > > > > This way you can keep numbering the staves top to bottom for the > whole score, but it's clear which staves are played by the same > player/instrument and should be grouped together when playing around with > parts. > > I agree that it needs to be possible to hide a single staff in a part with > multiple staves, but semantically spoken it's a big difference with hiding > a part. > > > > Would the `layerDef` mechanism help clear this up? You can define a > specific layer to correspond to a specific voice, in the same way you can > define a specific staffDef to define a specific staff. Then you can trace a > specific layer ("voice") throughout the work, having pre-defined it in your > scoreDef/staffDef block. > > > > For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have > the percussion instruments on a single staff: > > > > lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> > > > > > > > > > > > > > > > > > > and then in the body (for example): > > > > > > > instr="#P18-X2" pnum="61"/> > instr="#P18-X2" pnum="61"/> > > > > > > > > > > > > At the same time it would be great to have another attribute in the > staffDef element indicating that this staff is performed by multiple > players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice > (again, called layers in MEI). This would be very helpfull in reading some > chorus score's to (in the MEI examples this would clear up different parts > in Altenburg_Macht_auf_die_Tor). > > > > I think the layerDef mechanism will help here too. > > > > > > To be sure we are talking about the same: > > - staff: needed to notate music > > - part: music performed by a single player/instrument > > > > One part can be notated on multiple staves, multiple parts can be notated > on a single staff. For me part is definitely not the same as staff. > > > > Multiple parts on a single staff is pretty easy; one part on multiple > staves is a bit trickier, but can still be done. You can use the @staff and > @layer attributes on events (chords, notes, rests) to "assign" that event > to a particular staff and/or layer. > > > > See: http://www.verovio.org/examples/features/cross-staff.mei for an > example of how this might work (and > http://www.verovio.org/features.xhtml?id=cross-staff for a sample > rendering). > > > > > > Thanks > > Hans > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 00:58, Andrew Hankinson > wrote: > > Hi Hans, > > Welcome to MEI! > > Are you looking for the equivalent of the MIDI instrument that would > perform these parts? Or something else? > > If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts). If you have a staff that is "hidden" (for example, if you have an > instrument that does not play on certain pages) you still need to define > the staff and give it a number. This number should be constant throughout > the score. If it does not play in a specific place, it will simply not > appear in the measure (as far as I understand it). > > If you're in a renderer and you want to switch all the "n=2" parts off, > then, you would simply hide it whenever you have . The "2" > does not refer to the second staff on any given page; rather, it refers to > the second staff defined in a score, regardless of whether it appears or > not. > > -Andrew > > > > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: > > > > Hi, > > > > This is my first post to the MEI mailing list. > > I'm implementing MEI into our music renderer and am having trouble > getting all the info I need about staves. > > > > I searches the documentation and mail archives for answers but wasn't > able to find what I'm looking for. > > > > So each staff is declared seperatly, with the certain groups > and there symbols are declared. Although a brace usually means that the > staves within are the same player (e.g. piano brace), it is not enough to > be sure of it. > > > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the > relevant xml: > > > > meter.sym="common" key.sig="0" key.mode="major"> > > > > > > clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> > > > > barthru="true"> > > clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" > key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> > > clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> > > label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > key.sig="4f" key.mode="minor"> > > > > clef.line="2"/> > > clef.shape="F" lines="5"/> > > > > > > > > So in both cases I have a group of staves with a brace symbol, how > should I know which staves are played by which player. > > I can try to sniff the labels and by guessing the semantic meaning of > 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the > second example this isn't possible, so this won't work (no surprise). > > In a dynamic music renderer, where you can switch parts on/off this is > key information. > > > > How should it be done? Am I missing something? > > > > Thanks in advance! > > Hans Vereyken > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 pdr4h at eservices.virginia.edu Wed May 27 23:00:26 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 27 May 2015 21:00:26 +0000 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: I support the intention/motivation of the proposal, but it raises some issues: Moving out of the MIDI module doesn?t comply with its current definition because provides a description of a *MIDI instrument*, not a generic instrument. That role is handled somewhat by , but, as already noted, because is a child of , which has a descriptive function and is placed within , pointing to it could be problematic. Also, if @instr pointed to , the info provided by would be orphaned/inaccessible. The attributes provided by could be moved to or duplicated on , but moving them would create a backward compatibility problem and duplicating them would create a processing problem (that is, the same data could potentially be recorded in multiple locations). Since there are potentially overlapping hierarchies, I believe that the staff, part, and instrument entities should be independent of each other. Using @instr in the way suggested by the proposal creates too close an association between part and instrument concepts. How, for example, would doubling (one performer playing multiple instruments from a single printed part) be accounted for? A potential solution is to employ for the part-organizing concept, not just a physical part. By adding an attribute to , can be used to capture both physical and conceptual parts. In essence, we get *part-based markup of the score* for free. Since I?ve spent so much time emphasizing it, I get your point of view that a element can ONLY represent a physically independent thing in MEI. But, that was mostly a way to make sure that everyone got the idea that parts are *independent* of the score, not *components* of the score as in MusicXML. Physical and conceptual parts can maintain this independence even while using the same element. For example, represents a set of physically separate parts, each with its own staff definitions, MIDI instrument assignment, and, as an additional bonus, its own layout parameters. Changing @form to ?logical? allows the same markup to function as a part-wise representation of the score (to borrow a term from MusicXML). In this case, any layout parameters would be ignored in favor of those provided within and its descendants. On the other hand, if the grouping of the staves of a score into parts is our only goal, then another, much simpler approach is possible. Adding @part on permits the grouping of staves into parts independently of the grouping provided by . For example, And the association of staves with MIDI instruments is also preserved. If the keyboard accompaniment is for organ instead of piano, the following markup can be used -- Note the placement of the instrument definition for the organ to indicate that all 3 staves should be played using the same patch. And if there are 2 tubas (both written on the same staff) -- One more possibility -- use @part on and to indicate that the staff or staff descendants of the group bearing this attribute constitute a distinct part. In this case, @part functions as a marker and only needs one value, e.g. ?true? -- Here, the @part attribute for the organ moves to the containing all the staves of the part. For the ultimate in flexibility; that is, to be able to create ?custom? parts from any combination of staves, standoff markup can be used. For example, indicates the same part arrangement as the previous markup example, but would represent 3 parts -- one made up of staves 1 & 2, another of staves 3 & 4, and one containing only the pedals of the organ. The could use either staff numbers or IDs to indicate the appropriate staves. Hope this helps, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, May 27, 2015 3:28 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Perry, I am not sure I understand what you think of Andrew's proposal to take @instr out of the MIDI module. Does this seem a valid approach to you? I think it would be nice to have a way to encode parts in a score-based organization in more precise way than we can now. This might serve parts extraction but other purposes. The use of seems to serve a different purpose to me, which is to encode material in parts when no score is available/desired. As you pointed out, we cannot rely on brackets and braces for this, so I also have the impression we need something more. What Hans pointed out is that currently it would not be easy to extract a piano part (by itself or with another one) precisely because what the piano part is not clearly specified. Laurent On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) > wrote: Hi, There is no ?promotion? or ?demotion? between what is considered data and what is thought of as metadata -- there is only ?separation?. exists within in order to allow differing sets of symbols to be associated at multiple points within the tree. For example, movements of a multi-movement work need not refer to a single set of symbol definitions. This makes it possible for a movement (or similar segment) to be more independent (i.e., separable) and permit software to load/track/account for only those symbols necessary to process/render the symbols associated with the segment. While the data captured by is intended to be transcriptional in nature, is placed within the header (as a child of ) because it primarily serves a documentary purpose. Its data model is based on metadata standards (mainly MARC) and it is a member of attribute classes that place it squarely in the bibliographic realm. The blending of instrVoice, etc. and staffGrp, etc. would blur the distinction (a useful one, I believe) between these 2 functions. I second Raffaele?s suggestion of exploring the potential of the element. If the conceptual model of the ?score? is a collection of parts, then instead of trying to extract the part-level information from data within , why not store the data using elements in the first place? So that physically-separate and logical parts can be distinguished, it would be useful to add an attribute on to capture whether the parts are physical or logical. While MEI can be used as a format for notation editors (and I sincerely hope it will be), I urge caution not to focus on this particular application of it too much. Requirements for this (and other applications) are good candidates for Schematron assertions applied on top of the baseline rules. Requiring @instr is a good example of the kind of contextual constraint that Schematron is designed for. It is fitting that attention also be given to the tradition/convention that staves joined by a bracket are independent instruments, while those joined by a brace represent a single instrument. A group of staves joined by a brace (such as those for the piano) should be considered a single "part". A group of staves joined by a bracket (unless there's a further sub-grouping using a brace) represents separate parts. (The major exception is the organ, where the staff for the pedals is not included in the brace that joins the staves for the manuals. Manuscript notation might also violate the traditional "rule" regarding the function of brackets and braces.) The issue of separate parts written on a single staff can be handled, as Andrew has suggested, by using elements. The generation of parts from a score could also be thought of as an interactive/transformative process that doesn?t need to be explicitly marked in the XML. For example, why shouldn?t software offer the possibility of creating a ?part? from any combination of staves/layers the user selects? I believe a user interested in creating a piano or organ part would select the appropriate staves. And the user might even want to create specialized parts, for example, combining the flute and tuba staves because these two players are expected to sit next to each other. ? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, May 26, 2015 10:58 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Hans, Thanks for joining MEI-L and for starting this interesting conversation! Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid. Having said that, though, I am a bit surprised to see an element like , which groups user-defined symbols, be contained by , while is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding? Finally, it might be useful to look at as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common. Raff On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken > wrote: Hi Andrew and Laurent, @Andrew: Yes! thats what I'm after! So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data. So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff. @Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in and should be required if a part isn't one whole staff. Thanks! Hans On 2015-05-26 10:48, Laurent Pugin wrote: Hi Andrew and Hans, This makes sense to me. I guess you would also need to have @instr in when there is more than one instrument represented in one staff, wouldn't you? Laurent On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson > wrote: I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct? I believe what you are looking for is in the , , and cluster of tags. contains @count which indicates the number of performers. http://www.music-encoding.org/documentation/guidelines2013/instrVoice Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an element, and perhaps do the same and have @instrGrp / pairs as well. That way you could do: Violin I Violin II Viola Violoncello Piano And then: ... ...treble staff... ...bass staff... The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice. Anyone else out there have any ideas? -Andrew On May 22, 2015, at 8:01 AM, Hans Vereyken > wrote: I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; @players is required if it's isn't default. Would this be possible? Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 13:34, Andrew Hankinson > wrote: Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. Follow us on: Facebook // Twitter On 22 May 2015 at 09:54, Andrew Hankinson > wrote: On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: Hi Andrew, I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: and then in the body (for example): At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). I think the layerDef mechanism will help here too. To be sure we are talking about the same: - staff: needed to notate music - part: music performed by a single player/instrument One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). Thanks Hans Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 00:58, Andrew Hankinson > wrote: Hi Hans, Welcome to MEI! Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. -Andrew > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: > > Hi, > > This is my first post to the MEI mailing list. > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > In a dynamic music renderer, where you can switch parts on/off this is key information. > > How should it be done? Am I missing something? > > Thanks in advance! > Hans Vereyken > _______________________________________________ > 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 _______________________________________________ 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 lxpugin at gmail.com Wed May 27 23:35:47 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 27 May 2015 23:35:47 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: I'll need some time to digest this. Two remarks. 1) I understand the possibility to have a logical group of parts. This indeed solves the issue of the part identification. However, this is not equivalent to a score. For example, where would you have the staff groups that group several parts represented? If we have all string instruments separated each of them in one part, we cannot (easily?) encode that there is a staff group with a bracket englobing them. Or I am overlooking something? 2) I thought about a @part. This might be the missing piece, and is in a way similar to the @player proposed by Hans. I guess we would also need it on for the case where we have two parts in one staff. OK, now I go and digest it... Laurent On Wed, May 27, 2015 at 11:00 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > I support the intention/motivation of the proposal, but it raises some > issues: > > > > Moving out of the MIDI module doesn?t comply with its current > definition because provides a description of a *MIDI > instrument*, not a generic instrument. That role is handled somewhat by > , but, as already noted, because is a child of > , which has a descriptive function and is placed within > , pointing to it could be problematic. > > > > Also, if @instr pointed to , the info provided by > would be orphaned/inaccessible. The attributes provided by > could be moved to or duplicated on , but moving them would > create a backward compatibility problem and duplicating them would create a > processing problem (that is, the same data could potentially be recorded in > multiple locations). > > > > Since there are potentially overlapping hierarchies, I believe that the > staff, part, and instrument entities should be independent of each other. > Using @instr in the way suggested by the proposal creates too close an > association between part and instrument concepts. How, for example, would > doubling (one performer playing multiple instruments from a single printed > part) be accounted for? > > > > A potential solution is to employ for the part-organizing concept, > not just a physical part. By adding an attribute to , can be > used to capture both physical and conceptual parts. In essence, we get > *part-based markup of the score* for free. Since I?ve spent so much time > emphasizing it, I get your point of view that a element can ONLY > represent a physically independent thing in MEI. But, that was mostly a > way to make sure that everyone got the idea that parts are *independent* of > the score, not *components* of the score as in MusicXML. Physical and > conceptual parts can maintain this independence even while using the same > element. For example, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > represents a set of physically separate parts, each with its own staff > definitions, MIDI instrument assignment, and, as an additional bonus, its > own layout parameters. Changing @form to ?logical? allows the same markup > to function as a part-wise representation of the score (to borrow a term > from MusicXML). In this case, any layout parameters would be ignored in > favor of those provided within and its descendants. > > > > On the other hand, if the grouping of the staves of a score into parts is > our only goal, then another, much simpler approach is possible. Adding > @part on permits the grouping of staves into parts independently > of the grouping provided by . For example, > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > part="piano"/> > > part="piano"/> > > > > > > > > > > And the association of staves with MIDI instruments is also preserved. > > > > If the keyboard accompaniment is for organ instead of piano, the following > markup can be used -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > > > lines="5" part="Organ"/> > > lines="5" part="Organ"/> > > > > > > > > > > > > > > Note the placement of the instrument definition for the organ to indicate > that all 3 staves should be played using the same patch. > > > > And if there are 2 tubas (both written on the same staff) -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > > > > > > > > > > > > > lines="5" part="Organ"/> > > lines="5" part="Organ"/> > > > > > > > > > > > > > > One more possibility -- use @part on and to indicate > that the staff or staff descendants of the group bearing this attribute > constitute a distinct part. In this case, @part functions as a marker and > only needs one value, e.g. ?true? -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="true"> > > > > > > part="true"> > > > > > > > > > > > > > > > > > > > > > > > > lines="5"/> > > lines="5"/> > > > > > > > > > > > > > > Here, the @part attribute for the organ moves to the containing > all the staves of the part. > > > > For the ultimate in flexibility; that is, to be able to create ?custom? > parts from any combination of staves, standoff markup can be used. For > example, > > > > > > > > > > > > > > > > indicates the same part arrangement as the previous markup example, but > > > > > > > > > > > > > > > > would represent 3 parts -- one made up of staves 1 & 2, another of staves > 3 & 4, and one containing only the pedals of the organ. The > could use either staff numbers or IDs to indicate the appropriate staves. > > > > Hope this helps, > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Wednesday, May 27, 2015 3:28 AM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > Hi Perry, > > > > I am not sure I understand what you think of Andrew's proposal to take > @instr out of the MIDI module. Does this seem a valid approach to you? > > > > I think it would be nice to have a way to encode parts in a score-based > organization in more precise way than we can now. This might serve parts > extraction but other purposes. The use of seems to serve a > different purpose to me, which is to encode material in parts when no score > is available/desired. As you pointed out, we cannot rely on brackets and > braces for this, so I also have the impression we need something more. What > Hans pointed out is that currently it would not be easy to extract a piano > part (by itself or with another one) precisely because what the piano part > is not clearly specified. > > > > Laurent > > > > On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > Hi, > > > > There is no ?promotion? or ?demotion? between what is considered data and > what is thought of as metadata -- there is only ?separation?. > > > > exists within in order to allow differing sets of > symbols to be associated at multiple points within the tree. For > example, movements of a multi-movement work need not refer to a single set > of symbol definitions. This makes it possible for a movement (or similar > segment) to be more independent (i.e., separable) and permit software to > load/track/account for only those symbols necessary to process/render the > symbols associated with the segment. > > > > While the data captured by is intended to be transcriptional in > nature, is placed within the header (as a child of > ) because it primarily serves a documentary purpose. Its data > model is based on metadata standards (mainly MARC) and it is a member of > attribute classes that place it squarely in the bibliographic realm. The > blending of instrVoice, etc. and staffGrp, etc. would blur the distinction > (a useful one, I believe) between these 2 functions. > > > > I second Raffaele?s suggestion of exploring the potential of the > element. If the conceptual model of the ?score? is a collection of parts, > then instead of trying to extract the part-level information from data > within , why not store the data using elements in the first > place? So that physically-separate and logical parts can be distinguished, > it would be useful to add an attribute on to capture whether the > parts are physical or logical. > > > > While MEI can be used as a format for notation editors (and I sincerely > hope it will be), I urge caution not to focus on this particular > application of it too much. Requirements for this (and other applications) > are good candidates for Schematron assertions applied on top of the > baseline rules. Requiring @instr is a good example of the kind of > contextual constraint that Schematron is designed for. > > > > It is fitting that attention also be given to the tradition/convention > that staves joined by a bracket are independent instruments, while those > joined by a brace represent a single instrument. A group of staves joined > by a brace (such as those for the piano) should be considered a single > "part". A group of staves joined by a bracket (unless there's a further > sub-grouping using a brace) represents separate parts. (The major > exception is the organ, where the staff for the pedals is not included in > the brace that joins the staves for the manuals. Manuscript notation might > also violate the traditional "rule" regarding the function of brackets and > braces.) The issue of separate parts written on a single staff can be > handled, as Andrew has suggested, by using elements. > > > > The generation of parts from a score could also be thought of as an > interactive/transformative process that doesn?t need to be explicitly > marked in the XML. For example, why shouldn?t software offer the > possibility of creating a ?part? from any combination of staves/layers the > user selects? I believe a user interested in creating a piano or organ > part would select the appropriate staves. And the user might even want to > create specialized parts, for example, combining the flute and tuba staves > because these two players are expected to sit next to each other. J > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, May 26, 2015 10:58 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > Hi Hans, > > Thanks for joining MEI-L and for starting this interesting conversation! > > > Andrew, I think your solution is the correct answer. I agree that this is > "musical" information and may seem to not be appropriately located in the > header. However, the header is not just metadata, it is also a useful place > to define information that is re-used throughout the score. The header is > fundamental to parse the music content of an MEI file, which is why it is > required for an MEI file to be valid. > > Having said that, though, I am a bit surprised to see an element like > , which groups user-defined symbols, be contained by > , while is in the header. I would have expected > symbols to be defined in the header too - why are they promoted (or > demoted?) to the score definition? Why do instrument and symbol definition > belong to different areas of the encoding? > > Finally, it might be useful to look at as well, a powerful element > that is underused at the moment, IMO. It allows to re-define the score from > the perspective of one performer (or group of performers) and it allows to > do some nifty things when it comes to adjusting parts when going from an > orchestral score to separate parts. But maybe this is a different > discussion since you're interested in reading MEI and use of this element > is not common. > > > > Raff > > > > > > On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken wrote: > > Hi Andrew and Laurent, > > @Andrew: Yes! thats what I'm after! > So now I can see how I can read it (if the information is there). I'm a > bit surprised by location of this information in an mei file. I think this > information shouldn't be in the meta-data part of the file, this is > content, I expected to find this info somewhere inside the 'music' element. > I clicked trough some example files and found that the @instr and @instrGrp > aren't used, so I'm still stuck. I know now how a file can be created in a > way this info is clear, but I'm interesting in reading files. And I'm still > confident this info should (also) be inside the music element, it's > semantical data, not meta-data. > > So I think it would be good to have a system to make this more clear. And > to rule out any ambiguity this system should be required for any part using > more than one staff. > > @Laurent: yes! would be great, but like I said above, I think this > actually isn't meta-data. And Also, this @instr in and > should be required if a part isn't one whole staff. > > Thanks! > Hans > > > > On 2015-05-26 10:48, Laurent Pugin wrote: > > Hi Andrew and Hans, > > > > This makes sense to me. I guess you would also need to have @instr in > when there is more than one instrument represented in one staff, > wouldn't you? > > > > Laurent > > > > On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > > I think I know what you're trying to do: You're trying to ensure that a > part that gets extracted to the right amount of staves, correct? That, > given an ensemble work that features a piano, your software does not try to > extract two different parts for the right and left hands of the piano. > Correct? > > > > I believe what you are looking for is in the , > , and cluster of tags. > contains @count which indicates the number of performers. > > > > http://www.music-encoding.org/documentation/guidelines2013/instrVoice > > > > Looking this over I might suggest to move @instr out of the MIDI module > and specify that it should point to an element, and perhaps do > the same and have @instrGrp / pairs as well. That way you could > do: > > > > > > > Violin I > Violin II > Viola > Violoncello > > > > Piano > > > > > And then: > > > > ... > > > > ...treble staff... > > ...bass staff... > > > > > > The other possibility to move instrGrp/instrDef out of the MIDI module and > have them replace instrVoiceGrp/instrVoice. > > > > Anyone else out there have any ideas? > > > > -Andrew > > > > On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: > > > > I think this problem can be tackled with an @players. @players can be an > attribute of staffGrp and means that the content is played by x > player(s)/instrument(s). It defaults to the amount of staves in the group. > > The @players can also be an attribute of staffDef and means that the staff > is performed by x player(s)/instrument(s). It defaults to 1; > > @players is required if it's isn't default. > > > > Would this be possible? > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 13:34, Andrew Hankinson > wrote: > > > > Notating multiple parts on one staff can be done with the layerDef, looks > good, thanks. > > > > one part on multiple staves is a bit trickier, but can still be done. > You can use the @staff and @layer attributes on events (chords, notes, > rests) to "assign" that event to a particular staff and/or layer. > > > > One part on multiple staves is a very common thing (I'm a professional > pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading > files, not creating them. I didn't look through all the MEI examples but > this far I didn't found a single example demonstrating this technique. > Ruling out all files who don't follow this technique would be a massive > mistake. > > > > I didn't mean to suggest that it's uncommon; I just meant that within the > confines of XML, dealing with overlapping or crossing hierarchies requires > a bit of extra semantics. The link I sent you to the cross-staff example > should be able to give you a start on dealing with cross-staff notation. > > > > > > > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 09:54, Andrew Hankinson > wrote: > > > > On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: > > > > Hi Andrew, > > > > I see, my subject title is a bit confusing, better would be: How to > distinguish different players in the and elements. > > > > "If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts)." > > I strongly disagree on that, it is played by a single player and it is a > single part. This is even more clear if you think about harp parts, > (very often) one 'voice' (strangely called 'layers' in MEI) traveling > across 2 staves. > > > > But they are independent lines. In theory, you could have two one-handed > people playing a piano and it would make no practical difference. :) The > voice/layer nomenclature in MEI comes from a desire to separate a melodic > line from any idea of "voice leading." (i.e., not wanting to confuse the > practical separation of independent instrument lines from the > music-theoretical notions of harmonic and melodic progression). > > > > Another problem is cross staff notes, in your opinion these are the same > as something that would be called 'cross part notes' (since each staff is a > part). Think about it, 'cross part notes'... I don't even know any > contemporary composer who did this. > > I think this information should be added to the MEI format, and I think it > can be done with an attribute in the staffGrp element indicating that all > staves in that group are performed by one player/instrument (or group of > players, eg, 1st Violin). > > > > Sorry, I'm still not clear on what you are asking. Have you looked at the > @instr attribute on staffGrp? Is this what you are looking for? Or is it > something else? > > > > This way you can keep numbering the staves top to bottom for the whole > score, but it's clear which staves are played by the same player/instrument > and should be grouped together when playing around with parts. > > I agree that it needs to be possible to hide a single staff in a part with > multiple staves, but semantically spoken it's a big difference with hiding > a part. > > > > Would the `layerDef` mechanism help clear this up? You can define a > specific layer to correspond to a specific voice, in the same way you can > define a specific staffDef to define a specific staff. Then you can trace a > specific layer ("voice") throughout the work, having pre-defined it in your > scoreDef/staffDef block. > > > > For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have > the percussion instruments on a single staff: > > > > lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> > > > > > > > > > > > > > > > > > > and then in the body (for example): > > > > > > > instr="#P18-X2" pnum="61"/> > instr="#P18-X2" pnum="61"/> > > > > > > > > > > > > At the same time it would be great to have another attribute in the > staffDef element indicating that this staff is performed by multiple > players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice > (again, called layers in MEI). This would be very helpfull in reading some > chorus score's to (in the MEI examples this would clear up different parts > in Altenburg_Macht_auf_die_Tor). > > > > I think the layerDef mechanism will help here too. > > > > > > To be sure we are talking about the same: > > - staff: needed to notate music > > - part: music performed by a single player/instrument > > > > One part can be notated on multiple staves, multiple parts can be notated > on a single staff. For me part is definitely not the same as staff. > > > > Multiple parts on a single staff is pretty easy; one part on multiple > staves is a bit trickier, but can still be done. You can use the @staff and > @layer attributes on events (chords, notes, rests) to "assign" that event > to a particular staff and/or layer. > > > > See: http://www.verovio.org/examples/features/cross-staff.mei for an > example of how this might work (and > http://www.verovio.org/features.xhtml?id=cross-staff for a sample > rendering). > > > > > > Thanks > > Hans > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 00:58, Andrew Hankinson > wrote: > > Hi Hans, > > Welcome to MEI! > > Are you looking for the equivalent of the MIDI instrument that would > perform these parts? Or something else? > > If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts). If you have a staff that is "hidden" (for example, if you have an > instrument that does not play on certain pages) you still need to define > the staff and give it a number. This number should be constant throughout > the score. If it does not play in a specific place, it will simply not > appear in the measure (as far as I understand it). > > If you're in a renderer and you want to switch all the "n=2" parts off, > then, you would simply hide it whenever you have . The "2" > does not refer to the second staff on any given page; rather, it refers to > the second staff defined in a score, regardless of whether it appears or > not. > > -Andrew > > > > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: > > > > Hi, > > > > This is my first post to the MEI mailing list. > > I'm implementing MEI into our music renderer and am having trouble > getting all the info I need about staves. > > > > I searches the documentation and mail archives for answers but wasn't > able to find what I'm looking for. > > > > So each staff is declared seperatly, with the certain groups > and there symbols are declared. Although a brace usually means that the > staves within are the same player (e.g. piano brace), it is not enough to > be sure of it. > > > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the > relevant xml: > > > > meter.sym="common" key.sig="0" key.mode="major"> > > > > > > clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> > > > > barthru="true"> > > clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" > key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> > > clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> > > label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > key.sig="4f" key.mode="minor"> > > > > clef.line="2"/> > > clef.shape="F" lines="5"/> > > > > > > > > So in both cases I have a group of staves with a brace symbol, how > should I know which staves are played by which player. > > I can try to sniff the labels and by guessing the semantic meaning of > 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the > second example this isn't possible, so this won't work (no surprise). > > In a dynamic music renderer, where you can switch parts on/off this is > key information. > > > > How should it be done? Am I missing something? > > > > Thanks in advance! > > Hans Vereyken > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 pdr4h at eservices.virginia.edu Thu May 28 00:03:10 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 27 May 2015 22:03:10 +0000 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: 1) provides a standoff method of handling overlapping groups of staves. It could also be used inside . 2) Yes, @part on would be necessary. Making @part available also on events (note, chord, rest, etc.) would make it possible to ?disentangle? ambiguities at the sub-layer level and make it possible to create/accommodate/process note-list-like markup. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, May 27, 2015 5:36 PM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements I'll need some time to digest this. Two remarks. 1) I understand the possibility to have a logical group of parts. This indeed solves the issue of the part identification. However, this is not equivalent to a score. For example, where would you have the staff groups that group several parts represented? If we have all string instruments separated each of them in one part, we cannot (easily?) encode that there is a staff group with a bracket englobing them. Or I am overlooking something? 2) I thought about a @part. This might be the missing piece, and is in a way similar to the @player proposed by Hans. I guess we would also need it on for the case where we have two parts in one staff. OK, now I go and digest it... Laurent On Wed, May 27, 2015 at 11:00 PM, Roland, Perry D. (pdr4h) > wrote: I support the intention/motivation of the proposal, but it raises some issues: Moving out of the MIDI module doesn?t comply with its current definition because provides a description of a *MIDI instrument*, not a generic instrument. That role is handled somewhat by , but, as already noted, because is a child of , which has a descriptive function and is placed within , pointing to it could be problematic. Also, if @instr pointed to , the info provided by would be orphaned/inaccessible. The attributes provided by could be moved to or duplicated on , but moving them would create a backward compatibility problem and duplicating them would create a processing problem (that is, the same data could potentially be recorded in multiple locations). Since there are potentially overlapping hierarchies, I believe that the staff, part, and instrument entities should be independent of each other. Using @instr in the way suggested by the proposal creates too close an association between part and instrument concepts. How, for example, would doubling (one performer playing multiple instruments from a single printed part) be accounted for? A potential solution is to employ for the part-organizing concept, not just a physical part. By adding an attribute to , can be used to capture both physical and conceptual parts. In essence, we get *part-based markup of the score* for free. Since I?ve spent so much time emphasizing it, I get your point of view that a element can ONLY represent a physically independent thing in MEI. But, that was mostly a way to make sure that everyone got the idea that parts are *independent* of the score, not *components* of the score as in MusicXML. Physical and conceptual parts can maintain this independence even while using the same element. For example, represents a set of physically separate parts, each with its own staff definitions, MIDI instrument assignment, and, as an additional bonus, its own layout parameters. Changing @form to ?logical? allows the same markup to function as a part-wise representation of the score (to borrow a term from MusicXML). In this case, any layout parameters would be ignored in favor of those provided within and its descendants. On the other hand, if the grouping of the staves of a score into parts is our only goal, then another, much simpler approach is possible. Adding @part on permits the grouping of staves into parts independently of the grouping provided by . For example, And the association of staves with MIDI instruments is also preserved. If the keyboard accompaniment is for organ instead of piano, the following markup can be used -- Note the placement of the instrument definition for the organ to indicate that all 3 staves should be played using the same patch. And if there are 2 tubas (both written on the same staff) -- One more possibility -- use @part on and to indicate that the staff or staff descendants of the group bearing this attribute constitute a distinct part. In this case, @part functions as a marker and only needs one value, e.g. ?true? -- Here, the @part attribute for the organ moves to the containing all the staves of the part. For the ultimate in flexibility; that is, to be able to create ?custom? parts from any combination of staves, standoff markup can be used. For example, indicates the same part arrangement as the previous markup example, but would represent 3 parts -- one made up of staves 1 & 2, another of staves 3 & 4, and one containing only the pedals of the organ. The could use either staff numbers or IDs to indicate the appropriate staves. Hope this helps, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, May 27, 2015 3:28 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Perry, I am not sure I understand what you think of Andrew's proposal to take @instr out of the MIDI module. Does this seem a valid approach to you? I think it would be nice to have a way to encode parts in a score-based organization in more precise way than we can now. This might serve parts extraction but other purposes. The use of seems to serve a different purpose to me, which is to encode material in parts when no score is available/desired. As you pointed out, we cannot rely on brackets and braces for this, so I also have the impression we need something more. What Hans pointed out is that currently it would not be easy to extract a piano part (by itself or with another one) precisely because what the piano part is not clearly specified. Laurent On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) > wrote: Hi, There is no ?promotion? or ?demotion? between what is considered data and what is thought of as metadata -- there is only ?separation?. exists within in order to allow differing sets of symbols to be associated at multiple points within the tree. For example, movements of a multi-movement work need not refer to a single set of symbol definitions. This makes it possible for a movement (or similar segment) to be more independent (i.e., separable) and permit software to load/track/account for only those symbols necessary to process/render the symbols associated with the segment. While the data captured by is intended to be transcriptional in nature, is placed within the header (as a child of ) because it primarily serves a documentary purpose. Its data model is based on metadata standards (mainly MARC) and it is a member of attribute classes that place it squarely in the bibliographic realm. The blending of instrVoice, etc. and staffGrp, etc. would blur the distinction (a useful one, I believe) between these 2 functions. I second Raffaele?s suggestion of exploring the potential of the element. If the conceptual model of the ?score? is a collection of parts, then instead of trying to extract the part-level information from data within , why not store the data using elements in the first place? So that physically-separate and logical parts can be distinguished, it would be useful to add an attribute on to capture whether the parts are physical or logical. While MEI can be used as a format for notation editors (and I sincerely hope it will be), I urge caution not to focus on this particular application of it too much. Requirements for this (and other applications) are good candidates for Schematron assertions applied on top of the baseline rules. Requiring @instr is a good example of the kind of contextual constraint that Schematron is designed for. It is fitting that attention also be given to the tradition/convention that staves joined by a bracket are independent instruments, while those joined by a brace represent a single instrument. A group of staves joined by a brace (such as those for the piano) should be considered a single "part". A group of staves joined by a bracket (unless there's a further sub-grouping using a brace) represents separate parts. (The major exception is the organ, where the staff for the pedals is not included in the brace that joins the staves for the manuals. Manuscript notation might also violate the traditional "rule" regarding the function of brackets and braces.) The issue of separate parts written on a single staff can be handled, as Andrew has suggested, by using elements. The generation of parts from a score could also be thought of as an interactive/transformative process that doesn?t need to be explicitly marked in the XML. For example, why shouldn?t software offer the possibility of creating a ?part? from any combination of staves/layers the user selects? I believe a user interested in creating a piano or organ part would select the appropriate staves. And the user might even want to create specialized parts, for example, combining the flute and tuba staves because these two players are expected to sit next to each other. ? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, May 26, 2015 10:58 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Hans, Thanks for joining MEI-L and for starting this interesting conversation! Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid. Having said that, though, I am a bit surprised to see an element like , which groups user-defined symbols, be contained by , while is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding? Finally, it might be useful to look at as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common. Raff On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken > wrote: Hi Andrew and Laurent, @Andrew: Yes! thats what I'm after! So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data. So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff. @Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in and should be required if a part isn't one whole staff. Thanks! Hans On 2015-05-26 10:48, Laurent Pugin wrote: Hi Andrew and Hans, This makes sense to me. I guess you would also need to have @instr in when there is more than one instrument represented in one staff, wouldn't you? Laurent On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson > wrote: I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct? I believe what you are looking for is in the , , and cluster of tags. contains @count which indicates the number of performers. http://www.music-encoding.org/documentation/guidelines2013/instrVoice Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an element, and perhaps do the same and have @instrGrp / pairs as well. That way you could do: Violin I Violin II Viola Violoncello Piano And then: ... ...treble staff... ...bass staff... The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice. Anyone else out there have any ideas? -Andrew On May 22, 2015, at 8:01 AM, Hans Vereyken > wrote: I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; @players is required if it's isn't default. Would this be possible? Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 13:34, Andrew Hankinson > wrote: Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. Follow us on: Facebook // Twitter On 22 May 2015 at 09:54, Andrew Hankinson > wrote: On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: Hi Andrew, I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: and then in the body (for example): At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). I think the layerDef mechanism will help here too. To be sure we are talking about the same: - staff: needed to notate music - part: music performed by a single player/instrument One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). Thanks Hans Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 00:58, Andrew Hankinson > wrote: Hi Hans, Welcome to MEI! Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. -Andrew > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: > > Hi, > > This is my first post to the MEI mailing list. > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > In a dynamic music renderer, where you can switch parts on/off this is key information. > > How should it be done? Am I missing something? > > Thanks in advance! > Hans Vereyken > _______________________________________________ > 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 _______________________________________________ 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 lxpugin at gmail.com Thu May 28 10:26:53 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Thu, 28 May 2015 10:26:53 +0200 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: On Thu, May 28, 2015 at 12:03 AM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > 1) provides a standoff method of handling overlapping groups of > staves. It could also be used inside . > This makes sense, I was not aware of it. Is there any example how this works? I can see it can contain a staffGrp, but then I am a bit lost. Sorry! > > > 2) Yes, @part on would be necessary. > > > > Making @part available also on events (note, chord, rest, etc.) would make > it possible to ?disentangle? ambiguities at the sub-layer level and make it > possible to create/accommodate/process note-list-like markup. > This makes sense too. One question regarding the use of parts with a @form="logical". You are saying "In this case, any layout parameters would be ignored in favor of those provided within and its descendants." Does this mean that you would expect to have both and in the encoding? Then, would you duplicate the content (staves, layers, notes, etc.)? Maybe you want to do this in some cases, but I assume in most cases you would like to avoid it and just point to the content provided in one of them. I am sure this is possible (even though I am not perfectly clear how to do it), but is seems that it would make simple cases quite complex. > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Wednesday, May 27, 2015 5:36 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > I'll need some time to digest this. Two remarks. > > > > 1) I understand the possibility to have a logical group of parts. This > indeed solves the issue of the part identification. However, this is not > equivalent to a score. For example, where would you have the staff groups > that group several parts represented? If we have all string instruments > separated each of them in one part, we cannot (easily?) encode that there > is a staff group with a bracket englobing them. Or I am overlooking > something? > > > > 2) I thought about a @part. This might be the missing piece, and is in a > way similar to the @player proposed by Hans. I guess we would also need it > on for the case where we have two parts in one staff. > > > > OK, now I go and digest it... > > > > Laurent > > > > On Wed, May 27, 2015 at 11:00 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > I support the intention/motivation of the proposal, but it raises some > issues: > > > > Moving out of the MIDI module doesn?t comply with its current > definition because provides a description of a *MIDI > instrument*, not a generic instrument. That role is handled somewhat by > , but, as already noted, because is a child of > , which has a descriptive function and is placed within > , pointing to it could be problematic. > > > > Also, if @instr pointed to , the info provided by > would be orphaned/inaccessible. The attributes provided by > could be moved to or duplicated on , but moving them would > create a backward compatibility problem and duplicating them would create a > processing problem (that is, the same data could potentially be recorded in > multiple locations). > > > > Since there are potentially overlapping hierarchies, I believe that the > staff, part, and instrument entities should be independent of each other. > Using @instr in the way suggested by the proposal creates too close an > association between part and instrument concepts. How, for example, would > doubling (one performer playing multiple instruments from a single printed > part) be accounted for? > > > > A potential solution is to employ for the part-organizing concept, > not just a physical part. By adding an attribute to , can be > used to capture both physical and conceptual parts. In essence, we get > *part-based markup of the score* for free. Since I?ve spent so much time > emphasizing it, I get your point of view that a element can ONLY > represent a physically independent thing in MEI. But, that was mostly a > way to make sure that everyone got the idea that parts are *independent* of > the score, not *components* of the score as in MusicXML. Physical and > conceptual parts can maintain this independence even while using the same > element. For example, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > represents a set of physically separate parts, each with its own staff > definitions, MIDI instrument assignment, and, as an additional bonus, its > own layout parameters. Changing @form to ?logical? allows the same markup > to function as a part-wise representation of the score (to borrow a term > from MusicXML). In this case, any layout parameters would be ignored in > favor of those provided within and its descendants. > > > > On the other hand, if the grouping of the staves of a score into parts is > our only goal, then another, much simpler approach is possible. Adding > @part on permits the grouping of staves into parts independently > of the grouping provided by . For example, > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > part="piano"/> > > part="piano"/> > > > > > > > > > > And the association of staves with MIDI instruments is also preserved. > > > > If the keyboard accompaniment is for organ instead of piano, the following > markup can be used -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > > > lines="5" part="Organ"/> > > lines="5" part="Organ"/> > > > > > > > > > > > > > > Note the placement of the instrument definition for the organ to indicate > that all 3 staves should be played using the same patch. > > > > And if there are 2 tubas (both written on the same staff) -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="Flute"> > > > > > > part="Tuba"> > > > > > > > > > > > > > > > > > > > > > > > > lines="5" part="Organ"/> > > lines="5" part="Organ"/> > > > > > > > > > > > > > > One more possibility -- use @part on and to indicate > that the staff or staff descendants of the group bearing this attribute > constitute a distinct part. In this case, @part functions as a marker and > only needs one value, e.g. ?true? -- > > > > meter.unit="4" > > meter.sym="common" system.leftline="true"> > > > > > > part="true"> > > > > > > part="true"> > > > > > > > > > > > > > > > > > > > > > > > > lines="5"/> > > lines="5"/> > > > > > > > > > > > > > > Here, the @part attribute for the organ moves to the containing > all the staves of the part. > > > > For the ultimate in flexibility; that is, to be able to create ?custom? > parts from any combination of staves, standoff markup can be used. For > example, > > > > > > > > > > > > > > > > indicates the same part arrangement as the previous markup example, but > > > > > > > > > > > > > > > > would represent 3 parts -- one made up of staves 1 & 2, another of staves > 3 & 4, and one containing only the pedals of the organ. The > could use either staff numbers or IDs to indicate the appropriate staves. > > > > Hope this helps, > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Laurent Pugin > *Sent:* Wednesday, May 27, 2015 3:28 AM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > Hi Perry, > > > > I am not sure I understand what you think of Andrew's proposal to take > @instr out of the MIDI module. Does this seem a valid approach to you? > > > > I think it would be nice to have a way to encode parts in a score-based > organization in more precise way than we can now. This might serve parts > extraction but other purposes. The use of seems to serve a > different purpose to me, which is to encode material in parts when no score > is available/desired. As you pointed out, we cannot rely on brackets and > braces for this, so I also have the impression we need something more. What > Hans pointed out is that currently it would not be easy to extract a piano > part (by itself or with another one) precisely because what the piano part > is not clearly specified. > > > > Laurent > > > > On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > Hi, > > > > There is no ?promotion? or ?demotion? between what is considered data and > what is thought of as metadata -- there is only ?separation?. > > > > exists within in order to allow differing sets of > symbols to be associated at multiple points within the tree. For > example, movements of a multi-movement work need not refer to a single set > of symbol definitions. This makes it possible for a movement (or similar > segment) to be more independent (i.e., separable) and permit software to > load/track/account for only those symbols necessary to process/render the > symbols associated with the segment. > > > > While the data captured by is intended to be transcriptional in > nature, is placed within the header (as a child of > ) because it primarily serves a documentary purpose. Its data > model is based on metadata standards (mainly MARC) and it is a member of > attribute classes that place it squarely in the bibliographic realm. The > blending of instrVoice, etc. and staffGrp, etc. would blur the distinction > (a useful one, I believe) between these 2 functions. > > > > I second Raffaele?s suggestion of exploring the potential of the > element. If the conceptual model of the ?score? is a collection of parts, > then instead of trying to extract the part-level information from data > within , why not store the data using elements in the first > place? So that physically-separate and logical parts can be distinguished, > it would be useful to add an attribute on to capture whether the > parts are physical or logical. > > > > While MEI can be used as a format for notation editors (and I sincerely > hope it will be), I urge caution not to focus on this particular > application of it too much. Requirements for this (and other applications) > are good candidates for Schematron assertions applied on top of the > baseline rules. Requiring @instr is a good example of the kind of > contextual constraint that Schematron is designed for. > > > > It is fitting that attention also be given to the tradition/convention > that staves joined by a bracket are independent instruments, while those > joined by a brace represent a single instrument. A group of staves joined > by a brace (such as those for the piano) should be considered a single > "part". A group of staves joined by a bracket (unless there's a further > sub-grouping using a brace) represents separate parts. (The major > exception is the organ, where the staff for the pedals is not included in > the brace that joins the staves for the manuals. Manuscript notation might > also violate the traditional "rule" regarding the function of brackets and > braces.) The issue of separate parts written on a single staff can be > handled, as Andrew has suggested, by using elements. > > > > The generation of parts from a score could also be thought of as an > interactive/transformative process that doesn?t need to be explicitly > marked in the XML. For example, why shouldn?t software offer the > possibility of creating a ?part? from any combination of staves/layers the > user selects? I believe a user interested in creating a piano or organ > part would select the appropriate staves. And the user might even want to > create specialized parts, for example, combining the flute and tuba staves > because these two players are expected to sit next to each other. J > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, May 26, 2015 10:58 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] How to distinguish different instruments in the > and elements > > > > Hi Hans, > > Thanks for joining MEI-L and for starting this interesting conversation! > > > Andrew, I think your solution is the correct answer. I agree that this is > "musical" information and may seem to not be appropriately located in the > header. However, the header is not just metadata, it is also a useful place > to define information that is re-used throughout the score. The header is > fundamental to parse the music content of an MEI file, which is why it is > required for an MEI file to be valid. > > Having said that, though, I am a bit surprised to see an element like > , which groups user-defined symbols, be contained by > , while is in the header. I would have expected > symbols to be defined in the header too - why are they promoted (or > demoted?) to the score definition? Why do instrument and symbol definition > belong to different areas of the encoding? > > Finally, it might be useful to look at as well, a powerful element > that is underused at the moment, IMO. It allows to re-define the score from > the perspective of one performer (or group of performers) and it allows to > do some nifty things when it comes to adjusting parts when going from an > orchestral score to separate parts. But maybe this is a different > discussion since you're interested in reading MEI and use of this element > is not common. > > > > Raff > > > > > > On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken wrote: > > Hi Andrew and Laurent, > > @Andrew: Yes! thats what I'm after! > So now I can see how I can read it (if the information is there). I'm a > bit surprised by location of this information in an mei file. I think this > information shouldn't be in the meta-data part of the file, this is > content, I expected to find this info somewhere inside the 'music' element. > I clicked trough some example files and found that the @instr and @instrGrp > aren't used, so I'm still stuck. I know now how a file can be created in a > way this info is clear, but I'm interesting in reading files. And I'm still > confident this info should (also) be inside the music element, it's > semantical data, not meta-data. > > So I think it would be good to have a system to make this more clear. And > to rule out any ambiguity this system should be required for any part using > more than one staff. > > @Laurent: yes! would be great, but like I said above, I think this > actually isn't meta-data. And Also, this @instr in and > should be required if a part isn't one whole staff. > > Thanks! > Hans > > > > On 2015-05-26 10:48, Laurent Pugin wrote: > > Hi Andrew and Hans, > > > > This makes sense to me. I guess you would also need to have @instr in > when there is more than one instrument represented in one staff, > wouldn't you? > > > > Laurent > > > > On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson < > andrew.hankinson at mail.mcgill.ca> wrote: > > I think I know what you're trying to do: You're trying to ensure that a > part that gets extracted to the right amount of staves, correct? That, > given an ensemble work that features a piano, your software does not try to > extract two different parts for the right and left hands of the piano. > Correct? > > > > I believe what you are looking for is in the , > , and cluster of tags. > contains @count which indicates the number of performers. > > > > http://www.music-encoding.org/documentation/guidelines2013/instrVoice > > > > Looking this over I might suggest to move @instr out of the MIDI module > and specify that it should point to an element, and perhaps do > the same and have @instrGrp / pairs as well. That way you could > do: > > > > > > > Violin I > Violin II > Viola > Violoncello > > > > Piano > > > > > And then: > > > > ... > > > > ...treble staff... > > ...bass staff... > > > > > > The other possibility to move instrGrp/instrDef out of the MIDI module and > have them replace instrVoiceGrp/instrVoice. > > > > Anyone else out there have any ideas? > > > > -Andrew > > > > On May 22, 2015, at 8:01 AM, Hans Vereyken wrote: > > > > I think this problem can be tackled with an @players. @players can be an > attribute of staffGrp and means that the content is played by x > player(s)/instrument(s). It defaults to the amount of staves in the group. > > The @players can also be an attribute of staffDef and means that the staff > is performed by x player(s)/instrument(s). It defaults to 1; > > @players is required if it's isn't default. > > > > Would this be possible? > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 13:34, Andrew Hankinson > wrote: > > > > Notating multiple parts on one staff can be done with the layerDef, looks > good, thanks. > > > > one part on multiple staves is a bit trickier, but can still be done. > You can use the @staff and @layer attributes on events (chords, notes, > rests) to "assign" that event to a particular staff and/or layer. > > > > One part on multiple staves is a very common thing (I'm a professional > pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading > files, not creating them. I didn't look through all the MEI examples but > this far I didn't found a single example demonstrating this technique. > Ruling out all files who don't follow this technique would be a massive > mistake. > > > > I didn't mean to suggest that it's uncommon; I just meant that within the > confines of XML, dealing with overlapping or crossing hierarchies requires > a bit of extra semantics. The link I sent you to the cross-staff example > should be able to give you a start on dealing with cross-staff notation. > > > > > > > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 09:54, Andrew Hankinson > wrote: > > > > On May 22, 2015, at 9:16 AM, Hans Vereyken wrote: > > > > Hi Andrew, > > > > I see, my subject title is a bit confusing, better would be: How to > distinguish different players in the and elements. > > > > "If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts)." > > I strongly disagree on that, it is played by a single player and it is a > single part. This is even more clear if you think about harp parts, > (very often) one 'voice' (strangely called 'layers' in MEI) traveling > across 2 staves. > > > > But they are independent lines. In theory, you could have two one-handed > people playing a piano and it would make no practical difference. :) The > voice/layer nomenclature in MEI comes from a desire to separate a melodic > line from any idea of "voice leading." (i.e., not wanting to confuse the > practical separation of independent instrument lines from the > music-theoretical notions of harmonic and melodic progression). > > > > Another problem is cross staff notes, in your opinion these are the same > as something that would be called 'cross part notes' (since each staff is a > part). Think about it, 'cross part notes'... I don't even know any > contemporary composer who did this. > > I think this information should be added to the MEI format, and I think it > can be done with an attribute in the staffGrp element indicating that all > staves in that group are performed by one player/instrument (or group of > players, eg, 1st Violin). > > > > Sorry, I'm still not clear on what you are asking. Have you looked at the > @instr attribute on staffGrp? Is this what you are looking for? Or is it > something else? > > > > This way you can keep numbering the staves top to bottom for the whole > score, but it's clear which staves are played by the same player/instrument > and should be grouped together when playing around with parts. > > I agree that it needs to be possible to hide a single staff in a part with > multiple staves, but semantically spoken it's a big difference with hiding > a part. > > > > Would the `layerDef` mechanism help clear this up? You can define a > specific layer to correspond to a specific voice, in the same way you can > define a specific staffDef to define a specific staff. Then you can trace a > specific layer ("voice") throughout the work, having pre-defined it in your > scoreDef/staffDef block. > > > > For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have > the percussion instruments on a single staff: > > > > lines="1" clef.shape="perc" key.sig="4f" key.mode="major" spacing="117"> > > > > > > > > > > > > > > > > > > and then in the body (for example): > > > > > > > instr="#P18-X2" pnum="61"/> > instr="#P18-X2" pnum="61"/> > > > > > > > > > > > > At the same time it would be great to have another attribute in the > staffDef element indicating that this staff is performed by multiple > players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice > (again, called layers in MEI). This would be very helpfull in reading some > chorus score's to (in the MEI examples this would clear up different parts > in Altenburg_Macht_auf_die_Tor). > > > > I think the layerDef mechanism will help here too. > > > > > > To be sure we are talking about the same: > > - staff: needed to notate music > > - part: music performed by a single player/instrument > > > > One part can be notated on multiple staves, multiple parts can be notated > on a single staff. For me part is definitely not the same as staff. > > > > Multiple parts on a single staff is pretty easy; one part on multiple > staves is a bit trickier, but can still be done. You can use the @staff and > @layer attributes on events (chords, notes, rests) to "assign" that event > to a particular staff and/or layer. > > > > See: http://www.verovio.org/examples/features/cross-staff.mei for an > example of how this might work (and > http://www.verovio.org/features.xhtml?id=cross-staff for a sample > rendering). > > > > > > Thanks > > Hans > > > Hans Vereyken > *Developer* > > M hans at neoscores.com > T +32 472 52 75 59 > > neoScores BVBA // Pluyseghemstraat 19, > BE-2550 Kontich // Twitter: @neoscores > > ///////////////////////////////////////////////////////////////////////////////////////////////////// > > Follow us on: Facebook // Twitter > > > > > On 22 May 2015 at 00:58, Andrew Hankinson > wrote: > > Hi Hans, > > Welcome to MEI! > > Are you looking for the equivalent of the MIDI instrument that would > perform these parts? Or something else? > > If you have two different staves, these are two different players, > regardless of the label (a left and a right hand on a piano could be > thought of as two different "players" since they're playing two separate > parts). If you have a staff that is "hidden" (for example, if you have an > instrument that does not play on certain pages) you still need to define > the staff and give it a number. This number should be constant throughout > the score. If it does not play in a specific place, it will simply not > appear in the measure (as far as I understand it). > > If you're in a renderer and you want to switch all the "n=2" parts off, > then, you would simply hide it whenever you have . The "2" > does not refer to the second staff on any given page; rather, it refers to > the second staff defined in a score, regardless of whether it appears or > not. > > -Andrew > > > > On May 21, 2015, at 4:26 PM, Hans Vereyken wrote: > > > > Hi, > > > > This is my first post to the MEI mailing list. > > I'm implementing MEI into our music renderer and am having trouble > getting all the info I need about staves. > > > > I searches the documentation and mail archives for answers but wasn't > able to find what I'm looking for. > > > > So each staff is declared seperatly, with the certain groups > and there symbols are declared. Although a brace usually means that the > staves within are the same player (e.g. piano brace), it is not enough to > be sure of it. > > > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the > relevant xml: > > > > meter.sym="common" key.sig="0" key.mode="major"> > > > > > > clef.shape="G" key.sig="0" lines="5" label="Trompete 1" label.abbr="Tr 1"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 2" label.abbr="Tr 2"/> > > clef.shape="G" key.sig="0" lines="5" label="Trompete 3" label.abbr="Tr 3"/> > > > > barthru="true"> > > clef.dis="8" clef.dis.place="below" clef.line="2" label="Pos1 Tro 4" > key.sig="0" label.abbr="P 1 Tr 4" lines="5"/> > > clef.shape="F" lines="5" key.sig="0" label="Posaune 2" label.abbr="Pos 2"/> > > label.abbr="Pos 3" clef.line="4" clef.shape="F" key.sig="0" lines="5"/> > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > key.sig="4f" key.mode="minor"> > > > > clef.line="2"/> > > clef.shape="F" lines="5"/> > > > > > > > > So in both cases I have a group of staves with a brace symbol, how > should I know which staves are played by which player. > > I can try to sniff the labels and by guessing the semantic meaning of > 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the > second example this isn't possible, so this won't work (no surprise). > > In a dynamic music renderer, where you can switch parts on/off this is > key information. > > > > How should it be done? Am I missing something? > > > > Thanks in advance! > > Hans Vereyken > > > _______________________________________________ > > 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 > > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 May 28 20:57:05 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 28 May 2015 18:57:05 +0000 Subject: [MEI-L] How to distinguish different instruments in the and elements In-Reply-To: References: <24209_1432218423_555DEB36_24209_132_1_CA+d5Sp9hP4NHsSxQVdiJLF3sheL+Y7rzuxaVdHEjxEeOsC8_vA@mail.gmail.com> <316F3744-AF30-4CC9-91DF-6369572D8E1B@mail.mcgill.ca> <21950_1432278987_555ED7CA_21950_16_1_CA+d5Sp9fZBvAwekMar0VxFu7T8kWeoRXpvOwbA50_0JKe3MXKg@mail.gmail.com> <879B85A8-D1AA-49C1-9640-4CAACDF7DD29@mail.mcgill.ca> <24782_1432284811_555EEE8A_24782_398_1_CA+d5Sp8tBbNmsEAM3C6PupbK-_fEptt57dRgV4oRi57YQ9qEOA@mail.gmail.com> <32079_1432296108_555F1AAC_32079_27_1_CA+d5Sp9iV_L-o546CN=P0UoA4awd81WL1aSWhm8foVMLQScjtQ@mail.gmail.com> <7647FAEA-44CD-4174-AB22-A2F015FED248@mail.mcgill.ca> <55647BB6.7000507@neoscores.com> Message-ID: Just to clarify, doesn?t contain , but can be *contained by* . Here?s an example of the use of to capture overlapping grouping symbols -- Of course, this same methodology can also be used to record non-overlapping groups by changing the values in @startid and @endid -- Now, to answer your questions -- Yes, I believe and elements would both be necessary when the goal was to present the parts as a score. However, the musical content doesn?t have to be repeated. can function only as a container for , which in turn captures the parameters describing the score, while the musical content can be encoded in elements. Grouping symbols required by the score can be encoded in score/scoreDef, while those required in the parts go in part/score. The following example encodes parts (Violin 1, Violin 2, and Organ) but also provides information that can be used to assemble the parts into a score --
The physical layout information in score/scoreDef supersedes that in the individual parts. Another approach to combining part and score info would be to modify the element so that it takes on the role of and . This was the genesis of my comment about using within parts, but I now realize that statement was an unintentional red herring (a misdirection) that could lead us astray. I think this accommodates simple cases of creating a score from a set of logical or physical parts. The only potential problem I see at the moment is the use of @n on and @staff (on things like , etc. to associate these so-called ?control events? to a particular staff). For instance, in the encoding above there are multiple staffDef and staff elements with ?1? as the value of @n. As long as the value of staff/@n and slur/@staff (in the organ part) are interpreted *in the context of the part* all is well. If, however, these or elements are somehow moved to the score context, then confusion will result. That might be fixed by allowing either an integer or a URI (an IDREF, that is) as the value of @staff. The values of @staff would still have to be re-written as part of the move. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Thursday, May 28, 2015 4:27 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements On Thu, May 28, 2015 at 12:03 AM, Roland, Perry D. (pdr4h) > wrote: 1) provides a standoff method of handling overlapping groups of staves. It could also be used inside . This makes sense, I was not aware of it. Is there any example how this works? I can see it can contain a staffGrp, but then I am a bit lost. Sorry! 2) Yes, @part on would be necessary. Making @part available also on events (note, chord, rest, etc.) would make it possible to ?disentangle? ambiguities at the sub-layer level and make it possible to create/accommodate/process note-list-like markup. This makes sense too. One question regarding the use of parts with a @form="logical". You are saying "In this case, any layout parameters would be ignored in favor of those provided within and its descendants." Does this mean that you would expect to have both and in the encoding? Then, would you duplicate the content (staves, layers, notes, etc.)? Maybe you want to do this in some cases, but I assume in most cases you would like to avoid it and just point to the content provided in one of them. I am sure this is possible (even though I am not perfectly clear how to do it), but is seems that it would make simple cases quite complex. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, May 27, 2015 5:36 PM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements I'll need some time to digest this. Two remarks. 1) I understand the possibility to have a logical group of parts. This indeed solves the issue of the part identification. However, this is not equivalent to a score. For example, where would you have the staff groups that group several parts represented? If we have all string instruments separated each of them in one part, we cannot (easily?) encode that there is a staff group with a bracket englobing them. Or I am overlooking something? 2) I thought about a @part. This might be the missing piece, and is in a way similar to the @player proposed by Hans. I guess we would also need it on for the case where we have two parts in one staff. OK, now I go and digest it... Laurent On Wed, May 27, 2015 at 11:00 PM, Roland, Perry D. (pdr4h) > wrote: I support the intention/motivation of the proposal, but it raises some issues: Moving out of the MIDI module doesn?t comply with its current definition because provides a description of a *MIDI instrument*, not a generic instrument. That role is handled somewhat by , but, as already noted, because is a child of , which has a descriptive function and is placed within , pointing to it could be problematic. Also, if @instr pointed to , the info provided by would be orphaned/inaccessible. The attributes provided by could be moved to or duplicated on , but moving them would create a backward compatibility problem and duplicating them would create a processing problem (that is, the same data could potentially be recorded in multiple locations). Since there are potentially overlapping hierarchies, I believe that the staff, part, and instrument entities should be independent of each other. Using @instr in the way suggested by the proposal creates too close an association between part and instrument concepts. How, for example, would doubling (one performer playing multiple instruments from a single printed part) be accounted for? A potential solution is to employ for the part-organizing concept, not just a physical part. By adding an attribute to , can be used to capture both physical and conceptual parts. In essence, we get *part-based markup of the score* for free. Since I?ve spent so much time emphasizing it, I get your point of view that a element can ONLY represent a physically independent thing in MEI. But, that was mostly a way to make sure that everyone got the idea that parts are *independent* of the score, not *components* of the score as in MusicXML. Physical and conceptual parts can maintain this independence even while using the same element. For example, represents a set of physically separate parts, each with its own staff definitions, MIDI instrument assignment, and, as an additional bonus, its own layout parameters. Changing @form to ?logical? allows the same markup to function as a part-wise representation of the score (to borrow a term from MusicXML). In this case, any layout parameters would be ignored in favor of those provided within and its descendants. On the other hand, if the grouping of the staves of a score into parts is our only goal, then another, much simpler approach is possible. Adding @part on permits the grouping of staves into parts independently of the grouping provided by . For example, And the association of staves with MIDI instruments is also preserved. If the keyboard accompaniment is for organ instead of piano, the following markup can be used -- Note the placement of the instrument definition for the organ to indicate that all 3 staves should be played using the same patch. And if there are 2 tubas (both written on the same staff) -- One more possibility -- use @part on and to indicate that the staff or staff descendants of the group bearing this attribute constitute a distinct part. In this case, @part functions as a marker and only needs one value, e.g. ?true? -- Here, the @part attribute for the organ moves to the containing all the staves of the part. For the ultimate in flexibility; that is, to be able to create ?custom? parts from any combination of staves, standoff markup can be used. For example, indicates the same part arrangement as the previous markup example, but would represent 3 parts -- one made up of staves 1 & 2, another of staves 3 & 4, and one containing only the pedals of the organ. The could use either staff numbers or IDs to indicate the appropriate staves. Hope this helps, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Laurent Pugin Sent: Wednesday, May 27, 2015 3:28 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Perry, I am not sure I understand what you think of Andrew's proposal to take @instr out of the MIDI module. Does this seem a valid approach to you? I think it would be nice to have a way to encode parts in a score-based organization in more precise way than we can now. This might serve parts extraction but other purposes. The use of seems to serve a different purpose to me, which is to encode material in parts when no score is available/desired. As you pointed out, we cannot rely on brackets and braces for this, so I also have the impression we need something more. What Hans pointed out is that currently it would not be easy to extract a piano part (by itself or with another one) precisely because what the piano part is not clearly specified. Laurent On Wed, May 27, 2015 at 12:39 AM, Roland, Perry D. (pdr4h) > wrote: Hi, There is no ?promotion? or ?demotion? between what is considered data and what is thought of as metadata -- there is only ?separation?. exists within in order to allow differing sets of symbols to be associated at multiple points within the tree. For example, movements of a multi-movement work need not refer to a single set of symbol definitions. This makes it possible for a movement (or similar segment) to be more independent (i.e., separable) and permit software to load/track/account for only those symbols necessary to process/render the symbols associated with the segment. While the data captured by is intended to be transcriptional in nature, is placed within the header (as a child of ) because it primarily serves a documentary purpose. Its data model is based on metadata standards (mainly MARC) and it is a member of attribute classes that place it squarely in the bibliographic realm. The blending of instrVoice, etc. and staffGrp, etc. would blur the distinction (a useful one, I believe) between these 2 functions. I second Raffaele?s suggestion of exploring the potential of the element. If the conceptual model of the ?score? is a collection of parts, then instead of trying to extract the part-level information from data within , why not store the data using elements in the first place? So that physically-separate and logical parts can be distinguished, it would be useful to add an attribute on to capture whether the parts are physical or logical. While MEI can be used as a format for notation editors (and I sincerely hope it will be), I urge caution not to focus on this particular application of it too much. Requirements for this (and other applications) are good candidates for Schematron assertions applied on top of the baseline rules. Requiring @instr is a good example of the kind of contextual constraint that Schematron is designed for. It is fitting that attention also be given to the tradition/convention that staves joined by a bracket are independent instruments, while those joined by a brace represent a single instrument. A group of staves joined by a brace (such as those for the piano) should be considered a single "part". A group of staves joined by a bracket (unless there's a further sub-grouping using a brace) represents separate parts. (The major exception is the organ, where the staff for the pedals is not included in the brace that joins the staves for the manuals. Manuscript notation might also violate the traditional "rule" regarding the function of brackets and braces.) The issue of separate parts written on a single staff can be handled, as Andrew has suggested, by using elements. The generation of parts from a score could also be thought of as an interactive/transformative process that doesn?t need to be explicitly marked in the XML. For example, why shouldn?t software offer the possibility of creating a ?part? from any combination of staves/layers the user selects? I believe a user interested in creating a piano or organ part would select the appropriate staves. And the user might even want to create specialized parts, for example, combining the flute and tuba staves because these two players are expected to sit next to each other. ? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, May 26, 2015 10:58 AM To: Music Encoding Initiative Subject: Re: [MEI-L] How to distinguish different instruments in the and elements Hi Hans, Thanks for joining MEI-L and for starting this interesting conversation! Andrew, I think your solution is the correct answer. I agree that this is "musical" information and may seem to not be appropriately located in the header. However, the header is not just metadata, it is also a useful place to define information that is re-used throughout the score. The header is fundamental to parse the music content of an MEI file, which is why it is required for an MEI file to be valid. Having said that, though, I am a bit surprised to see an element like , which groups user-defined symbols, be contained by , while is in the header. I would have expected symbols to be defined in the header too - why are they promoted (or demoted?) to the score definition? Why do instrument and symbol definition belong to different areas of the encoding? Finally, it might be useful to look at as well, a powerful element that is underused at the moment, IMO. It allows to re-define the score from the perspective of one performer (or group of performers) and it allows to do some nifty things when it comes to adjusting parts when going from an orchestral score to separate parts. But maybe this is a different discussion since you're interested in reading MEI and use of this element is not common. Raff On Tue, May 26, 2015 at 9:57 AM, Hans Vereyken > wrote: Hi Andrew and Laurent, @Andrew: Yes! thats what I'm after! So now I can see how I can read it (if the information is there). I'm a bit surprised by location of this information in an mei file. I think this information shouldn't be in the meta-data part of the file, this is content, I expected to find this info somewhere inside the 'music' element. I clicked trough some example files and found that the @instr and @instrGrp aren't used, so I'm still stuck. I know now how a file can be created in a way this info is clear, but I'm interesting in reading files. And I'm still confident this info should (also) be inside the music element, it's semantical data, not meta-data. So I think it would be good to have a system to make this more clear. And to rule out any ambiguity this system should be required for any part using more than one staff. @Laurent: yes! would be great, but like I said above, I think this actually isn't meta-data. And Also, this @instr in and should be required if a part isn't one whole staff. Thanks! Hans On 2015-05-26 10:48, Laurent Pugin wrote: Hi Andrew and Hans, This makes sense to me. I guess you would also need to have @instr in when there is more than one instrument represented in one staff, wouldn't you? Laurent On Tue, May 26, 2015 at 12:56 AM, Andrew Hankinson > wrote: I think I know what you're trying to do: You're trying to ensure that a part that gets extracted to the right amount of staves, correct? That, given an ensemble work that features a piano, your software does not try to extract two different parts for the right and left hands of the piano. Correct? I believe what you are looking for is in the , , and cluster of tags. contains @count which indicates the number of performers. http://www.music-encoding.org/documentation/guidelines2013/instrVoice Looking this over I might suggest to move @instr out of the MIDI module and specify that it should point to an element, and perhaps do the same and have @instrGrp / pairs as well. That way you could do: Violin I Violin II Viola Violoncello Piano And then: ... ...treble staff... ...bass staff... The other possibility to move instrGrp/instrDef out of the MIDI module and have them replace instrVoiceGrp/instrVoice. Anyone else out there have any ideas? -Andrew On May 22, 2015, at 8:01 AM, Hans Vereyken > wrote: I think this problem can be tackled with an @players. @players can be an attribute of staffGrp and means that the content is played by x player(s)/instrument(s). It defaults to the amount of staves in the group. The @players can also be an attribute of staffDef and means that the staff is performed by x player(s)/instrument(s). It defaults to 1; @players is required if it's isn't default. Would this be possible? Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 13:34, Andrew Hankinson > wrote: Notating multiple parts on one staff can be done with the layerDef, looks good, thanks. one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. One part on multiple staves is a very common thing (I'm a professional pianist) and shouldn't be 'a bit trickier'. Besides I'm working on reading files, not creating them. I didn't look through all the MEI examples but this far I didn't found a single example demonstrating this technique. Ruling out all files who don't follow this technique would be a massive mistake. I didn't mean to suggest that it's uncommon; I just meant that within the confines of XML, dealing with overlapping or crossing hierarchies requires a bit of extra semantics. The link I sent you to the cross-staff example should be able to give you a start on dealing with cross-staff notation. Follow us on: Facebook // Twitter On 22 May 2015 at 09:54, Andrew Hankinson > wrote: On May 22, 2015, at 9:16 AM, Hans Vereyken > wrote: Hi Andrew, I see, my subject title is a bit confusing, better would be: How to distinguish different players in the and elements. "If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts)." I strongly disagree on that, it is played by a single player and it is a single part. This is even more clear if you think about harp parts, (very often) one 'voice' (strangely called 'layers' in MEI) traveling across 2 staves. But they are independent lines. In theory, you could have two one-handed people playing a piano and it would make no practical difference. :) The voice/layer nomenclature in MEI comes from a desire to separate a melodic line from any idea of "voice leading." (i.e., not wanting to confuse the practical separation of independent instrument lines from the music-theoretical notions of harmonic and melodic progression). Another problem is cross staff notes, in your opinion these are the same as something that would be called 'cross part notes' (since each staff is a part). Think about it, 'cross part notes'... I don't even know any contemporary composer who did this. I think this information should be added to the MEI format, and I think it can be done with an attribute in the staffGrp element indicating that all staves in that group are performed by one player/instrument (or group of players, eg, 1st Violin). Sorry, I'm still not clear on what you are asking. Have you looked at the @instr attribute on staffGrp? Is this what you are looking for? Or is it something else? This way you can keep numbering the staves top to bottom for the whole score, but it's clear which staves are played by the same player/instrument and should be grouped together when playing around with parts. I agree that it needs to be possible to hide a single staff in a part with multiple staves, but semantically spoken it's a big difference with hiding a part. Would the `layerDef` mechanism help clear this up? You can define a specific layer to correspond to a specific voice, in the same way you can define a specific staffDef to define a specific staff. Then you can trace a specific layer ("voice") throughout the work, having pre-defined it in your scoreDef/staffDef block. For an example, see the Ponchielli_LarrivoDelRe.mei file, where you have the percussion instruments on a single staff: and then in the body (for example): At the same time it would be great to have another attribute in the staffDef element indicating that this staff is performed by multiple players, for instance 1st and 2nd Violins are notated as 1st and 2nd voice (again, called layers in MEI). This would be very helpfull in reading some chorus score's to (in the MEI examples this would clear up different parts in Altenburg_Macht_auf_die_Tor). I think the layerDef mechanism will help here too. To be sure we are talking about the same: - staff: needed to notate music - part: music performed by a single player/instrument One part can be notated on multiple staves, multiple parts can be notated on a single staff. For me part is definitely not the same as staff. Multiple parts on a single staff is pretty easy; one part on multiple staves is a bit trickier, but can still be done. You can use the @staff and @layer attributes on events (chords, notes, rests) to "assign" that event to a particular staff and/or layer. See: http://www.verovio.org/examples/features/cross-staff.mei for an example of how this might work (and http://www.verovio.org/features.xhtml?id=cross-staff for a sample rendering). Thanks Hans Hans Vereyken Developer M hans at neoscores.com T +32 472 52 75 59 neoScores BVBA // Pluyseghemstraat 19, BE-2550 Kontich // Twitter: @neoscores ///////////////////////////////////////////////////////////////////////////////////////////////////// Follow us on: Facebook // Twitter On 22 May 2015 at 00:58, Andrew Hankinson > wrote: Hi Hans, Welcome to MEI! Are you looking for the equivalent of the MIDI instrument that would perform these parts? Or something else? If you have two different staves, these are two different players, regardless of the label (a left and a right hand on a piano could be thought of as two different "players" since they're playing two separate parts). If you have a staff that is "hidden" (for example, if you have an instrument that does not play on certain pages) you still need to define the staff and give it a number. This number should be constant throughout the score. If it does not play in a specific place, it will simply not appear in the measure (as far as I understand it). If you're in a renderer and you want to switch all the "n=2" parts off, then, you would simply hide it whenever you have . The "2" does not refer to the second staff on any given page; rather, it refers to the second staff defined in a score, regardless of whether it appears or not. -Andrew > On May 21, 2015, at 4:26 PM, Hans Vereyken > wrote: > > Hi, > > This is my first post to the MEI mailing list. > I'm implementing MEI into our music renderer and am having trouble getting all the info I need about staves. > > I searches the documentation and mail archives for answers but wasn't able to find what I'm looking for. > > So each staff is declared seperatly, with the certain groups and there symbols are declared. Although a brace usually means that the staves within are the same player (e.g. piano brace), it is not enough to be sure of it. > > In the example files I looked at 'Altenburg_Ein_feste_Burg', the relevant xml: > > > > > > > > > > > > > > > > > and: Chopin_Etude_op.10_no.9: > > > > > > > > > So in both cases I have a group of staves with a brace symbol, how should I know which staves are played by which player. > I can try to sniff the labels and by guessing the semantic meaning of 'Trompete 1,2,3' and conclude these has to be 3 different parts. In the second example this isn't possible, so this won't work (no surprise). > In a dynamic music renderer, where you can switch parts on/off this is key information. > > How should it be done? Am I missing something? > > Thanks in advance! > Hans Vereyken > _______________________________________________ > 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 _______________________________________________ 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 _______________________________________________ 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 stadler at edirom.de Sun May 31 18:44:44 2015 From: stadler at edirom.de (Peter Stadler) Date: Sun, 31 May 2015 12:44:44 -0400 Subject: [MEI-L] Pictures from MEC2015 Message-ID: <553A7A47-C701-4281-B27E-9E32CE515B47@edirom.de> May I remind you to please post a link to your pictures from Florence so everyone can enjoy them?! Many many thanks in advance Peter From atge at kb.dk Sun May 31 21:16:05 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Sun, 31 May 2015 19:16:05 +0000 Subject: [MEI-L] Pictures from MEC2015 In-Reply-To: <553A7A47-C701-4281-B27E-9E32CE515B47@edirom.de> References: <553A7A47-C701-4281-B27E-9E32CE515B47@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D10122840ECA@EXCHANGE-03.kb.dk> Thanks for the reminder, Peter. Sorry about the delay! You can download a zip folder with my images at https://dl.dropboxusercontent.com/u/4580077/mec2015.zip I'll leave it there for some weeks or so. To avoid the hard light I didn't use my flash. In some cases perhaps I should have ;-) Hope to see some others' pictures too! Best, Axel ________________________________________ Fra: mei-l [mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] på vegne af Peter Stadler [stadler at edirom.de] Sendt: 31. maj 2015 18:44 Til: Initiative Music Encoding Emne: [MEI-L] Pictures from MEC2015 May I remind you to please post a link to your pictures from Florence so everyone can enjoy them?! Many many thanks in advance Peter _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From klaus.rettinghaus at gmail.com Mon Jun 1 15:40:05 2015 From: klaus.rettinghaus at gmail.com (Klaus Rettinghaus) Date: Mon, 01 Jun 2015 15:40:05 +0200 Subject: [MEI-L] Pictures from MEC2015 In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D10122840ECA@EXCHANGE-03.kb.dk> References: <553A7A47-C701-4281-B27E-9E32CE515B47@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10122840ECA@EXCHANGE-03.kb.dk> Message-ID: <1433166005.2348.1@smtp.gmail.com> I made some (terrible bad) pics, too. Grab 'em here: https://flic.kr/s/aHskbYSvDn Cheerio, Klaus Am So, 31. Mai, 2015 um 9:16 schrieb Axel Teich Geertinger : > Thanks for the reminder, Peter. Sorry about the delay! > You can download a zip folder with my images at > https://dl.dropboxusercontent.com/u/4580077/mec2015.zip > I'll leave it there for some weeks or so. > > To avoid the hard light I didn't use my flash. In some cases perhaps > I should have ;-) > > Hope to see some others' pictures too! > > Best, > Axel > ________________________________________ > Fra: mei-l [mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] på > vegne af Peter Stadler [stadler at edirom.de] > Sendt: 31. maj 2015 18:44 > Til: Initiative Music Encoding > Emne: [MEI-L] Pictures from MEC2015 > > May I remind you to please post a link to your pictures from Florence > so everyone can enjoy them?! > > Many many thanks in advance > Peter > _______________________________________________ > 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From SWPFFM at web.de Sun Jun 7 11:36:19 2015 From: SWPFFM at web.de (SWPFFM) Date: Sun, 07 Jun 2015 11:36:19 +0200 Subject: [MEI-L] Verovio - add svg elements at runtime Message-ID: <55741093.7040500@web.de> Dear MEI List, I have a question concerning adding svg elements at runtime in the Javascript version of Verovio. Sorry for this question is not strictly related to MEI, but I think most Verovio users come from the MEI community. (And there is no Verovio mailinglist as far as I see.) I generate some Plaine&Easy Code that is displed by Verovio. Now my goal is to add a text element above each measure. This is what I have done so far: /* some example pae music */ data = "@clef:F-4"; data += "@keysig:\n"; data += "@timesig:4/4\n"; data += "@data:,8G,4.A'4C'4C}/'2G{,8B'8xC}'4D}/"; var vrvToolkit = new verovio.toolkit(); var svg = vrvToolkit.renderData(data, JSON.stringify({ inputFormat: 'pae', pageWidth: 800*2, scale: 40 }) ); /* this works fine and displays very nicely rendered music*/ $("div#output").html(svg); /* first get the lowest y value of all notes */ var yvals = $("g.note use").map(function() { return parseFloat( $(this).attr("y"), 10 ) ; }).get(); var lowest_y = (Math.min.apply(Math, yvals) - 500.0).toString(); /* now add a chord label above the first note of each measure*/ var chords = ["C major", "D minor"]; $("g.measure").map(function(index) { var chordname = chords[index]; var fnote = $($(this).find("g.note:first")).find("use:first"); var text_node = ' ' + chordname + ' '; $("svg svg").prepend(text_node); }); The result does not show any chord labels. However, if I copy the resulting SVG and save it as a standalone SVG file, my browser shows the chord labels. So I think it is supposed to work like this. How can it be achieved that the text shows up in embeded svg at runetime? Thanks for any ideas and suggestions, also thanks alot for Verovio! Too bad I couldn't be at MEC2015, but I heard it has been a great event! Best, Frank -- Frank Zalkow Rintheimer Str. 58 76131 Karlsruhe Web: www.frank-zalkow.de Mail: frank_zalkow at web.de Phone: +49 172 715 7995 From ul at openlilylib.org Sun Jun 7 11:57:59 2015 From: ul at openlilylib.org (Urs Liska) Date: Sun, 07 Jun 2015 11:57:59 +0200 Subject: [MEI-L] Verovio - add svg elements at runtime In-Reply-To: <55741093.7040500@web.de> References: <55741093.7040500@web.de> Message-ID: <557415A7.7040503@openlilylib.org> Hallo Frank, sorry f?r die unh?fliche K?rze, aber ich wollte kurz loswerden, dass ich am 1.7. im Karlsruher MuWi-Kolloquium ?ber (digitale) Musikedition, LilyPond, LaTeX, Git und MEI berichten werde. HG Urs Am 07.06.2015 um 11:36 schrieb SWPFFM: > Dear MEI List, > > I have a question concerning adding svg elements at runtime in the > Javascript version of Verovio. Sorry for this question is not strictly > related to MEI, but I think most Verovio users come from the MEI > community. (And there is no Verovio mailinglist as far as I see.) > > I generate some Plaine&Easy Code that is displed by Verovio. Now my > goal is to add a text element above each measure. This is what I have > done so far: > > /* some example pae music */ > data = "@clef:F-4"; > data += "@keysig:\n"; > data += "@timesig:4/4\n"; > data += "@data:,8G,4.A'4C'4C}/'2G{,8B'8xC}'4D}/"; > > var vrvToolkit = new verovio.toolkit(); > var svg = vrvToolkit.renderData(data, JSON.stringify({ > inputFormat: 'pae', > pageWidth: 800*2, > scale: 40 }) ); > > /* this works fine and displays very nicely rendered music*/ > $("div#output").html(svg); > > /* first get the lowest y value of all notes */ > var yvals = $("g.note use").map(function() { > return parseFloat( $(this).attr("y"), 10 ) ; > }).get(); > var lowest_y = (Math.min.apply(Math, yvals) - 500.0).toString(); > > /* now add a chord label above the first note of each measure*/ > var chords = ["C major", "D minor"]; > $("g.measure").map(function(index) { > var chordname = chords[index]; > var fnote = $($(this).find("g.note:first")).find("use:first"); > var text_node = ' ' + > chordname + ' '; > $("svg svg").prepend(text_node); > }); > > The result does not show any chord labels. However, if I copy the > resulting SVG and save it as a standalone SVG file, my browser shows > the chord labels. So I think it is supposed to work like this. How can > it be achieved that the text shows up in embeded svg at runetime? > > Thanks for any ideas and suggestions, also thanks alot for Verovio! > > Too bad I couldn't be at MEC2015, but I heard it has been a great event! > > Best, > > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ul at openlilylib.org Sun Jun 7 12:13:03 2015 From: ul at openlilylib.org (Urs Liska) Date: Sun, 07 Jun 2015 12:13:03 +0200 Subject: [MEI-L] Verovio - add svg elements at runtime In-Reply-To: <557415A7.7040503@openlilylib.org> References: <55741093.7040500@web.de> <557415A7.7040503@openlilylib.org> Message-ID: <5574192F.2090507@openlilylib.org> Am 07.06.2015 um 11:57 schrieb Urs Liska: > Hallo Frank, > > sorry f?r die unh?fliche K?rze, aber ich wollte kurz loswerden, dass ich > am 1.7. im Karlsruher MuWi-Kolloquium ?ber (digitale) Musikedition, > LilyPond, LaTeX, Git und MEI berichten werde. > > HG > Urs > > Am 07.06.2015 um 11:36 schrieb SWPFFM: >> Dear MEI List, >> >> I have a question concerning adding svg elements at runtime in the >> Javascript version of Verovio. Sorry for this question is not strictly >> related to MEI, but I think most Verovio users come from the MEI >> community. (And there is no Verovio mailinglist as far as I see.) ... and sorry to everybody else for posting this to the list. I'm used to having "Reply" go to the original poster and not to the list ... -- Urs Liska www.openlilylib.org From andrew.hankinson at mail.mcgill.ca Sun Jun 7 20:12:10 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sun, 7 Jun 2015 14:12:10 -0400 Subject: [MEI-L] Verovio - add svg elements at runtime In-Reply-To: <12111_1433669807_557410AF_12111_186_1_55741093.7040500@web.de> References: <12111_1433669807_557410AF_12111_186_1_55741093.7040500@web.de> Message-ID: <60AA35C6-A8FF-4054-96A7-811CA820E25F@mail.mcgill.ca> You might try adding the text nodes to the SVG before appending them to the HTML. You might also try using the built-in JavaScript "createElementNS" for creating the 'g' tag, instead of simply using text. See: http://stackoverflow.com/a/3642265 http://stackoverflow.com/a/2545257 -Andrew > On Jun 7, 2015, at 5:36 AM, SWPFFM wrote: > > Dear MEI List, > > I have a question concerning adding svg elements at runtime in the > Javascript version of Verovio. Sorry for this question is not strictly > related to MEI, but I think most Verovio users come from the MEI > community. (And there is no Verovio mailinglist as far as I see.) > > I generate some Plaine&Easy Code that is displed by Verovio. Now my > goal is to add a text element above each measure. This is what I have > done so far: > > /* some example pae music */ > data = "@clef:F-4"; > data += "@keysig:\n"; > data += "@timesig:4/4\n"; > data += "@data:,8G,4.A'4C'4C}/'2G{,8B'8xC}'4D}/"; > > var vrvToolkit = new verovio.toolkit(); > var svg = vrvToolkit.renderData(data, JSON.stringify({ > inputFormat: 'pae', > pageWidth: 800*2, > scale: 40 }) ); > > /* this works fine and displays very nicely rendered music*/ > $("div#output").html(svg); > > /* first get the lowest y value of all notes */ > var yvals = $("g.note use").map(function() { > return parseFloat( $(this).attr("y"), 10 ) ; > }).get(); > var lowest_y = (Math.min.apply(Math, yvals) - 500.0).toString(); > > /* now add a chord label above the first note of each measure*/ > var chords = ["C major", "D minor"]; > $("g.measure").map(function(index) { > var chordname = chords[index]; > var fnote = $($(this).find("g.note:first")).find("use:first"); > var text_node = ' ' + > chordname + ' '; > $("svg svg").prepend(text_node); > }); > > The result does not show any chord labels. However, if I copy the > resulting SVG and save it as a standalone SVG file, my browser shows > the chord labels. So I think it is supposed to work like this. How can > it be achieved that the text shows up in embeded svg at runetime? > > Thanks for any ideas and suggestions, also thanks alot for Verovio! > > Too bad I couldn't be at MEC2015, but I heard it has been a great event! > > Best, > > Frank > > -- > Frank Zalkow > Rintheimer Str. 58 > 76131 Karlsruhe > > Web: www.frank-zalkow.de > Mail: frank_zalkow at web.de > Phone: +49 172 715 7995 > > _______________________________________________ > 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 frank_zalkow at web.de Sun Jun 7 22:47:35 2015 From: frank_zalkow at web.de (Frank Z.) Date: Sun, 07 Jun 2015 22:47:35 +0200 Subject: [MEI-L] Verovio - add svg elements at runtime In-Reply-To: <60AA35C6-A8FF-4054-96A7-811CA820E25F@mail.mcgill.ca> References: <12111_1433669807_557410AF_12111_186_1_55741093.7040500@web.de> <60AA35C6-A8FF-4054-96A7-811CA820E25F@mail.mcgill.ca> Message-ID: <5574ADE7.8020306@web.de> Dear Andrew, thanks alot, using createElementNS instead of manually concatenating strings solved it! Best, Frank Am 07. Jun 2015 um 20:12 schrieb Andrew Hankinson : > You might try adding the text nodes to the SVG before appending them to > the HTML. > > You might also try using the built-in JavaScript "createElementNS" for > creating the 'g' tag, instead of simply using text. > > See: > http://stackoverflow.com/a/3642265 > http://stackoverflow.com/a/2545257 > > -Andrew > >> On Jun 7, 2015, at 5:36 AM, SWPFFM > > wrote: >> >> Dear MEI List, >> >> I have a question concerning adding svg elements at runtime in the >> Javascript version of Verovio. Sorry for this question is not strictly >> related to MEI, but I think most Verovio users come from the MEI >> community. (And there is no Verovio mailinglist as far as I see.) >> >> I generate some Plaine&Easy Code that is displed by Verovio. Now my >> goal is to add a text element above each measure. This is what I have >> done so far: >> >> /* some example pae music */ >> data = "@clef:F-4"; >> data += "@keysig:\n"; >> data += "@timesig:4/4\n"; >> data += "@data:,8G,4.A'4C'4C}/'2G{,8B'8xC}'4D}/"; >> >> var vrvToolkit = new verovio.toolkit(); >> var svg = vrvToolkit.renderData(data, JSON.stringify({ >> inputFormat: 'pae', >> pageWidth: 800*2, >> scale: 40 }) ); >> >> /* this works fine and displays very nicely rendered music*/ >> $("div#output").html(svg); >> >> /* first get the lowest y value of all notes */ >> var yvals = $("g.note use").map(function() { >> return parseFloat( $(this).attr("y"), 10 ) ; >> }).get(); >> var lowest_y = (Math.min.apply(Math, yvals) - 500.0).toString(); >> >> /* now add a chord label above the first note of each measure*/ >> var chords = ["C major", "D minor"]; >> $("g.measure").map(function(index) { >> var chordname = chords[index]; >> var fnote = $($(this).find("g.note:first")).find("use:first"); >> var text_node = ' ' + >> chordname + ' '; >> $("svg svg").prepend(text_node); >> }); >> >> The result does not show any chord labels. However, if I copy the >> resulting SVG and save it as a standalone SVG file, my browser shows >> the chord labels. So I think it is supposed to work like this. How can >> it be achieved that the text shows up in embeded svg at runetime? >> >> Thanks for any ideas and suggestions, also thanks alot for Verovio! >> >> Too bad I couldn't be at MEC2015, but I heard it has been a great event! >> >> Best, >> >> Frank >> >> -- >> Frank Zalkow >> Rintheimer Str. 58 >> 76131 Karlsruhe >> >> Web: www.frank-zalkow.de >> Mail: frank_zalkow at web.de >> Phone: +49 172 715 7995 >> >> _______________________________________________ >> 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 > -- Frank Zalkow Rintheimer Str. 58 76131 Karlsruhe Web: www.frank-zalkow.de Mail: frank_zalkow at web.de Phone: +49 172 715 7995 From ul at openlilylib.org Mon Jun 8 15:59:30 2015 From: ul at openlilylib.org (Urs Liska) Date: Mon, 08 Jun 2015 15:59:30 +0200 Subject: [MEI-L] To whom it (= LilyPond) may concern Message-ID: <55759FC2.202@openlilylib.org> Dear MEI community, I have sent this to the attendants of the Music Encoding Conference already, so if you've been there you may ignore the following. At the conference I gave a presentation about interfacing MEI with LilyPond to incorporate professional engraving in MEI-powered digital editions. It seems there is a need, and having the LilyPond side step forward and promote this idea makes it more likely to have significant progress in the foreseeable future. After returning from Florence I sat down and reviewed my presentation. It is now turned into a written paper, with the slides incoprorated where appropriate, but also significantly extended. I've reintroduced stuff that I had to throw out to match the 20 minutes limit, but I've also added new material, incorporating answers and open questions raised in discussions during the conference. The paper goes into more detail about current developments in LilyPond, and it has a new section outlining major topics that have to be discussed now if we want to bring the idea forward. So I offer this paper for anyone who is interested in the idea of interfacing LilyPond and MEI. In order not to flood your inbox if you don't consider yourself being part of the target group I don't attach it, but you can download it from http://lilypondblog.org/wp-content/uploads/2015/06/mei2ly.pdf. One major point is to ensure all interested parties start communicating. Therefore I've set up the mei2ly at openlilylib.org mailing-list and suggest that everybody who cares for the topic subscribes at http://lists.openlilylib.org/cgi-bin/mailman/listinfo/mei2ly. I would welcome if you write a short presentation post telling what kind of project you are working on and in what way an MEI-to-LilyPond interface would be relevant to your work. But of course "silent" subscriptions are welcome too. Best wishes Urs (Liska) From RKlugseder at gmx.de Tue Jun 9 13:52:18 2015 From: RKlugseder at gmx.de (RKlugseder at gmx.de) Date: Tue, 9 Jun 2015 13:52:18 +0200 Subject: [MEI-L] SibMei, XSLT MusicXML to MEI and MEISE problems Message-ID: Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From andrew.hankinson at mail.mcgill.ca Tue Jun 9 16:00:45 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 9 Jun 2015 10:00:45 -0400 Subject: [MEI-L] SibMei, XSLT MusicXML to MEI and MEISE problems In-Reply-To: <8767_1433850759_5576D386_8767_258_1_trinity-116d3e5a-a44b-4aa7-9d94-1bc4c17c422a-1433850738766@3capp-gmx-bs15> References: <8767_1433850759_5576D386_8767_258_1_trinity-116d3e5a-a44b-4aa7-9d94-1bc4c17c422a-1433850738766@3capp-gmx-bs15> Message-ID: <5CB99FA7-FBA3-4315-BD7A-5D196D795B58@mail.mcgill.ca> Hi Robert, When did you download and install the plugin? I've been working on it, so it gets updated frequently. The problems you're having with note durations sounds like a bug that was fixed a couple months ago, so if you're running a version that is older than that I would suggest updating to the latest version and seeing if the problem persists. If it does, I would be interested to see the file that produces the problems. As for the second one -- it sounds like the software you're using to produce the MusicXML (Sibelius?) is encoding it in such a way that parttime.xsl cannot parse it. As an experiment you might try exporting to MusicXML, loading it into another MusicXML program (Finale or MuseScore) and then exporting again. -Andrew > On Jun 9, 2015, at 7:52 AM, RKlugseder at gmx.de wrote: > > Dear colleagues, > > First time here and MEI beginner. Have some troubles with SibMEI and MusicXML to MEI stylesheet. > > > 1. I use the SibMEI plugin in Sibelius 7.5. The transformation is (more or less) ok, but with some errors: > > - no or wrong wordpos in > - duration and dots twice, in AND the childs > - accidentals twice, in front of the staff (key.sig) AND in every element > - some wrong durations in doted notes (e.g. every dotted 4 was transformed into a dotted 8). > > 2. musicxml2mei-3.0.xsl to MEI > > I use musicxml2mei in Oxygen (XSLT scenario with Saxon PE 9.6.0.5) but get always a (nearly) empty result file (only with the declaration and the schema). > > with parttime.xsl before, this error message: > > Programmname: Saxon-PE 9.6.0.5 > Fehlerlevel: fatal > Beschreibung: XPTY0004: A sequence of more than one item is not allowed as the first argument of evaluate() ("4", "4") > Anfang: 3818:0 > > Thanks for your help > Robert > > > > > _________________________ > Robert Klugseder, PhD > Austrian Academy of Sciences > Department for Musicology > Dr. Ignaz Seipel-Platz 2 > A-1010 WIEN > +43/699/11192366 > > > _______________________________________________ > 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 ul at openlilylib.org Tue Jun 9 16:33:10 2015 From: ul at openlilylib.org (Urs Liska) Date: Tue, 09 Jun 2015 16:33:10 +0200 Subject: [MEI-L] Oskar Fried "on air" Message-ID: <5576F926.3050102@openlilylib.org> Dear MEI community, maybe it could be considered inappropriate, but I think it *is* in a way related, as both topics this post is about have been part of my presentation and discussions in Florence. Few of you will have heard of "Das trunkne Lied" by Oskar Fried. It's an important late-romantic piece which triggered a number of important developments for LilyPond's ecosystem. And now it's (in a way) out! "Das junge Orchester NRW" (http://djo-nrw.de), the orchestra that commissioned new performance material for the piece, has now done two performances, and one of them will be broadcast by Deutschlandradio Kultur in the upcoming week. Producing this performance material was our proof-of-concept project to explore "crowd engraving" a.k.a. collaborative edition workflows using LilyPond, GitLab and our own task management web app. This was the project where the "grid" approach was developed for that I talked about in Florence. Tomorrow, Wednesday, June 10, 20.03-21.30 (CEST) Deutschlandradio Kultur dedicates its evening program to Oskar Fried. There will be at first the broadcast of "Das trunkne Lied" (approx. 35 minutes), and the rest of the programme will be a presentation of the production of Oskar Fried's piano songs which I had the honor to do a few years ago. This production also had some significant consequences for LilyPond. Deutschlandradio can be streamed online from its homepage http://dradio.de. Detail page of the event is at http://www.deutschlandradiokultur.de/das-junge-orchester-nrw-in-essen-oh-mensch.1091.de.html?dram:article_id=322010, and there's a link to do a pre-scheduled recording with a Win/Mac tool. Best wishes Urs Liska http://lilypondblog.org/category/das-trunkne-lied http://lilypondblog.org/category/productions/fried-songs/ -- Urs Liska www.openlilylib.org From tristano.tenaglia at mail.mcgill.ca Mon Jun 15 21:28:22 2015 From: tristano.tenaglia at mail.mcgill.ca (Tristano Tenaglia) Date: Mon, 15 Jun 2015 19:28:22 +0000 Subject: [MEI-L] Mei Repeats In-Reply-To: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> Message-ID: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> Dear MEI Community, I am wondering how repeats would be encoded in MEI. From the examples that I have seen so far, @left and @right attributes inside of measure elements can be given "rptstart" or "rptend" values and programs such as Verovio will interpret them accordingly. However let's say we have multiple endings with multiple bars or a multiple bar ending that needs to be repeated several times, then I am having trouble finding some examples. I have included some sample photos to give you an idea of what I am looking for. Would anyone be able to explain or send me some sample encoding of these cases? Regards, Tristano Tenaglia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: repeatending.jpg Type: image/jpeg Size: 54237 bytes Desc: repeatending.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1st-and-2nd-Endings-All-Together.png Type: image/png Size: 10160 bytes Desc: 1st-and-2nd-Endings-All-Together.png URL: From craigsapp at gmail.com Tue Jun 16 05:36:12 2015 From: craigsapp at gmail.com (Craig Sapp) Date: Mon, 15 Jun 2015 20:36:12 -0700 Subject: [MEI-L] Mei Repeats In-Reply-To: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> Message-ID: Also it would be good to discuss how to deal with da capo sort of repeats, and how to deal with da capo with an implicit "senza ripetizioni". A somewhat extreme case occurs in Chopin's mazurka Op. 7 No. 2 in A minor: http://petrucci.mus.auth.gr/imglnks/usimg/f/f0/IMSLP00461-Chopin_-_5_Mazurkas__Op_7.pdf (pages 3 & 4) Different pianists will play the four printed sections of this piece in various ways (score says to do AABBCDDA): And Raffaele can discuss/think how to access measures in the score which is coordinated with the score. Such as if I wanted to start the performance of the score at the start of the last repetition of the A section which is at measure 1 in the score, but typically the third performance of measure 1 in a recording... ? -=+Craig On 15 June 2015 at 12:28, Tristano Tenaglia < tristano.tenaglia at mail.mcgill.ca> wrote: > Dear MEI Community, > > I am wondering how repeats would be encoded in MEI. From the examples > that I have seen so far, @left and @right attributes inside of measure > elements can be given "rptstart" or "rptend" values and programs such as > Verovio will interpret them accordingly. However let's say we have multiple > endings with multiple bars or a multiple bar ending that needs to be > repeated several times, then I am having trouble finding some examples. > > I have included some sample photos to give you an idea of what I am > looking for. > > Would anyone be able to explain or send me some sample encoding of these > cases? > > Regards, > Tristano Tenaglia > > _______________________________________________ > 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 2015-06-15 at 8.20.59 PM.png Type: image/png Size: 37742 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Tue Jun 16 16:38:00 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 16 Jun 2015 14:38:00 +0000 Subject: [MEI-L] Mei Repeats In-Reply-To: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA>, <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> Message-ID: Hi Tristano, I thought this was covered in the Guidelines, but taking a closer look, I find that it isn't. So, I'll try to explain. There are multiple aspects of repeated sections that must be taken into account. First, there are the signs found in the notation. Second, there is the question of how the signs should be interpreted in performance. The first aspect is partially covered, as you already know, by the @left and @right attributes on . The second is encoded using the element. provides the means to encode the performance order of
and elements. There could be multiple interpretations of the repeat structure, so is repeatable. Here's an encoding of the relevant portion of your first example:
The repeat signs and the ending bar are encoded using @left and @right attributes. elements are used to wrap the measures under the first and second ending brackets. In order to be able to assign an ID to the repeated part of the music (measures 1 - 8), these measures are wrapped in a child
element. It's the performance order of the children of this outer section that the element's @plist attribute describes: section A, then Ending1, section A, then Ending1, section A, then Ending2. The only other "wrinkle" is the labeling of the endings. The @n attribute can be used to give a number or name to elements, such as the endings in this case. But, since @n can only hold a single token, if you want a space in the name, it's better to use the @label attribute. (I'll leave the larger discussion of "name" vs. "label" for another time.) Your second example doesn't introduce any new problems, so I leave it to you to work out its encoding. If you run into difficulty, though, just let me know. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Tristano Tenaglia [tristano.tenaglia at mail.mcgill.ca] Sent: Monday, June 15, 2015 3:28 PM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Mei Repeats Dear MEI Community, I am wondering how repeats would be encoded in MEI. From the examples that I have seen so far, @left and @right attributes inside of measure elements can be given "rptstart" or "rptend" values and programs such as Verovio will interpret them accordingly. However let's say we have multiple endings with multiple bars or a multiple bar ending that needs to be repeated several times, then I am having trouble finding some examples. I have included some sample photos to give you an idea of what I am looking for. Would anyone be able to explain or send me some sample encoding of these cases? Regards, Tristano Tenaglia -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Tue Jun 16 17:35:49 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 16 Jun 2015 15:35:49 +0000 Subject: [MEI-L] Mei Repeats In-Reply-To: References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA>, Message-ID: Craig, Da capo, dal segno, and such can be handled using the same technique described before; that is, with . In your example, I count only 3 repeated sections, so I'm a little confused. I take it that you're saying the "bridge" (the section that begins in A major) should be repeated too. But, that section follows the "Fine." direction. This is the heart of the matter, though, isn't it? Which sections should be repeated in performance versus those that are indicated as repeated in the score. In any case, here's an encoding of the relevant portion --
Fine.
D.C. al Fine
can be repeated in order to provide differing interpretations of the repeated sections. I'll let Raffaele speak about how he intends to handle such situations as the one you describe. (I think you meant to say, "how to access measures in the *performance* which is coordinated with the score".) I believe, however, that since a can only be associated with one element (using measure/@when), the starting point of the association in this case is the element. For example, in the upcoming MEI revision one can use -- Each of the different times at which measure 1 occurs points to the measure identified as "m1". -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com] Sent: Monday, June 15, 2015 11:36 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Mei Repeats Also it would be good to discuss how to deal with da capo sort of repeats, and how to deal with da capo with an implicit "senza ripetizioni". A somewhat extreme case occurs in Chopin's mazurka Op. 7 No. 2 in A minor: http://petrucci.mus.auth.gr/imglnks/usimg/f/f0/IMSLP00461-Chopin_-_5_Mazurkas__Op_7.pdf (pages 3 & 4) Different pianists will play the four printed sections of this piece in various ways (score says to do AABBCDDA): [cid:ii_iayrudlv2_14dfa6a85d52c025] And Raffaele can discuss/think how to access measures in the score which is coordinated with the score. Such as if I wanted to start the performance of the score at the start of the last repetition of the A section which is at measure 1 in the score, but typically the third performance of measure 1 in a recording... ? -=+Craig On 15 June 2015 at 12:28, Tristano Tenaglia > wrote: Dear MEI Community, I am wondering how repeats would be encoded in MEI. From the examples that I have seen so far, @left and @right attributes inside of measure elements can be given "rptstart" or "rptend" values and programs such as Verovio will interpret them accordingly. However let's say we have multiple endings with multiple bars or a multiple bar ending that needs to be repeated several times, then I am having trouble finding some examples. I have included some sample photos to give you an idea of what I am looking for. Would anyone be able to explain or send me some sample encoding of these cases? Regards, Tristano Tenaglia _______________________________________________ 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 2015-06-15 at 8.20.59 PM.png Type: image/png Size: 37742 bytes Desc: Screen Shot 2015-06-15 at 8.20.59 PM.png URL: From pdr4h at eservices.virginia.edu Tue Jun 16 17:40:58 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 16 Jun 2015 15:40:58 +0000 Subject: [MEI-L] Mei Repeats In-Reply-To: References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA>, , Message-ID: Yikes! There's an error in the encodings I provided. The ID references in @plist should use the fragment syntax, for example -- and There's a Schematron rule planned for this in the next revision. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Tuesday, June 16, 2015 11:35 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Mei Repeats Craig, Da capo, dal segno, and such can be handled using the same technique described before; that is, with . In your example, I count only 3 repeated sections, so I'm a little confused. I take it that you're saying the "bridge" (the section that begins in A major) should be repeated too. But, that section follows the "Fine." direction. This is the heart of the matter, though, isn't it? Which sections should be repeated in performance versus those that are indicated as repeated in the score. In any case, here's an encoding of the relevant portion --
Fine.
D.C. al Fine
can be repeated in order to provide differing interpretations of the repeated sections. I'll let Raffaele speak about how he intends to handle such situations as the one you describe. (I think you meant to say, "how to access measures in the *performance* which is coordinated with the score".) I believe, however, that since a can only be associated with one element (using measure/@when), the starting point of the association in this case is the element. For example, in the upcoming MEI revision one can use -- Each of the different times at which measure 1 occurs points to the measure identified as "m1". -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com] Sent: Monday, June 15, 2015 11:36 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Mei Repeats Also it would be good to discuss how to deal with da capo sort of repeats, and how to deal with da capo with an implicit "senza ripetizioni". A somewhat extreme case occurs in Chopin's mazurka Op. 7 No. 2 in A minor: http://petrucci.mus.auth.gr/imglnks/usimg/f/f0/IMSLP00461-Chopin_-_5_Mazurkas__Op_7.pdf (pages 3 & 4) Different pianists will play the four printed sections of this piece in various ways (score says to do AABBCDDA): [cid:ii_iayrudlv2_14dfa6a85d52c025] And Raffaele can discuss/think how to access measures in the score which is coordinated with the score. Such as if I wanted to start the performance of the score at the start of the last repetition of the A section which is at measure 1 in the score, but typically the third performance of measure 1 in a recording... ? -=+Craig On 15 June 2015 at 12:28, Tristano Tenaglia > wrote: Dear MEI Community, I am wondering how repeats would be encoded in MEI. From the examples that I have seen so far, @left and @right attributes inside of measure elements can be given "rptstart" or "rptend" values and programs such as Verovio will interpret them accordingly. However let's say we have multiple endings with multiple bars or a multiple bar ending that needs to be repeated several times, then I am having trouble finding some examples. I have included some sample photos to give you an idea of what I am looking for. Would anyone be able to explain or send me some sample encoding of these cases? Regards, Tristano Tenaglia _______________________________________________ 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 2015-06-15 at 8.20.59 PM.png Type: image/png Size: 37742 bytes Desc: Screen Shot 2015-06-15 at 8.20.59 PM.png URL: From raffaeleviglianti at gmail.com Tue Jun 16 17:52:46 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 16 Jun 2015 11:52:46 -0400 Subject: [MEI-L] Mei Repeats In-Reply-To: References: <9CE8EC68FFC4AC4B8AF7706427D5BAF010D3302E@EXMBX2010-5.campus.MCGILL.CA> <9CE8EC68FFC4AC4B8AF7706427D5BAF010D34045@EXMBX2010-5.campus.MCGILL.CA> Message-ID: On Tue, Jun 16, 2015 at 11:35 AM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > I'll let Raffaele speak about how he intends to handle such situations > as the one you describe. (I think you meant to say, "how to access measures > in the *performance* which is coordinated with the score".) > I wouldn't want to do with an addressing system such as EMA. It is meant to allow addressing the score, not the performance. It could be used in conjunction with time stamps to associate a segment of audio with the specific measure on the score regardless of how many times it has been played. This is the same idea as Perry's solution with . Raff > I believe, however, that since a can only be associated with > one element (using measure/@when), the starting point of the > association in this case is the element. For example, in the > upcoming MEI revision one can use -- > > > > > > > > > > Each of the different times at which measure 1 occurs points to the > measure identified as "m1". > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig > Sapp [craigsapp at gmail.com] > *Sent:* Monday, June 15, 2015 11:36 PM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Mei Repeats > > Also it would be good to discuss how to deal with da capo sort of > repeats, and how to deal with da capo with an implicit "senza ripetizioni". > > A somewhat extreme case occurs in Chopin's mazurka Op. 7 No. 2 in A > minor: > > http://petrucci.mus.auth.gr/imglnks/usimg/f/f0/IMSLP00461-Chopin_-_5_Mazurkas__Op_7.pdf > (pages 3 & 4) > > Different pianists will play the four printed sections of this piece in > various ways (score says to do AABBCDDA): > > > And Raffaele can discuss/think how to access measures in the score which > is coordinated with the score. Such as if I wanted to start the > performance of the score at the start of the last repetition of the A > section which is at measure 1 in the score, but typically the third > performance of measure 1 in a recording... > ? > > -=+Craig > > > > > > > On 15 June 2015 at 12:28, Tristano Tenaglia < > tristano.tenaglia at mail.mcgill.ca> wrote: > >> Dear MEI Community, >> >> I am wondering how repeats would be encoded in MEI. From the examples >> that I have seen so far, @left and @right attributes inside of measure >> elements can be given "rptstart" or "rptend" values and programs such as >> Verovio will interpret them accordingly. However let's say we have multiple >> endings with multiple bars or a multiple bar ending that needs to be >> repeated several times, then I am having trouble finding some examples. >> >> I have included some sample photos to give you an idea of what I am >> looking for. >> >> Would anyone be able to explain or send me some sample encoding of >> these cases? >> >> Regards, >> Tristano Tenaglia >> >> _______________________________________________ >> 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 2015-06-15 at 8.20.59 PM.png Type: image/png Size: 37742 bytes Desc: not available URL: From jaw475 at gmail.com Wed Jun 17 12:39:50 2015 From: jaw475 at gmail.com (Jennifer Ward) Date: Wed, 17 Jun 2015 12:39:50 +0200 Subject: [MEI-L] RISM at MEC 2015 Message-ID: Dear colleagues, I enjoyed meeting you at the MEC conference in Florence. I wrote a brief report of the conference for the RISM website today if you are interested: http://www.rism.info/en/home/newsdetails/article/2/rism-at-the-music-encoding-conference-florence-italy.html Of course, the emphasis is on RISM, but I linked to the projects and slides that I could find online. If I didn't link to your project, don't take it personally, I probably didn't do a good job looking. Send me links to materials and I'd be happy to post them. Der Beitrag ist nat?rlich auch in deutscher ?bersetzung zu lesen: http://www.rism.info/de/startseite/newsdetails/article/2/rism-at-the-music-encoding-conference-florence-italy.html Hope to see many of you at the IAML/IMS congress in New York next week! Best, Jennifer ___ Jennifer Ward RISM Zentralredaktion Frankfurt, Germany jennifer.ward at rism.info -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Wed Jun 17 19:53:52 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 17 Jun 2015 17:53:52 +0000 Subject: [MEI-L] =?utf-8?q?Save_the_date=3A_Music_Encoding_Conference_17?= =?utf-8?q?=E2=80=9320_May_2016?= Message-ID: <478FA11E-0852-471D-9E75-AA0CA150B702@mail.mcgill.ca> Dear colleagues, As mentioned in Florence, we are pleased to invite you to attend next year's Music Encoding Conference in Montreal, at the Schulich School of Music, McGill University, 17?20 May 2016. The Music Encoding Conference has emerged as one of the most important venues for scholars, editors, publishers, and software developers to meet and discuss digital music notation encoding, and its implications for digital scholarship. Although hosted by the Music Encoding Initiative, we invite members of all music encoding communities to participate and help move digital music notation forward. Further details about the call for papers, program, keynote speakers, and accommodations in Montreal will be posted to the conference website: http://music-encoding.org/mec2016/ We're looking forward to seeing you next May in Montreal! Ichiro Fujinaga Andrew Hankinson McGill University Twitter: #mec2016 From bohl at edirom.de Thu Jun 18 07:33:45 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 18 Jun 2015 07:33:45 +0200 Subject: [MEI-L] SibMei, XSLT MusicXML to MEI and MEISE problems In-Reply-To: <5CB99FA7-FBA3-4315-BD7A-5D196D795B58@mail.mcgill.ca> References: <8767_1433850759_5576D386_8767_258_1_trinity-116d3e5a-a44b-4aa7-9d94-1bc4c17c422a-1433850738766@3capp-gmx-bs15> <5CB99FA7-FBA3-4315-BD7A-5D196D795B58@mail.mcgill.ca> Message-ID: <55825839.2060109@edirom.de> Dear Robert, concerning your XSLT problem it would be very helpful to have the MusicXML file available for testing. IS that possible? best wishes benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freisch?tz Digital" Benjamin Wolff Bohl Gartenstra?e 20 D?32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 09.06.2015 um 16:00 schrieb Andrew Hankinson: > Hi Robert, > > When did you download and install the plugin? I've been working on it, > so it gets updated frequently. The problems you're having with note > durations sounds like a bug that was fixed a couple months ago, so if > you're running a version that is older than that I would suggest > updating to the latest version and seeing if the problem persists. > > If it does, I would be interested to see the file that produces the > problems. > > As for the second one -- it sounds like the software you're using to > produce the MusicXML (Sibelius?) is encoding it in such a way that > parttime.xsl cannot parse it. As an experiment you might try exporting > to MusicXML, loading it into another MusicXML program (Finale or > MuseScore) and then exporting again. > > -Andrew > >> On Jun 9, 2015, at 7:52 AM, RKlugseder at gmx.de >> wrote: >> >> Dear colleagues, >> First time here and MEI beginner. Have some troubles with SibMEI and >> MusicXML to MEI stylesheet. >> 1. I use the SibMEI plugin in Sibelius 7.5. The transformation is >> (more or less) ok, but with some errors: >> - no or wrong wordpos in >> - duration and dots twice, in AND the childs >> - accidentals twice, in front of the staff (key.sig) AND in every >> element >> - some wrong durations in doted notes (e.g. every dotted 4 was >> transformed into a dotted 8). >> 2. musicxml2mei-3.0.xsl to MEI >> I use musicxml2mei in Oxygen (XSLT scenario with Saxon PE 9.6.0.5) >> but get always a (nearly) empty result file (only with the >> declaration and the schema). >> with parttime.xsl before, this error message: >> Programmname: Saxon-PE 9.6.0.5 >> Fehlerlevel: fatal >> Beschreibung: XPTY0004: A sequence of more than one item is not >> allowed as the first argument of evaluate() ("4", "4") >> Anfang: 3818:0 >> Thanks for your help >> Robert >> _________________________ >> Robert Klugseder, PhD >> Austrian Academy of Sciences >> Department for Musicology >> Dr. Ignaz Seipel-Platz 2 >> A-1010 WIEN >> +43/699/11192366 >> _______________________________________________ >> 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 -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From raffaeleviglianti at gmail.com Mon Jul 13 01:17:40 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sun, 12 Jul 2015 19:17:40 -0400 Subject: [MEI-L] Combining MEI ornament elements Message-ID: Dear list, I was wondering if it is possible to combine two ornaments in MEi to describe one ornament on the page. (Please forgive any possible misunderstandings because of my limited knowledge of ornamentation outside of common symbols and little more.) For example how could I encode the type of mordent that in SMuFL is called "mordent with release"? http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/ The MEI encoding would definitely depend on context. Factors that will determine the encoding are: what kind of score is it in; who is the composer; which geographical place is the composer writing in; time/era of composition; and many more. Either way, none of the MEI elements , , and will be able to represent it adequately on its own. It will need to be a combination of those elements. Based solely on my training as a pianist, I would guess that this ornament should be treated as a trill plus a turn. If it were on a c note, I would resolve it as d-c-d-c d-c-b-c. I might be wrong about the exact resolution, but bear with me for the sake of discussing combining MEI ornaments. So I could encode this "mordent with release" with: I could then connect them together with @prev and @next That could be enough for what MEI is concerned. Do you agree? Is there a better way of encoding this? Finally, what if I wanted to map this to a specific rendition? eg to a SMuFL code, or my own SVG drawing? -- if I understand correctly, this is what the user defined symbol module is for (for some elements) [1]. However, there is currently no way of using the user defined symbol module for mapping one ornament element to a symbol. Though there is good reason to believe this is in the process of being adjusted for the 2015 release [2] [3]. This will likely be done with @altsym, and/or other dedicated attributes. But even with that upgrade in mind, how would I map my "combined" elements with one symbol? The only solution I could think of is a bit redundant, ideas? (this is invalid in MEI 2014, but possibly valid in 2015) Thanks, Raff [1] http://music-encoding.org/documentation/2.1.1/userSymbols/ [2] https://github.com/music-encoding/music-encoding/issues/232 [3] https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Mon Jul 13 17:28:10 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 13 Jul 2015 15:28:10 +0000 Subject: [MEI-L] Combining MEI ornament elements In-Reply-To: References: Message-ID: Hi Raffaele, The short answer is, , , and can’t be combined to represent more complex ornaments. The longer answer is, they weren’t intended to be used that way. These elements are named, simple instances of the more generic element , which should be used in cases like this. One can use character entity references to either Unicode or SMuFL entities to indicate the desired symbol For example, The resolution of such directives should be encoded inside the stream of events; that is, within . The notated and performed versions can be wrapped with and its sub-elements such as and . -- p. From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Sunday, July 12, 2015 7:18 PM To: Music Encoding Initiative Subject: [MEI-L] Combining MEI ornament elements Dear list, I was wondering if it is possible to combine two ornaments in MEi to describe one ornament on the page. (Please forgive any possible misunderstandings because of my limited knowledge of ornamentation outside of common symbols and little more.) For example how could I encode the type of mordent that in SMuFL is called "mordent with release"? http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/ The MEI encoding would definitely depend on context. Factors that will determine the encoding are: what kind of score is it in; who is the composer; which geographical place is the composer writing in; time/era of composition; and many more. Either way, none of the MEI elements , , and will be able to represent it adequately on its own. It will need to be a combination of those elements. Based solely on my training as a pianist, I would guess that this ornament should be treated as a trill plus a turn. If it were on a c note, I would resolve it as d-c-d-c d-c-b-c. I might be wrong about the exact resolution, but bear with me for the sake of discussing combining MEI ornaments. So I could encode this "mordent with release" with: I could then connect them together with @prev and @next That could be enough for what MEI is concerned. Do you agree? Is there a better way of encoding this? Finally, what if I wanted to map this to a specific rendition? eg to a SMuFL code, or my own SVG drawing? -- if I understand correctly, this is what the user defined symbol module is for (for some elements) [1]. However, there is currently no way of using the user defined symbol module for mapping one ornament element to a symbol. Though there is good reason to believe this is in the process of being adjusted for the 2015 release [2] [3]. This will likely be done with @altsym, and/or other dedicated attributes. But even with that upgrade in mind, how would I map my "combined" elements with one symbol? The only solution I could think of is a bit redundant, ideas? (this is invalid in MEI 2014, but possibly valid in 2015) Thanks, Raff [1] http://music-encoding.org/documentation/2.1.1/userSymbols/ [2] https://github.com/music-encoding/music-encoding/issues/232 [3] https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaeleviglianti at gmail.com Mon Jul 13 18:14:40 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 13 Jul 2015 12:14:40 -0400 Subject: [MEI-L] Combining MEI ornament elements In-Reply-To: References: Message-ID: Hi Perry, Thanks! Looks like I made this more complicated than it needed to be. If this is the recommended encoding for these cases, Chapter 8 of the guidelines should probably recommend and explain this use of . Best, Raff On Mon, Jul 13, 2015 at 11:28 AM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Hi Raffaele, > > > > The short answer is, , , and can’t be combined to > represent more complex ornaments. > > > > The longer answer is, they weren’t intended to be used that way. These > elements are named, simple instances of the more generic element , > which should be used in cases like this. One can use character entity > references to either Unicode or SMuFL entities to indicate the desired > symbol For example, > > > > > > > > The resolution of such directives should be encoded inside the stream of > events; that is, within . The notated and performed versions can be > wrapped with and its sub-elements such as and . > > > > > > > > > > > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces+pdr4h= > virginia.edu at lists.uni-paderborn.de] *On Behalf Of *Raffaele Viglianti > *Sent:* Sunday, July 12, 2015 7:18 PM > *To:* Music Encoding Initiative > *Subject:* [MEI-L] Combining MEI ornament elements > > > > Dear list, > > > > I was wondering if it is possible to combine two ornaments in MEi to > describe one ornament on the page. > > > > (Please forgive any possible misunderstandings because of my limited > knowledge of ornamentation outside of common symbols and little more.) > > > > For example how could I encode the type of mordent that in SMuFL is called > "mordent with release"? > http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/ > > > > The MEI encoding would definitely depend on context. Factors that will > determine the encoding are: what kind of score is it in; who is the > composer; which geographical place is the composer writing in; time/era of > composition; and many more. > > > > Either way, none of the MEI elements , , and will > be able to represent it adequately on its own. It will need to be a > combination of those elements. > > > > Based solely on my training as a pianist, I would guess that this ornament > should be treated as a trill plus a turn. If it were on a c note, I would > resolve it as d-c-d-c d-c-b-c. > > I might be wrong about the exact resolution, but bear with me for the sake > of discussing combining MEI ornaments. > > > > So I could encode this "mordent with release" with: > > > > > > > > > > I could then connect them together with @prev and @next > > > > > > > > > > That could be enough for what MEI is concerned. Do you agree? Is there a > better way of encoding this? > > > > Finally, what if I wanted to map this to a specific rendition? eg to a > SMuFL code, or my own SVG drawing? -- if I understand correctly, this is > what the user defined symbol module is for (for some elements) [1]. > > > > However, there is currently no way of using the user defined symbol module > for mapping one ornament element to a symbol. Though there is good reason > to believe this is in the process of being adjusted for the 2015 release > [2] [3]. This will likely be done with @altsym, and/or other dedicated > attributes. > > > > But even with that upgrade in mind, how would I map my "combined" elements > with one symbol? The only solution I could think of is a bit redundant, > ideas? > > > > > > > > (this is invalid in MEI 2014, but possibly valid in 2015) > > > > Thanks, > > Raff > > > > [1] http://music-encoding.org/documentation/2.1.1/userSymbols/ > > [2] https://github.com/music-encoding/music-encoding/issues/232 > > [3] > https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042 > > > > > > > > > > > > _______________________________________________ > 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 zolaemil at gmail.com Mon Jul 13 18:50:50 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Mon, 13 Jul 2015 17:50:50 +0100 Subject: [MEI-L] Combining MEI ornament elements In-Reply-To: References: Message-ID: Hi Perry, The schema currently clearly defines as "a text expression", but in the notes it says it also includes "music symbols, such as segno and coda symbols, fermatas over a bar line, etc." Maybe the definition could be improved to clear up the confusion? Perhaps something like: "an instruction expressed either as text or as a symbol, such as segno and coda symbols, fermatas over a bar line, etc."? Zoltan 2015-07-13 17:14 GMT+01:00 Raffaele Viglianti : > Hi Perry, > > Thanks! Looks like I made this more complicated than it needed to be. If > this is the recommended encoding for these cases, Chapter 8 of the > guidelines should probably recommend and explain this use of . > > Best, > Raff > > On Mon, Jul 13, 2015 at 11:28 AM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> >> >> Hi Raffaele, >> >> >> >> The short answer is, , , and can’t be combined to >> represent more complex ornaments. >> >> >> >> The longer answer is, they weren’t intended to be used that way. These >> elements are named, simple instances of the more generic element , >> which should be used in cases like this. One can use character entity >> references to either Unicode or SMuFL entities to indicate the desired >> symbol For example, >> >> >> >> >> >> >> >> The resolution of such directives should be encoded inside the stream of >> events; that is, within . The notated and performed versions can be >> wrapped with and its sub-elements such as and . >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> p. >> >> >> >> >> >> *From:* mei-l [mailto:mei-l-bounces+pdr4h= >> virginia.edu at lists.uni-paderborn.de] *On Behalf Of *Raffaele Viglianti >> *Sent:* Sunday, July 12, 2015 7:18 PM >> *To:* Music Encoding Initiative >> *Subject:* [MEI-L] Combining MEI ornament elements >> >> >> >> Dear list, >> >> >> >> I was wondering if it is possible to combine two ornaments in MEi to >> describe one ornament on the page. >> >> >> >> (Please forgive any possible misunderstandings because of my limited >> knowledge of ornamentation outside of common symbols and little more.) >> >> >> >> For example how could I encode the type of mordent that in SMuFL is >> called "mordent with release"? >> http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/ >> >> >> >> The MEI encoding would definitely depend on context. Factors that will >> determine the encoding are: what kind of score is it in; who is the >> composer; which geographical place is the composer writing in; time/era of >> composition; and many more. >> >> >> >> Either way, none of the MEI elements , , and will >> be able to represent it adequately on its own. It will need to be a >> combination of those elements. >> >> >> >> Based solely on my training as a pianist, I would guess that this >> ornament should be treated as a trill plus a turn. If it were on a c note, >> I would resolve it as d-c-d-c d-c-b-c. >> >> I might be wrong about the exact resolution, but bear with me for the >> sake of discussing combining MEI ornaments. >> >> >> >> So I could encode this "mordent with release" with: >> >> >> >> >> >> >> >> >> >> I could then connect them together with @prev and @next >> >> >> >> >> >> >> >> >> >> That could be enough for what MEI is concerned. Do you agree? Is there a >> better way of encoding this? >> >> >> >> Finally, what if I wanted to map this to a specific rendition? eg to a >> SMuFL code, or my own SVG drawing? -- if I understand correctly, this is >> what the user defined symbol module is for (for some elements) [1]. >> >> >> >> However, there is currently no way of using the user defined symbol >> module for mapping one ornament element to a symbol. Though there is good >> reason to believe this is in the process of being adjusted for the 2015 >> release [2] [3]. This will likely be done with @altsym, and/or other >> dedicated attributes. >> >> >> >> But even with that upgrade in mind, how would I map my "combined" >> elements with one symbol? The only solution I could think of is a bit >> redundant, ideas? >> >> >> >> >> >> > altsym="#combinedSymbol"/> >> >> (this is invalid in MEI 2014, but possibly valid in 2015) >> >> >> >> Thanks, >> >> Raff >> >> >> >> [1] http://music-encoding.org/documentation/2.1.1/userSymbols/ >> >> [2] https://github.com/music-encoding/music-encoding/issues/232 >> >> [3] >> https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042 >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Jul 13 19:28:06 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 13 Jul 2015 17:28:06 +0000 Subject: [MEI-L] Combining MEI ornament elements In-Reply-To: References: Message-ID: In a way, symbols mixed with text, or even symbols alone, are “text expressions” in that they’re one step removed from the events of the staff/layer. But, I see your point. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán Sent: Monday, July 13, 2015 12:51 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Combining MEI ornament elements Hi Perry, The schema currently clearly defines as "a text expression", but in the notes it says it also includes "music symbols, such as segno and coda symbols, fermatas over a bar line, etc." Maybe the definition could be improved to clear up the confusion? Perhaps something like: "an instruction expressed either as text or as a symbol, such as segno and coda symbols, fermatas over a bar line, etc."? Zoltan 2015-07-13 17:14 GMT+01:00 Raffaele Viglianti >: Hi Perry, Thanks! Looks like I made this more complicated than it needed to be. If this is the recommended encoding for these cases, Chapter 8 of the guidelines should probably recommend and explain this use of . Best, Raff On Mon, Jul 13, 2015 at 11:28 AM, Roland, Perry D. (pdr4h) > wrote: Hi Raffaele, The short answer is, , , and can’t be combined to represent more complex ornaments. The longer answer is, they weren’t intended to be used that way. These elements are named, simple instances of the more generic element , which should be used in cases like this. One can use character entity references to either Unicode or SMuFL entities to indicate the desired symbol For example, The resolution of such directives should be encoded inside the stream of events; that is, within . The notated and performed versions can be wrapped with and its sub-elements such as and . -- p. From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Sunday, July 12, 2015 7:18 PM To: Music Encoding Initiative Subject: [MEI-L] Combining MEI ornament elements Dear list, I was wondering if it is possible to combine two ornaments in MEi to describe one ornament on the page. (Please forgive any possible misunderstandings because of my limited knowledge of ornamentation outside of common symbols and little more.) For example how could I encode the type of mordent that in SMuFL is called "mordent with release"? http://www.smufl.org/version/latest/glyph/ornamentPrecompMordentRelease/ The MEI encoding would definitely depend on context. Factors that will determine the encoding are: what kind of score is it in; who is the composer; which geographical place is the composer writing in; time/era of composition; and many more. Either way, none of the MEI elements , , and will be able to represent it adequately on its own. It will need to be a combination of those elements. Based solely on my training as a pianist, I would guess that this ornament should be treated as a trill plus a turn. If it were on a c note, I would resolve it as d-c-d-c d-c-b-c. I might be wrong about the exact resolution, but bear with me for the sake of discussing combining MEI ornaments. So I could encode this "mordent with release" with: I could then connect them together with @prev and @next That could be enough for what MEI is concerned. Do you agree? Is there a better way of encoding this? Finally, what if I wanted to map this to a specific rendition? eg to a SMuFL code, or my own SVG drawing? -- if I understand correctly, this is what the user defined symbol module is for (for some elements) [1]. However, there is currently no way of using the user defined symbol module for mapping one ornament element to a symbol. Though there is good reason to believe this is in the process of being adjusted for the 2015 release [2] [3]. This will likely be done with @altsym, and/or other dedicated attributes. But even with that upgrade in mind, how would I map my "combined" elements with one symbol? The only solution I could think of is a bit redundant, ideas? (this is invalid in MEI 2014, but possibly valid in 2015) Thanks, Raff [1] http://music-encoding.org/documentation/2.1.1/userSymbols/ [2] https://github.com/music-encoding/music-encoding/issues/232 [3] https://github.com/music-encoding/music-encoding/issues/214#issuecomment-118944042 _______________________________________________ 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 nikolaos.beer at uni-paderborn.de Thu Jul 16 21:53:21 2015 From: nikolaos.beer at uni-paderborn.de (Nikolaos Beer) Date: Thu, 16 Jul 2015 21:53:21 +0200 Subject: [MEI-L] =?utf-8?q?Edirom-Summer-School_2015_=E2=80=93_Registratio?= =?utf-8?q?n_is_open!?= Message-ID: Dear list members, summer time is time for our next Edirom-Summer-School (ESS2015) which will take place in Paderborn/Germany from 7.-11. September. This is your chance to register (http://ess.upb.de/2015/registrierung.html ) for at least three directly MEI related workshops hosted by some of our well-known MEI specialists on the list. First, there will be our MEI Introduction (in German) with Maja Hartwig and Kristina Richts who will induct you into the basic secrets of encoding music content and metadata in MEI. Are you especially interested in MEI's capabilities in the field of metadata? Then you can register for our advanced MEI Metadata workshop (also in German) with Kristina Richts and Axel Teich Geertinger who will guide you through the many and varied ways of storing metadata in MEI for purposes like long time preservation, source description and/or cataloguing with MerMEId. Do you already have MEI content and do you want to start doing "something" with this as a tool developer? Then please look at our MEI Tool Development workshop (in English!) with Andrew Hankinson (McGill, CA), Laurent Pugin (RISM CH) and Johannes Kepper (UPB). They will present some of the most promising MEI software libraries and renderers developed in different projects and give you hints in hands-on sessions on how to facilitate them in your own tool ideas. There are many more interesting workshops within our ESS2015 program. You can learn about our Edirom Tools, TEI and ODD, about advanced working methods with XML data and eXist-db tool development. We also provide one expert workshop about (mostly german) legal issues when using and producing digital data in research and edition projects. Finally, there will be a workshop about different organizational and technical aspects in planing and realizing a digital edition project. Please find further information about the ESS2015's program schedule and registration on our website at http://ess.upb.de. In case of any questions about the ESS2015, please feel free to contact the organization team at ess at edirom.de. We hope to see you in September in Paderborn! For the ESS2015 organization team Nikolaos Beer ******** The Edirom-Summer-School 2015 is organized by the Virtual Research Group Edirom and the german eHumanities project DARIAH-DE. The Virtual Research Group Edirom is based at the Musicology Seminar Detmold/Paderborn, which is a co-faculty of the University of Paderborn and the Hochschule für Musik Detmold. Please find further information at http://www.edirom.de. DARIAH-DE is the German part of the EU eHumanities research project Digital Research Infrastructure for the Arts and Humanities. It is funded by the German Federal Ministry of Education and Research. Please find further information at http://de.dariah.eu. The Edirom-Summer-School 2015 on the internet: http://ess.upb.de Follow us on Twitter: https://twitter.com/edirom or #edirom2015 ******** ___________________________________ Nikolaos Beer M.A. Wissenschaftlicher Mitarbeiter BMBF-Projekt „DARIAH-DE“ und Verbundstelle Musikedition Universität Paderborn Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstraße 20 D-32756 Detmold Fon: +49 - (0)5231 - 975 - 669 @: nikolaos.beer at uni-paderborn.de -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kelnreiter at mozarteum.at Tue Jul 21 21:25:31 2015 From: kelnreiter at mozarteum.at (Franz Kelnreiter) Date: Tue, 21 Jul 2015 21:25:31 +0200 Subject: [MEI-L] Music Encoding Conference - Call for Proposals Message-ID: <55AE9CAB.10408@mozarteum.at> Dear colleagues, I am pleased to announce that the Call for Papers of the next Music Encoding Conference (http://music-encoding.org/mec2016/) has just been released:: You are cordially invited by the Music Encoding Initiative community to participate in the Music Encoding Conference, which will be held **18-19 May 2016** (with pre-conference workshops on 17 May and an "un-conference" day on 20 May) in Montreal, Canada, in cooperation with McGill University. Music encoding is a critical component of the emerging fields of digital musicology, digital editions, symbolic music information retrieval, and others. At the centre of these fields, the Music Encoding Conference has emerged as an important cross-disciplinary venue for theorists, musicologists, librarians, and technologists to meet and discuss new advances in their fields. The Music Encoding Conference is the annual focal point for the Music Encoding Initiative community (http://music-encoding.org), but members from all encoding and analysis communities are welcome to participate. Proposals for papers, posters, panel discussions, and pre-conference workshops are encouraged. Suggested topics include, but are not limited to: - music encoding as a theoretical approach for research - methodologies for encoding, music editing, description and analysis - rendering of symbolic music data in audio and graphical forms - relationships between symbolic music data, encoded text, and facsimile images - capture, interchange, and re-purposing of music data and metadata - ontologies, authority files, and linked data in music encoding and description - additional topics relevant to music encoding, editing, and description The deadline for all submissions is **15 October 2015**. ConfTool accepts PDF files only. The submission to ConfTool must include: - name(s) of author(s) - title - abstract - current or most recent institutional affiliation of author(s) and e-mail address - proposal type: paper, poster, panel session, or workshop All identifying information must be provided in the corresponding fields of ConfTool only, while the submitted PDF must be anonymized. For **paper** and **poster** proposals, abstracts of no more than 1000 words, including relevant bibliographic references, are requested. Please also include a short statement regarding your current interests related to music encoding. **Panel session** proposals, describing the topic and nature of the session and including short biographies of the participants, must be no longer than 2000 words. Proposals for half- or full-day pre-conference **workshops**, to be held on May 17th, should include the workshop's proposed duration, as well as its logistical and technical requirements. Friday is planned as **unconference day**, self-organized by the participants and open for anyone who wants to initiate a discussion on a topic mentioned above. Additional details regarding registration, accommodations, etc. will be announced on the conference web page (http://music-encoding.org/community/conference/). Important Dates --------------- 15 October 2015: Deadline for abstract submissions 15 December 2015: Notification of acceptance of submissions 17 May 2016: Pre-conference workshops 18-19 May 2016: Conference 20 May 2016: Un-conference Day If you have any questions, please e-mail conference at music-encoding.org. Program Committee ----------------- - Richard Chesser, British Library - Franz Kelnreiter, Internationale Stiftung Mozarteum Salzburg (chair) - Eleanor Selfridge-Field (Stanford University) - Peter Stadler (Carl-Maria-von-Weber-Gesamtausgabe) - Raffaele Viglianti (University of Maryland) Organizing Committee --------------------- - Ryan Bannon, McGill University - Karen Desmond, McGill University - Ichiro Fujinaga, McGill University (co-chair) - Andrew Hankinson, McGill University (co-chair) - Emily Hopkins, McGill University - Audrey Laplante, Université de Montréal - Laura Risk, McGill University -- Franz Kelnreiter Mozart-Institut / Digitale Mozart-Edition Internationale Stiftung Mozarteum Schwarzstr. 26 5020 Salzburg, Austria T +43 (0) 662 889 40 69 F +43 (0) 662 889 40 68 E kelnreiter at mozarteum.at www.mozarteum.at - http://dme.mozarteum.at Newsletter Stiftung Mozarteum Facebook Stiftung Mozarteum ZVR: 438729131, UID: ATU33977907 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x16DA0218.asc Type: application/pgp-keys Size: 1718 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Tue Jul 28 20:58:39 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 28 Jul 2015 18:58:39 +0000 Subject: [MEI-L] FW: Invitation to New W3C Music Notation Community Group In-Reply-To: <55B7CABF.1000809@w3.org> References: <55B7CABF.1000809@w3.org> Message-ID: Hello everyone, This appears to be an open invitation for anyone interested in music notation on the web to join the group, so consider yourselves invited. Hoping everyone's having a great summer, -- p. > -----Original Message----- > From: Doug Schepers [mailto:schepers at w3.org] > Sent: Tuesday, July 28, 2015 2:33 PM > To: Andrew Hankinson; Ardal Powell; Barbara Mackenzie; Bob Hamblok; Bob Judd; > Frans Wiering; Ichiro Fujinaga; Jonathan Greenberg; Laurent Pugin; Michael Scott > Cuthbert; Roland, Perry D. (pdr4h); Richard Freedman; Zdravko Blazekovic > Cc: Joseph Berkovitz; Michael Good; Daniel Spreadbury > Subject: Invitation to New W3C Music Notation Community Group > > Hi, folks– > > You were all recommended to me as people interested in digital music > notation. Some of you I've exchanged emails with before. > > Late last year, there were preliminary informal discussions about > digital music notation standards as a W3C Community Group; I'm not > really involved in this topic, but was brought in because of my > association with W3C (the Web standards organization) and our Audio > Working Group. There is obvious overlap between the Web Audio API, the > Web MIDI API, and interest in music notation, and I'm personally > interested in making sure that significant structured artifacts of human > culture, like music notation, can be represented on the Web. > > After much discussion among various communities, the principle leads for > MusicXML and SMuFL, Michael Good and Daniel Spreadbury, agreed that > W3C's Community Groups would be a good place to develop these > specifications further. Joe Berkovitz from Noteflight helped drive this, > and I was honored to help facilitate the process of creating a Music > Notation Community Group [1], which launched yesterday. > > W3C offers the Community Group framework as an free and open discussion > area for possible future standards; there is no cost to participate in a > W3C Community Group. Of course, MusicXML is already a defacto standard, > by merit of its wide adoption among music notation software, but there > is an opportunity to help make it more natively "Webby", which is what > makes W3C a good home. To be clear, W3C Community Groups don't produce > formal W3C standards, but sufficiently mature and well-developed > informal specifications can be taken up by W3C for formal standardization. > > The goal of the Music Notation Community Group is to foster open > discussion, and to create technical documents that are useful to the > music notation, and which may become standards. In addition to > conversation, this may include collecting use cases and requirements, > making interoperability tests, and drafting proposals for specification > text. > > While MusicXML is one of the two initial inputs into the Music Notation > Community Group, this doesn't preclude discussion of the Music Encoding > Initiative (MEI) or other digital music notation projects or approaches. > We invite everyone to participate, and hope that a wide variety of > experts in the notation community will join the Music Notation CG [2] > and have a lively, friendly, and productive discussion! > > Please feel free to invite other people interested in technical > discussion of digital music notation, or to pass this email along. > > [1] https://www.w3.org/community/music-notation/ > [2] https://www.w3.org/community/music-notation/join/ > > Regards- > -Doug From pdr4h at eservices.virginia.edu Tue Jul 28 21:01:23 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 28 Jul 2015 19:01:23 +0000 Subject: [MEI-L] FW: [ISMIR-Community] New W3C Music Notation Community Group In-Reply-To: <05F6E186-37B5-4484-AAC5-23D705D6587D@makemusic.com> References: <94eb2c092018bd3f48051bee094f@google.com> <05F6E186-37B5-4484-AAC5-23D705D6587D@makemusic.com> Message-ID: Hello again, A different message, with additional details, posted to the ISMIR-Community list. Again, if you’re interested in these efforts, I encourage you to join the group. -- p. From: Michael Good [mailto:mgood at makemusic.com] Sent: Tuesday, July 28, 2015 2:27 PM To: community at ismir.net Subject: [ISMIR-Community] New W3C Music Notation Community Group Dear ISMIR colleagues, A new Music Notation Community Group has formed at the W3C (World Wide Web Consortium). Membership in the Community Group is free of charge and does not require membership in the W3C. The group's home is at https://www.w3.org/community/music-notation/ The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases. The initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications. MakeMusic and Steinberg have announced today that they are transferring development of the MusicXML format and the SMuFL specification to this W3C Community Group. Daniel Spreadbury of Steinberg, Joe Berkovitz of Hal Leonard / Noteflight, and I are serving as co-chairs. There is a more detailed discussion about what led to the formation of this group at its new blog: https://www.w3.org/community/music-notation/2015/07/27/introducing-the-music-notation-community-group/ You can join the group by clicking on the "Join This Group" button at the group's home page. Members of the Community Group do need to set up a free W3C account, and agree to a Contributor License Agreement. If you work on music notation for an organization, please be sure to join on behalf of your organization. The agreement is available at: https://www.w3.org/community/about/agreements/cla/ This is an exciting day for open standards for music notation, and we are looking forward to the next chapter of music notation standards development at our new organizational home. Best regards, Michael _________________________________ Michael Good VP Research and Development MakeMusic, Inc. www.makemusic.com -- Reminder: ISMIR 2015 will take place in Malaga, Spain, October 26th-30th, 2015 -- Conference Website -- http://ismir2015.ismir.net/ ISMIR Home -- http://www.ismir.net/ --- You received this message because you are subscribed to the Google Groups "Community Announcements" group. To unsubscribe from this group and stop receiving emails from it, send an email to community+unsubscribe at ismir.net. To post to this group, send email to community at ismir.net. Visit this group at http://groups.google.com/a/ismir.net/group/community/. To view this discussion on the web visit https://groups.google.com/a/ismir.net/d/msgid/community/05F6E186-37B5-4484-AAC5-23D705D6587D%40makemusic.com. For more options, visit https://groups.google.com/a/ismir.net/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikolaos.beer at uni-paderborn.de Fri Aug 14 06:40:46 2015 From: nikolaos.beer at uni-paderborn.de (Nikolaos Beer) Date: Fri, 14 Aug 2015 06:40:46 +0200 Subject: [MEI-L] Pictures from MEC2015 In-Reply-To: <1433166005.2348.1@smtp.gmail.com> References: <553A7A47-C701-4281-B27E-9E32CE515B47@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D10122840ECA@EXCHANGE-03.kb.dk> <1433166005.2348.1@smtp.gmail.com> Message-ID: <6F5AD697-3A2A-4186-8953-8B2B49576517@uni-paderborn.de> Dear list members, finally got some time to take a look at my pictures from Florence/MEC 2015. Please find them here: https://www.icloud.com/sharedalbum/#B095qXGF1fmJSl I will leave them there until the end of September. All the best Niko > Am 01.06.2015 um 15:40 schrieb Klaus Rettinghaus : > > I made some (terrible bad) pics, too. Grab 'em here: https://flic.kr/s/aHskbYSvDn > > Cheerio, > Klaus > > Am So, 31. Mai, 2015 um 9:16 schrieb Axel Teich Geertinger : >> Thanks for the reminder, Peter. Sorry about the delay! >> You can download a zip folder with my images at https://dl.dropboxusercontent.com/u/4580077/mec2015.zip >> I'll leave it there for some weeks or so. >> >> To avoid the hard light I didn't use my flash. In some cases perhaps I should have ;-) >> >> Hope to see some others' pictures too! >> >> Best, >> Axel >> ________________________________________ >> Fra: mei-l [mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de ] på vegne af Peter Stadler [stadler at edirom.de ] >> Sendt: 31. maj 2015 18:44 >> Til: Initiative Music Encoding >> Emne: [MEI-L] Pictures from MEC2015 >> >> May I remind you to please post a link to your pictures from Florence so everyone can enjoy them?! >> >> Many many thanks in advance >> Peter >> _______________________________________________ >> 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 -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From lxpugin at gmail.com Wed Aug 26 08:22:48 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 26 Aug 2015 08:22:48 +0200 Subject: [MEI-L] Beat in 6/8 Message-ID: Hi, I am looking at beat repeats () and I am not sure how to deal with them in 6/8 (or 9/8, etc). Defining the beat in 6/8 is a recurrent issue. Looking at timestamps, it seems that each 8th has to be considered as a beat. But in the beatRpt examples in the guidelines it seems that a 4.th is considered as a beat. Considering that the number of slashes have to be encoded in the @rend attribute, rendering the beat repeats properly is not that much of an issue because we could just ignore the beat duration and just display the dashes. (Only rendering repeats of mixed duration values would be an issue since it is not clear how this has to be encoded.) However, this would not work if we need to align them with other voices, for example. Any recommendation on this particular issue () and on how to consider beats in 6/8 in general? Best, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From donbyrd at indiana.edu Wed Aug 26 16:03:17 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Wed, 26 Aug 2015 14:03:17 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: Message-ID: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> Executive summary: In 6/8 specifically, I think it should be a dotted quarter, not an eighth. Now some discussion of the issues: I think most of us would agree that whether the beat is an 8th or a dotted quarter in 6/8 (or 9/8, 12/8, etc.) depends mostly on the tempo, but I doubt if we want to infer that from metronome marks, much less verbal tempo indications! FWIW, I'd guess the dotted-quarter beat is more common. Of course the same question arises in compound meters with denominators other than 8. Is the beat in 9/16 a 16th or a dotted 8th? It even worse in irregular meters. In 5/8, a measure might have five beats of an 8th each, or a quarter followed by a dotted quarter, or a dotted quarter followed by a quarter! But in _Behind Bars_, p. 230, Gould solves the problem in terms of notation with the rule that a single diagonal line means to repeat the previous beamed group of total duration of a quarter (or dotted quarter), two diagonal lines a duration of an 8th (or dotted 8th), three diagonal lines a duration of… You get the idea. So, while she calls these beat repeats, she defines them in terms of beaming! But of course she's talking about usage for new scores, not what appears in Weber or Beethoven or whever's manuscripts! --Don On Aug 26, 2015, at 2:22 AM, Laurent Pugin wrote: > Hi, > > I am looking at beat repeats () and I am not sure how to deal with them in 6/8 (or 9/8, etc). Defining the beat in 6/8 is a recurrent issue. Looking at timestamps, it seems that each 8th has to be considered as a beat. But in the beatRpt examples in the guidelines it seems that a 4.th is considered as a beat. > > Considering that the number of slashes have to be encoded in the @rend attribute, rendering the beat repeats properly is not that much of an issue because we could just ignore the beat duration and just display the dashes. (Only rendering repeats of mixed duration values would be an issue since it is not clear how this has to be encoded.) However, this would not work if we need to align them with other voices, for example. Any recommendation on this particular issue () and on how to consider beats in 6/8 in general? > > Best, > Laurent > _______________________________________________ > 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 Wed Aug 26 17:19:17 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 26 Aug 2015 17:19:17 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> Message-ID: I saw the examples in Behind Bars. It indeed works if we assume that a is actually a "". I have the feeling, however, that this would to be too restrictive. One idea that came to my mind is to have an attribute in beatRpt for specifying how many beats the repeat covers, if not 1. in 6/8, this attribute would need to be 3 for repeats of 4. . That way we stay compliant with what is assumed with timestamps. It also has the advantage of enabling repeats that could be less than a beat. For example repeats of a beam of four 16th in 2/2 (if this can ever happen). Of course, this would be a solution specifically for beatRpt and does not solve the issue at a more general level. Laurent On Wed, Aug 26, 2015 at 4:03 PM, Byrd, Donald A. wrote: > Executive summary: In 6/8 specifically, I think it should be a dotted > quarter, not an eighth. Now some discussion of the issues: > > I think most of us would agree that whether the beat is an 8th or a dotted > quarter in 6/8 (or 9/8, 12/8, etc.) depends mostly on the tempo, but I > doubt if we want to infer that from metronome marks, much less verbal tempo > indications! FWIW, I'd guess the dotted-quarter beat is more common. > > Of course the same question arises in compound meters with denominators > other than 8. Is the beat in 9/16 a 16th or a dotted 8th? It even worse in > irregular meters. In 5/8, a measure might have five beats of an 8th each, > or a quarter followed by a dotted quarter, or a dotted quarter followed by > a quarter! > > But in _Behind Bars_, p. 230, Gould solves the problem in terms of > notation with the rule that a single diagonal line means to repeat the > previous beamed group of total duration of a quarter (or dotted quarter), > two diagonal lines a duration of an 8th (or dotted 8th), three diagonal > lines a duration of… You get the idea. So, while she calls these beat > repeats, she defines them in terms of beaming! But of course she's talking > about usage for new scores, not what appears in Weber or Beethoven or > whever's manuscripts! > > --Don > > > On Aug 26, 2015, at 2:22 AM, Laurent Pugin wrote: > > > Hi, > > > > I am looking at beat repeats () and I am not sure how to deal > with them in 6/8 (or 9/8, etc). Defining the beat in 6/8 is a recurrent > issue. Looking at timestamps, it seems that each 8th has to be considered > as a beat. But in the beatRpt examples in the guidelines it seems that a > 4.th is considered as a beat. > > > > Considering that the number of slashes have to be encoded in the @rend > attribute, rendering the beat repeats properly is not that much of an issue > because we could just ignore the beat duration and just display the dashes. > (Only rendering repeats of mixed duration values would be an issue since it > is not clear how this has to be encoded.) However, this would not work if > we need to align them with other voices, for example. Any recommendation on > this particular issue () and on how to consider beats in 6/8 in > general? > > > > Best, > > Laurent > > _______________________________________________ > > 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 esfield at stanford.edu Thu Aug 27 01:08:26 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Wed, 26 Aug 2015 23:08:26 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> Message-ID: To pick up threads from Don's and Laurent's posts, the main reason MuseData allows a double representation in certain rhythmic situations is precisely because in eighteenth-century music the logic of written notation and the logic of sound-oriented files such as MIDI simply do not coincide. Some instructive instances occur in Corelli--e.g. in movements in compound meter (6/8, 12/8), where active parts such as violins maintain a running series of eighth notes grouped conventionally by threes, but the accompanying bass parts are notated in C (common time) and the units are undotted quarter notes. In Bach, a common situation involves a beamed group consisting of a dotted quarter followed by three (or five) thirty-seconds (i.e., non-binary subdivisions). The values in performances are subject to interpretation. In short, it does not take an irregular meter to produce irregular groupings or "illegal" polyphonic alignments. Eleanor Eleanor Selfridge-Field Consulting Professor, Music Stanford University Stanford, CA 94305-3076, USA esfield at stanford.edu Profile: https://profiles.stanford.edu/eleanor-selfridge-field -----Original Message----- From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A. Sent: Wednesday, August 26, 2015 7:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Executive summary: In 6/8 specifically, I think it should be a dotted quarter, not an eighth. Now some discussion of the issues: I think most of us would agree that whether the beat is an 8th or a dotted quarter in 6/8 (or 9/8, 12/8, etc.) depends mostly on the tempo, but I doubt if we want to infer that from metronome marks, much less verbal tempo indications! FWIW, I'd guess the dotted-quarter beat is more common. Of course the same question arises in compound meters with denominators other than 8. Is the beat in 9/16 a 16th or a dotted 8th? It even worse in irregular meters. In 5/8, a measure might have five beats of an 8th each, or a quarter followed by a dotted quarter, or a dotted quarter followed by a quarter! But in _Behind Bars_, p. 230, Gould solves the problem in terms of notation with the rule that a single diagonal line means to repeat the previous beamed group of total duration of a quarter (or dotted quarter), two diagonal lines a duration of an 8th (or dotted 8th), three diagonal lines a duration of… You get the idea. So, while she calls these beat repeats, she defines them in terms of beaming! But of course she's talking about usage for new scores, not what appears in Weber or Beethoven or whever's manuscripts! --Don On Aug 26, 2015, at 2:22 AM, Laurent Pugin wrote: > Hi, > > I am looking at beat repeats () and I am not sure how to deal with them in 6/8 (or 9/8, etc). Defining the beat in 6/8 is a recurrent issue. Looking at timestamps, it seems that each 8th has to be considered as a beat. But in the beatRpt examples in the guidelines it seems that a 4.th is considered as a beat. > > Considering that the number of slashes have to be encoded in the @rend attribute, rendering the beat repeats properly is not that much of an issue because we could just ignore the beat duration and just display the dashes. (Only rendering repeats of mixed duration values would be an issue since it is not clear how this has to be encoded.) However, this would not work if we need to align them with other voices, for example. Any recommendation on this particular issue () and on how to consider beats in 6/8 in general? > > Best, > Laurent > _______________________________________________ > 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 From bohl at edirom.de Thu Aug 27 10:19:57 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 27 Aug 2015 10:19:57 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> Message-ID: <55DEC82D.4010601@edirom.de> Hi all, many thanks for bringing up this interesting discussion, I was not aware that the definition of "beats" was so uncertain throughout music history! Nevertheless I think that in MEI the definition of beat is very clear. If we consider http://music-encoding.org/documentation/2.1.1/cmn/ and the description of the following scoreDef attributes (4.1.2 Defining Score Parameters for CMN): > > meter.count captures the number of beats in a measure, that is, the > top number of the meter signature. It must contain a decimal number or > an additive expression that evaluates to a decimal number, such as 2+3. > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. > and further the description of timestamps (4.1.5 Timestamps and Durations): > Thetimestamp(tstamp) of a musical event is calculated in relation to > the meter of the current measure and resembles the so-called ‘beat’. > In a common time measure with four quarter notes, the timestamp of > each quarter equals its beat position in the measure: The first > quarter has a timestamp of 1, the second has a timestamp of 2, and so on. If we then consider 4.2.9 Repetition in CMN the descrition of beatRpt might be a bit confusing, as the only definition of the "logical domain" implication is the first sentence: > ThebeatRpt > element is used > to represent a single repeated beat. All the rest of the paragraph deals with "visual domain" aspects exclusively: > Its visual rendition can be recorded using therendattribute. This > attribute indicates the number of slashes required to render the > appropriate repeat symbol, which, as demonstrated in the preceding > figure, depends on the rhythmic content of the beat being repeated. > When a beat that consists of a single note or chord is repeated, the > repetition sign is typically rendered as a single thick, slanting > slash; therefore, the value '1' should be used. The following values > should be used when the beat is divided into even notes: 4ths or > 8ths=1, 16ths=2, 32nds=3, 64ths=4, 128ths=5. When the beat is > comprised of mixed duration values, the symbol is always rendered as 2 > slashes and 2 dots. So to summarize: A beatRpt always repeats a timespan with a duration according to the "locally valid" scoreDef/@meter.unit. At least that's how I understand it, an how we used it in Freischütz Digital ;-) Cheers, Benjamin *********************************************************** Musikwissenschaftliches Seminar Detmold/Paderborn BMBF-Projekt "Freischütz Digital" Benjamin Wolff Bohl Gartenstraße 20 D–32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 E-Mail: bohl at edirom.de http://www.freischuetz-digital.de *********************************************************** Am 27.08.2015 um 01:08 schrieb Eleanor Selfridge-Field: > To pick up threads from Don's and Laurent's posts, the main reason MuseData allows a double representation in certain rhythmic situations is precisely because in eighteenth-century music the logic of written notation and the logic of sound-oriented files such as MIDI simply do not coincide. > > Some instructive instances occur in Corelli--e.g. in movements in compound meter (6/8, 12/8), where active parts such as violins maintain a running series of eighth notes grouped conventionally by threes, but the accompanying bass parts are notated in C (common time) and the units are undotted quarter notes. > > In Bach, a common situation involves a beamed group consisting of a dotted quarter followed by three (or five) thirty-seconds (i.e., non-binary subdivisions). The values in performances are subject to interpretation. > > In short, it does not take an irregular meter to produce irregular groupings or "illegal" polyphonic alignments. > > Eleanor > > Eleanor Selfridge-Field > Consulting Professor, Music > Stanford University > Stanford, CA 94305-3076, USA > esfield at stanford.edu > Profile: https://profiles.stanford.edu/eleanor-selfridge-field > > > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A. > Sent: Wednesday, August 26, 2015 7:03 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > Executive summary: In 6/8 specifically, I think it should be a dotted quarter, not an eighth. Now some discussion of the issues: > > I think most of us would agree that whether the beat is an 8th or a dotted quarter in 6/8 (or 9/8, 12/8, etc.) depends mostly on the tempo, but I doubt if we want to infer that from metronome marks, much less verbal tempo indications! FWIW, I'd guess the dotted-quarter beat is more common. > > Of course the same question arises in compound meters with denominators other than 8. Is the beat in 9/16 a 16th or a dotted 8th? It even worse in irregular meters. In 5/8, a measure might have five beats of an 8th each, or a quarter followed by a dotted quarter, or a dotted quarter followed by a quarter! > > But in _Behind Bars_, p. 230, Gould solves the problem in terms of notation with the rule that a single diagonal line means to repeat the previous beamed group of total duration of a quarter (or dotted quarter), two diagonal lines a duration of an 8th (or dotted 8th), three diagonal lines a duration of… You get the idea. So, while she calls these beat repeats, she defines them in terms of beaming! But of course she's talking about usage for new scores, not what appears in Weber or Beethoven or whever's manuscripts! > > --Don > > > On Aug 26, 2015, at 2:22 AM, Laurent Pugin wrote: > >> Hi, >> >> I am looking at beat repeats () and I am not sure how to deal with them in 6/8 (or 9/8, etc). Defining the beat in 6/8 is a recurrent issue. Looking at timestamps, it seems that each 8th has to be considered as a beat. But in the beatRpt examples in the guidelines it seems that a 4.th is considered as a beat. >> >> Considering that the number of slashes have to be encoded in the @rend attribute, rendering the beat repeats properly is not that much of an issue because we could just ignore the beat duration and just display the dashes. (Only rendering repeats of mixed duration values would be an issue since it is not clear how this has to be encoded.) However, this would not work if we need to align them with other voices, for example. Any recommendation on this particular issue () and on how to consider beats in 6/8 in general? >> >> Best, >> Laurent >> _______________________________________________ >> 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 > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From craigsapp at gmail.com Thu Aug 27 11:08:56 2015 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 27 Aug 2015 02:08:56 -0700 Subject: [MEI-L] Beat in 6/8 In-Reply-To: <55DEC82D.4010601@edirom.de> References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> Message-ID: Hi Benjamin, The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From bohl at edirom.de Thu Aug 27 16:06:38 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 27 Aug 2015 16:06:38 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> Message-ID: <55DF196E.2060405@edirom.de> Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: > The problem is the ambiguous/conflicting terminology in this sentence: > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: > > meter.unit contains the number indicating the beat unit, that is, > the bottom number of the meter signature. > This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. > > The problem is that in compound meters such as 6/8 > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" > is an eighth note. Using the word "beat" in such a way is unfortunate > as it can conflict with the musical definition of a beat, and this > will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a > note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning > it to be a dotted quarter note, but there are exceptions to this > definition which would require a way of assigning an explicit duration > to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > For example, the middle slow movements in a piano sonata may be > labeled as 6/8, with the beat actually assigned to the eighth note, in > which case the "musical beat" and the MEI "beat unit" are the same. > > Another more common corner case would be time signatures such as 3/8. > Is that a compound meter with one beat in a measure, or a simple meter > with three beats in the measure (a variant on a 3/4 meter also > possible in slow movements)? > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth > notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. > > Compound meters resulted in a degeneration of mensural notation. > Since modern rhythms are always "imperfect", to emulate a perfect > mensuration dots are added to the notes (which would usually be > implicit the mensural metric equivalent). These are represented as > compound meters in modern notation (who knows why they did not invent > "2/4." time signatures instead of "6/8" for such cases). The problem > is that modern time signatures are ambiguous, since 6/8 could be > considered like C-dot, or it could be considered as a non-compound > meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni > > I whine to Perry every once in a while about this, so we can wait for > his reply on how to disambiguate such cases... > > -=+Craig > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From lxpugin at gmail.com Thu Aug 27 16:42:08 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Thu, 27 Aug 2015 16:42:08 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: <55DF196E.2060405@edirom.de> References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl wrote: > Dear Craig, > many thanks for your always helpful advice! > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > The problem is the ambiguous/conflicting terminology in this sentence: > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > >> meter.unit contains the number indicating the beat unit, that is, the >> bottom number of the meter signature. > > > This is only ambiguous/conflicting if you are to smart and know too much > about music! Regarding the term "beat" in the closed system of MEI > everything is obvious an unambiguous. > > > The problem is that in compound meters such as 6/8 > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is > an eighth note. Using the word "beat" in such a way is unfortunate as it > can conflict with the musical definition of a beat, and this will continue > to cause mis-interpretation of what a beat is. > > > This then would promote using another term in MEI in order to avoid > confusion, let's say "meter-unit-n". > > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a note on > or off of the beat. > > > This could be a beating argument, if it is the purpose and intention of > MEI to do musical analysis. > Is it? I'd rather say it provides a basis for doing analysis, the logic of > the analysis is not part of MEI, although the result of the analysis might > be encoded in MEI. > > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning it to > be a dotted quarter note, but there are exceptions to this definition which > would require a way of assigning an explicit duration to the musical beat. > > > "Automatically" beaming notes is not part of the encoding but of the > rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > For example, the middle slow movements in a piano sonata may be labeled as > 6/8, with the beat actually assigned to the eighth note, in which case the > "musical beat" and the MEI "beat unit" are the same. > > Another more common corner case would be time signatures such as 3/8. Is > that a compound meter with one beat in a measure, or a simple meter with > three beats in the measure (a variant on a 3/4 meter also possible in slow > movements)? > > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth notes, or > 2+3 or a mixture of both in different measures. > > > The two above are only a problem if we consider "beat" as being the > "musical beat". If we consider it to be "meter-unit-n" instead, everything > would work out fine. > > > Compound meters resulted in a degeneration of mensural notation. Since > modern rhythms are always "imperfect", to emulate a perfect mensuration > dots are added to the notes (which would usually be implicit the mensural > metric equivalent). These are represented as compound meters in modern > notation (who knows why they did not invent "2/4." time signatures instead > of "6/8" for such cases). The problem is that modern time signatures are > ambiguous, since 6/8 could be considered like C-dot, or it could be > considered as a non-compound meter with 6 beat at the eighth-note level. > > > Ok, air is getting thin for me... > I've had a problem with modern transcription of mensural notation ever > since I first encountered it, or more precisely I was whinig about modern > notation being so restrictive due to having abandoned mensuration signs. I > would prefer modern transcription sticking to mensuration signs and logic > instead of adding dots, but I might not be able to change the world about > this... > > But to bang the drum for "meter-unit-n": Couldn't this problem also be > solved by or some additional attribute on or > ? > > Considering the case of a modern transcription of "perfect" mensural > notation using in terms of "meter-unit-n" would result in > completely different applicable cases compared to using it in the sense of > "musical beat". An there it is the again, > ** ambiguous and conflicting** > > Just for the sake ofplaying advocatus diavoli 3;-) > Benni > > > I whine to Perry every once in a while about this, so we can wait for his > reply on how to disambiguate such cases... > > -=+Craig > > > > _______________________________________________ > mei-l mailing listmei-l at lists.uni-paderborn.dehttps://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 Thu Aug 27 16:52:00 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 27 Aug 2015 14:52:00 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de>, Message-ID: So much ambiguity, so little time to deal with it all. :-( It's important to note that the primary goal of an encoding based on notation is to deal with *time signatures*, not meter. So, while it may offend our musical sensibilities occasionally, treating time signatures literally is the best way to eliminate ambiguity. All time signatures -- simple, additive (e.g., 3+2/4), and compound -- are treated the same way without regard to context (tempo, date of composition, etc.). The determination of meter is always contextual. Even though there are elements named "meter", "meterSig", and "meterSigGrp", so far MEI has not addressed musical meter, only notated time signatures. Maybe "time", "timeSig", and "timeSigGrp" are better names, but some purists will undoubtedly complain, especially about the use of the name "time". The term "beat unit" was an attempt to avoid confusion with "musical beats". Obviously, for the quite/very/terminally literal-minded, it failed. Perhaps replacing all mentions of "beat" in descriptions and documentation with "beat unit" may help. I don't think I've ever seen published/printed music in which "inter-measure repetition signs" (how's that for an awful name?) are used for single "beat units" in a compound meter, for example as replacements single 8th notes in 6/8. What is most often seen is the repetition of half a measure (for example, the 2nd set of three 8th notes in 6/8). In this case, use the halfmRpt element, not beatRpt. Doing so avoids the confusion of MEI "beat unit" and "musical beat". The beatRpt element was intended to allow the encoding of a particular symbol (the dot-slash-dot thing and its relatives), so it's already somewhat of a misnomer since it's not literally about repetition of either MEI "beat units" or "musical beats". To be absolutely pedantic about it, a beat from the past can never be repeated, only the material that occurred on it. :-) So, yes, beatRpt represents the repetition of material that occurred on on previous "musical beat". What's the problem again? :-) -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com] Sent: Thursday, August 27, 2015 5:09 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Hi Benjamin, The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Thu Aug 27 17:02:38 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 27 Aug 2015 15:02:38 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de>, Message-ID: Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? And how does one allow an attribute directly "in" or ? We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. I still don't see the point -- what does this have to do with beatRpt? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 10:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig _______________________________________________ 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 lxpugin at gmail.com Thu Aug 27 17:17:57 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Thu, 27 Aug 2015 17:17:57 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). Laurent On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an > attribute? > > And how does one allow an attribute directly "in" or ? > > We should stay away from determination of meter in MEI. As we've already > heard, it often introduces a lot of subjectivity and interpretation. That > kind of thing is best left to a different, analytical layer. > > I still don't see the point -- what does this have to do with beatRpt? > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > *Sent:* Thursday, August 27, 2015 10:45 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > What seems fortunate to me is that "beat" is not used as attribute in MEI > (yet?) > > Maybe we could use it when we need to specify a musical beat that is not > the meter.unit. As I suggested with , it would be assumed to be 1 > in most cases, but could be "3" in 6/8 (or similar) when the desired > musical beat is 4. . In 5/8, we could imagine having an attribute value > such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, > it could be useful to allow the attribute directly in (or even > ?) when the beat structure is changing. > > Laurent > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > >> Dear Craig, >> many thanks for your always helpful advice! >> >> Am 27.08.2015 um 11:08 schrieb Craig Sapp: >> >> The problem is the ambiguous/conflicting terminology in this sentence: >> >> On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: >> >>> meter.unit contains the number indicating the beat unit, that is, the >>> bottom number of the meter signature. >> >> >> This is only ambiguous/conflicting if you are to smart and know too much >> about music! Regarding the term "beat" in the closed system of MEI >> everything is obvious an unambiguous. >> >> >> The problem is that in compound meters such as 6/8 >> https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter >> The "musical beat" is a dotted quarter note, while the MEI "beat unit" is >> an eighth note. Using the word "beat" in such a way is unfortunate as it >> can conflict with the musical definition of a beat, and this will continue >> to cause mis-interpretation of what a beat is. >> >> >> This then would promote using another term in MEI in order to avoid >> confusion, let's say "meter-unit-n". >> >> >> The duration of a beat is necessary for music analysis, since the >> treatment of dissonance and consonance is tied to the location of a note on >> or off of the beat. >> >> >> This could be a beating argument, if it is the purpose and intention of >> MEI to do musical analysis. >> Is it? I'd rather say it provides a basis for doing analysis, the logic >> of the analysis is not part of MEI, although the result of the analysis >> might be encoded in MEI. >> >> The musical beat is also needed to automatically beam notes. Implicit >> interpretation of the musical beat can be done with 6/8 by assigning it to >> be a dotted quarter note, but there are exceptions to this definition which >> would require a way of assigning an explicit duration to the musical beat. >> >> >> "Automatically" beaming notes is not part of the encoding but of the >> rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. >> >> >> For example, the middle slow movements in a piano sonata may be labeled >> as 6/8, with the beat actually assigned to the eighth note, in which case >> the "musical beat" and the MEI "beat unit" are the same. >> >> Another more common corner case would be time signatures such as 3/8. Is >> that a compound meter with one beat in a measure, or a simple meter with >> three beats in the measure (a variant on a 3/4 meter also possible in slow >> movements)? >> >> >> And of course in modern music with irregular meters such as 5/8, the >> musical beats in the measure may may have two beats as 3+2 eighth notes, or >> 2+3 or a mixture of both in different measures. >> >> >> The two above are only a problem if we consider "beat" as being the >> "musical beat". If we consider it to be "meter-unit-n" instead, everything >> would work out fine. >> >> >> Compound meters resulted in a degeneration of mensural notation. Since >> modern rhythms are always "imperfect", to emulate a perfect mensuration >> dots are added to the notes (which would usually be implicit the mensural >> metric equivalent). These are represented as compound meters in modern >> notation (who knows why they did not invent "2/4." time signatures instead >> of "6/8" for such cases). The problem is that modern time signatures are >> ambiguous, since 6/8 could be considered like C-dot, or it could be >> considered as a non-compound meter with 6 beat at the eighth-note level. >> >> >> Ok, air is getting thin for me... >> I've had a problem with modern transcription of mensural notation ever >> since I first encountered it, or more precisely I was whinig about modern >> notation being so restrictive due to having abandoned mensuration signs. I >> would prefer modern transcription sticking to mensuration signs and logic >> instead of adding dots, but I might not be able to change the world about >> this... >> >> But to bang the drum for "meter-unit-n": Couldn't this problem also be >> solved by or some additional attribute on or >> ? >> >> Considering the case of a modern transcription of "perfect" mensural >> notation using in terms of "meter-unit-n" would result in >> completely different applicable cases compared to using it in the sense of >> "musical beat". An there it is the again, >> ** ambiguous and conflicting** >> >> Just for the sake ofplaying advocatus diavoli 3;-) >> Benni >> >> >> I whine to Perry every once in a while about this, so we can wait for his >> reply on how to disambiguate such cases... >> >> -=+Craig >> >> >> >> _______________________________________________ >> mei-l mailing listmei-l at lists.uni-paderborn.dehttps://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 lxpugin at gmail.com Thu Aug 27 17:24:11 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Thu, 27 Aug 2015 17:24:11 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: > > > And how does one allow an attribute directly "in" or ? > > > We should stay away from determination of meter in MEI. As we've already > heard, it often introduces a lot of subjectivity and interpretation. That > kind of thing is best left to a different, analytical layer. > Doesn't MEI have an analytical layer? ;-) > > I still don't see the point -- what does this have to do with beatRpt? > Again, sorry if I am overlooking something, but because of this ambiguity it seems that nothing in a beatRpt provides me with its actual duration in an unambiguous way. Maybe a @dur would do it? > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > *Sent:* Thursday, August 27, 2015 10:45 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > What seems fortunate to me is that "beat" is not used as attribute in MEI > (yet?) > > Maybe we could use it when we need to specify a musical beat that is not > the meter.unit. As I suggested with , it would be assumed to be 1 > in most cases, but could be "3" in 6/8 (or similar) when the desired > musical beat is 4. . In 5/8, we could imagine having an attribute value > such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, > it could be useful to allow the attribute directly in (or even > ?) when the beat structure is changing. > > Laurent > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > >> Dear Craig, >> many thanks for your always helpful advice! >> >> Am 27.08.2015 um 11:08 schrieb Craig Sapp: >> >> The problem is the ambiguous/conflicting terminology in this sentence: >> >> On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: >> >>> meter.unit contains the number indicating the beat unit, that is, the >>> bottom number of the meter signature. >> >> >> This is only ambiguous/conflicting if you are to smart and know too much >> about music! Regarding the term "beat" in the closed system of MEI >> everything is obvious an unambiguous. >> >> >> The problem is that in compound meters such as 6/8 >> https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter >> The "musical beat" is a dotted quarter note, while the MEI "beat unit" is >> an eighth note. Using the word "beat" in such a way is unfortunate as it >> can conflict with the musical definition of a beat, and this will continue >> to cause mis-interpretation of what a beat is. >> >> >> This then would promote using another term in MEI in order to avoid >> confusion, let's say "meter-unit-n". >> >> >> The duration of a beat is necessary for music analysis, since the >> treatment of dissonance and consonance is tied to the location of a note on >> or off of the beat. >> >> >> This could be a beating argument, if it is the purpose and intention of >> MEI to do musical analysis. >> Is it? I'd rather say it provides a basis for doing analysis, the logic >> of the analysis is not part of MEI, although the result of the analysis >> might be encoded in MEI. >> >> The musical beat is also needed to automatically beam notes. Implicit >> interpretation of the musical beat can be done with 6/8 by assigning it to >> be a dotted quarter note, but there are exceptions to this definition which >> would require a way of assigning an explicit duration to the musical beat. >> >> >> "Automatically" beaming notes is not part of the encoding but of the >> rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. >> >> >> For example, the middle slow movements in a piano sonata may be labeled >> as 6/8, with the beat actually assigned to the eighth note, in which case >> the "musical beat" and the MEI "beat unit" are the same. >> >> Another more common corner case would be time signatures such as 3/8. Is >> that a compound meter with one beat in a measure, or a simple meter with >> three beats in the measure (a variant on a 3/4 meter also possible in slow >> movements)? >> >> >> And of course in modern music with irregular meters such as 5/8, the >> musical beats in the measure may may have two beats as 3+2 eighth notes, or >> 2+3 or a mixture of both in different measures. >> >> >> The two above are only a problem if we consider "beat" as being the >> "musical beat". If we consider it to be "meter-unit-n" instead, everything >> would work out fine. >> >> >> Compound meters resulted in a degeneration of mensural notation. Since >> modern rhythms are always "imperfect", to emulate a perfect mensuration >> dots are added to the notes (which would usually be implicit the mensural >> metric equivalent). These are represented as compound meters in modern >> notation (who knows why they did not invent "2/4." time signatures instead >> of "6/8" for such cases). The problem is that modern time signatures are >> ambiguous, since 6/8 could be considered like C-dot, or it could be >> considered as a non-compound meter with 6 beat at the eighth-note level. >> >> >> Ok, air is getting thin for me... >> I've had a problem with modern transcription of mensural notation ever >> since I first encountered it, or more precisely I was whinig about modern >> notation being so restrictive due to having abandoned mensuration signs. I >> would prefer modern transcription sticking to mensuration signs and logic >> instead of adding dots, but I might not be able to change the world about >> this... >> >> But to bang the drum for "meter-unit-n": Couldn't this problem also be >> solved by or some additional attribute on or >> ? >> >> Considering the case of a modern transcription of "perfect" mensural >> notation using in terms of "meter-unit-n" would result in >> completely different applicable cases compared to using it in the sense of >> "musical beat". An there it is the again, >> ** ambiguous and conflicting** >> >> Just for the sake ofplaying advocatus diavoli 3;-) >> Benni >> >> >> I whine to Perry every once in a while about this, so we can wait for his >> reply on how to disambiguate such cases... >> >> -=+Craig >> >> >> >> _______________________________________________ >> mei-l mailing listmei-l at lists.uni-paderborn.dehttps://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 Thu Aug 27 17:48:26 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 27 Aug 2015 15:48:26 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , Message-ID: Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 11:18 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). Laurent On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) > wrote: Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? And how does one allow an attribute directly "in" or ? We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. I still don't see the point -- what does this have to do with beatRpt? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 10:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig _______________________________________________ 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 Thu Aug 27 17:50:45 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 27 Aug 2015 15:50:45 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , Message-ID: Oh, man, that's ugly. And, by the way, that's an attribute *on* an element, not *in* an element. :-) Indeed, MEI has an analytical layer. But I meant the kind of analysis performed in the wetware. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 11:26 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 And how does one allow an attribute directly "in" or ? We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. Doesn't MEI have an analytical layer? ;-) I still don't see the point -- what does this have to do with beatRpt? Again, sorry if I am overlooking something, but because of this ambiguity it seems that nothing in a beatRpt provides me with its actual duration in an unambiguous way. Maybe a @dur would do it? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 10:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig _______________________________________________ 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 Thu Aug 27 23:57:45 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 27 Aug 2015 21:57:45 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , , Message-ID: Here are some possibilities for moving forward -- Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example -- or perhaps In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example. There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing. That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead. Of course, this also gets us into a little trouble as both @copyof and @plist would be allowed. As a work-around, a new @targets (notice the plural) could be added to beatRpt. Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or elements that reference the events; for example, or Each one of these options allows an easy "toggling" between the repetition sign and the material inside. The 2nd method may be more flexible because of the use of references. The down-side for both of these possibilities is that they are more verbose than using an attribute. Yet another approach is to create a generic copy element, say, that represents a copy of any event. That may be too general, however. For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute. This could lead to mis-use and it would be more difficult to control where certain functions could occur. But, Johannes has put this forward in the past, so he's better qualified to address this approach than I. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Thursday, August 27, 2015 11:48 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 11:18 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). Laurent On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) > wrote: Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? And how does one allow an attribute directly "in" or ? We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. I still don't see the point -- what does this have to do with beatRpt? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 10:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig _______________________________________________ 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 zolaemil at gmail.com Tue Sep 1 11:54:44 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Tue, 1 Sep 2015 10:54:44 +0100 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi All, As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by : 1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated. 2. provide explicitly what material is repeated. I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :) Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case? Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution. Best Zoltan 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu>: > > Here are some possibilities for moving forward -- > > Using @copyof on beatRpt makes it possible to indicate which events are to > be repeated; for example -- > > > > > > > > > or perhaps > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been > determined that the copy is a modified "deep" one; that is, that the result > tree has the same structure as the designated node with certain attribute > values removed or modified, like xml:id, for example. > > There's a slight problem with using @copyof, however, in that it doesn't > allow multiple URIs. We could allow multiple values, but I'm not sure what > it means to say that something is a copy of more than one thing. That > means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add > @copyof and I lean more toward adding @plist instead. Of course, this also > gets us into a little trouble as both @copyof and @plist would be > allowed. As a work-around, a new @targets (notice the plural) could be > added to beatRpt. > > Another option is to allow beatRpt to contain content -- either new events > that duplicate those that the repetition sign refers to or elements > that reference the events; for example, > > > > > > > > > > > > > or > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the repetition > sign and the material inside. The 2nd method may be more flexible because > of the use of references. The down-side for both of these possibilities is > that they are more verbose than using an attribute. > > Yet another approach is to create a generic copy element, say, > that represents a copy of any event. That may be too general, however. > For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to > be placed in an attribute. This could lead to mis-use and it would be more > difficult to control where certain functions could occur. But, Johannes > has put this forward in the past, so he's better qualified to address this > approach than I. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, > Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > *Sent:* Thursday, August 27, 2015 11:48 AM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > > Ok, this gives us a place to start. It seems to me, however, that rather > than talking about how much time it repeats (as this reignites the > confusion around "beat" and "beat unit"), it may be better to investigate > ways to explicitly indicate which *events* are to repeated. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > *Sent:* Thursday, August 27, 2015 11:18 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > The problem is that when I encounter a in an encoding I would > like to know how much time it repeats. I understand that it represent the > repetition of the material that occur on a previous musical beat, as you > say. However, since the duration of what the musical beat is not encoded > explicitly (as far as I understand) it does not seem to be possible to know > it (i.e., how much time it repeats.). > > Laurent > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> >> >> Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an >> attribute? >> >> And how does one allow an attribute directly "in" or ? >> >> We should stay away from determination of meter in MEI. As we've already >> heard, it often introduces a lot of subjectivity and interpretation. That >> kind of thing is best left to a different, analytical layer. >> >> I still don't see the point -- what does this have to do with beatRpt? >> >> -- >> p. >> >> >> __________________________ >> Perry Roland >> Music Library >> University of Virginia >> P. O. Box 400175 >> Charlottesville, VA 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> ------------------------------ >> *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Laurent Pugin [lxpugin at gmail.com] >> *Sent:* Thursday, August 27, 2015 10:45 AM >> *To:* Music Encoding Initiative >> *Subject:* Re: [MEI-L] Beat in 6/8 >> >> What seems fortunate to me is that "beat" is not used as attribute in MEI >> (yet?) >> >> Maybe we could use it when we need to specify a musical beat that is not >> the meter.unit. As I suggested with , it would be assumed to be 1 >> in most cases, but could be "3" in 6/8 (or similar) when the desired >> musical beat is 4. . In 5/8, we could imagine having an attribute value >> such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, >> it could be useful to allow the attribute directly in (or even >> ?) when the beat structure is changing. >> >> Laurent >> >> On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl >> wrote: >> >>> Dear Craig, >>> many thanks for your always helpful advice! >>> >>> Am 27.08.2015 um 11:08 schrieb Craig Sapp: >>> >>> The problem is the ambiguous/conflicting terminology in this sentence: >>> >>> On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: >>> >>>> meter.unit contains the number indicating the beat unit, that is, the >>>> bottom number of the meter signature. >>> >>> >>> This is only ambiguous/conflicting if you are to smart and know too much >>> about music! Regarding the term "beat" in the closed system of MEI >>> everything is obvious an unambiguous. >>> >>> >>> The problem is that in compound meters such as 6/8 >>> https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter >>> The "musical beat" is a dotted quarter note, while the MEI "beat unit" >>> is an eighth note. Using the word "beat" in such a way is unfortunate as >>> it can conflict with the musical definition of a beat, and this will >>> continue to cause mis-interpretation of what a beat is. >>> >>> >>> This then would promote using another term in MEI in order to avoid >>> confusion, let's say "meter-unit-n". >>> >>> >>> The duration of a beat is necessary for music analysis, since the >>> treatment of dissonance and consonance is tied to the location of a note on >>> or off of the beat. >>> >>> >>> This could be a beating argument, if it is the purpose and intention of >>> MEI to do musical analysis. >>> Is it? I'd rather say it provides a basis for doing analysis, the logic >>> of the analysis is not part of MEI, although the result of the analysis >>> might be encoded in MEI. >>> >>> The musical beat is also needed to automatically beam notes. Implicit >>> interpretation of the musical beat can be done with 6/8 by assigning it to >>> be a dotted quarter note, but there are exceptions to this definition which >>> would require a way of assigning an explicit duration to the musical beat. >>> >>> >>> "Automatically" beaming notes is not part of the encoding but of the >>> rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. >>> >>> >>> For example, the middle slow movements in a piano sonata may be labeled >>> as 6/8, with the beat actually assigned to the eighth note, in which case >>> the "musical beat" and the MEI "beat unit" are the same. >>> >>> Another more common corner case would be time signatures such as 3/8. >>> Is that a compound meter with one beat in a measure, or a simple meter with >>> three beats in the measure (a variant on a 3/4 meter also possible in slow >>> movements)? >>> >>> >>> And of course in modern music with irregular meters such as 5/8, the >>> musical beats in the measure may may have two beats as 3+2 eighth notes, or >>> 2+3 or a mixture of both in different measures. >>> >>> >>> The two above are only a problem if we consider "beat" as being the >>> "musical beat". If we consider it to be "meter-unit-n" instead, everything >>> would work out fine. >>> >>> >>> Compound meters resulted in a degeneration of mensural notation. Since >>> modern rhythms are always "imperfect", to emulate a perfect mensuration >>> dots are added to the notes (which would usually be implicit the mensural >>> metric equivalent). These are represented as compound meters in modern >>> notation (who knows why they did not invent "2/4." time signatures instead >>> of "6/8" for such cases). The problem is that modern time signatures are >>> ambiguous, since 6/8 could be considered like C-dot, or it could be >>> considered as a non-compound meter with 6 beat at the eighth-note level. >>> >>> >>> Ok, air is getting thin for me... >>> I've had a problem with modern transcription of mensural notation ever >>> since I first encountered it, or more precisely I was whinig about modern >>> notation being so restrictive due to having abandoned mensuration signs. I >>> would prefer modern transcription sticking to mensuration signs and logic >>> instead of adding dots, but I might not be able to change the world about >>> this... >>> >>> But to bang the drum for "meter-unit-n": Couldn't this problem also be >>> solved by or some additional attribute on or >>> ? >>> >>> Considering the case of a modern transcription of "perfect" mensural >>> notation using in terms of "meter-unit-n" would result in >>> completely different applicable cases compared to using it in the sense of >>> "musical beat". An there it is the again, >>> ** ambiguous and conflicting** >>> >>> Just for the sake ofplaying advocatus diavoli 3;-) >>> Benni >>> >>> >>> I whine to Perry every once in a while about this, so we can wait for >>> his reply on how to disambiguate such cases... >>> >>> -=+Craig >>> >>> >>> >>> _______________________________________________ >>> mei-l mailing listmei-l at lists.uni-paderborn.dehttps://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 veit at weber-gesamtausgabe.de Tue Sep 1 23:08:05 2015 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Tue, 01 Sep 2015 23:08:05 +0200 Subject: [MEI-L] Questionnaire In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , Message-ID: <55E613B5.2060506@weber-gesamtausgabe.de> Dear Colleagues, as many of you know, we are collaborating with colleagues from our university and from the Detmold Music Academy under the roof of a newly founded center „Music – Edition – Media“ since last winter. In the context of this center three colleagues from our university developed an electronic questionnaire concerning digital editions (not only, but also working with the „Edirom“ software) in order to evaluate tools which are available in this field at the moment, but more important: to find out desiderata or „urgent needs“ of those strange people doing digital editions in future … The questionnaire is only available in German, but we would be very happy if you would kindly support our endeavours to collect as many „editorial requests“ as possible – so, if you understand a bit of German, please take part in this survey and fill in your own suggestions in English, French or any other language you guess we will be able to decipher... The address for the electronic questionnaire (which only needs 15 minutes of your attention) is: https://www.soscisurvey.de/musikedition/ Please do not hesitate to fill in things/requests in the free spaces which are not mentioned otherwise. Certainly the results will be presented at one of our Music Encoding Conferences. With many thanks for your valuable help and best wishes, Joachim -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : veit.vcf Dateityp : text/x-vcard Dateigröße : 364 bytes Beschreibung: nicht verfügbar URL : From pdr4h at eservices.virginia.edu Thu Sep 3 21:15:06 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 3 Sep 2015 19:15:06 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi, Thanks for contributing to the discussion, Zoltán. As usual, I too am in favor of multiple encoding methods, especially in the early phases of trying to figure out the best approach – we can deprecate all but one at the point where the “right” solution is obvious. That being said, and despite what I said earlier about the co-occurrence of @copyof and @plist, I think the two approaches here are: 1. add @plist to to allow explicit referencing of the events to be repeated 2. add another attribute, yet to be named, to permit encoding of the amount of time to be repeated The first option is super easy – just make a member of att.plist. The differentiation of @plist and @copyof must remain clear, however. @plist identifies the events to be repeated while @copyof identifies the element *which the beatRpt element is a copy of*. The likelihood of any element being a copy of another one is rare, so the use of @copyof should also occur very infrequently. The second option is somewhat more complex, but still practical. I just don’t think we can overload @dur or @dur.ges for this purpose. I suggest that syntax similar to that of @dur.ges be used but another name selected, perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a beat in a particular context. Here, we *are* talking about metrical/musical beats, not MEI beat units. So, in a measure of 6/8, @beatDef should take the value “4.r” (using Humdrum notation). This defines a repeated beat as a dotted quarter note. Suggestions for a better name for this attribute are greatly appreciated. Adding these new attributes may help with automated resolution of a beatRpt sign, but their presence can’t be required, meaning that can’t rely on them entirely in the determination of how much time or which events should be repeated. There always has to be a fallback approach that makes a reasonable guess based on the context. I’ve had a cursory look at where/how the term “beat” is used in descriptions and documentation and I think that simply replacing “beat” with “beat unit” won’t work well. It probably would be better to look for places to insert new text about how MEI treats compound meters literally, for example in section 4.1.5 “Timestamps and Durations”. Sound good? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán Sent: Tuesday, September 01, 2015 5:55 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Hi All, As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by : 1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated. 2. provide explicitly what material is repeated. I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :) Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case? Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution. Best Zoltan 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) >: Here are some possibilities for moving forward -- Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example -- or perhaps In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example. There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing. That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead. Of course, this also gets us into a little trouble as both @copyof and @plist would be allowed. As a work-around, a new @targets (notice the plural) could be added to beatRpt. Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or elements that reference the events; for example, or Each one of these options allows an easy "toggling" between the repetition sign and the material inside. The 2nd method may be more flexible because of the use of references. The down-side for both of these possibilities is that they are more verbose than using an attribute. Yet another approach is to create a generic copy element, say, that represents a copy of any event. That may be too general, however. For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute. This could lead to mis-use and it would be more difficult to control where certain functions could occur. But, Johannes has put this forward in the past, so he's better qualified to address this approach than I. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Thursday, August 27, 2015 11:48 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 11:18 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). Laurent On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) > wrote: Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? And how does one allow an attribute directly "in" or ? We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. I still don't see the point -- what does this have to do with beatRpt? -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Thursday, August 27, 2015 10:45 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. Laurent On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: Dear Craig, many thanks for your always helpful advice! Am 27.08.2015 um 11:08 schrieb Craig Sapp: The problem is the ambiguous/conflicting terminology in this sentence: On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. The problem is that in compound meters such as 6/8 https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. Ok, air is getting thin for me... I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, ** ambiguous and conflicting** Just for the sake ofplaying advocatus diavoli 3;-) Benni I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... -=+Craig _______________________________________________ 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 kepper at edirom.de Thu Sep 3 22:49:48 2015 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 3 Sep 2015 22:49:48 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi all, sorry for coming to this discussion very late. Fwiw, I'd like to mention an element we came up with during the Freischütz project, which still lacks sufficient documentation to be implemented into general MEI – even though I strongly believe it's very useful for other projects as well. In essence, it's a more general approach to repeat symbols and other notational "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla parte". This element is a controlEvent (= it lives inside a measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff could look like this: / The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" that this element will say something about – just as in any other control event. "beats" in this context is clearly the numbers of the @meter.count. Then, the attribute pair @ref.offset and @ref.offset2 is used to say from where context is to be copied into this "empty" or "abbreviated" slot. @ref.offset uses the same data type as @tstamp2, with the only difference that the first number (the one before the "m+" part) may take negative values, that is, refer to preceding measures), and @ref.offset2 uses the exact same data type as @tstamp2 (it's value is relative to the origin defined by @ref.offset). These elements may be combined or replaced by @ref.staff (and @ref.layer), which allow to do a colla parte encoding ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark may contain textual content (plus some editorial stuff) to grab what the source says – a simple slash, a verbal instruction, whatever. This is just a very brief introduction to this element, but I hope you get the idea. Like I said, I'm not sure if it really helps in this discussion of , but I think it allows to be very explicit about the scope of a beat repetition symbol. In my understanding, , , and all the other <*Rpt> elements are syntactic sugar for this element, which is really a more semantic solution for a specific type of . Would it be an option to use instead of – just to be more explicit? I think this is more or less in line with Perry's second suggestion, or at least I believe we should coordinate the search for an additional attribute with our proposal. Hth, jo Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) : > > Hi, > > Thanks for contributing to the discussion, Zoltán. As usual, I too am in favor of multiple encoding methods, especially in the early phases of trying to figure out the best approach – we can deprecate all but one at the point where the “right” solution is obvious. > > That being said, and despite what I said earlier about the co-occurrence of @copyof and @plist, I think the two approaches here are: > > 1. add @plist to to allow explicit referencing of the events to be repeated > 2. add another attribute, yet to be named, to permit encoding of the amount of time to be repeated > > The first option is super easy – just make a member of att.plist. The differentiation of @plist and @copyof must remain clear, however. @plist identifies the events to be repeated while @copyof identifies the element *which the beatRpt element is a copy of*. The likelihood of any element being a copy of another one is rare, so the use of @copyof should also occur very infrequently. > > The second option is somewhat more complex, but still practical. I just don’t think we can overload @dur or @dur.ges for this purpose. I suggest that syntax similar to that of @dur.ges be used but another name selected, perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a beat in a particular context. Here, we *are* talking about metrical/musical beats, not MEI beat units. So, in a measure of 6/8, @beatDef should take the value “4.r” (using Humdrum notation). This defines a repeated beat as a dotted quarter note. Suggestions for a better name for this attribute are greatly appreciated. > > Adding these new attributes may help with automated resolution of a beatRpt sign, but their presence can’t be required, meaning that can’t rely on them entirely in the determination of how much time or which events should be repeated. There always has to be a fallback approach that makes a reasonable guess based on the context. > > I’ve had a cursory look at where/how the term “beat” is used in descriptions and documentation and I think that simply replacing “beat” with “beat unit” won’t work well. It probably would be better to look for places to insert new text about how MEI treats compound meters literally, for example in section 4.1.5 “Timestamps and Durations”. > > Sound good? > > -- > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán > Sent: Tuesday, September 01, 2015 5:55 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > Hi All, > > As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by : > 1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated. > 2. provide explicitly what material is repeated. > > I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :) > > Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case? > > Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution. > > Best > Zoltan > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) : > > Here are some possibilities for moving forward -- > > Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example -- > > > > > > > > > or perhaps > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example. > > There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing. That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead. Of course, this also gets us into a little trouble as both @copyof and @plist would be allowed. As a work-around, a new @targets (notice the plural) could be added to beatRpt. > > Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or elements that reference the events; for example, > > > > > > > > > > > > > or > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the repetition sign and the material inside. The 2nd method may be more flexible because of the use of references. The down-side for both of these possibilities is that they are more verbose than using an attribute. > > Yet another approach is to create a generic copy element, say, that represents a copy of any event. That may be too general, however. For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute. This could lead to mis-use and it would be more difficult to control where certain functions could occur. But, Johannes has put this forward in the past, so he's better qualified to address this approach than I. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > Sent: Thursday, August 27, 2015 11:48 AM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > > Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > Sent: Thursday, August 27, 2015 11:18 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). > > Laurent > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) wrote: > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? > > And how does one allow an attribute directly "in" or ? > > We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. > > I still don't see the point -- what does this have to do with beatRpt? > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > Sent: Thursday, August 27, 2015 10:45 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) > > Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. > > Laurent > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl wrote: > Dear Craig, > many thanks for your always helpful advice! > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > The problem is the ambiguous/conflicting terminology in this sentence: > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. > > This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. > > > > The problem is that in compound meters such as 6/8 > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. > > This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". > > > > The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. > > This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. > Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. > > > The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. > > "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. > > Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? > > And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. > > The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. > > > > Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. > > Ok, air is getting thin for me... > I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... > > But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? > > Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, > ** ambiguous and conflicting** > > Just for the sake ofplaying advocatus diavoli 3;-) > Benni > > > > I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... > > -=+Craig > > > > _______________________________________________ > 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 zolaemil at gmail.com Thu Sep 3 23:22:52 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 3 Sep 2015 22:22:52 +0100 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi, Great thoughts, Perry! 1. Re allowing @dur on beatRpt: Strictly speaking this could be understood as the duration of the beatRpt itself - and while one may argue that this must, inevitably be the duration of the material that it repeats, and thinking about it, I am not in favour of this kind of indirection. 2. Defining the beat duration on the beatRpt I prefer this solution because it is more explicit, and also very intuitive: for a beatRpt it defines what the beat is. In either case, the data type could be either very similar to that of @dur, or indeed a syntax borrowed from elsewhere. I'd be alert to prepare for obscure cases when the simple duration+dots approach doesn't work: for example, 14/16 meter could be divided into 3 beats, first two lasting 5 16th-note each, the last one for 4 16th-note. The first and second beats can't be expressed by means of "dotting" quarter, eights, sixteenth, etc. notes. 3. Fixing the confusion surrounding beats: Having had a glance through the usage of beat throughout the guidelines, it seems to me that it wouldn't be necessary to define @meter.unit and @meter.count in terms of beats: if we could simply avoid the use of "beat" in the definition of @meter.count and @meter.unit, the confusion may just walk away... In the meantime, I am not suggesting ripping off the use of "beat" at every instance when we talk about the resolution of tstamps however: in simple meter the beat and meter.unit coincide, so this is perfectly fine: "*For example, a value of "0m+3" in 4/4 time indicates that the element bearing this attribute, a slur for example, ends on beat 3 of the same measure where it started.*" In short, my suggestion is to reserve the term "beat" for the musical beat exclusively. Inclusion of a short paragraph about how tstamps are understood in compound meter should only make things even clearer. Best Zoltan 2015-09-03 20:15 GMT+01:00 Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu>: > > > Hi, > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am in > favor of multiple encoding methods, especially in the early phases of > trying to figure out the best approach – we can deprecate all but one at > the point where the “right” solution is obvious. > > > > That being said, and despite what I said earlier about the co-occurrence > of @copyof and @plist, I think the two approaches here are: > > > > 1. add @plist to to allow explicit referencing of the events to > be repeated > > 2. add another attribute, yet to be named, to permit encoding of the > amount of time to be repeated > > > > The first option is super easy – just make a member of > att.plist. The differentiation of @plist and @copyof must remain clear, > however. @plist identifies the events to be repeated while @copyof > identifies the element **which the beatRpt element is a copy of**. The > likelihood of any element being a copy of another one is rare, so the use > of @copyof should also occur very infrequently. > > > > The second option is somewhat more complex, but still practical. I just > don’t think we can overload @dur or @dur.ges for this purpose. I suggest > that syntax similar to that of @dur.ges be used but another name selected, > perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a > beat in a particular context. Here, we **are** talking about > metrical/musical beats, not MEI beat units. So, in a measure of 6/8, > @beatDef should take the value “4.r” (using Humdrum notation). This defines > a repeated beat as a dotted quarter note. Suggestions for a better name > for this attribute are greatly appreciated. > > > > Adding these new attributes may help with automated resolution of a > beatRpt sign, but their presence can’t be required, meaning that can’t rely > on them entirely in the determination of how much time or which events > should be repeated. There always has to be a fallback approach that makes > a reasonable guess based on the context. > > > > I’ve had a cursory look at where/how the term “beat” is used in > descriptions and documentation and I think that simply replacing “beat” > with “beat unit” won’t work well. It probably would be better to look for > places to insert new text about how MEI treats compound meters literally, > for example in section 4.1.5 “Timestamps and Durations”. > > > > Sound good? > > > > -- > > p. > > > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Komíves Zoltán > *Sent:* Tuesday, September 01, 2015 5:55 AM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > > > Hi All, > > > > As far as I understand there have been two suggestions to solve the > problem of determining the material that is repeated by : > > 1. use @dur attribute on beatRpt to indicate how much of the preceding > material is repeated. > > 2. provide explicitly what material is repeated. > > > > I think both solutions make sense. The first one is concise, and has no > complicated implications, while the second one provides more flexibility - > I sense there could be situations when the (1) would not suffice, perhaps > some multi-voice situation when only the material in one voice is repeated, > but don't want to think about this too hard now... :) > > > > Could we perhaps allow both solutions, so encoders could chose whichever > fits best their use case? > > > > Regarding the discussion of beat in compound meters, I also think it's > perhaps best to stay away from defining the beat as such, but I also > support to clarify terminology: using "beat unit" rigorously could be a > good enough solution. > > > > Best > > Zoltan > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > Here are some possibilities for moving forward -- > > > > Using @copyof on beatRpt makes it possible to indicate which events are to > be repeated; for example -- > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been > determined that the copy is a modified "deep" one; that is, that the result > tree has the same structure as the designated node with certain attribute > values removed or modified, like xml:id, for example. > > > > There's a slight problem with using @copyof, however, in that it doesn't > allow multiple URIs. We could allow multiple values, but I'm not sure what > it means to say that something is a copy of more than one thing. That > means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add > @copyof and I lean more toward adding @plist instead. Of course, this also > gets us into a little trouble as both @copyof and @plist would be > allowed. As a work-around, a new @targets (notice the plural) could be > added to beatRpt. > > > > Another option is to allow beatRpt to contain content -- either new events > that duplicate those that the repetition sign refers to or elements > that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the repetition > sign and the material inside. The 2nd method may be more flexible because > of the use of references. The down-side for both of these possibilities is > that they are more verbose than using an attribute. > > > > Yet another approach is to create a generic copy element, say, > that represents a copy of any event. That may be too general, however. > For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to > be placed in an attribute. This could lead to mis-use and it would be more > difficult to control where certain functions could occur. But, Johannes > has put this forward in the past, so he's better qualified to address this > approach than I. > > > > -- > > p. > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, > Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > *Sent:* Thursday, August 27, 2015 11:48 AM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > > > > > Ok, this gives us a place to start. It seems to me, however, that rather > than talking about how much time it repeats (as this reignites the > confusion around "beat" and "beat unit"), it may be better to investigate > ways to explicitly indicate which *events* are to repeated. > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > *Sent:* Thursday, August 27, 2015 11:18 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > The problem is that when I encounter a in an encoding I would > like to know how much time it repeats. I understand that it represent the > repetition of the material that occur on a previous musical beat, as you > say. However, since the duration of what the musical beat is not encoded > explicitly (as far as I understand) it does not seem to be possible to know > it (i.e., how much time it repeats.). > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an > attribute? > > > > And how does one allow an attribute directly "in" or ? > > > > We should stay away from determination of meter in MEI. As we've already > heard, it often introduces a lot of subjectivity and interpretation. That > kind of thing is best left to a different, analytical layer. > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > -- > > p. > > > > > __________________________ > Perry Roland > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ------------------------------ > > *From:* mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > *Sent:* Thursday, August 27, 2015 10:45 AM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Beat in 6/8 > > What seems fortunate to me is that "beat" is not used as attribute in MEI > (yet?) > > > > Maybe we could use it when we need to specify a musical beat that is not > the meter.unit. As I suggested with , it would be assumed to be 1 > in most cases, but could be "3" in 6/8 (or similar) when the desired > musical beat is 4. . In 5/8, we could imagine having an attribute value > such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, > it could be useful to allow the attribute directly in (or even > ?) when the beat structure is changing. > > > > Laurent > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > > Dear Craig, > many thanks for your always helpful advice! > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. > > > This is only ambiguous/conflicting if you are to smart and know too much > about music! Regarding the term "beat" in the closed system of MEI > everything is obvious an unambiguous. > > > > > The problem is that in compound meters such as 6/8 > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is > an eighth note. Using the word "beat" in such a way is unfortunate as it > can conflict with the musical definition of a beat, and this will continue > to cause mis-interpretation of what a beat is. > > > This then would promote using another term in MEI in order to avoid > confusion, let's say "meter-unit-n". > > > > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a note on > or off of the beat. > > > This could be a beating argument, if it is the purpose and intention of > MEI to do musical analysis. > Is it? I'd rather say it provides a basis for doing analysis, the logic of > the analysis is not part of MEI, although the result of the analysis might > be encoded in MEI. > > > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning it to > be a dotted quarter note, but there are exceptions to this definition which > would require a way of assigning an explicit duration to the musical beat. > > > "Automatically" beaming notes is not part of the encoding but of the > rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > For example, the middle slow movements in a piano sonata may be labeled as > 6/8, with the beat actually assigned to the eighth note, in which case the > "musical beat" and the MEI "beat unit" are the same. > > > > Another more common corner case would be time signatures such as 3/8. Is > that a compound meter with one beat in a measure, or a simple meter with > three beats in the measure (a variant on a 3/4 meter also possible in slow > movements)? > > > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth notes, or > 2+3 or a mixture of both in different measures. > > > The two above are only a problem if we consider "beat" as being the > "musical beat". If we consider it to be "meter-unit-n" instead, everything > would work out fine. > > > > > Compound meters resulted in a degeneration of mensural notation. Since > modern rhythms are always "imperfect", to emulate a perfect mensuration > dots are added to the notes (which would usually be implicit the mensural > metric equivalent). These are represented as compound meters in modern > notation (who knows why they did not invent "2/4." time signatures instead > of "6/8" for such cases). The problem is that modern time signatures are > ambiguous, since 6/8 could be considered like C-dot, or it could be > considered as a non-compound meter with 6 beat at the eighth-note level. > > > Ok, air is getting thin for me... > I've had a problem with modern transcription of mensural notation ever > since I first encountered it, or more precisely I was whinig about modern > notation being so restrictive due to having abandoned mensuration signs. I > would prefer modern transcription sticking to mensuration signs and logic > instead of adding dots, but I might not be able to change the world about > this... > > But to bang the drum for "meter-unit-n": Couldn't this problem also be > solved by or some additional attribute on or > ? > > Considering the case of a modern transcription of "perfect" mensural > notation using in terms of "meter-unit-n" would result in > completely different applicable cases compared to using it in the sense of > "musical beat". An there it is the again, > ** ambiguous and conflicting** > > Just for the sake ofplaying advocatus diavoli 3;-) > Benni > > > > > I whine to Perry every once in a while about this, so we can wait for his > reply on how to disambiguate such cases... > > > > -=+Craig > > > > > > _______________________________________________ > > 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 zolaemil at gmail.com Thu Sep 3 23:47:07 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Thu, 3 Sep 2015 22:47:07 +0100 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi Jo, Interesting proposition! I am sure there are great use cases for this, especially for editorial purposes. My feeling is that the sugar of beatRpt would still be handy for a great deal of cases. I have couple of questions: 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in order to determine how long this repetition lasts, i.e. it will last for as long as the material at tstamp="2" lasts for. Do I understand this correctly? 2. What would the "target slot" addressed by the @ref.* attributes contain? perhaps? 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I could see why, especially when the target context has a different meter...) Best Zoltan 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > Hi all, > > sorry for coming to this discussion very late. Fwiw, I'd like to mention > an element we came up with during the Freischütz project, which still lacks > sufficient documentation to be implemented into general MEI – even though I > strongly believe it's very useful for other projects as well. In essence, > it's a more general approach to repeat symbols and other notational > "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" > and / or "colla parte". This element is a controlEvent (= it lives inside a > measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the > second beat of the first staff could look like this: > > ref.offset2="0m+1">/ > > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" > that this element will say something about – just as in any other control > event. "beats" in this context is clearly the numbers of the @meter.count. > Then, the attribute pair @ref.offset and @ref.offset2 is used to say from > where context is to be copied into this "empty" or "abbreviated" slot. > @ref.offset uses the same data type as @tstamp2, with the only difference > that the first number (the one before the "m+" part) may take negative > values, that is, refer to preceding measures), and @ref.offset2 uses the > exact same data type as @tstamp2 (it's value is relative to the origin > defined by @ref.offset). These elements may be combined or replaced by > @ref.staff (and @ref.layer), which allow to do a colla parte encoding > ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in > @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark > may contain textual content (plus some editorial stuff) to grab what the > source says – a simple slash, a verbal instruction, whatever. > > This is just a very brief introduction to this element, but I hope you get > the idea. Like I said, I'm not sure if it really helps in this discussion > of , but I think it allows to be very explicit about the scope of > a beat repetition symbol. In my understanding, , , and all > the other <*Rpt> elements are syntactic sugar for this element, > which is really a more semantic solution for a specific type of . > Would it be an option to use instead of – just to be > more explicit? I think this is more or less in line with Perry's second > suggestion, or at least I believe we should coordinate the search for an > additional attribute with our proposal. > > Hth, > jo > > > > > > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > > Hi, > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am > in favor of multiple encoding methods, especially in the early phases of > trying to figure out the best approach – we can deprecate all but one at > the point where the “right” solution is obvious. > > > > That being said, and despite what I said earlier about the co-occurrence > of @copyof and @plist, I think the two approaches here are: > > > > 1. add @plist to to allow explicit referencing of the events > to be repeated > > 2. add another attribute, yet to be named, to permit encoding of the > amount of time to be repeated > > > > The first option is super easy – just make a member of > att.plist. The differentiation of @plist and @copyof must remain clear, > however. @plist identifies the events to be repeated while @copyof > identifies the element *which the beatRpt element is a copy of*. The > likelihood of any element being a copy of another one is rare, so the use > of @copyof should also occur very infrequently. > > > > The second option is somewhat more complex, but still practical. I just > don’t think we can overload @dur or @dur.ges for this purpose. I suggest > that syntax similar to that of @dur.ges be used but another name selected, > perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a > beat in a particular context. Here, we *are* talking about > metrical/musical beats, not MEI beat units. So, in a measure of 6/8, > @beatDef should take the value “4.r” (using Humdrum notation). This defines > a repeated beat as a dotted quarter note. Suggestions for a better name > for this attribute are greatly appreciated. > > > > Adding these new attributes may help with automated resolution of a > beatRpt sign, but their presence can’t be required, meaning that can’t rely > on them entirely in the determination of how much time or which events > should be repeated. There always has to be a fallback approach that makes > a reasonable guess based on the context. > > > > I’ve had a cursory look at where/how the term “beat” is used in > descriptions and documentation and I think that simply replacing “beat” > with “beat unit” won’t work well. It probably would be better to look for > places to insert new text about how MEI treats compound meters literally, > for example in section 4.1.5 “Timestamps and Durations”. > > > > Sound good? > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Komíves Zoltán > > Sent: Tuesday, September 01, 2015 5:55 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > Hi All, > > > > As far as I understand there have been two suggestions to solve the > problem of determining the material that is repeated by : > > 1. use @dur attribute on beatRpt to indicate how much of the preceding > material is repeated. > > 2. provide explicitly what material is repeated. > > > > I think both solutions make sense. The first one is concise, and has no > complicated implications, while the second one provides more flexibility - > I sense there could be situations when the (1) would not suffice, perhaps > some multi-voice situation when only the material in one voice is repeated, > but don't want to think about this too hard now... :) > > > > Could we perhaps allow both solutions, so encoders could chose whichever > fits best their use case? > > > > Regarding the discussion of beat in compound meters, I also think it's > perhaps best to stay away from defining the beat as such, but I also > support to clarify terminology: using "beat unit" rigorously could be a > good enough solution. > > > > Best > > Zoltan > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > Here are some possibilities for moving forward -- > > > > Using @copyof on beatRpt makes it possible to indicate which events are > to be repeated; for example -- > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been > determined that the copy is a modified "deep" one; that is, that the result > tree has the same structure as the designated node with certain attribute > values removed or modified, like xml:id, for example. > > > > There's a slight problem with using @copyof, however, in that it doesn't > allow multiple URIs. We could allow multiple values, but I'm not sure what > it means to say that something is a copy of more than one thing. That > means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add > @copyof and I lean more toward adding @plist instead. Of course, this also > gets us into a little trouble as both @copyof and @plist would be > allowed. As a work-around, a new @targets (notice the plural) could be > added to beatRpt. > > > > Another option is to allow beatRpt to contain content -- either new > events that duplicate those that the repetition sign refers to or > elements that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the > repetition sign and the material inside. The 2nd method may be more > flexible because of the use of references. The down-side for both of these > possibilities is that they are more verbose than using an attribute. > > > > Yet another approach is to create a generic copy element, say, > that represents a copy of any event. That may be too general, however. > For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to > be placed in an attribute. This could lead to mis-use and it would be more > difficult to control where certain functions could occur. But, Johannes > has put this forward in the past, so he's better qualified to address this > approach than I. > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, > Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > > Sent: Thursday, August 27, 2015 11:48 AM > > > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > Ok, this gives us a place to start. It seems to me, however, that > rather than talking about how much time it repeats (as this reignites the > confusion around "beat" and "beat unit"), it may be better to investigate > ways to explicitly indicate which *events* are to repeated. > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 11:18 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > The problem is that when I encounter a in an encoding I would > like to know how much time it repeats. I understand that it represent the > repetition of the material that occur on a previous musical beat, as you > say. However, since the duration of what the musical beat is not encoded > explicitly (as far as I understand) it does not seem to be possible to know > it (i.e., how much time it repeats.). > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as > an attribute? > > > > And how does one allow an attribute directly "in" or ? > > > > We should stay away from determination of meter in MEI. As we've > already heard, it often introduces a lot of subjectivity and > interpretation. That kind of thing is best left to a different, analytical > layer. > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent > Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 10:45 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > What seems fortunate to me is that "beat" is not used as attribute in > MEI (yet?) > > > > Maybe we could use it when we need to specify a musical beat that is not > the meter.unit. As I suggested with , it would be assumed to be 1 > in most cases, but could be "3" in 6/8 (or similar) when the desired > musical beat is 4. . In 5/8, we could imagine having an attribute value > such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, > it could be useful to allow the attribute directly in (or even > ?) when the beat structure is changing. > > > > Laurent > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > > Dear Craig, > > many thanks for your always helpful advice! > > > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. > > > > This is only ambiguous/conflicting if you are to smart and know too much > about music! Regarding the term "beat" in the closed system of MEI > everything is obvious an unambiguous. > > > > > > > > The problem is that in compound meters such as 6/8 > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" > is an eighth note. Using the word "beat" in such a way is unfortunate as > it can conflict with the musical definition of a beat, and this will > continue to cause mis-interpretation of what a beat is. > > > > This then would promote using another term in MEI in order to avoid > confusion, let's say "meter-unit-n". > > > > > > > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a note on > or off of the beat. > > > > This could be a beating argument, if it is the purpose and intention of > MEI to do musical analysis. > > Is it? I'd rather say it provides a basis for doing analysis, the logic > of the analysis is not part of MEI, although the result of the analysis > might be encoded in MEI. > > > > > > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning it to > be a dotted quarter note, but there are exceptions to this definition which > would require a way of assigning an explicit duration to the musical beat. > > > > "Automatically" beaming notes is not part of the encoding but of the > rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > > > > For example, the middle slow movements in a piano sonata may be labeled > as 6/8, with the beat actually assigned to the eighth note, in which case > the "musical beat" and the MEI "beat unit" are the same. > > > > Another more common corner case would be time signatures such as 3/8. > Is that a compound meter with one beat in a measure, or a simple meter with > three beats in the measure (a variant on a 3/4 meter also possible in slow > movements)? > > > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth notes, or > 2+3 or a mixture of both in different measures. > > > > The two above are only a problem if we consider "beat" as being the > "musical beat". If we consider it to be "meter-unit-n" instead, everything > would work out fine. > > > > > > > > Compound meters resulted in a degeneration of mensural notation. Since > modern rhythms are always "imperfect", to emulate a perfect mensuration > dots are added to the notes (which would usually be implicit the mensural > metric equivalent). These are represented as compound meters in modern > notation (who knows why they did not invent "2/4." time signatures instead > of "6/8" for such cases). The problem is that modern time signatures are > ambiguous, since 6/8 could be considered like C-dot, or it could be > considered as a non-compound meter with 6 beat at the eighth-note level. > > > > Ok, air is getting thin for me... > > I've had a problem with modern transcription of mensural notation ever > since I first encountered it, or more precisely I was whinig about modern > notation being so restrictive due to having abandoned mensuration signs. I > would prefer modern transcription sticking to mensuration signs and logic > instead of adding dots, but I might not be able to change the world about > this... > > > > But to bang the drum for "meter-unit-n": Couldn't this problem also be > solved by or some additional attribute on or ? > > > > Considering the case of a modern transcription of "perfect" mensural > notation using in terms of "meter-unit-n" would result in > completely different applicable cases compared to using it in the sense of > "musical beat". An there it is the again, > > ** ambiguous and conflicting** > > > > Just for the sake ofplaying advocatus diavoli 3;-) > > Benni > > > > > > > > I whine to Perry every once in a while about this, so we can wait for > his reply on how to disambiguate such cases... > > > > -=+Craig > > > > > > > > _______________________________________________ > > 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 lxpugin at gmail.com Fri Sep 4 09:34:59 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Fri, 4 Sep 2015 09:34:59 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Thanks Perry for the suggestion. As a simple man I like the simple one ;-) and adding @beat or @beatDef goes along the same lines as my initial idea. One question: why would you use Humdrum-like notation and not make is a factor or a ratio of the current meter.unit? I must be overlooking something. Laurent On Thu, Sep 3, 2015 at 11:47 PM, Kőmíves Zoltán wrote: > Hi Jo, > > Interesting proposition! I am sure there are great use cases for this, > especially for editorial purposes. My feeling is that the sugar of beatRpt > would still be handy for a great deal of cases. > > I have couple of questions: > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in > order to determine how long this repetition lasts, i.e. it will last for as > long as the material at tstamp="2" lasts for. Do I understand this > correctly? > 2. What would the "target slot" addressed by the @ref.* attributes > contain? perhaps? > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I > could see why, especially when the target context has a different meter...) > > Best > Zoltan > > > 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > >> Hi all, >> >> sorry for coming to this discussion very late. Fwiw, I'd like to mention >> an element we came up with during the Freischütz project, which still lacks >> sufficient documentation to be implemented into general MEI – even though I >> strongly believe it's very useful for other projects as well. In essence, >> it's a more general approach to repeat symbols and other notational >> "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" >> and / or "colla parte". This element is a controlEvent (= it lives inside a >> measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the >> second beat of the first staff could look like this: >> >> > ref.offset2="0m+1">/ >> >> The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" >> that this element will say something about – just as in any other control >> event. "beats" in this context is clearly the numbers of the @meter.count. >> Then, the attribute pair @ref.offset and @ref.offset2 is used to say from >> where context is to be copied into this "empty" or "abbreviated" slot. >> @ref.offset uses the same data type as @tstamp2, with the only difference >> that the first number (the one before the "m+" part) may take negative >> values, that is, refer to preceding measures), and @ref.offset2 uses the >> exact same data type as @tstamp2 (it's value is relative to the origin >> defined by @ref.offset). These elements may be combined or replaced by >> @ref.staff (and @ref.layer), which allow to do a colla parte encoding >> ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in >> @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark >> may contain textual content (plus some editorial stuff) to grab what the >> source says – a simple slash, a verbal instruction, whatever. >> >> This is just a very brief introduction to this element, but I hope you >> get the idea. Like I said, I'm not sure if it really helps in this >> discussion of , but I think it allows to be very explicit about >> the scope of a beat repetition symbol. In my understanding, , >> , and all the other <*Rpt> elements are syntactic sugar for this >> element, which is really a more semantic solution for a specific >> type of . Would it be an option to use instead of – >> just to be more explicit? I think this is more or less in line with Perry's >> second suggestion, or at least I believe we should coordinate the search >> for an additional attribute with our proposal. >> >> Hth, >> jo >> >> >> >> >> >> Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) < >> pdr4h at eservices.virginia.edu>: >> >> > >> > Hi, >> > >> > Thanks for contributing to the discussion, Zoltán. As usual, I too am >> in favor of multiple encoding methods, especially in the early phases of >> trying to figure out the best approach – we can deprecate all but one at >> the point where the “right” solution is obvious. >> > >> > That being said, and despite what I said earlier about the >> co-occurrence of @copyof and @plist, I think the two approaches here are: >> > >> > 1. add @plist to to allow explicit referencing of the events >> to be repeated >> > 2. add another attribute, yet to be named, to permit encoding of the >> amount of time to be repeated >> > >> > The first option is super easy – just make a member of >> att.plist. The differentiation of @plist and @copyof must remain clear, >> however. @plist identifies the events to be repeated while @copyof >> identifies the element *which the beatRpt element is a copy of*. The >> likelihood of any element being a copy of another one is rare, so the use >> of @copyof should also occur very infrequently. >> > >> > The second option is somewhat more complex, but still practical. I >> just don’t think we can overload @dur or @dur.ges for this purpose. I >> suggest that syntax similar to that of @dur.ges be used but another name >> selected, perhaps “beat” or “beatDef”, as its purpose is to define what >> constitutes a beat in a particular context. Here, we *are* talking about >> metrical/musical beats, not MEI beat units. So, in a measure of 6/8, >> @beatDef should take the value “4.r” (using Humdrum notation). This defines >> a repeated beat as a dotted quarter note. Suggestions for a better name >> for this attribute are greatly appreciated. >> > >> > Adding these new attributes may help with automated resolution of a >> beatRpt sign, but their presence can’t be required, meaning that can’t rely >> on them entirely in the determination of how much time or which events >> should be repeated. There always has to be a fallback approach that makes >> a reasonable guess based on the context. >> > >> > I’ve had a cursory look at where/how the term “beat” is used in >> descriptions and documentation and I think that simply replacing “beat” >> with “beat unit” won’t work well. It probably would be better to look for >> places to insert new text about how MEI treats compound meters literally, >> for example in section 4.1.5 “Timestamps and Durations”. >> > >> > Sound good? >> > >> > -- >> > p. >> > >> > >> > >> > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Komíves Zoltán >> > Sent: Tuesday, September 01, 2015 5:55 AM >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Beat in 6/8 >> > >> > Hi All, >> > >> > As far as I understand there have been two suggestions to solve the >> problem of determining the material that is repeated by : >> > 1. use @dur attribute on beatRpt to indicate how much of the preceding >> material is repeated. >> > 2. provide explicitly what material is repeated. >> > >> > I think both solutions make sense. The first one is concise, and has no >> complicated implications, while the second one provides more flexibility - >> I sense there could be situations when the (1) would not suffice, perhaps >> some multi-voice situation when only the material in one voice is repeated, >> but don't want to think about this too hard now... :) >> > >> > Could we perhaps allow both solutions, so encoders could chose >> whichever fits best their use case? >> > >> > Regarding the discussion of beat in compound meters, I also think it's >> perhaps best to stay away from defining the beat as such, but I also >> support to clarify terminology: using "beat unit" rigorously could be a >> good enough solution. >> > >> > Best >> > Zoltan >> > >> > >> > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) < >> pdr4h at eservices.virginia.edu>: >> > >> > Here are some possibilities for moving forward -- >> > >> > Using @copyof on beatRpt makes it possible to indicate which events are >> to be repeated; for example -- >> > >> > >> > >> > >> > >> > >> > >> > >> > or perhaps >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > In previous discussions about using the copyof attribute, it has been >> determined that the copy is a modified "deep" one; that is, that the result >> tree has the same structure as the designated node with certain attribute >> values removed or modified, like xml:id, for example. >> > >> > There's a slight problem with using @copyof, however, in that it >> doesn't allow multiple URIs. We could allow multiple values, but I'm not >> sure what it means to say that something is a copy of more than one thing. >> That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant >> to add @copyof and I lean more toward adding @plist instead. Of course, >> this also gets us into a little trouble as both @copyof and @plist would >> be allowed. As a work-around, a new @targets (notice the plural) could be >> added to beatRpt. >> > >> > Another option is to allow beatRpt to contain content -- either new >> events that duplicate those that the repetition sign refers to or >> elements that reference the events; for example, >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > or >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Each one of these options allows an easy "toggling" between the >> repetition sign and the material inside. The 2nd method may be more >> flexible because of the use of references. The down-side for both of these >> possibilities is that they are more verbose than using an attribute. >> > >> > Yet another approach is to create a generic copy element, say, >> that represents a copy of any event. That may be too general, however. >> For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to >> be placed in an attribute. This could lead to mis-use and it would be more >> difficult to control where certain functions could occur. But, Johannes >> has put this forward in the past, so he's better qualified to address this >> approach than I. >> > >> > -- >> > p. >> > >> > __________________________ >> > Perry Roland >> > Music Library >> > University of Virginia >> > P. O. Box 400175 >> > Charlottesville, VA 22904 >> > 434-982-2702 (w) >> > pdr4h (at) virginia (dot) edu >> > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] >> > Sent: Thursday, August 27, 2015 11:48 AM >> > >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Beat in 6/8 >> > >> > >> > Ok, this gives us a place to start. It seems to me, however, that >> rather than talking about how much time it repeats (as this reignites the >> confusion around "beat" and "beat unit"), it may be better to investigate >> ways to explicitly indicate which *events* are to repeated. >> > >> > -- >> > p. >> > >> > >> > __________________________ >> > Perry Roland >> > Music Library >> > University of Virginia >> > P. O. Box 400175 >> > Charlottesville, VA 22904 >> > 434-982-2702 (w) >> > pdr4h (at) virginia (dot) edu >> > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Laurent Pugin [lxpugin at gmail.com] >> > Sent: Thursday, August 27, 2015 11:18 AM >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Beat in 6/8 >> > >> > The problem is that when I encounter a in an encoding I would >> like to know how much time it repeats. I understand that it represent the >> repetition of the material that occur on a previous musical beat, as you >> say. However, since the duration of what the musical beat is not encoded >> explicitly (as far as I understand) it does not seem to be possible to know >> it (i.e., how much time it repeats.). >> > >> > Laurent >> > >> > >> > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < >> pdr4h at eservices.virginia.edu> wrote: >> > >> > >> > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as >> an attribute? >> > >> > And how does one allow an attribute directly "in" or ? >> > >> > We should stay away from determination of meter in MEI. As we've >> already heard, it often introduces a lot of subjectivity and >> interpretation. That kind of thing is best left to a different, analytical >> layer. >> > >> > I still don't see the point -- what does this have to do with beatRpt? >> > >> > -- >> > p. >> > >> > >> > __________________________ >> > Perry Roland >> > Music Library >> > University of Virginia >> > P. O. Box 400175 >> > Charlottesville, VA 22904 >> > 434-982-2702 (w) >> > pdr4h (at) virginia (dot) edu >> > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of >> Laurent Pugin [lxpugin at gmail.com] >> > Sent: Thursday, August 27, 2015 10:45 AM >> > To: Music Encoding Initiative >> > Subject: Re: [MEI-L] Beat in 6/8 >> > >> > What seems fortunate to me is that "beat" is not used as attribute in >> MEI (yet?) >> > >> > Maybe we could use it when we need to specify a musical beat that is >> not the meter.unit. As I suggested with , it would be assumed to >> be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired >> musical beat is 4. . In 5/8, we could imagine having an attribute value >> such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, >> it could be useful to allow the attribute directly in (or even >> ?) when the beat structure is changing. >> > >> > Laurent >> > >> > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl >> wrote: >> > Dear Craig, >> > many thanks for your always helpful advice! >> > >> > Am 27.08.2015 um 11:08 schrieb Craig Sapp: >> > >> > The problem is the ambiguous/conflicting terminology in this sentence: >> > >> > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: >> > meter.unit contains the number indicating the beat unit, that is, the >> bottom number of the meter signature. >> > >> > This is only ambiguous/conflicting if you are to smart and know too >> much about music! Regarding the term "beat" in the closed system of MEI >> everything is obvious an unambiguous. >> > >> > >> > >> > The problem is that in compound meters such as 6/8 >> > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter >> > The "musical beat" is a dotted quarter note, while the MEI "beat unit" >> is an eighth note. Using the word "beat" in such a way is unfortunate as >> it can conflict with the musical definition of a beat, and this will >> continue to cause mis-interpretation of what a beat is. >> > >> > This then would promote using another term in MEI in order to avoid >> confusion, let's say "meter-unit-n". >> > >> > >> > >> > The duration of a beat is necessary for music analysis, since the >> treatment of dissonance and consonance is tied to the location of a note on >> or off of the beat. >> > >> > This could be a beating argument, if it is the purpose and intention of >> MEI to do musical analysis. >> > Is it? I'd rather say it provides a basis for doing analysis, the logic >> of the analysis is not part of MEI, although the result of the analysis >> might be encoded in MEI. >> > >> > >> > The musical beat is also needed to automatically beam notes. Implicit >> interpretation of the musical beat can be done with 6/8 by assigning it to >> be a dotted quarter note, but there are exceptions to this definition which >> would require a way of assigning an explicit duration to the musical beat. >> > >> > "Automatically" beaming notes is not part of the encoding but of the >> rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. >> > >> > >> > >> > For example, the middle slow movements in a piano sonata may be labeled >> as 6/8, with the beat actually assigned to the eighth note, in which case >> the "musical beat" and the MEI "beat unit" are the same. >> > >> > Another more common corner case would be time signatures such as 3/8. >> Is that a compound meter with one beat in a measure, or a simple meter with >> three beats in the measure (a variant on a 3/4 meter also possible in slow >> movements)? >> > >> > And of course in modern music with irregular meters such as 5/8, the >> musical beats in the measure may may have two beats as 3+2 eighth notes, or >> 2+3 or a mixture of both in different measures. >> > >> > The two above are only a problem if we consider "beat" as being the >> "musical beat". If we consider it to be "meter-unit-n" instead, everything >> would work out fine. >> > >> > >> > >> > Compound meters resulted in a degeneration of mensural notation. Since >> modern rhythms are always "imperfect", to emulate a perfect mensuration >> dots are added to the notes (which would usually be implicit the mensural >> metric equivalent). These are represented as compound meters in modern >> notation (who knows why they did not invent "2/4." time signatures instead >> of "6/8" for such cases). The problem is that modern time signatures are >> ambiguous, since 6/8 could be considered like C-dot, or it could be >> considered as a non-compound meter with 6 beat at the eighth-note level. >> > >> > Ok, air is getting thin for me... >> > I've had a problem with modern transcription of mensural notation ever >> since I first encountered it, or more precisely I was whinig about modern >> notation being so restrictive due to having abandoned mensuration signs. I >> would prefer modern transcription sticking to mensuration signs and logic >> instead of adding dots, but I might not be able to change the world about >> this... >> > >> > But to bang the drum for "meter-unit-n": Couldn't this problem also be >> solved by or some additional attribute on or ? >> > >> > Considering the case of a modern transcription of "perfect" mensural >> notation using in terms of "meter-unit-n" would result in >> completely different applicable cases compared to using it in the sense of >> "musical beat". An there it is the again, >> > ** ambiguous and conflicting** >> > >> > Just for the sake ofplaying advocatus diavoli 3;-) >> > Benni >> > >> > >> > >> > I whine to Perry every once in a while about this, so we can wait for >> his reply on how to disambiguate such cases... >> > >> > -=+Craig >> > >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > 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 kepper at edirom.de Fri Sep 4 11:31:41 2015 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 4 Sep 2015 11:31:41 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: Hi Zoltan, Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán : > Hi Jo, > > Interesting proposition! I am sure there are great use cases for this, especially for editorial purposes. My feeling is that the sugar of beatRpt would still be handy for a great deal of cases. > By no means I'm in favor of removing all the specialized <*Rpt> elements, so should definitely stay. It's just that the can be very explicit about what to copy in cases where the "beat" may be confusing. > I have couple of questions: > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in order to determine how long this repetition lasts, i.e. it will last for as long as the material at tstamp="2" lasts for. Do I understand this correctly? Well, afaik we didn't come across a beatRpt that would have been replaced by a . In essence, this is another occasion of the "ending tstamp" discussion Raffaele brought up with addressability proposal. My assumption with encoding this (in 4/4) was that the first beat holds a quarter note. If there were 8th notes, I would have written tstamp2="0m+2.5". I know this isn't absolutely satisfactory, but I believe it's a more general problem, which just surfaces in this situation. But yes, your understanding is correct. > 2. What would the "target slot" addressed by the @ref.* attributes contain? perhaps? That's how we used it. Actually, we generated a , with an containing a space, and an containing the copied material. This way, you can simply decide if you want to see the source as it is written or as it is performed. In addition, all "copied" notes etc. have a @corresp pointing to their original counterpart, which makes certain analytical approaches very simple. > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I could see why, especially when the target context has a different meter...) In most cases, it is redundant (and could be defaulted to the value of @tstamp2 in the documentation). However, if you try to encode a with the means of (which we did quite often), your origin sits in a different slot than the target. The complex meters you brought up in your other mail also require to have a separate attribute for this, I believe. Thanks, jo > > Best > Zoltan > > > 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > Hi all, > > sorry for coming to this discussion very late. Fwiw, I'd like to mention an element we came up with during the Freischütz project, which still lacks sufficient documentation to be implemented into general MEI – even though I strongly believe it's very useful for other projects as well. In essence, it's a more general approach to repeat symbols and other notational "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla parte". This element is a controlEvent (= it lives inside a measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff could look like this: > > / > > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" that this element will say something about – just as in any other control event. "beats" in this context is clearly the numbers of the @meter.count. Then, the attribute pair @ref.offset and @ref.offset2 is used to say from where context is to be copied into this "empty" or "abbreviated" slot. @ref.offset uses the same data type as @tstamp2, with the only difference that the first number (the one before the "m+" part) may take negative values, that is, refer to preceding measures), and @ref.offset2 uses the exact same data type as @tstamp2 (it's value is relative to the origin defined by @ref.offset). These elements may be combined or replaced by @ref.staff (and @ref.layer), which allow to do a colla parte encoding ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark may contain textual content (plus some editorial stuff) to grab what the source says – a simple slash, a verbal instruction, whatever. > > This is just a very brief introduction to this element, but I hope you get the idea. Like I said, I'm not sure if it really helps in this discussion of , but I think it allows to be very explicit about the scope of a beat repetition symbol. In my understanding, , , and all the other <*Rpt> elements are syntactic sugar for this element, which is really a more semantic solution for a specific type of . Would it be an option to use instead of – just to be more explicit? I think this is more or less in line with Perry's second suggestion, or at least I believe we should coordinate the search for an additional attribute with our proposal. > > Hth, > jo > > > > > > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) : > > > > > Hi, > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am in favor of multiple encoding methods, especially in the early phases of trying to figure out the best approach – we can deprecate all but one at the point where the “right” solution is obvious. > > > > That being said, and despite what I said earlier about the co-occurrence of @copyof and @plist, I think the two approaches here are: > > > > 1. add @plist to to allow explicit referencing of the events to be repeated > > 2. add another attribute, yet to be named, to permit encoding of the amount of time to be repeated > > > > The first option is super easy – just make a member of att.plist. The differentiation of @plist and @copyof must remain clear, however. @plist identifies the events to be repeated while @copyof identifies the element *which the beatRpt element is a copy of*. The likelihood of any element being a copy of another one is rare, so the use of @copyof should also occur very infrequently. > > > > The second option is somewhat more complex, but still practical. I just don’t think we can overload @dur or @dur.ges for this purpose. I suggest that syntax similar to that of @dur.ges be used but another name selected, perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a beat in a particular context. Here, we *are* talking about metrical/musical beats, not MEI beat units. So, in a measure of 6/8, @beatDef should take the value “4.r” (using Humdrum notation). This defines a repeated beat as a dotted quarter note. Suggestions for a better name for this attribute are greatly appreciated. > > > > Adding these new attributes may help with automated resolution of a beatRpt sign, but their presence can’t be required, meaning that can’t rely on them entirely in the determination of how much time or which events should be repeated. There always has to be a fallback approach that makes a reasonable guess based on the context. > > > > I’ve had a cursory look at where/how the term “beat” is used in descriptions and documentation and I think that simply replacing “beat” with “beat unit” won’t work well. It probably would be better to look for places to insert new text about how MEI treats compound meters literally, for example in section 4.1.5 “Timestamps and Durations”. > > > > Sound good? > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán > > Sent: Tuesday, September 01, 2015 5:55 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > Hi All, > > > > As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by : > > 1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated. > > 2. provide explicitly what material is repeated. > > > > I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :) > > > > Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case? > > > > Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution. > > > > Best > > Zoltan > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) : > > > > Here are some possibilities for moving forward -- > > > > Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example -- > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example. > > > > There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing. That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead. Of course, this also gets us into a little trouble as both @copyof and @plist would be allowed. As a work-around, a new @targets (notice the plural) could be added to beatRpt. > > > > Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or elements that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the repetition sign and the material inside. The 2nd method may be more flexible because of the use of references. The down-side for both of these possibilities is that they are more verbose than using an attribute. > > > > Yet another approach is to create a generic copy element, say, that represents a copy of any event. That may be too general, however. For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute. This could lead to mis-use and it would be more difficult to control where certain functions could occur. But, Johannes has put this forward in the past, so he's better qualified to address this approach than I. > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > > Sent: Thursday, August 27, 2015 11:48 AM > > > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 11:18 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) wrote: > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? > > > > And how does one allow an attribute directly "in" or ? > > > > We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 10:45 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) > > > > Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. > > > > Laurent > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl wrote: > > Dear Craig, > > many thanks for your always helpful advice! > > > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > > meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. > > > > This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. > > > > > > > > The problem is that in compound meters such as 6/8 > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. > > > > This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". > > > > > > > > The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. > > > > This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. > > Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. > > > > > > The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. > > > > "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > > > > For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. > > > > Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? > > > > And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. > > > > The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. > > > > > > > > Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. > > > > Ok, air is getting thin for me... > > I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... > > > > But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? > > > > Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, > > ** ambiguous and conflicting** > > > > Just for the sake ofplaying advocatus diavoli 3;-) > > Benni > > > > > > > > I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... > > > > -=+Craig > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From lxpugin at gmail.com Fri Sep 4 13:57:49 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Fri, 4 Sep 2015 13:57:49 +0200 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> Message-ID: On Fri, Sep 4, 2015 at 11:31 AM, Johannes Kepper wrote: > Hi Zoltan, > > > Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán : > > > Hi Jo, > > > > Interesting proposition! I am sure there are great use cases for this, > especially for editorial purposes. My feeling is that the sugar of beatRpt > would still be handy for a great deal of cases. > > > > By no means I'm in favor of removing all the specialized <*Rpt> elements, > so should definitely stay. It's just that the can be > very explicit about what to copy in cases where the "beat" may be confusing. > > > > I have couple of questions: > > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in > order to determine how long this repetition lasts, i.e. it will last for as > long as the material at tstamp="2" lasts for. Do I understand this > correctly? > > Well, afaik we didn't come across a beatRpt that would have been replaced > by a . In essence, this is another occasion of the "ending tstamp" > discussion Raffaele brought up with addressability proposal. My assumption > with encoding this (in 4/4) was that the first beat holds a quarter note. > If there were 8th notes, I would have written tstamp2="0m+2.5". I know this > isn't absolutely satisfactory, but I believe it's a more general problem, > which just surfaces in this situation. But yes, your understanding is > correct. > I agree this is problematic. I would expect The fact that timestamp use decimal (and not fractions) was another issue raised in the aforementioned discussion that would clearly cause problems here. > > > 2. What would the "target slot" addressed by the @ref.* attributes > contain? perhaps? > > That's how we used it. Actually, we generated a , with an > containing a space, and an containing the copied material. This > way, you can simply decide if you want to see the source as it is written > or as it is performed. In addition, all "copied" notes etc. have a @corresp > pointing to their original counterpart, which makes certain analytical > approaches very simple. > > > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I > could see why, especially when the target context has a different meter...) > > In most cases, it is redundant (and could be defaulted to the value of > @tstamp2 in the documentation). However, if you try to encode a > with the means of (which we did quite often), your origin sits in > a different slot than the target. The complex meters you brought up in your > other mail also require to have a separate attribute for this, I believe. > > Thanks, > jo > > > > > Best > > Zoltan > > > > > > 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > > Hi all, > > > > sorry for coming to this discussion very late. Fwiw, I'd like to mention > an element we came up with during the Freischütz project, which still lacks > sufficient documentation to be implemented into general MEI – even though I > strongly believe it's very useful for other projects as well. In essence, > it's a more general approach to repeat symbols and other notational > "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" > and / or "colla parte". This element is a controlEvent (= it lives inside a > measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the > second beat of the first staff could look like this: > > > > ref.offset2="0m+1">/ > > > > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" > that this element will say something about – just as in any other control > event. "beats" in this context is clearly the numbers of the @meter.count. > Then, the attribute pair @ref.offset and @ref.offset2 is used to say from > where context is to be copied into this "empty" or "abbreviated" slot. > @ref.offset uses the same data type as @tstamp2, with the only difference > that the first number (the one before the "m+" part) may take negative > values, that is, refer to preceding measures), and @ref.offset2 uses the > exact same data type as @tstamp2 (it's value is relative to the origin > defined by @ref.offset). These elements may be combined or replaced by > @ref.staff (and @ref.layer), which allow to do a colla parte encoding > ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in > @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark > may contain textual content (plus some editorial stuff) to grab what the > source says – a simple slash, a verbal instruction, whatever. > > > > This is just a very brief introduction to this element, but I hope you > get the idea. Like I said, I'm not sure if it really helps in this > discussion of , but I think it allows to be very explicit about > the scope of a beat repetition symbol. In my understanding, , > , and all the other <*Rpt> elements are syntactic sugar for this > element, which is really a more semantic solution for a specific > type of . Would it be an option to use instead of – > just to be more explicit? I think this is more or less in line with Perry's > second suggestion, or at least I believe we should coordinate the search > for an additional attribute with our proposal. > > > > Hth, > > jo > > > > > > > > > > > > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > > > > > Hi, > > > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am > in favor of multiple encoding methods, especially in the early phases of > trying to figure out the best approach – we can deprecate all but one at > the point where the “right” solution is obvious. > > > > > > That being said, and despite what I said earlier about the > co-occurrence of @copyof and @plist, I think the two approaches here are: > > > > > > 1. add @plist to to allow explicit referencing of the events > to be repeated > > > 2. add another attribute, yet to be named, to permit encoding of the > amount of time to be repeated > > > > > > The first option is super easy – just make a member of > att.plist. The differentiation of @plist and @copyof must remain clear, > however. @plist identifies the events to be repeated while @copyof > identifies the element *which the beatRpt element is a copy of*. The > likelihood of any element being a copy of another one is rare, so the use > of @copyof should also occur very infrequently. > > > > > > The second option is somewhat more complex, but still practical. I > just don’t think we can overload @dur or @dur.ges for this purpose. I > suggest that syntax similar to that of @dur.ges be used but another name > selected, perhaps “beat” or “beatDef”, as its purpose is to define what > constitutes a beat in a particular context. Here, we *are* talking about > metrical/musical beats, not MEI beat units. So, in a measure of 6/8, > @beatDef should take the value “4.r” (using Humdrum notation). This defines > a repeated beat as a dotted quarter note. Suggestions for a better name > for this attribute are greatly appreciated. > > > > > > Adding these new attributes may help with automated resolution of a > beatRpt sign, but their presence can’t be required, meaning that can’t rely > on them entirely in the determination of how much time or which events > should be repeated. There always has to be a fallback approach that makes > a reasonable guess based on the context. > > > > > > I’ve had a cursory look at where/how the term “beat” is used in > descriptions and documentation and I think that simply replacing “beat” > with “beat unit” won’t work well. It probably would be better to look for > places to insert new text about how MEI treats compound meters literally, > for example in section 4.1.5 “Timestamps and Durations”. > > > > > > Sound good? > > > > > > -- > > > p. > > > > > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > Of Komíves Zoltán > > > Sent: Tuesday, September 01, 2015 5:55 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > Hi All, > > > > > > As far as I understand there have been two suggestions to solve the > problem of determining the material that is repeated by : > > > 1. use @dur attribute on beatRpt to indicate how much of the preceding > material is repeated. > > > 2. provide explicitly what material is repeated. > > > > > > I think both solutions make sense. The first one is concise, and has > no complicated implications, while the second one provides more flexibility > - I sense there could be situations when the (1) would not suffice, perhaps > some multi-voice situation when only the material in one voice is repeated, > but don't want to think about this too hard now... :) > > > > > > Could we perhaps allow both solutions, so encoders could chose > whichever fits best their use case? > > > > > > Regarding the discussion of beat in compound meters, I also think it's > perhaps best to stay away from defining the beat as such, but I also > support to clarify terminology: using "beat unit" rigorously could be a > good enough solution. > > > > > > Best > > > Zoltan > > > > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu>: > > > > > > Here are some possibilities for moving forward -- > > > > > > Using @copyof on beatRpt makes it possible to indicate which events > are to be repeated; for example -- > > > > > > > > > > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been > determined that the copy is a modified "deep" one; that is, that the result > tree has the same structure as the designated node with certain attribute > values removed or modified, like xml:id, for example. > > > > > > There's a slight problem with using @copyof, however, in that it > doesn't allow multiple URIs. We could allow multiple values, but I'm not > sure what it means to say that something is a copy of more than one thing. > That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant > to add @copyof and I lean more toward adding @plist instead. Of course, > this also gets us into a little trouble as both @copyof and @plist would > be allowed. As a work-around, a new @targets (notice the plural) could be > added to beatRpt. > > > > > > Another option is to allow beatRpt to contain content -- either new > events that duplicate those that the repetition sign refers to or > elements that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the > repetition sign and the material inside. The 2nd method may be more > flexible because of the use of references. The down-side for both of these > possibilities is that they are more verbose than using an attribute. > > > > > > Yet another approach is to create a generic copy element, say, > that represents a copy of any event. That may be too general, > however. For example, the function of the copyOf (beatRpt, mRpt, etc.) > would have to be placed in an attribute. This could lead to mis-use and it > would be more difficult to control where certain functions could occur. > But, Johannes has put this forward in the past, so he's better qualified to > address this approach than I. > > > > > > -- > > > p. > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > > > Sent: Thursday, August 27, 2015 11:48 AM > > > > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > > > > Ok, this gives us a place to start. It seems to me, however, that > rather than talking about how much time it repeats (as this reignites the > confusion around "beat" and "beat unit"), it may be better to investigate > ways to explicitly indicate which *events* are to repeated. > > > > > > -- > > > p. > > > > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Laurent Pugin [lxpugin at gmail.com] > > > Sent: Thursday, August 27, 2015 11:18 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > The problem is that when I encounter a in an encoding I > would like to know how much time it repeats. I understand that it represent > the repetition of the material that occur on a previous musical beat, as > you say. However, since the duration of what the musical beat is not > encoded explicitly (as far as I understand) it does not seem to be possible > to know it (i.e., how much time it repeats.). > > > > > > Laurent > > > > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as > an attribute? > > > > > > And how does one allow an attribute directly "in" or ? > > > > > > We should stay away from determination of meter in MEI. As we've > already heard, it often introduces a lot of subjectivity and > interpretation. That kind of thing is best left to a different, analytical > layer. > > > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > > > -- > > > p. > > > > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > Laurent Pugin [lxpugin at gmail.com] > > > Sent: Thursday, August 27, 2015 10:45 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > What seems fortunate to me is that "beat" is not used as attribute in > MEI (yet?) > > > > > > Maybe we could use it when we need to specify a musical beat that is > not the meter.unit. As I suggested with , it would be assumed to > be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired > musical beat is 4. . In 5/8, we could imagine having an attribute value > such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, > it could be useful to allow the attribute directly in (or even > ?) when the beat structure is changing. > > > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > > > Dear Craig, > > > many thanks for your always helpful advice! > > > > > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > > > > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: > > > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. > > > > > > This is only ambiguous/conflicting if you are to smart and know too > much about music! Regarding the term "beat" in the closed system of MEI > everything is obvious an unambiguous. > > > > > > > > > > > > The problem is that in compound meters such as 6/8 > > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" > is an eighth note. Using the word "beat" in such a way is unfortunate as > it can conflict with the musical definition of a beat, and this will > continue to cause mis-interpretation of what a beat is. > > > > > > This then would promote using another term in MEI in order to avoid > confusion, let's say "meter-unit-n". > > > > > > > > > > > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a note on > or off of the beat. > > > > > > This could be a beating argument, if it is the purpose and intention > of MEI to do musical analysis. > > > Is it? I'd rather say it provides a basis for doing analysis, the > logic of the analysis is not part of MEI, although the result of the > analysis might be encoded in MEI. > > > > > > > > > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning it to > be a dotted quarter note, but there are exceptions to this definition which > would require a way of assigning an explicit duration to the musical beat. > > > > > > "Automatically" beaming notes is not part of the encoding but of the > rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > > > > > > > > For example, the middle slow movements in a piano sonata may be > labeled as 6/8, with the beat actually assigned to the eighth note, in > which case the "musical beat" and the MEI "beat unit" are the same. > > > > > > Another more common corner case would be time signatures such as 3/8. > Is that a compound meter with one beat in a measure, or a simple meter with > three beats in the measure (a variant on a 3/4 meter also possible in slow > movements)? > > > > > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth notes, or > 2+3 or a mixture of both in different measures. > > > > > > The two above are only a problem if we consider "beat" as being the > "musical beat". If we consider it to be "meter-unit-n" instead, everything > would work out fine. > > > > > > > > > > > > Compound meters resulted in a degeneration of mensural notation. > Since modern rhythms are always "imperfect", to emulate a perfect > mensuration dots are added to the notes (which would usually be implicit > the mensural metric equivalent). These are represented as compound meters > in modern notation (who knows why they did not invent "2/4." time > signatures instead of "6/8" for such cases). The problem is that modern > time signatures are ambiguous, since 6/8 could be considered like C-dot, or > it could be considered as a non-compound meter with 6 beat at the > eighth-note level. > > > > > > Ok, air is getting thin for me... > > > I've had a problem with modern transcription of mensural notation ever > since I first encountered it, or more precisely I was whinig about modern > notation being so restrictive due to having abandoned mensuration signs. I > would prefer modern transcription sticking to mensuration signs and logic > instead of adding dots, but I might not be able to change the world about > this... > > > > > > But to bang the drum for "meter-unit-n": Couldn't this problem also be > solved by or some additional attribute on or ? > > > > > > Considering the case of a modern transcription of "perfect" mensural > notation using in terms of "meter-unit-n" would result in > completely different applicable cases compared to using it in the sense of > "musical beat". An there it is the again, > > > ** ambiguous and conflicting** > > > > > > Just for the sake ofplaying advocatus diavoli 3;-) > > > Benni > > > > > > > > > > > > I whine to Perry every once in a while about this, so we can wait for > his reply on how to disambiguate such cases... > > > > > > -=+Craig > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 Fri Sep 4 15:53:55 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 4 Sep 2015 13:53:55 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , Message-ID: Yes, should/must stay. I think is a great idea, but adding all the attributes that more specific elements like need would cause a great deal of confusion. I'm concerned about the potential for confusion in the addressing system Jo proposes, but let's think about the possibility of creating a cpMark attribute class that provides this kind of addressing and make the <*Rpt> elements members of this new class. This way, <*Rpt> elements may use the new addressing possibilities while retaining their specialized attributes. Another alternative already present in MEI is the use of with (containing ) and (containing the performed result) sub-elements. This is another way to be explicit about what is written and its performance implications. This is somewhat verbose, however, and not obvious to our classic "naive encoder" (otherwise known as OMR). My suggestions yesterday were an attempt to locate all one might need to know about a element in/on the element itself. As for Z's example of complex time signatures, I can't ever recall seeing such usage. This is not proof that such things don't exist, but it's my impression that users of such things eschew the use of traditional CMN approaches to repetition. Just in case, however, @beatDef could use the data.DURATION.additive datatype that allows multiple, optionally dotted values, which taken together add up to the desired amount of time. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Friday, September 04, 2015 5:32 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Beat in 6/8 Hi Zoltan, Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán : > Hi Jo, > > Interesting proposition! I am sure there are great use cases for this, especially for editorial purposes. My feeling is that the sugar of beatRpt would still be handy for a great deal of cases. > By no means I'm in favor of removing all the specialized <*Rpt> elements, so should definitely stay. It's just that the can be very explicit about what to copy in cases where the "beat" may be confusing. > I have couple of questions: > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in order to determine how long this repetition lasts, i.e. it will last for as long as the material at tstamp="2" lasts for. Do I understand this correctly? Well, afaik we didn't come across a beatRpt that would have been replaced by a . In essence, this is another occasion of the "ending tstamp" discussion Raffaele brought up with addressability proposal. My assumption with encoding this (in 4/4) was that the first beat holds a quarter note. If there were 8th notes, I would have written tstamp2="0m+2.5". I know this isn't absolutely satisfactory, but I believe it's a more general problem, which just surfaces in this situation. But yes, your understanding is correct. > 2. What would the "target slot" addressed by the @ref.* attributes contain? perhaps? That's how we used it. Actually, we generated a , with an containing a space, and an containing the copied material. This way, you can simply decide if you want to see the source as it is written or as it is performed. In addition, all "copied" notes etc. have a @corresp pointing to their original counterpart, which makes certain analytical approaches very simple. > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? (I could see why, especially when the target context has a different meter...) In most cases, it is redundant (and could be defaulted to the value of @tstamp2 in the documentation). However, if you try to encode a with the means of (which we did quite often), your origin sits in a different slot than the target. The complex meters you brought up in your other mail also require to have a separate attribute for this, I believe. Thanks, jo > > Best > Zoltan > > > 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > Hi all, > > sorry for coming to this discussion very late. Fwiw, I'd like to mention an element we came up with during the Freischütz project, which still lacks sufficient documentation to be implemented into general MEI – even though I strongly believe it's very useful for other projects as well. In essence, it's a more general approach to repeat symbols and other notational "shortcuts". We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla parte". This element is a controlEvent (= it lives inside a measure, just like a slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff could look like this: > > / > > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" that this element will say something about – just as in any other control event. "beats" in this context is clearly the numbers of the @meter.count. Then, the attribute pair @ref.offset and @ref.offset2 is used to say from where context is to be copied into this "empty" or "abbreviated" slot. @ref.offset uses the same data type as @tstamp2, with the only difference that the first number (the one before the "m+" part) may take negative values, that is, refer to preceding measures), and @ref.offset2 uses the exact same data type as @tstamp2 (it's value is relative to the origin defined by @ref.offset). These elements may be combined or replaced by @ref.staff (and @ref.layer), which allow to do a colla parte encoding ("…for the range defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff, potentially affected by @dis for an 'in ottava'…"). The cpMark may contain textual content (plus some editorial stuff) to grab what the source says – a simple slash, a verbal instruction, whatever. > > This is just a very brief introduction to this element, but I hope you get the idea. Like I said, I'm not sure if it really helps in this discussion of , but I think it allows to be very explicit about the scope of a beat repetition symbol. In my understanding, , , and all the other <*Rpt> elements are syntactic sugar for this element, which is really a more semantic solution for a specific type of . Would it be an option to use instead of – just to be more explicit? I think this is more or less in line with Perry's second suggestion, or at least I believe we should coordinate the search for an additional attribute with our proposal. > > Hth, > jo > > > > > > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) : > > > > > Hi, > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am in favor of multiple encoding methods, especially in the early phases of trying to figure out the best approach – we can deprecate all but one at the point where the “right” solution is obvious. > > > > That being said, and despite what I said earlier about the co-occurrence of @copyof and @plist, I think the two approaches here are: > > > > 1. add @plist to to allow explicit referencing of the events to be repeated > > 2. add another attribute, yet to be named, to permit encoding of the amount of time to be repeated > > > > The first option is super easy – just make a member of att.plist. The differentiation of @plist and @copyof must remain clear, however. @plist identifies the events to be repeated while @copyof identifies the element *which the beatRpt element is a copy of*. The likelihood of any element being a copy of another one is rare, so the use of @copyof should also occur very infrequently. > > > > The second option is somewhat more complex, but still practical. I just don’t think we can overload @dur or @dur.ges for this purpose. I suggest that syntax similar to that of @dur.ges be used but another name selected, perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a beat in a particular context. Here, we *are* talking about metrical/musical beats, not MEI beat units. So, in a measure of 6/8, @beatDef should take the value “4.r” (using Humdrum notation). This defines a repeated beat as a dotted quarter note. Suggestions for a better name for this attribute are greatly appreciated. > > > > Adding these new attributes may help with automated resolution of a beatRpt sign, but their presence can’t be required, meaning that can’t rely on them entirely in the determination of how much time or which events should be repeated. There always has to be a fallback approach that makes a reasonable guess based on the context. > > > > I’ve had a cursory look at where/how the term “beat” is used in descriptions and documentation and I think that simply replacing “beat” with “beat unit” won’t work well. It probably would be better to look for places to insert new text about how MEI treats compound meters literally, for example in section 4.1.5 “Timestamps and Durations”. > > > > Sound good? > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Komíves Zoltán > > Sent: Tuesday, September 01, 2015 5:55 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > Hi All, > > > > As far as I understand there have been two suggestions to solve the problem of determining the material that is repeated by : > > 1. use @dur attribute on beatRpt to indicate how much of the preceding material is repeated. > > 2. provide explicitly what material is repeated. > > > > I think both solutions make sense. The first one is concise, and has no complicated implications, while the second one provides more flexibility - I sense there could be situations when the (1) would not suffice, perhaps some multi-voice situation when only the material in one voice is repeated, but don't want to think about this too hard now... :) > > > > Could we perhaps allow both solutions, so encoders could chose whichever fits best their use case? > > > > Regarding the discussion of beat in compound meters, I also think it's perhaps best to stay away from defining the beat as such, but I also support to clarify terminology: using "beat unit" rigorously could be a good enough solution. > > > > Best > > Zoltan > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) : > > > > Here are some possibilities for moving forward -- > > > > Using @copyof on beatRpt makes it possible to indicate which events are to be repeated; for example -- > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been determined that the copy is a modified "deep" one; that is, that the result tree has the same structure as the designated node with certain attribute values removed or modified, like xml:id, for example. > > > > There's a slight problem with using @copyof, however, in that it doesn't allow multiple URIs. We could allow multiple values, but I'm not sure what it means to say that something is a copy of more than one thing. That means it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I lean more toward adding @plist instead. Of course, this also gets us into a little trouble as both @copyof and @plist would be allowed. As a work-around, a new @targets (notice the plural) could be added to beatRpt. > > > > Another option is to allow beatRpt to contain content -- either new events that duplicate those that the repetition sign refers to or elements that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the repetition sign and the material inside. The 2nd method may be more flexible because of the use of references. The down-side for both of these possibilities is that they are more verbose than using an attribute. > > > > Yet another approach is to create a generic copy element, say, that represents a copy of any event. That may be too general, however. For example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be placed in an attribute. This could lead to mis-use and it would be more difficult to control where certain functions could occur. But, Johannes has put this forward in the past, so he's better qualified to address this approach than I. > > > > -- > > p. > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > > Sent: Thursday, August 27, 2015 11:48 AM > > > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > Ok, this gives us a place to start. It seems to me, however, that rather than talking about how much time it repeats (as this reignites the confusion around "beat" and "beat unit"), it may be better to investigate ways to explicitly indicate which *events* are to repeated. > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 11:18 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > The problem is that when I encounter a in an encoding I would like to know how much time it repeats. I understand that it represent the repetition of the material that occur on a previous musical beat, as you say. However, since the duration of what the musical beat is not encoded explicitly (as far as I understand) it does not seem to be possible to know it (i.e., how much time it repeats.). > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) wrote: > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an attribute? > > > > And how does one allow an attribute directly "in" or ? > > > > We should stay away from determination of meter in MEI. As we've already heard, it often introduces a lot of subjectivity and interpretation. That kind of thing is best left to a different, analytical layer. > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > -- > > p. > > > > > > __________________________ > > Perry Roland > > Music Library > > University of Virginia > > P. O. Box 400175 > > Charlottesville, VA 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] > > Sent: Thursday, August 27, 2015 10:45 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] Beat in 6/8 > > > > What seems fortunate to me is that "beat" is not used as attribute in MEI (yet?) > > > > Maybe we could use it when we need to specify a musical beat that is not the meter.unit. As I suggested with , it would be assumed to be 1 in most cases, but could be "3" in 6/8 (or similar) when the desired musical beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if the beat is expected to be 4 - 4. . Along the same lines, it could be useful to allow the attribute directly in (or even ?) when the beat structure is changing. > > > > Laurent > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl wrote: > > Dear Craig, > > many thanks for your always helpful advice! > > > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl wrote: > > meter.unit contains the number indicating the beat unit, that is, the bottom number of the meter signature. > > > > This is only ambiguous/conflicting if you are to smart and know too much about music! Regarding the term "beat" in the closed system of MEI everything is obvious an unambiguous. > > > > > > > > The problem is that in compound meters such as 6/8 > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is an eighth note. Using the word "beat" in such a way is unfortunate as it can conflict with the musical definition of a beat, and this will continue to cause mis-interpretation of what a beat is. > > > > This then would promote using another term in MEI in order to avoid confusion, let's say "meter-unit-n". > > > > > > > > The duration of a beat is necessary for music analysis, since the treatment of dissonance and consonance is tied to the location of a note on or off of the beat. > > > > This could be a beating argument, if it is the purpose and intention of MEI to do musical analysis. > > Is it? I'd rather say it provides a basis for doing analysis, the logic of the analysis is not part of MEI, although the result of the analysis might be encoded in MEI. > > > > > > The musical beat is also needed to automatically beam notes. Implicit interpretation of the musical beat can be done with 6/8 by assigning it to be a dotted quarter note, but there are exceptions to this definition which would require a way of assigning an explicit duration to the musical beat. > > > > "Automatically" beaming notes is not part of the encoding but of the rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > > > > For example, the middle slow movements in a piano sonata may be labeled as 6/8, with the beat actually assigned to the eighth note, in which case the "musical beat" and the MEI "beat unit" are the same. > > > > Another more common corner case would be time signatures such as 3/8. Is that a compound meter with one beat in a measure, or a simple meter with three beats in the measure (a variant on a 3/4 meter also possible in slow movements)? > > > > And of course in modern music with irregular meters such as 5/8, the musical beats in the measure may may have two beats as 3+2 eighth notes, or 2+3 or a mixture of both in different measures. > > > > The two above are only a problem if we consider "beat" as being the "musical beat". If we consider it to be "meter-unit-n" instead, everything would work out fine. > > > > > > > > Compound meters resulted in a degeneration of mensural notation. Since modern rhythms are always "imperfect", to emulate a perfect mensuration dots are added to the notes (which would usually be implicit the mensural metric equivalent). These are represented as compound meters in modern notation (who knows why they did not invent "2/4." time signatures instead of "6/8" for such cases). The problem is that modern time signatures are ambiguous, since 6/8 could be considered like C-dot, or it could be considered as a non-compound meter with 6 beat at the eighth-note level. > > > > Ok, air is getting thin for me... > > I've had a problem with modern transcription of mensural notation ever since I first encountered it, or more precisely I was whinig about modern notation being so restrictive due to having abandoned mensuration signs. I would prefer modern transcription sticking to mensuration signs and logic instead of adding dots, but I might not be able to change the world about this... > > > > But to bang the drum for "meter-unit-n": Couldn't this problem also be solved by or some additional attribute on or ? > > > > Considering the case of a modern transcription of "perfect" mensural notation using in terms of "meter-unit-n" would result in completely different applicable cases compared to using it in the sense of "musical beat". An there it is the again, > > ** ambiguous and conflicting** > > > > Just for the sake ofplaying advocatus diavoli 3;-) > > Benni > > > > > > > > I whine to Perry every once in a while about this, so we can wait for his reply on how to disambiguate such cases... > > > > -=+Craig > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > 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 Sep 9 16:13:44 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 9 Sep 2015 14:13:44 +0000 Subject: [MEI-L] Beat in 6/8 In-Reply-To: References: <25F9F8B5-B4AF-4150-81A6-1019A36CBB6D@indiana.edu> <55DEC82D.4010601@edirom.de> <55DF196E.2060405@edirom.de> , Message-ID: I have a problem with how @tstamp and @tstamp2 are described with regard to the proposed element. In every other case, these two attributes refer to *points in time*, not durations. For example, when we say we mean that the slur begins on beat unit 1 and ends precisely on beat unit 3. If we want it to end somewhere in the middle of beat unit 3, then we must use the value "3.5". (But this still means it ends precisely on the & of 3 and doesn't describe how long it lasts.) It is therefore inconsistent for to use these attributes to mean "get the stuff between beat units 1 and 3 *inclusive of beat unit 3*". Either we must re-define how these attributes work (an onerous task that might break a lot of other things, I believe) or different attributes must be used on / defined for . Returning to the example above, if we want to capture the *duration* of the slur, then we must write Now *this* says that the slur begins on beat unit 1 and *lasts for a dotted half-note*; that is, inclusive of the endpoint of the dotted half-note. The use of @dur instead of @tstamp2 resolves the inconsistency between the definition of @tstamp2 on and that used elsewhere. I'd have to see more examples of the use of to speak definitively about @ref.offset and @ref.offset2, but I suspect that using a time point / @tstamp for the first and a duration (instead of a time point) for the second may work better; that is, retain consistency. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Roland, Perry D. (pdr4h) > Sent: Friday, September 04, 2015 9:54 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > > Yes, should/must stay. I think is a great idea, but > adding all the attributes that more specific elements like need > would cause a great deal of confusion. I'm concerned about the potential for > confusion in the addressing system Jo proposes, but let's think about the > possibility of creating a cpMark attribute class that provides this kind of > addressing and make the <*Rpt> elements members of this new class. This > way, <*Rpt> elements may use the new addressing possibilities while > retaining their specialized attributes. > > Another alternative already present in MEI is the use of with > (containing ) and (containing the performed result) sub- > elements. This is another way to be explicit about what is written and its > performance implications. This is somewhat verbose, however, and not > obvious to our classic "naive encoder" (otherwise known as OMR). My > suggestions yesterday were an attempt to locate all one might need to know > about a element in/on the element itself. > > As for Z's example of complex time signatures, I can't ever recall seeing such > usage. This is not proof that such things don't exist, but it's my impression > that users of such things eschew the use of traditional CMN approaches to > repetition. Just in case, however, @beatDef could use the > data.DURATION.additive datatype that allows multiple, optionally dotted > values, which taken together add up to the desired amount of time. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > ________________________________________ > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes > Kepper [kepper at edirom.de] > Sent: Friday, September 04, 2015 5:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Beat in 6/8 > > Hi Zoltan, > > > Am 03.09.2015 um 23:47 schrieb Kőmíves Zoltán : > > > Hi Jo, > > > > Interesting proposition! I am sure there are great use cases for this, > especially for editorial purposes. My feeling is that the sugar of beatRpt > would still be handy for a great deal of cases. > > > > By no means I'm in favor of removing all the specialized <*Rpt> elements, so > should definitely stay. It's just that the can be very > explicit about what to copy in cases where the "beat" may be confusing. > > > > I have couple of questions: > > 1. tstamp="2" tstamp2="0m+2": it seems to me that a context is needed in > order to determine how long this repetition lasts, i.e. it will last for as long as > the material at tstamp="2" lasts for. Do I understand this correctly? > > Well, afaik we didn't come across a beatRpt that would have been replaced > by a . In essence, this is another occasion of the "ending tstamp" > discussion Raffaele brought up with addressability proposal. My assumption > with encoding this (in 4/4) was that the first beat holds a quarter note. If > there were 8th notes, I would have written tstamp2="0m+2.5". I know this > isn't absolutely satisfactory, but I believe it's a more general problem, which > just surfaces in this situation. But yes, your understanding is correct. > > > 2. What would the "target slot" addressed by the @ref.* attributes > contain? perhaps? > > That's how we used it. Actually, we generated a , with an > containing a space, and an containing the copied material. This way, > you can simply decide if you want to see the source as it is written or as it is > performed. In addition, all "copied" notes etc. have a @corresp pointing to > their original counterpart, which makes certain analytical approaches very > simple. > > > 3. ref.tstamp2 feels redundant. Is it mainly for convenience reasons? > > (I could see why, especially when the target context has a different > > meter...) > > In most cases, it is redundant (and could be defaulted to the value of > @tstamp2 in the documentation). However, if you try to encode a > with the means of (which we did quite often), your > origin sits in a different slot than the target. The complex meters you brought > up in your other mail also require to have a separate attribute for this, I > believe. > > Thanks, > jo > > > > > Best > > Zoltan > > > > > > 2015-09-03 21:49 GMT+01:00 Johannes Kepper : > > Hi all, > > > > sorry for coming to this discussion very late. Fwiw, I'd like to mention an > element we came up with during the Freischütz project, which still lacks > sufficient documentation to be implemented into general MEI – even though > I strongly believe it's very useful for other projects as well. In essence, it's a > more general approach to repeat symbols and other notational "shortcuts". > We call it a "cpMark", where the "cp" may be read as "copy" and / or "colla > parte". This element is a controlEvent (= it lives inside a measure, just like a > slur or dir). In a 4/4 measure, a beatRpt on the second beat of the first staff > could look like this: > > > > > ref.offset2="0m+1">/ > > > > The attribute pair @tstamp and @tstamp2 is used to delimit the "beats" > that this element will say something about – just as in any other control > event. "beats" in this context is clearly the numbers of the @meter.count. > Then, the attribute pair @ref.offset and @ref.offset2 is used to say from > where context is to be copied into this "empty" or "abbreviated" slot. > @ref.offset uses the same data type as @tstamp2, with the only difference > that the first number (the one before the "m+" part) may take negative > values, that is, refer to preceding measures), and @ref.offset2 uses the exact > same data type as @tstamp2 (it's value is relative to the origin defined by > @ref.offset). These elements may be combined or replaced by @ref.staff > (and @ref.layer), which allow to do a colla parte encoding ("…for the range > defined by @tstamp and @tstamp2, just copy in the stuff in @ref.staff, > potentially affected by @dis for an 'in ottava'…"). The cpMark may contain > textual content (plus some editorial stuff) to grab what the source says – a > simple slash, a verbal instruction, whatever. > > > > This is just a very brief introduction to this element, but I hope you get the > idea. Like I said, I'm not sure if it really helps in this discussion of , > but I think it allows to be very explicit about the scope of a beat repetition > symbol. In my understanding, , , and all the other <*Rpt> > elements are syntactic sugar for this element, which is really a > more semantic solution for a specific type of . Would it be an option to > use instead of – just to be more explicit? I think this is > more or less in line with Perry's second suggestion, or at least I believe we > should coordinate the search for an additional attribute with our > proposal. > > > > Hth, > > jo > > > > > > > > > > > > Am 03.09.2015 um 21:15 schrieb Roland, Perry D. (pdr4h) > : > > > > > > > > Hi, > > > > > > Thanks for contributing to the discussion, Zoltán. As usual, I too am in > favor of multiple encoding methods, especially in the early phases of trying > to figure out the best approach – we can deprecate all but one at the point > where the “right” solution is obvious. > > > > > > That being said, and despite what I said earlier about the co-occurrence > of @copyof and @plist, I think the two approaches here are: > > > > > > 1. add @plist to to allow explicit referencing of the > > > events to be repeated 2. add another attribute, yet to be named, to > > > permit encoding of the amount of time to be repeated > > > > > > The first option is super easy – just make a member of att.plist. > The differentiation of @plist and @copyof must remain clear, however. > @plist identifies the events to be repeated while @copyof identifies the > element *which the beatRpt element is a copy of*. The likelihood of any > element being a copy of another one is rare, so the use of @copyof should > also occur very infrequently. > > > > > > The second option is somewhat more complex, but still practical. I just > don’t think we can overload @dur or @dur.ges for this purpose. I suggest > that syntax similar to that of @dur.ges be used but another name selected, > perhaps “beat” or “beatDef”, as its purpose is to define what constitutes a > beat in a particular context. Here, we *are* talking about metrical/musical > beats, not MEI beat units. So, in a measure of 6/8, @beatDef should take > the value “4.r” (using Humdrum notation). This defines a repeated beat as a > dotted quarter note. Suggestions for a better name for this attribute are > greatly appreciated. > > > > > > Adding these new attributes may help with automated resolution of a > beatRpt sign, but their presence can’t be required, meaning that can’t rely on > them entirely in the determination of how much time or which events should > be repeated. There always has to be a fallback approach that makes a > reasonable guess based on the context. > > > > > > I’ve had a cursory look at where/how the term “beat” is used in > descriptions and documentation and I think that simply replacing “beat” with > “beat unit” won’t work well. It probably would be better to look for places to > insert new text about how MEI treats compound meters literally, for example > in section 4.1.5 “Timestamps and Durations”. > > > > > > Sound good? > > > > > > -- > > > p. > > > > > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > > > Of Komíves Zoltán > > > Sent: Tuesday, September 01, 2015 5:55 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > Hi All, > > > > > > As far as I understand there have been two suggestions to solve the > problem of determining the material that is repeated by : > > > 1. use @dur attribute on beatRpt to indicate how much of the preceding > material is repeated. > > > 2. provide explicitly what material is repeated. > > > > > > I think both solutions make sense. The first one is concise, and has > > > no complicated implications, while the second one provides more > > > flexibility - I sense there could be situations when the (1) would > > > not suffice, perhaps some multi-voice situation when only the > > > material in one voice is repeated, but don't want to think about > > > this too hard now... :) > > > > > > Could we perhaps allow both solutions, so encoders could chose > whichever fits best their use case? > > > > > > Regarding the discussion of beat in compound meters, I also think it's > perhaps best to stay away from defining the beat as such, but I also support > to clarify terminology: using "beat unit" rigorously could be a good enough > solution. > > > > > > Best > > > Zoltan > > > > > > > > > 2015-08-27 22:57 GMT+01:00 Roland, Perry D. (pdr4h) > : > > > > > > Here are some possibilities for moving forward -- > > > > > > Using @copyof on beatRpt makes it possible to indicate which events > > > are to be repeated; for example -- > > > > > > > > > > > > > > > > > > > > > > > > > > > or perhaps > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In previous discussions about using the copyof attribute, it has been > determined that the copy is a modified "deep" one; that is, that the result > tree has the same structure as the designated node with certain attribute > values removed or modified, like xml:id, for example. > > > > > > There's a slight problem with using @copyof, however, in that it doesn't > allow multiple URIs. We could allow multiple values, but I'm not sure what it > means to say that something is a copy of more than one thing. That means > it's a synthesis, doesn't it? :-) So, I'm a little reluctant to add @copyof and I > lean more toward adding @plist instead. Of course, this also gets us into a > little trouble as both @copyof and @plist would be allowed. As a work- > around, a new @targets (notice the plural) could be added to beatRpt. > > > > > > Another option is to allow beatRpt to contain content -- either new > > > events that duplicate those that the repetition sign refers to or > > > elements that reference the events; for example, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each one of these options allows an easy "toggling" between the > repetition sign and the material inside. The 2nd method may be more > flexible because of the use of references. The down-side for both of these > possibilities is that they are more verbose than using an attribute. > > > > > > Yet another approach is to create a generic copy element, say, > that represents a copy of any event. That may be too general, however. For > example, the function of the copyOf (beatRpt, mRpt, etc.) would have to be > placed in an attribute. This could lead to mis-use and it would be more > difficult to control where certain functions could occur. But, Johannes has > put this forward in the past, so he's better qualified to address this approach > than I. > > > > > > -- > > > p. > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > > > Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] > > > Sent: Thursday, August 27, 2015 11:48 AM > > > > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > > > > Ok, this gives us a place to start. It seems to me, however, that rather > than talking about how much time it repeats (as this reignites the confusion > around "beat" and "beat unit"), it may be better to investigate ways to > explicitly indicate which *events* are to repeated. > > > > > > -- > > > p. > > > > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > > > Laurent Pugin [lxpugin at gmail.com] > > > Sent: Thursday, August 27, 2015 11:18 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > The problem is that when I encounter a in an encoding I would > like to know how much time it repeats. I understand that it represent the > repetition of the material that occur on a previous musical beat, as you say. > However, since the duration of what the musical beat is not encoded > explicitly (as far as I understand) it does not seem to be possible to know it > (i.e., how much time it repeats.). > > > > > > Laurent > > > > > > > > > On Thu, Aug 27, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) > wrote: > > > > > > > > > Did you mean to say it is "unfortunate" that MEI doesn't use "beat" as an > attribute? > > > > > > And how does one allow an attribute directly "in" or ? > > > > > > We should stay away from determination of meter in MEI. As we've > already heard, it often introduces a lot of subjectivity and interpretation. > That kind of thing is best left to a different, analytical layer. > > > > > > I still don't see the point -- what does this have to do with beatRpt? > > > > > > -- > > > p. > > > > > > > > > __________________________ > > > Perry Roland > > > Music Library > > > University of Virginia > > > P. O. Box 400175 > > > Charlottesville, VA 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of > > > Laurent Pugin [lxpugin at gmail.com] > > > Sent: Thursday, August 27, 2015 10:45 AM > > > To: Music Encoding Initiative > > > Subject: Re: [MEI-L] Beat in 6/8 > > > > > > What seems fortunate to me is that "beat" is not used as attribute > > > in MEI (yet?) > > > > > > Maybe we could use it when we need to specify a musical beat that is not > the meter.unit. As I suggested with , it would be assumed to be 1 > in most cases, but could be "3" in 6/8 (or similar) when the desired musical > beat is 4. . In 5/8, we could imagine having an attribute value such as "2+3" if > the beat is expected to be 4 - 4. . Along the same lines, it could be useful to > allow the attribute directly in (or even ?) when the beat > structure is changing. > > > > > > Laurent > > > > > > On Thu, Aug 27, 2015 at 4:06 PM, Benjamin Wolff Bohl > wrote: > > > Dear Craig, > > > many thanks for your always helpful advice! > > > > > > Am 27.08.2015 um 11:08 schrieb Craig Sapp: > > > > > > The problem is the ambiguous/conflicting terminology in this sentence: > > > > > > On 27 August 2015 at 01:19, Benjamin Wolff Bohl > wrote: > > > meter.unit contains the number indicating the beat unit, that is, the > bottom number of the meter signature. > > > > > > This is only ambiguous/conflicting if you are to smart and know too much > about music! Regarding the term "beat" in the closed system of MEI > everything is obvious an unambiguous. > > > > > > > > > > > > The problem is that in compound meters such as 6/8 > > > https://en.wikipedia.org/wiki/Meter_(music)#Compound_meter > > > The "musical beat" is a dotted quarter note, while the MEI "beat unit" is > an eighth note. Using the word "beat" in such a way is unfortunate as it can > conflict with the musical definition of a beat, and this will continue to cause > mis-interpretation of what a beat is. > > > > > > This then would promote using another term in MEI in order to avoid > confusion, let's say "meter-unit-n". > > > > > > > > > > > > The duration of a beat is necessary for music analysis, since the > treatment of dissonance and consonance is tied to the location of a note on > or off of the beat. > > > > > > This could be a beating argument, if it is the purpose and intention of MEI > to do musical analysis. > > > Is it? I'd rather say it provides a basis for doing analysis, the logic of the > analysis is not part of MEI, although the result of the analysis might be > encoded in MEI. > > > > > > > > > The musical beat is also needed to automatically beam notes. Implicit > interpretation of the musical beat can be done with 6/8 by assigning it to be a > dotted quarter note, but there are exceptions to this definition which would > require a way of assigning an explicit duration to the musical beat. > > > > > > "Automatically" beaming notes is not part of the encoding but of the > rendering logic an thus will not be reflected in (pure-logical-domain-)MEI. > > > > > > > > > > > > For example, the middle slow movements in a piano sonata may be > labeled as 6/8, with the beat actually assigned to the eighth note, in which > case the "musical beat" and the MEI "beat unit" are the same. > > > > > > Another more common corner case would be time signatures such as > 3/8. Is that a compound meter with one beat in a measure, or a simple > meter with three beats in the measure (a variant on a 3/4 meter also > possible in slow movements)? > > > > > > And of course in modern music with irregular meters such as 5/8, the > musical beats in the measure may may have two beats as 3+2 eighth notes, > or 2+3 or a mixture of both in different measures. > > > > > > The two above are only a problem if we consider "beat" as being the > "musical beat". If we consider it to be "meter-unit-n" instead, everything > would work out fine. > > > > > > > > > > > > Compound meters resulted in a degeneration of mensural notation. > Since modern rhythms are always "imperfect", to emulate a perfect > mensuration dots are added to the notes (which would usually be implicit > the mensural metric equivalent). These are represented as compound > meters in modern notation (who knows why they did not invent "2/4." time > signatures instead of "6/8" for such cases). The problem is that modern time > signatures are ambiguous, since 6/8 could be considered like C-dot, or it > could be considered as a non-compound meter with 6 beat at the eighth- > note level. > > > > > > Ok, air is getting thin for me... > > > I've had a problem with modern transcription of mensural notation ever > since I first encountered it, or more precisely I was whinig about modern > notation being so restrictive due to having abandoned mensuration signs. I > would prefer modern transcription sticking to mensuration signs and logic > instead of adding dots, but I might not be able to change the world about > this... > > > > > > But to bang the drum for "meter-unit-n": Couldn't this problem also be > solved by or some additional attribute on or > ? > > > > > > Considering the case of a modern transcription of "perfect" mensural > > > notation using in terms of "meter-unit-n" would result in > > > completely different applicable cases compared to using it in the > > > sense of "musical beat". An there it is the again, > > > ** ambiguous and conflicting** > > > > > > Just for the sake ofplaying advocatus diavoli 3;-) Benni > > > > > > > > > > > > I whine to Perry every once in a while about this, so we can wait for his > reply on how to disambiguate such cases... > > > > > > -=+Craig > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > 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 Sep 15 23:00:06 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 15 Sep 2015 21:00:06 +0000 Subject: [MEI-L] revision of content model of Message-ID: Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 atge at kb.dk Wed Sep 16 15:02:22 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 16 Sep 2015 13:02:22 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: References: Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 pdr4h at eservices.virginia.edu Wed Sep 16 21:56:46 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 16 Sep 2015 19:56:46 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 pdr4h at eservices.virginia.edu Thu Sep 17 20:11:15 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 17 Sep 2015 18:11:15 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> Message-ID: Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 atge at kb.dk Fri Sep 18 11:18:28 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 18 Sep 2015 09:18:28 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> Hi Perry First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility? I can think of a very simple situation where the current model seems more appropriate: piano This would have to be changed into piano or piano It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as violin piano rather than violin piano The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other... If wrapping all and into a single - one of your suggestions to my cantata example - is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . Your other suggestion - grouping the soloists in a - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). Sorry if I don't get your point! /axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 17. september 2015 20:11 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 pdr4h at eservices.virginia.edu Fri Sep 18 16:14:42 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 18 Sep 2015 14:14:42 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> Message-ID: Axel, Adding the extra layer of markup - piano isn't particularly onerous since it's relatively easy to automate. I'm also not particularly troubled by a list containing a single item. To me, it's still a list. doesn't necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones - But, you're right, we could do without . Here's where we can eliminate a level of nesting. That's a good thing, right? "Instrumentation" isn't a particular good name for the enumeration of performance resources anyway. My example 4 was just a demonstration of a markup possibility. The next example, no. 5, does not attempt to group the soloists. Even so, soloists are still part of the larger group - orchestra + chorus + soloists - that is expected to perform the work, are they not? I guess that if you're not excited about those changes, then you really won't like the following suggestion - I'd like to eliminate and fold its functionality into , *BUT* rename to (performance resource). At the same time, should be renamed . This will eliminate the cognitive dissonance created between "Grp" and "ensemble" and "instrVoice". In this new paradigm, an instrumentalist, a singer, and an ensemble are all "performance resources" and a bunch of these resources can be gathered into a "performance resource list". In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC). As a compromise, I'm happy to leave most of the model of in place, but remove and also remove PCDATA from . I could even see retaining a single to accommodate your minimal nesting objection - piano The upshot of this is that ensemble names will have to be placed in , as in - dance band If you're with me so far, then changing "instrVoice" to "perfRes" and "instrVoiceGrp" to "perfResList" resolves the mental confusion of calling a dance band a "voice", doesn't it? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, September 18, 2015 5:19 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility? I can think of a very simple situation where the current model seems more appropriate: piano This would have to be changed into piano or piano It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as violin piano rather than violin piano The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other... If wrapping all and into a single - one of your suggestions to my cantata example - is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . Your other suggestion - grouping the soloists in a - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). Sorry if I don't get your point! /axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 17. september 2015 20:11 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 kepper at edirom.de Sat Sep 19 13:46:16 2015 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 19 Sep 2015 13:46:16 +0200 Subject: [MEI-L] W3C on music encoding Message-ID: Hi all, the W3C Music Notation Community Group (https://www.w3.org/community/music-notation/), which has been convened by both MusicXML and SMuFL, is starting to work on the successor of MusicXML 3.0. Interestingly enough, the first response to their initial post on the mailing list was suggesting to base on MEI instead of MusicXML (see the archives at http://lists.w3.org/Archives/Public/public-music-notation-contrib/). In case you're interested in the relation of MusicXML and MEI, or music encoding in general, I highly recommend to subscribe to this group and join the discussion there. I'll try to post summaries of the MEI-related discussions there to MEI-L every now and then. Best, Johannes From atge at kb.dk Mon Sep 21 11:40:42 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Mon, 21 Sep 2015 09:40:42 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> Hi Perry Yes, there is a difference between a list and a group. I have no objections to putting soloists or a single player on a list, of course. I just don't want to call them a group; so your suggestion naming the elements and instead is fine with me. If we decide to rename and , however, I suggest dropping . Of course, 'instrumentation' is a name easier to understand than 'perfResList'; I am not sure whether that is a problem. But it seems misleading to me having inside , as the former is a more generic term than the latter. Why not make it and allowing and any number of and elements inside ? - if we do want to change the schema, that is. I'd really like to hear some more opinions on this. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 18. september 2015 16:15 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Axel, Adding the extra layer of markup - piano isn't particularly onerous since it's relatively easy to automate. I'm also not particularly troubled by a list containing a single item. To me, it's still a list. doesn't necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones - But, you're right, we could do without . Here's where we can eliminate a level of nesting. That's a good thing, right? "Instrumentation" isn't a particular good name for the enumeration of performance resources anyway. My example 4 was just a demonstration of a markup possibility. The next example, no. 5, does not attempt to group the soloists. Even so, soloists are still part of the larger group - orchestra + chorus + soloists - that is expected to perform the work, are they not? I guess that if you're not excited about those changes, then you really won't like the following suggestion - I'd like to eliminate and fold its functionality into , *BUT* rename to (performance resource). At the same time, should be renamed . This will eliminate the cognitive dissonance created between "Grp" and "ensemble" and "instrVoice". In this new paradigm, an instrumentalist, a singer, and an ensemble are all "performance resources" and a bunch of these resources can be gathered into a "performance resource list". In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC). As a compromise, I'm happy to leave most of the model of in place, but remove and also remove PCDATA from . I could even see retaining a single to accommodate your minimal nesting objection - piano The upshot of this is that ensemble names will have to be placed in , as in - dance band If you're with me so far, then changing "instrVoice" to "perfRes" and "instrVoiceGrp" to "perfResList" resolves the mental confusion of calling a dance band a "voice", doesn't it? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, September 18, 2015 5:19 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility? I can think of a very simple situation where the current model seems more appropriate: piano This would have to be changed into piano or piano It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as violin piano rather than violin piano The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other... If wrapping all and into a single - one of your suggestions to my cantata example - is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . Your other suggestion - grouping the soloists in a - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). Sorry if I don't get your point! /axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 17. september 2015 20:11 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 pdr4h at eservices.virginia.edu Mon Sep 21 15:28:37 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 21 Sep 2015 13:28:37 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> Message-ID: Hi Axel, I think that simplifying the model of is highly desirable. Your suggested change is fine with me. Better than fine, I embrace it wholeheartedly. I'd like to hear from others too. But if we don't, then I'm fine with taking silence as tacit agreement. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Monday, September 21, 2015 5:41 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry Yes, there is a difference between a list and a group. I have no objections to putting soloists or a single player on a list, of course. I just don't want to call them a group; so your suggestion naming the elements and instead is fine with me. If we decide to rename and , however, I suggest dropping . Of course, 'instrumentation' is a name easier to understand than 'perfResList'; I am not sure whether that is a problem. But it seems misleading to me having inside , as the former is a more generic term than the latter. Why not make it and allowing and any number of and elements inside ? - if we do want to change the schema, that is. I'd really like to hear some more opinions on this. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 18. september 2015 16:15 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Axel, Adding the extra layer of markup - piano isn't particularly onerous since it's relatively easy to automate. I'm also not particularly troubled by a list containing a single item. To me, it's still a list. doesn't necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones - But, you're right, we could do without . Here's where we can eliminate a level of nesting. That's a good thing, right? "Instrumentation" isn't a particular good name for the enumeration of performance resources anyway. My example 4 was just a demonstration of a markup possibility. The next example, no. 5, does not attempt to group the soloists. Even so, soloists are still part of the larger group - orchestra + chorus + soloists - that is expected to perform the work, are they not? I guess that if you're not excited about those changes, then you really won't like the following suggestion - I'd like to eliminate and fold its functionality into , *BUT* rename to (performance resource). At the same time, should be renamed . This will eliminate the cognitive dissonance created between "Grp" and "ensemble" and "instrVoice". In this new paradigm, an instrumentalist, a singer, and an ensemble are all "performance resources" and a bunch of these resources can be gathered into a "performance resource list". In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC). As a compromise, I'm happy to leave most of the model of in place, but remove and also remove PCDATA from . I could even see retaining a single to accommodate your minimal nesting objection - piano The upshot of this is that ensemble names will have to be placed in , as in - dance band If you're with me so far, then changing "instrVoice" to "perfRes" and "instrVoiceGrp" to "perfResList" resolves the mental confusion of calling a dance band a "voice", doesn't it? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, September 18, 2015 5:19 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility? I can think of a very simple situation where the current model seems more appropriate: piano This would have to be changed into piano or piano It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as violin piano rather than violin piano The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other... If wrapping all and into a single - one of your suggestions to my cantata example - is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . Your other suggestion - grouping the soloists in a - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). Sorry if I don't get your point! /axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 17. september 2015 20:11 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 raffaeleviglianti at gmail.com Mon Sep 21 16:19:10 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 21 Sep 2015 10:19:10 -0400 Subject: [MEI-L] Updating Technical Team page on website Message-ID: Hi all, The technical team page at http://music-encoding.org/community/mei-organization/technical-team/ is out of date a this poin; e.g. we don't have mei-incubator anymore and the team is supposed to be more fluid in terms of membership. Can we adjust it to reflect the current setup better? It might also be a good place to refer to the GitHub repository. Best, Raff -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdr4h at eservices.virginia.edu Mon Sep 21 17:41:02 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 21 Sep 2015 15:41:02 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> Message-ID: Another opportunity to clean up or clarify the markup surrounding performing forces - Can we drop the att.coded class and use att.canonical? In fact, I don't see a difference between these two classes and I'd like to eliminate att.coded. The problem with doing so, however, as it was with the instrVoice* elements, may be a matter of naming rather than function. Is dbkey (borrowed from TEI) a reasonable name for an attribute that essentially holds a coded value? "dbkey" indicates a very specific kind of coded value, so the name is probably too narrow. Would "code" or "codedvalue" be better, but now in the att.canonical class? Would either of those names still fit the database key use, especially if the documentation was changed to read - " a coded value that identifies the element content or serves as a primary key in an external database"? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Monday, September 21, 2015 9:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think that simplifying the model of is highly desirable. Your suggested change is fine with me. Better than fine, I embrace it wholeheartedly. I'd like to hear from others too. But if we don't, then I'm fine with taking silence as tacit agreement. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Monday, September 21, 2015 5:41 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry Yes, there is a difference between a list and a group. I have no objections to putting soloists or a single player on a list, of course. I just don't want to call them a group; so your suggestion naming the elements and instead is fine with me. If we decide to rename and , however, I suggest dropping . Of course, 'instrumentation' is a name easier to understand than 'perfResList'; I am not sure whether that is a problem. But it seems misleading to me having inside , as the former is a more generic term than the latter. Why not make it and allowing and any number of and elements inside ? - if we do want to change the schema, that is. I'd really like to hear some more opinions on this. Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 18. september 2015 16:15 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Axel, Adding the extra layer of markup - piano isn't particularly onerous since it's relatively easy to automate. I'm also not particularly troubled by a list containing a single item. To me, it's still a list. doesn't necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones - But, you're right, we could do without . Here's where we can eliminate a level of nesting. That's a good thing, right? "Instrumentation" isn't a particular good name for the enumeration of performance resources anyway. My example 4 was just a demonstration of a markup possibility. The next example, no. 5, does not attempt to group the soloists. Even so, soloists are still part of the larger group - orchestra + chorus + soloists - that is expected to perform the work, are they not? I guess that if you're not excited about those changes, then you really won't like the following suggestion - I'd like to eliminate and fold its functionality into , *BUT* rename to (performance resource). At the same time, should be renamed . This will eliminate the cognitive dissonance created between "Grp" and "ensemble" and "instrVoice". In this new paradigm, an instrumentalist, a singer, and an ensemble are all "performance resources" and a bunch of these resources can be gathered into a "performance resource list". In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC). As a compromise, I'm happy to leave most of the model of in place, but remove and also remove PCDATA from . I could even see retaining a single to accommodate your minimal nesting objection - piano The upshot of this is that ensemble names will have to be placed in , as in - dance band If you're with me so far, then changing "instrVoice" to "perfRes" and "instrVoiceGrp" to "perfResList" resolves the mental confusion of calling a dance band a "voice", doesn't it? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Friday, September 18, 2015 5:19 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry First of all, I am afraid I still can't see the importance of changing the model; is it important enough to break backwards compatibility? I can think of a very simple situation where the current model seems more appropriate: piano This would have to be changed into piano or piano It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as violin piano rather than violin piano The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn't make any sense trying to define the exact line between the one and the other... If wrapping all and into a single - one of your suggestions to my cantata example - is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . Your other suggestion - grouping the soloists in a - conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). Sorry if I don't get your point! /axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 17. september 2015 20:11 Til: Music Encoding Initiative Emne: Re: [MEI-L] revision of content model of Sue me, I lied - this is still bugging me. :) I still want to constrain the content of , but I think I've finally found a better solution. Changing the model to ELEMENT instrumentation (ensemble|instrVoiceGrp)* will validate all the following examples - Ex 1. Empty Ex 2. Single named ensemble Orchestra Ex 3. Any number of enumerated performing groups air guitar nose flute Ex 4. (Axel's example with the soloists wrapped using ) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex 5. (Axel's example with the entire content wrapped using , nested enumerated groups) fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Ex. 6 Named ensemble + enumerated (nested) groups Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Ex. 7 Multiple named ensembles Band Orchestra Steel Band If anyone can demonstrate problems with this model, please let me know. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) Sent: Wednesday, September 16, 2015 3:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Axel, I think you've got it. Another layer of nesting using an outer isn't necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it's not required, I'm just being foolishly consistent. :) Looking more carefully, I now think the current model for can't really be improved, since all my so-called "improvements" result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) - Orchestra Weird collection o' players air guitar nose flute tambourine autoharp Sorry for the unnecessary thrashing, -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger Sent: Wednesday, September 16, 2015 9:03 AM To: Music Encoding Initiative Subject: Re: [MEI-L] revision of content model of Hi Perry I use several elements within very often. I haven't been using , though. But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: fl. ob. cl. fg. cor. cnt. trb. tb. timp. cmplli. Choir S. A. T. B. S. T. Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? Best, Axel Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 15. september 2015 23:00 Til: mei-l at lists.uni-paderborn.de Emne: [MEI-L] revision of content model of Hello everyone, This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. :) The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements - My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I'm inclined to allow only one sub-element to be used at a time - Using this approach, one can use to encode the name of a performing group, like "orchestra" or use to enumerate the parts/players of the group, but not both. However, this change re-focuses attention on the relationship between and - possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further - eliminating entirely. The problem with this solution is that some confusion may be created as "instrVoice" doesn't immediately spring to mind as a way to name an ensemble. Conversely, the "Grp" part of the name "instrVoiceGrp" may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. So, I'm looking for advice on how to resolve this quandary - a model that's too lax vs. a model that's more tightly controlled but with elements that are not completely descriptive of the material we're trying to encode. At this point, I'm leaning toward the most restrictive model. Is everyone OK with using Band to name an ensemble without enumerating its constituents and using Band Flutes Clarinets etc. to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? Thanks for your input, -- 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 lxpugin at gmail.com Mon Sep 21 20:17:11 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Mon, 21 Sep 2015 20:17:11 +0200 Subject: [MEI-L] New GitHub repository Message-ID: Dear all, This is an official announcement of the new GitHub account and repository for MEI. The new MEI repository is accessible at https://github.com/music-encoding/music-encoding. All the information from the previous GoogleCode repository has been migrated to the GitHub one, including issues, branches, tags, etc. This announcement means that GoogleCode repository is no longer in use and will not be maintained. We recommend not to refer to it, including for schema validation. All the schemata are now permanently available directly from music-encoding.org under 'schema' plus the version number. For example, the latest release is available at http://www.music-encoding.org/schema/2.1.1/mei-all.rng The move to GitHub has also been an opportunity for us to re-think workflows and contribution guidelines for MEI. Of course, since MEI is a schema and not a software product, we expect all contributions to be thoughtfully discussed by the community before they find their way to the MEI source. Contributors should not expect any pull request to be included in MEI straight away without the required discussion, even if the contribution does not create any conflict and seems straight forward to integrate. In order to clarify this, Andrew Hankinson has written some contributions guidelines that we strongly recommend reading if you are interested in contributing to the MEI schema. The GitHub account of MEI includes other repositories than the MEI source one. MEI also hosts repositories for the customization service and the SibMEI plugin, for example. You can see all of them listed directly on the MEI GitHub account: https://github.com/music-encoding. At some point, we will evaluate whether parts of the current MEI repository should become distinct repositories themselves. As specified by the MEI by-laws, the GitHub account of MEI is managed by the co-chairs of the technical teams. At their discretion, the co-chairs may provide write access to the repositories to other members of the technical team. Thank you to all who contributed to the migration to GitHub. We are looking forward to your feed-back and to your contributions. For the technical team Perry and Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From lxpugin at gmail.com Mon Sep 21 20:22:20 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Mon, 21 Sep 2015 20:22:20 +0200 Subject: [MEI-L] New GitHub repository In-Reply-To: References: Message-ID: PS Sorry, I forgot to include the link to the contribution guidelines. Here it is: https://github.com/music-encoding/music-encoding/blob/develop/CONTRIBUTING.md On Mon, Sep 21, 2015 at 8:17 PM, Laurent Pugin wrote: > Dear all, > > This is an official announcement of the new GitHub account and repository > for MEI. The new MEI repository is accessible at > https://github.com/music-encoding/music-encoding. All the information > from the previous GoogleCode repository has been migrated to the GitHub > one, including issues, branches, tags, etc. > > This announcement means that GoogleCode repository is no longer in use and > will not be maintained. We recommend not to refer to it, including for > schema validation. All the schemata are now permanently available directly > from music-encoding.org under 'schema' plus the version number. For > example, the latest release is available at > http://www.music-encoding.org/schema/2.1.1/mei-all.rng > > The move to GitHub has also been an opportunity for us to re-think > workflows and contribution guidelines for MEI. Of course, since MEI is a > schema and not a software product, we expect all contributions to be > thoughtfully discussed by the community before they find their way to the > MEI source. Contributors should not expect any pull request to be included > in MEI straight away without the required discussion, even if the > contribution does not create any conflict and seems straight forward to > integrate. In order to clarify this, Andrew Hankinson has written some > contributions guidelines that we strongly recommend reading if you are > interested in contributing to the MEI schema. > > The GitHub account of MEI includes other repositories than the MEI source > one. MEI also hosts repositories for the customization service and the > SibMEI plugin, for example. You can see all of them listed directly on the > MEI GitHub account: https://github.com/music-encoding. At some point, we > will evaluate whether parts of the current MEI repository should become > distinct repositories themselves. As specified by the MEI by-laws, the > GitHub account of MEI is managed by the co-chairs of the technical teams. > At their discretion, the co-chairs may provide write access to the > repositories to other members of the technical team. > > Thank you to all who contributed to the migration to GitHub. We are > looking forward to your feed-back and to your contributions. > > For the technical team > Perry and Laurent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stadler at edirom.de Tue Sep 22 10:24:23 2015 From: stadler at edirom.de (Peter Stadler) Date: Tue, 22 Sep 2015 10:24:23 +0200 Subject: [MEI-L] revision of content model of In-Reply-To: References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> Message-ID: <536A0A9C-AED5-4467-BA85-52D25EC658A5@edirom.de> To me, @code, @dbkey, @n, @label et. al are all the same since they are some identifier, making sense only to (some) humans, because their way of identifying (and how to resolve the reference) is nowhere made explicit. The TEI is currently deprecating its @key attribute in favor of the more formally defined @ref, noting: "No particular syntax is proposed for the values of the key attribute, since its form will depend entirely on practice within a given project. For the same reason, this attribute is not recommended in data interchange, since there is no way of ensuring that the values used by one project are distinct from those used by another. In such a situation, a preferable approach for magic tokens which follows standard practice on the Web is to use a ref attribute whose value is a tag URI as defined in RFC 4151.“ [1] In fact, every local identifier ("magic token“) can easily be converted to a 'real‘ URI through the usage of private URI schemes [2]. Just thought I’d mention this … Best Peter [1] http://www.tei-c.org/Vault/P5/2.8.0/doc/tei-p5-doc/en/html/ref-att.canonical.html [2] http://wiki.tei-c.org/index.php/Private_URI_Schemes > Am 21.09.2015 um 17:41 schrieb Roland, Perry D. (pdr4h) : > > > Another opportunity to clean up or clarify the markup surrounding performing forces – > > Can we drop the att.coded class and use att.canonical? In fact, I don’t see a difference between these two classes and I’d like to eliminate att.coded. > > The problem with doing so, however, as it was with the instrVoice* elements, may be a matter of naming rather than function. Is dbkey (borrowed from TEI) a reasonable name for an attribute that essentially holds a coded value? “dbkey” indicates a very specific kind of coded value, so the name is probably too narrow. Would “code” or “codedvalue” be better, but now in the att.canonical class? Would either of those names still fit the database key use, especially if the documentation was changed to read – > > “ a coded value that identifies the element content or serves as a primary key in an external database”? > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) > Sent: Monday, September 21, 2015 9:29 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > > Hi Axel, > > I think that simplifying the model of is highly desirable. Your suggested change is fine with me. Better than fine, I embrace it wholeheartedly. > > I’d like to hear from others too. But if we don’t, then I’m fine with taking silence as tacit agreement. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Monday, September 21, 2015 5:41 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > Hi Perry > > Yes, there is a difference between a list and a group. I have no objections to putting soloists or a single player on a list, of course. I just don’t want to call them a group; so your suggestion naming the elements and instead is fine with me. > If we decide to rename and , however, I suggest dropping . Of course, ‘instrumentation’ is a name easier to understand than ‘perfResList’; I am not sure whether that is a problem. But it seems misleading to me having inside , as the former is a more generic term than the latter. Why not make it > > > > > > > and allowing and any number of and elements inside ? > > – if we do want to change the schema, that is. I’d really like to hear some more opinions on this. > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) > Sendt: 18. september 2015 16:15 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] revision of content model of > > > Axel, > > Adding the extra layer of markup – > > > > piano > > > > isn’t particularly onerous since it’s relatively easy to automate. I’m also not particularly troubled by a list containing a single item. To me, it’s still a list. > > doesn’t necessarily become obsolete as it can still be used to separate information about non-dramatic performing forces from dramatic ones – > > > > > > > But, you’re right, we could do without . Here’s where we can eliminate a level of nesting. That’s a good thing, right? “Instrumentation” isn’t a particular good name for the enumeration of performance resources anyway. > > My example 4 was just a demonstration of a markup possibility. The next example, no. 5, does not attempt to group the soloists. Even so, soloists are still part of the larger group – orchestra + chorus + soloists – that is expected to perform the work, are they not? > > I guess that if you’re not excited about those changes, then you really won’t like the following suggestion – > > I’d like to eliminate and fold its functionality into , *BUT* rename to (performance resource). At the same time, should be renamed . This will eliminate the cognitive dissonance created between “Grp” and “ensemble” and “instrVoice”. In this new paradigm, an instrumentalist, a singer, and an ensemble are all “performance resources” and a bunch of these resources can be gathered into a “performance resource list”. In addition to increased clarity, this change also better fits existing models of performing forces description (e.g., MARC). > > As a compromise, I’m happy to leave most of the model of in place, but remove and also remove PCDATA from . I could even see retaining a single to accommodate your minimal nesting objection – > > > This would continue to validate > > > piano > > > The upshot of this is that ensemble names will have to be placed in , as in – > > > dance band > > > If you’re with me so far, then changing “instrVoice” to “perfRes” and “instrVoiceGrp” to “perfResList” resolves the mental confusion of calling a dance band a “voice”, doesn’t it? > > -- > p. > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Friday, September 18, 2015 5:19 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > Hi Perry > > First of all, I am afraid I still can’t see the importance of changing the model; is it important enough to break backwards compatibility? > > I can think of a very simple situation where the current model seems more appropriate: > > > piano > > > This would have to be changed into > > > > > piano > > > > or > > > piano > > > It bothers me that I would always have to define a group, even if there is just a single instrument. Or very few instruments: I actually like being able to make a distinction between a few single instruments playing together and a group of instruments (an ensemble). For instance, I regard an orchestra as a group in a very different way than, say, a piano and violin playing a sonata. I am happy that the current model allows me to describe the sonata players as > > > violin > piano > > > rather than > > > > violin > piano > > > > The difference may be a subtle one, I admit. But it fits may way of thinking of a group or an ensemble as something different from two musicians playing together, even if it wouldn’t make any sense trying to define the exact line between the one and the other... > > If wrapping all and into a single – one of your suggestions to my cantata example – is to be the recommendation, their parent would become obsolete as it would always contain just one (or zero) . > Your other suggestion – grouping the soloists in a – conflicts with my understanding of them being marked explicitly as soloists (as in: NOT part of a group or an ensemble). > > Sorry if I don’t get your point! > > /axel > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) > Sendt: 17. september 2015 20:11 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] revision of content model of > > > Sue me, I lied – this is still bugging me. J > > I still want to constrain the content of , but I think I’ve finally found a better solution. Changing the model to > > ELEMENT instrumentation (ensemble|instrVoiceGrp)* > > will validate all the following examples – > > Ex 1. Empty > > > Ex 2. Single named ensemble > > Orchestra > > > Ex 3. Any number of enumerated performing groups > > > air guitar > nose flute > > > > Ex 4. (Axel’s example with the soloists wrapped using ) > > > fl. > ob. > cl. > fg. > cor. > cnt. > trb. > tb. > timp. > cmplli. > > > Choir > S. > A. > T. > B. > > > S. > T. > > > > Ex 5. (Axel’s example with the entire content wrapped using , nested enumerated groups) > > > > fl. > ob. > cl. > fg. > cor. > cnt. > trb. > tb. > timp. > cmplli. > > > Choir > S. > A. > T. > B. > > S. > T. > > > > Ex. 6 Named ensemble + enumerated (nested) groups > > Orchestra > > Weird collection o’ players > air guitar > nose flute > > tambourine > autoharp > > > > > Ex. 7 Multiple named ensembles > > Band > Orchestra > Steel Band > > > If anyone can demonstrate problems with this model, please let me know. > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry D. (pdr4h) > Sent: Wednesday, September 16, 2015 3:57 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > Hi Axel, > > I think you’ve got it. Another layer of nesting using an outer isn’t necessary. I would recommend that you use within all the elements, not just the one for the Choir. You could also group the soloists, but it’s not required, I’m just being foolishly consistent. J > > Looking more carefully, I now think the current model for can’t really be improved, since all my so-called “improvements” result in not being able to handle works for a standard ensemble (e.g., orchestra) and an enumerated list of performers (for example, air guitar, nose flute, tambourine and autoharp, where one player uses 2 instruments) – > > > Orchestra > > Weird collection o’ players > air guitar > nose flute > > tambourine > autoharp > > > > > Sorry for the unnecessary thrashing, > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Wednesday, September 16, 2015 9:03 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > Hi Perry > > I use several elements within very often. I haven’t been using , though. > But in a cantata like this one: http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the following to define an orchestra, a choir and vocal soloists: > > > > fl. > ob. > cl. > fg. > cor. > cnt. > trb. > tb. > timp. > cmplli. > > > Choir > S. > A. > T. > B. > > S. > T. > > > Is that a misunderstanding of the concept? How would you organize this instrumentation? By another layer of nesting and elements? > > Best, > Axel > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) > Sendt: 15. september 2015 23:00 > Til: mei-l at lists.uni-paderborn.de > Emne: [MEI-L] revision of content model of > > > Hello everyone, > > This is pretty arcane stuff, so I expect that it will only be of interest to those who are deeply involved in creating detailed metadata regarding instrumentation, especially from MARC-encoded metadata. Consider yourself warned. J > > The current model of is very lax in order to allow liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements – > > > > > > > > > > > > > > > My original thinking on this was that a very loosely structured model would be helpful if were ever allowed to occur with the textual parts of MEI, say in

. However, I believe that it is unlikely that will ever occur in the presence of the other two possibilities. Therefore, unless someone can prove my hunch to be incorrect, I’m inclined to allow only one sub-element to be used at a time – > > > > > > > > > > > > > > > Using this approach, one can use to encode the name of a performing group, like “orchestra” or use to enumerate the parts/players of the group, but not both. > > However, this change re-focuses attention on the relationship between and – possibly a distinction without a difference, as the expected content of both is text and both provide the same attributes (att.authorized and att.coded) for connecting the textual content to an authorized list. With this in mind, it might be beneficial to modify the content model even further – > > > > > > > > > > > > > > eliminating entirely. The problem with this solution is that some confusion may be created as “instrVoice” doesn’t immediately spring to mind as a way to name an ensemble. Conversely, the “Grp” part of the name “instrVoiceGrp” may lead the unwary into thinking that it can be used to *label* an ensemble, when in fact it should be used to *describe* an ensemble. > > So, I’m looking for advice on how to resolve this quandary – a model that’s too lax vs. a model that’s more tightly controlled but with elements that are not completely descriptive of the material we’re trying to encode. At this point, I’m leaning toward the most restrictive model. > > Is everyone OK with using Band to name an ensemble without enumerating its constituents and using > > > Band > Flutes > Clarinets > etc. > > to provide detailed instrumentation when needed? Also, has anyone created markup that this change would break? > > Thanks for your input, > > -- > p. > > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > 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 Sep 22 16:25:38 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 22 Sep 2015 14:25:38 +0000 Subject: [MEI-L] revision of content model of In-Reply-To: <536A0A9C-AED5-4467-BA85-52D25EC658A5@edirom.de> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEA8FA7@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEB9E80@EXCHANGE-02.kb.dk> <0B6F63F59F405E4C902DFE2C2329D0D1013DED4A90@EXCHANGE-02.kb.dk> <536A0A9C-AED5-4467-BA85-52D25EC658A5@edirom.de> Message-ID: Hi Peter, Thanks for the info. I don't agree that @code, @dbkey, @n, @label etc. are all _exactly_ the same. They all have a similar, but not the same function. For instance, as defined by MEI @label is a displayable string (think of it as a "tool tip") while @n is (typically) a number that identifies its bearer within a collection of objects (as @n identifies a particular measure in the collection of measures). As I mentioned yesterday, I do think that @code and @dbkey are similar enough to warrant merging them into a single attribute. In MEI there's the att.authorized class (containing @authority and @authURI) and att.canonical (containing @dbkey). With @authURI one can provide an "authoritative Uniform Resource Identifier" for the content of the GI (similar to the proposed TEI @ref). That URI can be a complete one; that is, it can include the terminating point, or it may stop one step short, in which case the terminal (a particular database record or document fragment, for instance) is captured in the @dbkey attribute. When the URI is complete, there's no need for @dbkey. But sometimes there's a need for the labeling function of @dbkey _without_ a corresponding need for the URI. For example, one might use @dbkey to hold a canonical identifier (such as a Köchel designation for a title or a VIAF record number for a name) without providing a URI. In fact, there may be no corresponding internet resource to point to. We do, after all, sometimes have to cope with the "not-yet-completely-networked-real-world", so it's important to maintain a separation between these two attribute classes. "dbkey" is probably not the best name for the thing that holds a canonical reference. I'm hesitant to use "ref" because it's too generic. The best I've come up with so far is "codedval". A "coded value" represents or identifies the element content (as, for example, "ka" represents the piano in the MARC Instruments and Voices Code List). Of course, it's the encoder's responsibility to provide the means (or at least a description of the means) to resolve the reference -- whether there's a URI or not. The so-called "Private URI Scheme" solution seems sound, but let's allow TEI to explore this territory first. :-) -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni- > paderborn.de] On Behalf Of Peter Stadler > Sent: Tuesday, September 22, 2015 4:27 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] revision of content model of > > To me, @code, @dbkey, @n, @label et. al are all the same since they are > some identifier, making sense only to (some) humans, because their way of > identifying (and how to resolve the reference) is nowhere made explicit. > > The TEI is currently deprecating its @key attribute in favor of the more > formally defined @ref, noting: > "No particular syntax is proposed for the values of the key attribute, since its > form will depend entirely on practice within a given project. For the same > reason, this attribute is not recommended in data interchange, since there is > no way of ensuring that the values used by one project are distinct from > those used by another. In such a situation, a preferable approach for magic > tokens which follows standard practice on the Web is to use a ref attribute > whose value is a tag URI as defined in RFC 4151.“ [1] > > In fact, every local identifier ("magic token“) can easily be converted to a > 'real‘ URI through the usage of private URI schemes [2]. > > Just thought I’d mention this … > Best > Peter > > > [1] http://www.tei-c.org/Vault/P5/2.8.0/doc/tei-p5-doc/en/html/ref- > att.canonical.html > [2] http://wiki.tei-c.org/index.php/Private_URI_Schemes > > > > Am 21.09.2015 um 17:41 schrieb Roland, Perry D. (pdr4h) > : > > > > > > Another opportunity to clean up or clarify the markup surrounding > > performing forces – > > > > Can we drop the att.coded class and use att.canonical? In fact, I don’t see > a difference between these two classes and I’d like to eliminate att.coded. > > > > The problem with doing so, however, as it was with the instrVoice* > > elements, may be a matter of naming rather than function. Is dbkey > > (borrowed from TEI) a reasonable name for an attribute that > > essentially holds a coded value? “dbkey” indicates a very specific > > kind of coded value, so the name is probably too narrow. Would “code” > > or “codedvalue” be better, but now in the att.canonical class? Would > > either of those names still fit the database key use, especially if > > the documentation was changed to read – > > > > “ a coded value that identifies the element content or serves as a primary > key in an external database”? > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Roland, Perry D. (pdr4h) > > Sent: Monday, September 21, 2015 9:29 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] revision of content model of > > > > > > Hi Axel, > > > > I think that simplifying the model of is highly desirable. > Your suggested change is fine with me. Better than fine, I embrace it > wholeheartedly. > > > > I’d like to hear from others too. But if we don’t, then I’m fine with taking > silence as tacit agreement. > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Axel Teich Geertinger > > Sent: Monday, September 21, 2015 5:41 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] revision of content model of > > > > Hi Perry > > > > Yes, there is a difference between a list and a group. I have no objections to > putting soloists or a single player on a list, of course. I just don’t want to call > them a group; so your suggestion naming the elements and > instead is fine with me. > > If we decide to rename and , however, I > > suggest dropping . Of course, ‘instrumentation’ is a > > name easier to understand than ‘perfResList’; I am not sure whether > > that is a problem. But it seems misleading to me having > > inside , as the former is a more generic term than > > the latter. Why not make it > > > > > > > > > > > > > > and allowing and any number of and > elements inside ? > > > > – if we do want to change the schema, that is. I’d really like to hear some > more opinions on this. > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af > > Roland, Perry D. (pdr4h) > > Sendt: 18. september 2015 16:15 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] revision of content model of > > > > > > Axel, > > > > Adding the extra layer of markup – > > > > > > > > piano > > > > > > > > isn’t particularly onerous since it’s relatively easy to automate. I’m also not > particularly troubled by a list containing a single item. To me, it’s still a list. > > > > doesn’t necessarily become obsolete as it can still > > be used to separate information about non-dramatic performing forces > > from dramatic ones – > > > > > > > > > --> > > > > But, you’re right, we could do without . Here’s where > we can eliminate a level of nesting. That’s a good thing, right? > “Instrumentation” isn’t a particular good name for the enumeration of > performance resources anyway. > > > > My example 4 was just a demonstration of a markup possibility. The next > example, no. 5, does not attempt to group the soloists. Even so, soloists are > still part of the larger group – orchestra + chorus + soloists – that is expected > to perform the work, are they not? > > > > I guess that if you’re not excited about those changes, then you > > really won’t like the following suggestion – > > > > I’d like to eliminate and fold its functionality into , > *BUT* rename to (performance resource). At the > same time, should be renamed . This will > eliminate the cognitive dissonance created between “Grp” and “ensemble” > and “instrVoice”. In this new paradigm, an instrumentalist, a singer, and an > ensemble are all “performance resources” and a bunch of these resources > can be gathered into a “performance resource list”. In addition to increased > clarity, this change also better fits existing models of performing forces > description (e.g., MARC). > > > > As a compromise, I’m happy to leave most of the model of > > in place, but remove and also remove > > PCDATA from . I could even see retaining a single > > to accommodate your minimal nesting objection – > > > > > > > This would continue to validate > > > > > > piano > > > > > > The upshot of this is that ensemble names will have to be placed in > > , as in – > > > > > > dance band > > > > > > If you’re with me so far, then changing “instrVoice” to “perfRes” and > “instrVoiceGrp” to “perfResList” resolves the mental confusion of calling a > dance band a “voice”, doesn’t it? > > > > -- > > p. > > > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Axel Teich Geertinger > > Sent: Friday, September 18, 2015 5:19 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] revision of content model of > > > > Hi Perry > > > > First of all, I am afraid I still can’t see the importance of changing the > model; is it important enough to break backwards compatibility? > > > > I can think of a very simple situation where the current model seems more > appropriate: > > > > > > piano > > > > > > This would have to be changed into > > > > > > > > > > piano > > > > > > > > or > > > > > > piano > > > > > > It bothers me that I would always have to define a group, even if > > there is just a single instrument. Or very few instruments: I actually > > like being able to make a distinction between a few single instruments > > playing together and a group of instruments (an ensemble). For > > instance, I regard an orchestra as a group in a very different way > > than, say, a piano and violin playing a sonata. I am happy that the > > current model allows me to describe the sonata players as > > > > > > violin > > piano > > > > > > rather than > > > > > > > > violin > > piano > > > > > > > > The difference may be a subtle one, I admit. But it fits may way of thinking > of a group or an ensemble as something different from two musicians > playing together, even if it wouldn’t make any sense trying to define the > exact line between the one and the other... > > > > If wrapping all and into a single > – one of your suggestions to my cantata example – is to be > the recommendation, their parent would become > obsolete as it would always contain just one (or zero) . > > Your other suggestion – grouping the soloists in a – > conflicts with my understanding of them being marked explicitly as soloists > (as in: NOT part of a group or an ensemble). > > > > Sorry if I don’t get your point! > > > > /axel > > > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af > > Roland, Perry D. (pdr4h) > > Sendt: 17. september 2015 20:11 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] revision of content model of > > > > > > Sue me, I lied – this is still bugging me. J > > > > I still want to constrain the content of , but I > > think I’ve finally found a better solution. Changing the model to > > > > ELEMENT instrumentation (ensemble|instrVoiceGrp)* > > > > will validate all the following examples – > > > > Ex 1. Empty > > > > > > Ex 2. Single named ensemble > > > > Orchestra > > > > > > Ex 3. Any number of enumerated performing groups > > > > air guitar > > nose flute > > > > > > > > Ex 4. (Axel’s example with the soloists wrapped using ) > > > > > > xml:id="instrVoice_35190376">fl. > > xml:id="instrVoice_eb76cb3c">ob. > > xml:id="instrVoice_2a3dad65">cl. > > xml:id="instrVoice_8452f43c">fg. > > xml:id="instrVoice_4af15a73">cor. > > xml:id="instrVoice_b3ce4944">cnt. > > xml:id="instrVoice_6abf5bd6">trb. > > xml:id="instrVoice_29d73610">tb. > > xml:id="instrVoice_589f0915">timp. > > xml:id="instrVoice_54e51406">cmplli. > > > > > > Choir > > xml:id="instrVoice_44c2685b">S. > > xml:id="instrVoice_ba0dcf90">A. > > xml:id="instrVoice_205d576b">T. > > xml:id="instrVoice_95d6fb3b">B. > > > > > > xml:id="instrVoice_069a4d9b">S. > > xml:id="instrVoice_205d8825">T. > > > > > > > > Ex 5. (Axel’s example with the entire content wrapped using > > , nested enumerated groups) > > > > > > xml:id="instrVoice_35190376">fl. > > xml:id="instrVoice_eb76cb3c">ob. > > xml:id="instrVoice_2a3dad65">cl. > > xml:id="instrVoice_8452f43c">fg. > > xml:id="instrVoice_4af15a73">cor. > > xml:id="instrVoice_b3ce4944">cnt. > > xml:id="instrVoice_6abf5bd6">trb. > > xml:id="instrVoice_29d73610">tb. > > xml:id="instrVoice_589f0915">timp. > > xml:id="instrVoice_54e51406">cmplli. > > > > > > Choir > > xml:id="instrVoice_44c2685b">S. > > xml:id="instrVoice_ba0dcf90">A. > > xml:id="instrVoice_205d576b">T. > > xml:id="instrVoice_95d6fb3b">B. > > > > xml:id="instrVoice_069a4d9b">S. > > xml:id="instrVoice_205d8825">T. > > > > > > > > Ex. 6 Named ensemble + enumerated (nested) groups > > Orchestra > > > > Weird collection o’ players > > air guitar > > nose flute > > > > tambourine > > autoharp > > > > > > > > > > Ex. 7 Multiple named ensembles > > > > Band > > Orchestra > > Steel Band > > > > > > If anyone can demonstrate problems with this model, please let me know. > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Roland, Perry D. (pdr4h) > > Sent: Wednesday, September 16, 2015 3:57 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] revision of content model of > > > > Hi Axel, > > > > I think you’ve got it. Another layer of nesting using an outer > > isn’t necessary. I would recommend that you use > > within all the elements, not just the one for > > the Choir. You could also group the soloists, but it’s not required, > > I’m just being foolishly consistent. J > > > > Looking more carefully, I now think the current model for > > can’t really be improved, since all my so-called > > “improvements” result in not being able to handle works for a standard > > ensemble (e.g., orchestra) and an enumerated list of performers (for > > example, air guitar, nose flute, tambourine and autoharp, where one > > player uses 2 instruments) – > > > > > > Orchestra > > > > Weird collection o’ players > > air guitar > > nose flute > > > > tambourine > > autoharp > > > > > > > > > > Sorry for the unnecessary thrashing, > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Axel Teich Geertinger > > Sent: Wednesday, September 16, 2015 9:03 AM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] revision of content model of > > > > Hi Perry > > > > I use several elements within very often. I haven’t been > using , though. > > But in a cantata like this one: > http://www.kb.dk/dcm/cnw/document.xq?doc=cnw0113.xml , I have the > following to define an orchestra, a choir and vocal soloists: > > > > > > > > xml:id="instrVoice_35190376">fl. > > xml:id="instrVoice_eb76cb3c">ob. > > xml:id="instrVoice_2a3dad65">cl. > > xml:id="instrVoice_8452f43c">fg. > > xml:id="instrVoice_4af15a73">cor. > > xml:id="instrVoice_b3ce4944">cnt. > > xml:id="instrVoice_6abf5bd6">trb. > > xml:id="instrVoice_29d73610">tb. > > xml:id="instrVoice_589f0915">timp. > > xml:id="instrVoice_54e51406">cmplli. > > > > > > Choir > > xml:id="instrVoice_44c2685b">S. > > xml:id="instrVoice_ba0dcf90">A. > > xml:id="instrVoice_205d576b">T. > > xml:id="instrVoice_95d6fb3b">B. > > > > xml:id="instrVoice_069a4d9b">S. > > > xml:id="instrVoice_205d8825">T. > > > > > > Is that a misunderstanding of the concept? How would you organize this > instrumentation? By another layer of nesting and > elements? > > > > Best, > > Axel > > > > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af > > Roland, Perry D. (pdr4h) > > Sendt: 15. september 2015 23:00 > > Til: mei-l at lists.uni-paderborn.de > > Emne: [MEI-L] revision of content model of > > > > > > Hello everyone, > > > > This is pretty arcane stuff, so I expect that it will only be of > > interest to those who are deeply involved in creating detailed > > metadata regarding instrumentation, especially from MARC-encoded > > metadata. Consider yourself warned. J > > > > The current model of is very lax in order to allow > > liberal mixing of ensemble, instrVoice, and instrVoiceGrp elements – > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My original thinking on this was that a very loosely structured model > > would be helpful if were ever allowed to occur with > > the textual parts of MEI, say in

. However, I believe that it is > > unlikely that will ever occur in the presence of the other > > two possibilities. Therefore, unless someone can prove my hunch to be > > incorrect, I’m inclined to allow only one sub-element to be used at a > > time – > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using this approach, one can use to encode the name of a > performing group, like “orchestra” or use to enumerate the > parts/players of the group, but not both. > > > > However, this change re-focuses attention on the relationship between > > and – possibly a distinction without a > > difference, as the expected content of both is text and both provide > > the same attributes (att.authorized and att.coded) for connecting the > > textual content to an authorized list. With this in mind, it might be > > beneficial to modify the content model even further – > > > > > > > > > > > > > > > > > > > > > > > > > > > > eliminating entirely. The problem with this solution is that > some confusion may be created as “instrVoice” doesn’t immediately spring > to mind as a way to name an ensemble. Conversely, the “Grp” part of the > name “instrVoiceGrp” may lead the unwary into thinking that it can be used > to *label* an ensemble, when in fact it should be used to *describe* an > ensemble. > > > > So, I’m looking for advice on how to resolve this quandary – a model that’s > too lax vs. a model that’s more tightly controlled but with elements that are > not completely descriptive of the material we’re trying to encode. At this > point, I’m leaning toward the most restrictive model. > > > > Is everyone OK with using Band to name an > > ensemble without enumerating its constituents and using > > > > > > Band > > Flutes > > Clarinets > > etc. > > > > to provide detailed instrumentation when needed? Also, has anyone > created markup that this change would break? > > > > Thanks for your input, > > > > -- > > p. > > > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > 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 Thu Sep 24 08:37:17 2015 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 24 Sep 2015 08:37:17 +0200 Subject: [MEI-L] New GitHub repository In-Reply-To: References: Message-ID: <56039A1D.3070508@edirom.de> Dear Perry, Laurent, and especially Andrew, many thanks for your efforts in migrating the MEI repository to GitHub! This is great news in terms of code management and community envolvement in the development of the schemata, the guidelines and the sample encodings! I think you've done excellent work with the contribution guidelines, too! All the best, Benjamin Am 21.09.2015 um 20:17 schrieb Laurent Pugin: > Dear all, > This is an official announcement of the new GitHub account and > repository for MEI. The new MEI repository is accessible at > https://github.com/music-encoding/music-encoding. All the information > from the previous GoogleCode repository has been migrated to the > GitHub one, including issues, branches, tags, etc. > This announcement means that GoogleCode repository is no longer in use > and will not be maintained. We recommend not to refer to it, including > for schema validation. All the schemata are now permanently available > directly from music-encoding.org under > 'schema' plus the version number. For example, the latest release is > available at http://www.music-encoding.org/schema/2.1.1/mei-all.rng > The move to GitHub has also been an opportunity for us to re-think > workflows and contribution guidelines for MEI. Of course, since MEI is > a schema and not a software product, we expect all contributions to be > thoughtfully discussed by the community before they find their way to > the MEI source. Contributors should not expect any pull request to be > included in MEI straight away without the required discussion, even if > the contribution does not create any conflict and seems straight > forward to integrate. In order to clarify this, Andrew Hankinson has > written some contributions guidelines that we strongly recommend > reading if you are interested in contributing to the MEI schema. > The GitHub account of MEI includes other repositories than the MEI > source one. MEI also hosts repositories for the customization service > and the SibMEI plugin, for example. You can see all of them listed > directly on the MEI GitHub account: https://github.com/music-encoding. > At some point, we will evaluate whether parts of the current MEI > repository should become distinct repositories themselves. As > specified by the MEI by-laws, the GitHub account of MEI is managed by > the co-chairs of the technical teams. At their discretion, the > co-chairs may provide write access to the repositories to other > members of the technical team. > Thank you to all who contributed to the migration to GitHub. We are > looking forward to your feed-back and to your contributions. > > For the technical team > Perry and Laurent > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kelnreiter at mozarteum.at Sat Sep 26 22:56:10 2015 From: kelnreiter at mozarteum.at (Franz Kelnreiter Internationale Stiftung Mozarteum) Date: Sat, 26 Sep 2015 22:56:10 +0200 Subject: [MEI-L] MEC2016: upload of your submissions Message-ID: <20150926225610.EGroupware.5XIgTjo9nO0UQd4cO9Hxpy0@egw.mozarteum.at> Dear colleagues, I'd very much like to inform you that the Conftool for registration of your paper, poster, panel session or workshop submissions at the Music Encoding Conference 2016 is now up and running and encourage you to submit your proposals on https://www.conftool.net/music-encoding2016/ . The new and final deadline for registration has been extended to 31 October 11:59 pm EST (conference time). For any further information please refer to the [ http://music-encoding.org/community/conference/call-for-proposals/ -> Call for Proposals ] or send an email to mailto:conference2016 at music-encoding.org . Please note that the use of Conftool is mandatory and proposals sent as email cannot be accepted. On behalf of the Program Committee Franz -------------------------------------------------------- Franz Kelnreiter Mozart Institut/ Digitale Mozart-Edition Internationale Stiftung Mozarteum Schwarzstrasse 26 5020 Salzburg, Austria T +43 (0) 662 88 940 69 M +43 (0) 662 88 940 68 E mailto:kelnreiter at mozarteum.at [ http://www.mozarteum.at/ -> www.mozarteum.at ] [ http://www.mozarteum.at/content/newsletter -> Newsletter Stiftung Mozarteum ] [ http://www.facebook.com/StiftungMozarteum -> Facebook Stiftung Mozarteum ] ZVR: 438729131, UID: ATU33977907 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tw at notabit.eu Wed Sep 30 11:37:40 2015 From: tw at notabit.eu (Thomas Weber) Date: Wed, 30 Sep 2015 11:37:40 +0200 Subject: [MEI-L] Semantically unspecific text (sub)divisions Message-ID: <560BAD64.3090804@notabit.eu> As far as I understand, in TEI, the elements , and would be options to (sub-)divide/mark up a stretch of text without necessarily inducing some pre-defined semantic implications[1]. I see no way of doing that in MEI, e.g. for * encoding some text that neither classifies as anchored text, heading, table, paragraph, line group, list or block quote. * annotating a span of text inside a

or element, but not the entire element. Unless I'm missing something, would it be sensible to take the mentioned TEI elements as a model for MEI? To the TEI experts - what exactly is the difference between and ? It seems to me is more like an HTML

(a "block" - is that what TEI calls a "chunk"?), while is more like an HTML ("inline" in HTML terms). Specifically I was looking into how to sensibly encode rubrics in neumatic notation, wondering whether I should use something like

some rubric text

but I don't think describing rubrics as paragraphs is semantically appropriate. could be considered appropriate in some cases, but it's not allowed as the only element inside a
. I'll probably circumvent that problem by adding a NeumesXML-like element[2] in our customization, but I feel the general problem that standard MEI might currently force one to classify text in potentially inappropriate ways remains. One option could also be to allow text immediately inside
without having to wrap it into a more semantically specific element, but enforcing more semantical markup is of course not a bad idea, provided semantically appropriate choices are made available, including a fallback to more generic markup. [1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SASE [2] http://www.scribeserver.com/NEUMES/neumesxml_tree/tree_detail_west/rubric.htm -- Thomas Weber Notabit Burgkstraße 28 01159 Dresden Tel.: +49 (0)351 4794689 http://notabit.eu/ From raffaeleviglianti at gmail.com Wed Sep 30 16:22:59 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 30 Sep 2015 10:22:59 -0400 Subject: [MEI-L] Semantically unspecific text (sub)divisions In-Reply-To: <560BAD64.3090804@notabit.eu> References: <560BAD64.3090804@notabit.eu> Message-ID: Hi Thomas, On Wed, Sep 30, 2015 at 5:37 AM, Thomas Weber wrote: > > Unless I'm missing something, would it be sensible to take the mentioned > TEI elements as a model for MEI? To the TEI experts - what exactly is the > difference between and ? It seems to me is more like an > HTML
(a "block" - is that what TEI calls a "chunk"?), while is > more like an HTML ("inline" in HTML terms). > > That's my understanding too. They belong to two different levels and class systems. I am wary of adding more semantic text encoding to MEI. My rule of thumb is that if I'm finding it difficult to encode text with MEI, it's time to switch to TEI. ODD makes it possible to mix the two at a fairly granular level (though admittedly using both standard at once does add substantial overhead to your ODD workflow). Raff > Specifically I was looking into how to sensibly encode rubrics in neumatic > notation, wondering whether I should use something like > > >
>

some rubric text

>
> > > but I don't think describing rubrics as paragraphs is semantically > appropriate. could be considered appropriate in some cases, but > it's not allowed as the only element inside a
. I'll probably > circumvent that problem by adding a NeumesXML-like element[2] in > our customization, but I feel the general problem that standard MEI might > currently force one to classify text in potentially inappropriate ways > remains. > > One option could also be to allow text immediately inside
without > having to wrap it into a more semantically specific element, but enforcing > more semantical markup is of course not a bad idea, provided semantically > appropriate choices are made available, including a fallback to more > generic markup. > > > [1] http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SASE > [2] > http://www.scribeserver.com/NEUMES/neumesxml_tree/tree_detail_west/rubric.htm > > -- > Thomas Weber > Notabit > Burgkstraße 28 > 01159 Dresden > > Tel.: +49 (0)351 4794689 > http://notabit.eu/ > > > _______________________________________________ > 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 andrew.hankinson at mail.mcgill.ca Wed Sep 30 22:42:03 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 30 Sep 2015 16:42:03 -0400 Subject: [MEI-L] Bracketed Lines in MEI Message-ID: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> Hello all, I'm looking at the following: It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 13626 bytes Desc: not available URL: From esfield at stanford.edu Wed Sep 30 22:59:45 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Wed, 30 Sep 2015 20:59:45 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> Message-ID: Hi, Andrew, This is a ligature (the three notes were connected in the original notation). The ligature element (http://music-encoding.org/documentation/2.1.1/ligature/) should work. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 1:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: [cid:image001.png at 01D0FB88.41FFC6B0] It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13626 bytes Desc: image001.png URL: From andrew.hankinson at mail.mcgill.ca Wed Sep 30 23:24:47 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 30 Sep 2015 17:24:47 -0400 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <24472_1443646875_560C4D9B_24472_42_1_DM2PR02MB5123FFB9FD633939F7F6C7FC34D0@DM2PR02MB512.namprd02.prod.outlook.com> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <24472_1443646875_560C4D9B_24472_42_1_DM2PR02MB5123FFB9FD633939F7F6C7FC34D0@DM2PR02MB512.namprd02.prod.outlook.com> Message-ID: <38E3456C-77AE-4A3B-9D09-B2A77A0DD210@mail.mcgill.ca> Hi Eleanor, Thank you for responding. Perhaps it would be helpful if I could give the full context of why I'm asking: The common use of this symbol is, indeed, to signify a ligature, and it's even what it's supposed to be doing in the particular example I posted. However, I'm looking to translate this score from Sibelius (which is the environment I'm in) to MEI. As such, I don't think I can assume that everywhere a bracket like this occurred it "meant" a ligature, especially given the range of brackets one may encounter in this software: This is why I hope to use the more generic "line" element to represent this particular graphic, and am looking for a way to represent its start and end points without also giving it any particular meaning. That said, one of the modifications I hope to work on soon is the translation of common editorial idioms from Sibelius into editorial markup, e.g., assuming notes under a group are ligatures, or assuming that a sharp symbol above the staff is a ficta, and marking it up as such in the MEI. This would be an option that a person would enable when they exported their file to MEI, but for now I'm focusing on just getting the symbols encoded. Thanks again, -Andrew > On Sep 30, 2015, at 4:59 PM, Eleanor Selfridge-Field wrote: > > Hi, Andrew, > > This is a ligature (the three notes were connected in the original notation). > > The ligature element (http://music-encoding.org/documentation/2.1.1/ligature/ ) should work. > > Eleanor > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 1:42 PM > To: Music Encoding Initiative > Subject: [MEI-L] Bracketed Lines in MEI > > Hello all, > > I'm looking at the following: > > > > It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). > > Is there a better element to use for this object, or should a modification be proposed for the schema? > > Many thanks, > -Andrew > _______________________________________________ > 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: PastedGraphic-3.png Type: image/png Size: 9581 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Wed Sep 30 23:35:59 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 30 Sep 2015 21:35:59 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> Message-ID: 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? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 4:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: [cid:image001.png at 01D0FBA1.D203DF80] It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 13626 bytes Desc: image001.png URL: From andrew.hankinson at mail.mcgill.ca Wed Sep 30 23:41:33 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 30 Sep 2015 17:41:33 -0400 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <20699_1443648979_560C55D3_20699_193_2_BBCC497C40D85642B90E9F94FC30343D7C6D7242@grant1.eservices.virginia.edu> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <20699_1443648979_560C55D3_20699_193_2_BBCC497C40D85642B90E9F94FC30343D7C6D7242@grant1.eservices.virginia.edu> Message-ID: <372EE527-C114-4AAC-AFA0-F67DBE5D43F4@mail.mcgill.ca> No, I'm not using any of those particular attributes since I can't really extract those from the Sibelius original. I will go ahead and create a pull request that adds these attributes to line. Thanks! > On Sep 30, 2015, at 5:35 PM, Roland, Perry D. (pdr4h) wrote: > > > 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? > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 4:42 PM > To: Music Encoding Initiative > Subject: [MEI-L] Bracketed Lines in MEI > > Hello all, > > I'm looking at the following: > > > > It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). > > Is there a better element to use for this object, or should a modification be proposed for the schema? > > Many thanks, > -Andrew > _______________________________________________ > 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 Wed Sep 30 23:49:53 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 30 Sep 2015 21:49:53 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <372EE527-C114-4AAC-AFA0-F67DBE5D43F4@mail.mcgill.ca> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <20699_1443648979_560C55D3_20699_193_2_BBCC497C40D85642B90E9F94FC30343D7C6D7242@grant1.eservices.virginia.edu> <372EE527-C114-4AAC-AFA0-F67DBE5D43F4@mail.mcgill.ca> Message-ID: Ok, but are @startid and @endid sufficient? How does Sibelius position the line? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 5:42 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI No, I'm not using any of those particular attributes since I can't really extract those from the Sibelius original. I will go ahead and create a pull request that adds these attributes to line. Thanks! On Sep 30, 2015, at 5:35 PM, Roland, Perry D. (pdr4h) > wrote: 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? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 4:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew _______________________________________________ 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 esfield at stanford.edu Wed Sep 30 23:56:34 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Wed, 30 Sep 2015 21:56:34 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <38E3456C-77AE-4A3B-9D09-B2A77A0DD210@mail.mcgill.ca> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <24472_1443646875_560C4D9B_24472_42_1_DM2PR02MB5123FFB9FD633939F7F6C7FC34D0@DM2PR02MB512.namprd02.prod.outlook.com> <38E3456C-77AE-4A3B-9D09-B2A77A0DD210@mail.mcgill.ca> Message-ID: Hi, Andrew, The same styles of lines can also turn up as first and second endings, so if "line" is divorced from musical semantics, it could in other contexts produce ambiguities. The exact presentation of editorial markup styles varies from one publisher to another. We inventoried methods of indicating da capo returns and their (re)starting points once. When we accumulated 25, we decided to give up on signs and settle for semantic meanings. In a mark-up language environment, an argument can be made for representing meaning and leaving refinements to the software. In starting with Sibelius (or any other notation software) the direction is reversed, and of course the questions change. So the real question may be how to deal with the idiosyncracies that will inevitably arise. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 2:25 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI Hi Eleanor, Thank you for responding. Perhaps it would be helpful if I could give the full context of why I'm asking: The common use of this symbol is, indeed, to signify a ligature, and it's even what it's supposed to be doing in the particular example I posted. However, I'm looking to translate this score from Sibelius (which is the environment I'm in) to MEI. As such, I don't think I can assume that everywhere a bracket like this occurred it "meant" a ligature, especially given the range of brackets one may encounter in this software: [cid:image001.png at 01D0FB8E.DB45D8E0] This is why I hope to use the more generic "line" element to represent this particular graphic, and am looking for a way to represent its start and end points without also giving it any particular meaning. That said, one of the modifications I hope to work on soon is the translation of common editorial idioms from Sibelius into editorial markup, e.g., assuming notes under a group are ligatures, or assuming that a sharp symbol above the staff is a ficta, and marking it up as such in the MEI. This would be an option that a person would enable when they exported their file to MEI, but for now I'm focusing on just getting the symbols encoded. Thanks again, -Andrew On Sep 30, 2015, at 4:59 PM, Eleanor Selfridge-Field > wrote: Hi, Andrew, This is a ligature (the three notes were connected in the original notation). The ligature element (http://music-encoding.org/documentation/2.1.1/ligature/) should work. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 1:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew _______________________________________________ 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: image001.png Type: image/png Size: 9581 bytes Desc: image001.png URL: From andrew.hankinson at mail.mcgill.ca Wed Sep 30 23:57:08 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 30 Sep 2015 17:57:08 -0400 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <9795_1443649817_560C5919_9795_77_1_BBCC497C40D85642B90E9F94FC30343D7C6D727B@grant1.eservices.virginia.edu> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <20699_1443648979_560C55D3_20699_193_2_BBCC497C40D85642B90E9F94FC30343D7C6D7242@grant1.eservices.virginia.edu> <372EE527-C114-4AAC-AFA0-F67DBE5D43F4@mail.mcgill.ca> <9795_1443649817_560C5919_9795_77_1_BBCC497C40D85642B90E9F94FC30343D7C6D727B@grant1.eservices.virginia.edu> Message-ID: Sibelius positions it within its own timing system, which gives you (in a measure of 4/4) 1024 positions. However, most often than not the lines are tied to a note, which is at a specific position. I've got a process that tries to find the nearest note to a given position, and then uses that for the start/end IDs. Failing that, it will record @tstamp/@tstamp2 for start/end relative to the measure/staff/layer. It will also record the @dur.ges, just to store the "performed" duration from Sibelius (e.g., dur.ges="256p" would mean that the duration is a quarter-note in Sibelius ticks). So @tstamp/@tstamp2 and @staff/@layer are the most critical parts of ensuring we can preserve the location of the note, beyond @start/end id. > On Sep 30, 2015, at 5:49 PM, Roland, Perry D. (pdr4h) wrote: > > > Ok, but are @startid and @endid sufficient? How does Sibelius position the line? > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 5:42 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Bracketed Lines in MEI > > No, I'm not using any of those particular attributes since I can't really extract those from the Sibelius original. > > I will go ahead and create a pull request that adds these attributes to line. > > Thanks! > > On Sep 30, 2015, at 5:35 PM, Roland, Perry D. (pdr4h) > wrote: > > > 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? > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 4:42 PM > To: Music Encoding Initiative > Subject: [MEI-L] Bracketed Lines in MEI > > Hello all, > > I'm looking at the following: > > > > It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). > > Is there a better element to use for this object, or should a modification be proposed for the schema? > > Many thanks, > -Andrew > _______________________________________________ > 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 Thu Oct 1 00:03:14 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 30 Sep 2015 22:03:14 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <20699_1443648979_560C55D3_20699_193_2_BBCC497C40D85642B90E9F94FC30343D7C6D7242@grant1.eservices.virginia.edu> <372EE527-C114-4AAC-AFA0-F67DBE5D43F4@mail.mcgill.ca> <9795_1443649817_560C5919_9795_77_1_BBCC497C40D85642B90E9F94FC30343D7C6D727B@grant1.eservices.virginia.edu> Message-ID: Makes sense. I’ll add the extra attributes (@staff, @layer, @place, @tstamp, @tstamp2, @dur, and @dur.ges) to my to-do list for the next release. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 5:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI Sibelius positions it within its own timing system, which gives you (in a measure of 4/4) 1024 positions. However, most often than not the lines are tied to a note, which is at a specific position. I've got a process that tries to find the nearest note to a given position, and then uses that for the start/end IDs. Failing that, it will record @tstamp/@tstamp2 for start/end relative to the measure/staff/layer. It will also record the @dur.ges, just to store the "performed" duration from Sibelius (e.g., dur.ges="256p" would mean that the duration is a quarter-note in Sibelius ticks). So @tstamp/@tstamp2 and @staff/@layer are the most critical parts of ensuring we can preserve the location of the note, beyond @start/end id. On Sep 30, 2015, at 5:49 PM, Roland, Perry D. (pdr4h) > wrote: Ok, but are @startid and @endid sufficient? How does Sibelius position the line? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 5:42 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI No, I'm not using any of those particular attributes since I can't really extract those from the Sibelius original. I will go ahead and create a pull request that adds these attributes to line. Thanks! On Sep 30, 2015, at 5:35 PM, Roland, Perry D. (pdr4h) > wrote: 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? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 4:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew _______________________________________________ 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 andrew.hankinson at mail.mcgill.ca Thu Oct 1 00:08:10 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Wed, 30 Sep 2015 18:08:10 -0400 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: <26573_1443650224_560C5AB0_26573_226_1_DM2PR02MB512A8760B6B75967F003503C34D0@DM2PR02MB512.namprd02.prod.outlook.com> References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <24472_1443646875_560C4D9B_24472_42_1_DM2PR02MB5123FFB9FD633939F7F6C7FC34D0@DM2PR02MB512.namprd02.prod.outlook.com> <38E3456C-77AE-4A3B-9D09-B2A77A0DD210@mail.mcgill.ca> <26573_1443650224_560C5AB0_26573_226_1_DM2PR02MB512A8760B6B75967F003503C34D0@DM2PR02MB512.namprd02.prod.outlook.com> Message-ID: <52C1823B-4069-4769-B531-804D039ED445@mail.mcgill.ca> The idiosyncracies that will inevitably arise is a large part why I'm making it an option, since it would be *useful* to many people, but it would make assumptions that would probably not be globally desirable. For endings, however, the Sibelius plugin will treat them as endings and encode them as such in MEI. In this case I do infer the meaning, but it's because Sibelius has a very specific symbol for endings ('RepeatTimeLine') whereas the brackets that I showed earlier are just represented by the generic 'Line' type. -Andrew > On Sep 30, 2015, at 5:56 PM, Eleanor Selfridge-Field wrote: > > Hi, Andrew, > > The same styles of lines can also turn up as first and second endings, so if “line” is divorced from musical semantics, it could in other contexts produce ambiguities. > > The exact presentation of editorial markup styles varies from one publisher to another. We inventoried methods of indicating da capo returns and their (re)starting points once. When we accumulated 25, we decided to give up on signs and settle for semantic meanings. In a mark-up language environment, an argument can be made for representing meaning and leaving refinements to the software. > > In starting with Sibelius (or any other notation software) the direction is reversed, and of course the questions change. So the real question may be how to deal with the idiosyncracies that will inevitably arise. > > Eleanor > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 2:25 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Bracketed Lines in MEI > > Hi Eleanor, > > Thank you for responding. Perhaps it would be helpful if I could give the full context of why I'm asking: The common use of this symbol is, indeed, to signify a ligature, and it's even what it's supposed to be doing in the particular example I posted. > > However, I'm looking to translate this score from Sibelius (which is the environment I'm in) to MEI. As such, I don't think I can assume that everywhere a bracket like this occurred it "meant" a ligature, especially given the range of brackets one may encounter in this software: > > > > This is why I hope to use the more generic "line" element to represent this particular graphic, and am looking for a way to represent its start and end points without also giving it any particular meaning. > > That said, one of the modifications I hope to work on soon is the translation of common editorial idioms from Sibelius into editorial markup, e.g., assuming notes under a group are ligatures, or assuming that a sharp symbol above the staff is a ficta, and marking it up as such in the MEI. This would be an option that a person would enable when they exported their file to MEI, but for now I'm focusing on just getting the symbols encoded. > > Thanks again, > -Andrew > > > On Sep 30, 2015, at 4:59 PM, Eleanor Selfridge-Field > wrote: > > Hi, Andrew, > > This is a ligature (the three notes were connected in the original notation). > > The ligature element (http://music-encoding.org/documentation/2.1.1/ligature/ ) should work. > > Eleanor > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de ] On Behalf Of Andrew Hankinson > Sent: Wednesday, September 30, 2015 1:42 PM > To: Music Encoding Initiative > Subject: [MEI-L] Bracketed Lines in MEI > > Hello all, > > I'm looking at the following: > > > > It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). > > Is there a better element to use for this object, or should a modification be proposed for the schema? > > Many thanks, > -Andrew > _______________________________________________ > 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 Thu Oct 1 00:08:59 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 30 Sep 2015 22:08:59 +0000 Subject: [MEI-L] Bracketed Lines in MEI In-Reply-To: References: <689A7AE5-9BD4-4105-8B1C-B24F215882B1@mail.mcgill.ca> <24472_1443646875_560C4D9B_24472_42_1_DM2PR02MB5123FFB9FD633939F7F6C7FC34D0@DM2PR02MB512.namprd02.prod.outlook.com> <38E3456C-77AE-4A3B-9D09-B2A77A0DD210@mail.mcgill.ca> Message-ID: Hi Eleanor, It's always better to use semantic markup whenever possible. That being said, I don't think it's necessary to have a semantic "tag" for everything, especially when some of those things are visual in nature anyhow. Of course, that introduces a certain amount of inconsistency - MEI has an element for endings, but not for brackets - but I think it's preferable to an EXPLOSION! of elements. I certainly hope that no one would ever try to use to draw endings, but that's a chance I'm willing to take. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Eleanor Selfridge-Field Sent: Wednesday, September 30, 2015 5:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI Hi, Andrew, The same styles of lines can also turn up as first and second endings, so if "line" is divorced from musical semantics, it could in other contexts produce ambiguities. The exact presentation of editorial markup styles varies from one publisher to another. We inventoried methods of indicating da capo returns and their (re)starting points once. When we accumulated 25, we decided to give up on signs and settle for semantic meanings. In a mark-up language environment, an argument can be made for representing meaning and leaving refinements to the software. In starting with Sibelius (or any other notation software) the direction is reversed, and of course the questions change. So the real question may be how to deal with the idiosyncracies that will inevitably arise. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 2:25 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Bracketed Lines in MEI Hi Eleanor, Thank you for responding. Perhaps it would be helpful if I could give the full context of why I'm asking: The common use of this symbol is, indeed, to signify a ligature, and it's even what it's supposed to be doing in the particular example I posted. However, I'm looking to translate this score from Sibelius (which is the environment I'm in) to MEI. As such, I don't think I can assume that everywhere a bracket like this occurred it "meant" a ligature, especially given the range of brackets one may encounter in this software: [cid:image001.png at 01D0FBAB.1470A390] This is why I hope to use the more generic "line" element to represent this particular graphic, and am looking for a way to represent its start and end points without also giving it any particular meaning. That said, one of the modifications I hope to work on soon is the translation of common editorial idioms from Sibelius into editorial markup, e.g., assuming notes under a group are ligatures, or assuming that a sharp symbol above the staff is a ficta, and marking it up as such in the MEI. This would be an option that a person would enable when they exported their file to MEI, but for now I'm focusing on just getting the symbols encoded. Thanks again, -Andrew On Sep 30, 2015, at 4:59 PM, Eleanor Selfridge-Field > wrote: Hi, Andrew, This is a ligature (the three notes were connected in the original notation). The ligature element (http://music-encoding.org/documentation/2.1.1/ligature/) should work. Eleanor From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Wednesday, September 30, 2015 1:42 PM To: Music Encoding Initiative Subject: [MEI-L] Bracketed Lines in MEI Hello all, I'm looking at the following: It seems that the best element to use in this case would be 'line'; however, the line element currently does not support durational attributes (@dur, @dur.ges, @tstamp, @tstamp2) or positional (@staff, @layer, @place). Is there a better element to use for this object, or should a modification be proposed for the schema? Many thanks, -Andrew _______________________________________________ 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: image001.png Type: image/png Size: 9581 bytes Desc: image001.png URL: From andrew.hankinson at gmail.com Sat Oct 10 19:18:39 2015 From: andrew.hankinson at gmail.com (Andrew Hankinson) Date: Sat, 10 Oct 2015 13:18:39 -0400 Subject: [MEI-L] Sibelius to MEI 2.0 Beta Message-ID: <4973229E-9665-4D1B-A82D-03A94BF81B61@gmail.com> Hi everyone, I've been putting the finishing touches on a rewrite of the Sibelius to MEI plugin. Today, I'm sending around a preview release of it, to help me shake out any remaining bugs or missing features. So, if you use it or would like to use it, here's your chance to get your favourite feature in! You can download the files here: https://github.com/music-encoding/sibmei/releases/tag/2.0.0-beta Please read the release notes for any 'gotchas.' It's important to note that I'm aiming to support the upcoming MEI 3.0.0 release. For those who are interested, here is a list of some of the changes that are in this release. - Switched to using the `plgToMSS` framework by Tido (Thanks Zoltan & crew, you're awesome!) - Re-organized the code base so that it wasn't just one big loop that did everything - Also switched to using the `sib-test` plugin and wrote lots of unit tests (again, Tido: thanks!) - Visible/invisible accidentals are more reliably determined - Placement of 'spanners' (ties, slurs, cresc., decresc., etc.) are now fairly reliably attached to their note objects - Support for many new symbols If you notice any problems, please open an issue on the GitHub page. I think you can also attach .mei and .sib files, which would both be helpful for me tracking down problems. Thanks, -Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From zolaemil at gmail.com Sat Oct 10 20:23:12 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Sat, 10 Oct 2015 19:23:12 +0100 Subject: [MEI-L] Sibelius to MEI 2.0 Beta In-Reply-To: <4973229E-9665-4D1B-A82D-03A94BF81B61@gmail.com> References: <4973229E-9665-4D1B-A82D-03A94BF81B61@gmail.com> Message-ID: Andrew, thanks for the shout out, for plgToMSS credit goes to David Harvey! 2015-10-10 18:18 GMT+01:00 Andrew Hankinson : > Hi everyone, > > I've been putting the finishing touches on a rewrite of the Sibelius to > MEI plugin. Today, I'm sending around a preview release of it, to help me > shake out any remaining bugs or missing features. So, if you use it or > would like to use it, here's your chance to get your favourite feature in! > > You can download the files here: > > https://github.com/music-encoding/sibmei/releases/tag/2.0.0-beta > > Please read the release notes for any 'gotchas.' It's important to note > that I'm aiming to support the upcoming MEI 3.0.0 release. > > For those who are interested, here is a list of some of the changes that > are in this release. > > - Switched to using the `plgToMSS` framework by Tido (Thanks Zoltan & > crew, you're awesome!) > - Re-organized the code base so that it wasn't just one big loop that did > everything > - Also switched to using the `sib-test` plugin and wrote lots of unit > tests (again, Tido: thanks!) > - Visible/invisible accidentals are more reliably determined > - Placement of 'spanners' (ties, slurs, cresc., decresc., etc.) are now > fairly reliably attached to their note objects > - Support for many new symbols > > If you notice any problems, please open an issue on the GitHub page. I > think you can also attach .mei and .sib files, which would both be helpful > for me tracking down problems. > > Thanks, > -Andrew > > _______________________________________________ > 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 andrew.hankinson at gmail.com Tue Oct 13 22:09:14 2015 From: andrew.hankinson at gmail.com (Andrew Hankinson) Date: Tue, 13 Oct 2015 16:09:14 -0400 Subject: [MEI-L] News: Music Encoding Conference 2016 Message-ID: <123689E7-378C-4D66-BF6C-7E9C598010BF@gmail.com> Dear MEI Community, We're pleased to announce that we have received funding from the Social Sciences and Humanities Research Council of Canada (SSHRC) for the 2016 Music Encoding Conference. As part of this funding, we will be offering travel support for students to attend the conference and present their work. This comes in two forms: -- Significantly reduced registration rates for all students -- Five $800 travel bursaries, awarded on a merit basis to student presenters The details of how to apply for the travel bursaries will be announced in the coming weeks. We will also be organizing a special event for conference attendees, the details of which will follow in the new year. As a reminder, the deadline for submissions is the 31 October. Call for Proposals: http://music-encoding.org/community/conference/call-for-proposals/ Conftool Submissions: https://www.conftool.net/music-encoding2016/ We look forward to seeing your (and your students'!) submissions. Thank you, Ichiro Fujinaga Andrew Hankinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Wed Oct 14 10:54:20 2015 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 14 Oct 2015 10:54:20 +0200 Subject: [MEI-L] dots on chords and rests Message-ID: Dear list, we're slightly puzzled by the encoding of dotted chords and rests for Beethovens Werkstatt. As we need to attach SVG shapes to our dots, we have to encode them as elements. When encoding a note, this is perfectly possible, using the child element within note. However, is not allowed within rest. With chords, a is also not allowed inside . Here, I understand the complications: If you put two elements inside a chord, it could mean that there is a separate dot for each of the two notes (duration * 1.5), or it could mean that it's a double-dotted chord (duration * 1.75). This means you have to put the s inside the child notes, which means that querying for durations is really a pain (you have to look for @dur on , and for inside the contained ). I know it's possible to put the dot inside , but this weakens the connection between dot and the music event it belongs to in a rather severe way. Opinions? Recommendations? Johannes -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From zolaemil at gmail.com Wed Oct 14 12:21:18 2015 From: zolaemil at gmail.com (=?UTF-8?B?S8WRbcOtdmVzIFpvbHTDoW4=?=) Date: Wed, 14 Oct 2015 11:21:18 +0100 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: Hi Jo, I am thinking that this is one of the situations when relying on redundancy is a good thing - if you can. You could rely on the @dots attribute for determining the duration of chords, while relying on the element for visual representation - provided you have any means to ensure that the attribute and the element are used consistently. Of course redundancy is a double-edged sword (e.g. it could cause complications if you want to make changes to a redundant model), but perhaps something to consider? Best Zoltan 2015-10-14 9:54 GMT+01:00 Johannes Kepper : > Dear list, > > we're slightly puzzled by the encoding of dotted chords and rests for > Beethovens Werkstatt. As we need to attach SVG shapes to our dots, we have > to encode them as elements. When encoding a note, this is perfectly > possible, using the child element within note. However, is not > allowed within rest. With chords, a is also not allowed inside > . Here, I understand the complications: If you put two > elements inside a chord, it could mean that there is a separate dot for > each of the two notes (duration * 1.5), or it could mean that it's a > double-dotted chord (duration * 1.75). This means you have to put the > s inside the child notes, which means that querying for durations is > really a pain (you have to look for @dur on , and for inside > the contained ). > > I know it's possible to put the dot inside , but this weakens the > connection between dot and the music event it belongs to in a rather severe > way. > > Opinions? Recommendations? > > Johannes > > _______________________________________________ > 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 lxpugin at gmail.com Wed Oct 14 13:22:08 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 14 Oct 2015 13:22:08 +0200 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: I am not sure assume that dot attributes determine the duration and dot elements the visual appearance makes sense. The fact that we have @dots and /dot and where to encode them with chords are two different issues to me. My understanding of promoting attributes to element is that you can then have additional information, including embed them within /app and /rdg, for example. Now for making the distinction between the actual duration and the appearance we might want to introduce .ges attributes. I am thinking of something like: Now if you want to represent this with elements: / This is just an idea. Laurent On Wed, Oct 14, 2015 at 12:21 PM, Kőmíves Zoltán wrote: > Hi Jo, > > I am thinking that this is one of the situations when relying on > redundancy is a good thing - if you can. You could rely on the @dots > attribute for determining the duration of chords, while relying on the > element for visual representation - provided you have any means to ensure > that the attribute and the element are used consistently. > > Of course redundancy is a double-edged sword (e.g. it could cause > complications if you want to make changes to a redundant model), but > perhaps something to consider? > > Best > Zoltan > > > > 2015-10-14 9:54 GMT+01:00 Johannes Kepper : > >> Dear list, >> >> we're slightly puzzled by the encoding of dotted chords and rests for >> Beethovens Werkstatt. As we need to attach SVG shapes to our dots, we have >> to encode them as elements. When encoding a note, this is perfectly >> possible, using the child element within note. However, is not >> allowed within rest. With chords, a is also not allowed inside >> . Here, I understand the complications: If you put two >> elements inside a chord, it could mean that there is a separate dot for >> each of the two notes (duration * 1.5), or it could mean that it's a >> double-dotted chord (duration * 1.75). This means you have to put the >> s inside the child notes, which means that querying for durations is >> really a pain (you have to look for @dur on , and for inside >> the contained ). >> >> I know it's possible to put the dot inside , but this weakens the >> connection between dot and the music event it belongs to in a rather severe >> way. >> >> Opinions? Recommendations? >> >> Johannes >> >> _______________________________________________ >> 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 Wed Oct 14 16:30:23 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 14 Oct 2015 14:30:23 +0000 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: The lack of within is an oversight that can be easily remedied. It will be there in the next release. within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding is short hand for and because these attributes are all optional, then there’s nothing inherently wrong with The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. Similarly, there is nothing wrong with the following: Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. -- p. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donbyrd at indiana.edu Wed Oct 14 17:17:16 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Wed, 14 Oct 2015 15:17:16 +0000 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. --Don On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" wrote: > > The lack of within is an oversight that can be easily remedied. It will be there in the next release. > > within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. > > I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding > > > > > > > > is short hand for > > > > > > > > and because these attributes are all optional, then there’s nothing inherently wrong with > > > > > > > > The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. > > It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) > > is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. > > -- > p. > > _______________________________________________ > 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 Wed Oct 14 18:42:32 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 14 Oct 2015 18:42:32 +0200 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: Quick question: how would you encode a chord where only some notes have a dot? On Oct 14, 2015 5:17 PM, "Byrd, Donald A." wrote: > I agree: chords themselves are never dotted. Chords containing a mixture > of dotted and undotted notes have been observed in the music of Bartok and > Brahms; they surely occur in other composers. The essential point is that > chords can contain notes with any mixture of durations. > > --Don > > > On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" < > pdr4h at eservices.virginia.edu> > wrote: > > > > > The lack of within is an oversight that can be easily > remedied. It will be there in the next release. > > > > within , however, is a completely different problem. It > seems to me that chords are never dotted, only the notes within them. It > is true that @dots is allowed on , but it was placed there as a > convenience. However, one cannot extrapolate from its existence the need > to allow within . As Jo has already noted, allowing > within introduces unnecessary complexity and ambiguity, so I advise > against that approach. > > > > I’m not trying to re-ignite the recent discussion re: so-called > “invisible accidentals” and its focus on redundancy, but since the > following encoding > > > > > > > > > > > > > > > > is short hand for > > > > > > > > > > > > > > > > and because these attributes are all optional, then there’s nothing > inherently wrong with > > > > > > > > > > > > > > > > The @dur and @dots attributes on are redundant, but allow the > kind of “one stop” rhythmic query Jo is seeking. > > > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the > element, but they serve different purposes -- @dots exists in the > logical domain and exists in the visual one. The element is > providing additional information not communicated by the @dots attribute, > not supplanting it. > > > > It’s often difficult to draw a bright line between the logical and > visual domains. As a general rule, however, when there is only one “source > of information”, such as note/@dots, then it functions in both domains. > The addition of another “source”, such as note/dot, separates the domains. > In other words, the visual domain can often be surmised from the logical, > but making it explicit requires extra information; that is, usually > elements. (BTW, the gestural domain can also be inferred from the > logical/visual, but making it explicit also requires additional > information, usually attributes.) > > > > is permitted inside in order to capture the ambiguous > nature of dots in the mensural repertoire and probably should be disallowed > by the CMN customization. Using layer/dot in this case would be abuse in > my opinion. > > > > -- > > p. > > > > _______________________________________________ > > 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 kepper at edirom.de Wed Oct 14 19:13:18 2015 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 14 Oct 2015 19:13:18 +0200 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: Message-ID: I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper… Just my 2c, jo Am 14.10.2015 um 18:42 schrieb Laurent Pugin : > Quick question: how would you encode a chord where only some notes have a dot? > > On Oct 14, 2015 5:17 PM, "Byrd, Donald A." wrote: > I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. > > --Don > > > On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > wrote: > > > > > The lack of within is an oversight that can be easily remedied. It will be there in the next release. > > > > within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. > > > > I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding > > > > > > > > > > > > > > > > is short hand for > > > > > > > > > > > > > > > > and because these attributes are all optional, then there’s nothing inherently wrong with > > > > > > > > > > > > > > > > The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. > > > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. > > > > It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) > > > > is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. > > > > -- > > p. > > > > _______________________________________________ > > 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 > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From Christine.Siegert at beethoven-haus-bonn.de Thu Oct 15 06:51:56 2015 From: Christine.Siegert at beethoven-haus-bonn.de (Christine Siegert) Date: Thu, 15 Oct 2015 04:51:56 +0000 Subject: [MEI-L] dots on chords and rests In-Reply-To: References: , Message-ID: <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> Dear Johannes and all, looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes. All the best, Christine Prof. Dr. Christine Siegert Leitung Beethoven-Archiv und Verlag Beethoven-Haus Bonn Bonngasse 24-26 D-53111 Bonn Tel.: +49(0)228-98175-22 ________________________________________ Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von "Johannes Kepper [kepper at edirom.de] Gesendet: Mittwoch, 14. Oktober 2015 19:13 An: Music Encoding Initiative Betreff: Re: [MEI-L] dots on chords and rests I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper… Just my 2c, jo Am 14.10.2015 um 18:42 schrieb Laurent Pugin : > Quick question: how would you encode a chord where only some notes have a dot? > > On Oct 14, 2015 5:17 PM, "Byrd, Donald A." wrote: > I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. > > --Don > > > On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > wrote: > > > > > The lack of within is an oversight that can be easily remedied. It will be there in the next release. > > > > within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. > > > > I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding > > > > > > > > > > > > > > > > is short hand for > > > > > > > > > > > > > > > > and because these attributes are all optional, then there’s nothing inherently wrong with > > > > > > > > > > > > > > > > The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. > > > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. > > > > It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) > > > > is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. > > > > -- > > p. > > > > _______________________________________________ > > 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 > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l ***************************************************************** Sonderausstellung im Museum Originalhandschriften Beethovens – vermittelt von Stefan Zweig 13. Mai 2015 bis 17. Oktober 2015 Mehr... ***************************************************************** From kepper at edirom.de Thu Oct 15 17:10:55 2015 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 15 Oct 2015 17:10:55 +0200 Subject: [MEI-L] dots on chords and rests In-Reply-To: <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> References: , <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> Message-ID: <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> Dear all, thanks for the responses. By no means I question that there are chords with insufficient dots for all contained notes. The point is: Are these lacking dots just lacking in the visual domains, but contained in the logical domain (~ intended to be played), or do they really say that the notes should be played with different durations. Especially in manuscripts, I think it is often the first case. However, there are certainly cases when chords intentionally have notes of uneven durations, and they're probably not restricted to printed music. My question is if these chords should be modeled in MEI using the element, or if they should be split up into layers. I know this may result in problems with parallel vs. shared stems, but from a logical point of view, it seems more faithful to me. If you keep different durations inside a chord, it seems unclear to me when following notes should start – after the shortest note in the chord, or after the longest. In essence, this introduces ambiguity in the encoding which normally isn't found in the original. I kind of like Perry's approach to say that the chord's attributes specify the logical duration, while the child notes provide information about the graphical appearance. That way, one can still "calculate" with the duration, while tracking the visuals independently from that. This would even allow to have different durations in chords (even though I still don't like them). My original concern was that querying the duration from the chord element and grandchildren elements seems impractical. If we'd clarify the guidelines in the direction above, I'm happy :-) Johannes Am 15.10.2015 um 06:51 schrieb Christine Siegert : > Dear Johannes and all, > looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes. > All the best, > Christine > > Prof. Dr. Christine Siegert > Leitung Beethoven-Archiv und Verlag > Beethoven-Haus Bonn > Bonngasse 24-26 > D-53111 Bonn > Tel.: +49(0)228-98175-22 > > ________________________________________ > Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von "Johannes Kepper [kepper at edirom.de] > Gesendet: Mittwoch, 14. Oktober 2015 19:13 > An: Music Encoding Initiative > Betreff: Re: [MEI-L] dots on chords and rests > > I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper… > > Just my 2c, > jo > > > Am 14.10.2015 um 18:42 schrieb Laurent Pugin : > >> Quick question: how would you encode a chord where only some notes have a dot? >> >> On Oct 14, 2015 5:17 PM, "Byrd, Donald A." wrote: >> I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. >> >> --Don >> >> >> On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" >> wrote: >> >>> >>> The lack of within is an oversight that can be easily remedied. It will be there in the next release. >>> >>> within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. >>> >>> I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding >>> >>> >>> >>> >>> >>> >>> >>> is short hand for >>> >>> >>> >>> >>> >>> >>> >>> and because these attributes are all optional, then there’s nothing inherently wrong with >>> >>> >>> >>> >>> >>> >>> >>> The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. >>> >>> Similarly, there is nothing wrong with the following: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. >>> >>> It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) >>> >>> is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. >>> >>> -- >>> p. >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > ***************************************************************** > Sonderausstellung im Museum > Originalhandschriften Beethovens – vermittelt von Stefan Zweig > 13. Mai 2015 bis 17. Oktober 2015 > Mehr... > ***************************************************************** > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From donbyrd at indiana.edu Thu Oct 15 20:13:29 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Thu, 15 Oct 2015 18:13:29 +0000 Subject: [MEI-L] dots on chords and rests; chords with notes of differing duration In-Reply-To: <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> References: , <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> Message-ID: <26E15452-50F4-4956-8EB2-ACAFFA58FD1C@indiana.edu> I expanded the subject line because (IMO) the basic issue here has to do with _any_ differing durations; there may or may not not be dotted notes. Good question, Johannes; this is a bit tricky! After looking at a few examples (Mozart, Chopin, Brahms, Amy Beach, Ysaye), I'd say there are three situations. The first is the one you mention, involving dotted and undotted versions of the same duration, where there aren't enough dots for all the notes (generally because of 2nds) but all notes are intended to be played with the same duration. The second situation is where the notes obviously belong to one voice and some really are intended to be sustained longer than others. Every example I've seen in music for strings is like this and is a chord of at least three notes, the obvious reason for the notation being that modern instruments can sustain only two notes. Anyway, the duration of the chord is simply the duration of its longest note. But there's yet another situation, of which the first page of Chopin's "Raindrop" Prelude (in D-flat, Op. 28 no. 15) has many examples; the attached excerpt is from a Universal edition. Here there are clearly two voices, and the longer note(s) (halfs or dotted halfs) are in a different voice from the shorter one(s) (eighths or dotted eighths). Or it might be better to think of the longer notes as "really" hiding eighth-note heads at the same pitch, so there are two notes of the same pitched attacked at the same time. There are two examples of this situation in m. 1. For tbe one on the 2nd beat, the duration of the chord in one voice is a half, while in the other voice it's an eighth. --Don On Oct 15, 2015, at 11:10 AM, Johannes Kepper > wrote: Dear all, thanks for the responses. By no means I question that there are chords with insufficient dots for all contained notes. The point is: Are these lacking dots just lacking in the visual domains, but contained in the logical domain (~ intended to be played), or do they really say that the notes should be played with different durations. Especially in manuscripts, I think it is often the first case. However, there are certainly cases when chords intentionally have notes of uneven durations, and they're probably not restricted to printed music. My question is if these chords should be modeled in MEI using the element, or if they should be split up into layers. I know this may result in problems with parallel vs. shared stems, but from a logical point of view, it seems more faithful to me. If you keep different durations inside a chord, it seems unclear to me when following notes should start – after the shortest note in the chord, or after the longest. In essence, this introduces ambiguity in the encoding which normally isn't found in the original. I kind of like Perry's approach to say that the chord's attributes specify the logical duration, while the child notes provide information about the graphical appearance. That way, one can still "calculate" with the duration, while tracking the visuals independently from that. This would even allow to have different durations in chords (even though I still don't like them). My original concern was that querying the duration from the chord element and grandchildren elements seems impractical. If we'd clarify the guidelines in the direction above, I'm happy :-) Johannes Am 15.10.2015 um 06:51 schrieb Christine Siegert >: Dear Johannes and all, looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes. All the best, Christine Prof. Dr. Christine Siegert Leitung Beethoven-Archiv und Verlag Beethoven-Haus Bonn Bonngasse 24-26 D-53111 Bonn Tel.: +49(0)228-98175-22 ________________________________________ Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von "Johannes Kepper [kepper at edirom.de] Gesendet: Mittwoch, 14. Oktober 2015 19:13 An: Music Encoding Initiative Betreff: Re: [MEI-L] dots on chords and rests I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper… Just my 2c, jo Am 14.10.2015 um 18:42 schrieb Laurent Pugin >: Quick question: how would you encode a chord where only some notes have a dot? On Oct 14, 2015 5:17 PM, "Byrd, Donald A." > wrote: I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. --Don On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > wrote: The lack of within is an oversight that can be easily remedied. It will be there in the next release. within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding is short hand for and because these attributes are all optional, then there’s nothing inherently wrong with The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. Similarly, there is nothing wrong with the following: Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. -- p. _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l ***************************************************************** Sonderausstellung im Museum Originalhandschriften Beethovens – vermittelt von Stefan Zweig 13. Mai 2015 bis 17. Oktober 2015 Mehr... ***************************************************************** _______________________________________________ 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 [cid:AF47F267-9EA0-4D3B-9B05-832E93315F6D] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Chopin_RaindDropPrelude_MultidurChords.png Type: image/png Size: 275461 bytes Desc: Chopin_RaindDropPrelude_MultidurChords.png URL: From pdr4h at eservices.virginia.edu Thu Oct 15 21:44:15 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 15 Oct 2015 19:44:15 +0000 Subject: [MEI-L] dots on chords and rests; chords with notes of differing duration In-Reply-To: <26E15452-50F4-4956-8EB2-ACAFFA58FD1C@indiana.edu> References: , <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> <26E15452-50F4-4956-8EB2-ACAFFA58FD1C@indiana.edu> Message-ID: Hi Don, Thanks for the classification - I think it's dead on. The situation's a little more complex, however, in that we must be mindful of *which* duration we're talking about - logical, visual, or gestural. In any case, MEI can handle all these cases: 1. The differences in "dotted-ness" of the notes is in the visual domain. The key word here is "intended", the scribe just didn't get around to putting in all the dots. In MEI, the omitted dots can be encoded using . In the visual and gestural domains, this is the same as class 2; that is, the chord's duration is the longest of its (dotted) notes. 2. As you say, the duration of the *chord* is often equal to that of the longest note, although I could imagine a situation where the following chord is actually only a quarter note in duration and the half note heads indicate some kind of laissez vibrer indication. In this situation, it's a good idea to state the duration of the chord explicitly. 3. In this case it makes sense to split the "chord" into multiple layers. Unfortunately, the attachment didn't make it through (or perhaps you forgot it), so I'll just make up an example: The visual appearance is / can be the same, but the difference between ex. 1 and ex. 3 is in the intention of the encoder - to explicitly say that there are 2 layers / voices here. This has consequences for the encoding depending on what comes later in the shorter of the two "voices"; that is, whether/how the difference is "made up". If the shorter voice has any material following this chord, say starting on beat 3 in this example, then space has to be inserted to make the 2 layers the same length, or at least, account for beat 2 in layer 2. Jo, would you like to draft an explanation for the Guidelines? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A. Sent: Thursday, October 15, 2015 2:14 PM To: Music Encoding Initiative Subject: Re: [MEI-L] dots on chords and rests; chords with notes of differing duration I expanded the subject line because (IMO) the basic issue here has to do with _any_ differing durations; there may or may not not be dotted notes. Good question, Johannes; this is a bit tricky! After looking at a few examples (Mozart, Chopin, Brahms, Amy Beach, Ysaye), I'd say there are three situations. The first is the one you mention, involving dotted and undotted versions of the same duration, where there aren't enough dots for all the notes (generally because of 2nds) but all notes are intended to be played with the same duration. The second situation is where the notes obviously belong to one voice and some really are intended to be sustained longer than others. Every example I've seen in music for strings is like this and is a chord of at least three notes, the obvious reason for the notation being that modern instruments can sustain only two notes. Anyway, the duration of the chord is simply the duration of its longest note. But there's yet another situation, of which the first page of Chopin's "Raindrop" Prelude (in D-flat, Op. 28 no. 15) has many examples; the attached excerpt is from a Universal edition. Here there are clearly two voices, and the longer note(s) (halfs or dotted halfs) are in a different voice from the shorter one(s) (eighths or dotted eighths). Or it might be better to think of the longer notes as "really" hiding eighth-note heads at the same pitch, so there are two notes of the same pitched attacked at the same time. There are two examples of this situation in m. 1. For tbe one on the 2nd beat, the duration of the chord in one voice is a half, while in the other voice it's an eighth. --Don On Oct 15, 2015, at 11:10 AM, Johannes Kepper > wrote: Dear all, thanks for the responses. By no means I question that there are chords with insufficient dots for all contained notes. The point is: Are these lacking dots just lacking in the visual domains, but contained in the logical domain (~ intended to be played), or do they really say that the notes should be played with different durations. Especially in manuscripts, I think it is often the first case. However, there are certainly cases when chords intentionally have notes of uneven durations, and they're probably not restricted to printed music. My question is if these chords should be modeled in MEI using the element, or if they should be split up into layers. I know this may result in problems with parallel vs. shared stems, but from a logical point of view, it seems more faithful to me. If you keep different durations inside a chord, it seems unclear to me when following notes should start - after the shortest note in the chord, or after the longest. In essence, this introduces ambiguity in the encoding which normally isn't found in the original. I kind of like Perry's approach to say that the chord's attributes specify the logical duration, while the child notes provide information about the graphical appearance. That way, one can still "calculate" with the duration, while tracking the visuals independently from that. This would even allow to have different durations in chords (even though I still don't like them). My original concern was that querying the duration from the chord element and grandchildren elements seems impractical. If we'd clarify the guidelines in the direction above, I'm happy :-) Johannes Am 15.10.2015 um 06:51 schrieb Christine Siegert >: Dear Johannes and all, looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes. All the best, Christine Prof. Dr. Christine Siegert Leitung Beethoven-Archiv und Verlag Beethoven-Haus Bonn Bonngasse 24-26 D-53111 Bonn Tel.: +49(0)228-98175-22 ________________________________________ Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von "Johannes Kepper [kepper at edirom.de] Gesendet: Mittwoch, 14. Oktober 2015 19:13 An: Music Encoding Initiative Betreff: Re: [MEI-L] dots on chords and rests I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper... Just my 2c, jo Am 14.10.2015 um 18:42 schrieb Laurent Pugin >: Quick question: how would you encode a chord where only some notes have a dot? On Oct 14, 2015 5:17 PM, "Byrd, Donald A." > wrote: I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. --Don On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > wrote: The lack of within is an oversight that can be easily remedied. It will be there in the next release. within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. I'm not trying to re-ignite the recent discussion re: so-called "invisible accidentals" and its focus on redundancy, but since the following encoding is short hand for and because these attributes are all optional, then there's nothing inherently wrong with The @dur and @dots attributes on are redundant, but allow the kind of "one stop" rhythmic query Jo is seeking. Similarly, there is nothing wrong with the following: Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. It's often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one "source of information", such as note/@dots, then it functions in both domains. The addition of another "source", such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. -- p. _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l ***************************************************************** Sonderausstellung im Museum Originalhandschriften Beethovens - vermittelt von Stefan Zweig 13. Mai 2015 bis 17. Oktober 2015 Mehr... ***************************************************************** _______________________________________________ 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 [cid:image002.png at 01D10759.84E3F230] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 231866 bytes Desc: image002.png URL: From donbyrd at indiana.edu Thu Oct 15 22:07:06 2015 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Thu, 15 Oct 2015 20:07:06 +0000 Subject: [MEI-L] dots on chords and rests; chords with notes of differing duration In-Reply-To: References: , <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> <26E15452-50F4-4956-8EB2-ACAFFA58FD1C@indiana.edu> Message-ID: Ah yes, we do need to think in terms of the various domains to be clear about all this. Odd you didn't get the attachment; I checked, and this is one of the rare cases where I failed to forget it :-) . Anyway, it's now available at https://drive.google.com/file/d/0B2p91S3Iky-VZ1hkNXl3MzZncnM/view?usp=sharing For case #2, you say "I could imagine a situation where the following chord is actually only a quarter note in duration and the half note heads indicate…" Surely you mean "the following chord is actually only a quarter note LATER"? If so, I've situations -- especially in Chopin -- that could be interpreted this way. In that case, a voice is overlapping with itself in the logical domain: an unpleasant situation, and one that could be avoided here by assuming the presence of an additional voice… But I've also seen (very rarely) situations where I think the most sensible interpretation really is a voice overlapping itself :-| . --DAB On Oct 15, 2015, at 3:44 PM, "Roland, Perry D. (pdr4h)" wrote: > > Hi Don, > > Thanks for the classification – I think it’s dead on. The situation’s a little more complex, however, in that we must be mindful of *which* duration we’re talking about – logical, visual, or gestural. > > In any case, MEI can handle all these cases: > > 1. The differences in “dotted-ness” of the notes is in the visual domain. The key word here is “intended”, the scribe just didn’t get around to putting in all the dots. In MEI, the omitted dots can be encoded using . In the visual and gestural domains, this is the same as class 2; that is, the chord’s duration is the longest of its (dotted) notes. > > > > > > > > > > > > 2. As you say, the duration of the *chord* is often equal to that of the longest note, although I could imagine a situation where the following chord is actually only a quarter note in duration and the half note heads indicate some kind of laissez vibrer indication. In this situation, it’s a good idea to state the duration of the chord explicitly. > > > > > > > > > 3. In this case it makes sense to split the “chord” into multiple layers. Unfortunately, the attachment didn’t make it through (or perhaps you forgot it), so I’ll just make up an example: > > > > > > > > > > > > > > > > > The visual appearance is / can be the same, but the difference between ex. 1 and ex. 3 is in the intention of the encoder – to explicitly say that there are 2 layers / voices here. This has consequences for the encoding depending on what comes later in the shorter of the two “voices”; that is, whether/how the difference is “made up”. If the shorter voice has any material following this chord, say starting on beat 3 in this example, then space has to be inserted to make the 2 layers the same length, or at least, account for beat 2 in layer 2. > > Jo, would you like to draft an explanation for the Guidelines? > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A. > Sent: Thursday, October 15, 2015 2:14 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] dots on chords and rests; chords with notes of differing duration > > I expanded the subject line because (IMO) the basic issue here has to do with _any_ differing durations; there may or may not not be dotted notes. > > Good question, Johannes; this is a bit tricky! After looking at a few examples (Mozart, Chopin, Brahms, Amy Beach, Ysaye), I'd say there are three situations. The first is the one you mention, involving dotted and undotted versions of the same duration, where there aren't enough dots for all the notes (generally because of 2nds) but all notes are intended to be played with the same duration. > > The second situation is where the notes obviously belong to one voice and some really are intended to be sustained longer than others. Every example I've seen in music for strings is like this and is a chord of at least three notes, the obvious reason for the notation being that modern instruments can sustain only two notes. Anyway, the duration of the chord is simply the duration of its longest note. > > But there's yet another situation, of which the first page of Chopin's "Raindrop" Prelude (in D-flat, Op. 28 no. 15) has many examples; the attached excerpt is from a Universal edition. Here there are clearly two voices, and the longer note(s) (halfs or dotted halfs) are in a different voice from the shorter one(s) (eighths or dotted eighths). Or it might be better to think of the longer notes as "really" hiding eighth-note heads at the same pitch, so there are two notes of the same pitched attacked at the same time. There are two examples of this situation in m. 1. For tbe one on the 2nd beat, the duration of the chord in one voice is a half, while in the other voice it's an eighth. > > --Don > > > On Oct 15, 2015, at 11:10 AM, Johannes Kepper wrote: > > > Dear all, > > thanks for the responses. By no means I question that there are chords with insufficient dots for all contained notes. The point is: Are these lacking dots just lacking in the visual domains, but contained in the logical domain (~ intended to be played), or do they really say that the notes should be played with different durations. Especially in manuscripts, I think it is often the first case. However, there are certainly cases when chords intentionally have notes of uneven durations, and they're probably not restricted to printed music. My question is if these chords should be modeled in MEI using the element, or if they should be split up into layers. I know this may result in problems with parallel vs. shared stems, but from a logical point of view, it seems more faithful to me. If you keep different durations inside a chord, it seems unclear to me when following notes should start – after the shortest note in the chord, or after the longest. In essence, this introduces ambiguity in the encoding which normally isn't found in the original. I kind of like Perry's approach to say that the chord's attributes specify the logical duration, while the child notes provide information about the graphical appearance. That way, one can still "calculate" with the duration, while tracking the visuals independently from that. This would even allow to have different durations in chords (even though I still don't like them). > > My original concern was that querying the duration from the chord element and grandchildren elements seems impractical. If we'd clarify the guidelines in the direction above, I'm happy :-) > > Johannes > > > Am 15.10.2015 um 06:51 schrieb Christine Siegert : > > > Dear Johannes and all, > looking at sources from the time of about 1800, I recognize that there are many chords with notes of different durations. I think mainly of conventions of writing music. When a composer is writing a chord, he perhaps has notes of the same duration in mind (not always), but writes perhaps only one or two dots instead of three. As far as I see, these notes have to belong to the same layer. So it seems to me that the dots really are part of the notes. > All the best, > Christine > > Prof. Dr. Christine Siegert > Leitung Beethoven-Archiv und Verlag > Beethoven-Haus Bonn > Bonngasse 24-26 > D-53111 Bonn > Tel.: +49(0)228-98175-22 > > ________________________________________ > Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von "Johannes Kepper [kepper at edirom.de] > Gesendet: Mittwoch, 14. Oktober 2015 19:13 > An: Music Encoding Initiative > Betreff: Re: [MEI-L] dots on chords and rests > > I know this is and endless debate, and eventually, it's just a matter of words, or analytical concepts, but I would always argue that chords in MEI are always constituted by notes of the same duration. Everything else is a matter of splitting things up into layers. This can become quite ugly, as it easily results in a bunch of elements, but I strongly prefer this very strict approach over a loose concept of a chord constituted by arbitrary notes just sharing a stem. Again, I'm talking about how to encode things in MEI. I don't care much how people call these things on paper… > > Just my 2c, > jo > > > Am 14.10.2015 um 18:42 schrieb Laurent Pugin : > > > Quick question: how would you encode a chord where only some notes have a dot? > > On Oct 14, 2015 5:17 PM, "Byrd, Donald A." wrote: > I agree: chords themselves are never dotted. Chords containing a mixture of dotted and undotted notes have been observed in the music of Bartok and Brahms; they surely occur in other composers. The essential point is that chords can contain notes with any mixture of durations. > > --Don > > > On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > wrote: > > > > The lack of within is an oversight that can be easily remedied. It will be there in the next release. > > within , however, is a completely different problem. It seems to me that chords are never dotted, only the notes within them. It is true that @dots is allowed on , but it was placed there as a convenience. However, one cannot extrapolate from its existence the need to allow within . As Jo has already noted, allowing within introduces unnecessary complexity and ambiguity, so I advise against that approach. > > I’m not trying to re-ignite the recent discussion re: so-called “invisible accidentals” and its focus on redundancy, but since the following encoding > > > > > > > > is short hand for > > > > > > > > and because these attributes are all optional, then there’s nothing inherently wrong with > > > > > > > > The @dur and @dots attributes on are redundant, but allow the kind of “one stop” rhythmic query Jo is seeking. > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the element, but they serve different purposes -- @dots exists in the logical domain and exists in the visual one. The element is providing additional information not communicated by the @dots attribute, not supplanting it. > > It’s often difficult to draw a bright line between the logical and visual domains. As a general rule, however, when there is only one “source of information”, such as note/@dots, then it functions in both domains. The addition of another “source”, such as note/dot, separates the domains. In other words, the visual domain can often be surmised from the logical, but making it explicit requires extra information; that is, usually elements. (BTW, the gestural domain can also be inferred from the logical/visual, but making it explicit also requires additional information, usually attributes.) > > is permitted inside in order to capture the ambiguous nature of dots in the mensural repertoire and probably should be disallowed by the CMN customization. Using layer/dot in this case would be abuse in my opinion. > > -- > p. > > > > > > > _______________________________________________ > 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 pdr4h at eservices.virginia.edu Fri Oct 16 17:18:23 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 16 Oct 2015 15:18:23 +0000 Subject: [MEI-L] dots on chords and rests; chords with notes of differing duration In-Reply-To: References: , <5F65EB7AFFDCF5448B5370D5E3678AC68E00BA@WINEXCHNG.lvb.bonn> <7581E3B2-9629-44DD-8336-4E5171224C39@edirom.de> <26E15452-50F4-4956-8EB2-ACAFFA58FD1C@indiana.edu> Message-ID: Thanks for providing the Chopin example. Staff 2 of measure 1 illustrates what I was trying to get at. The 3rd 8th note of the left hand has half-note heads, indicating, as you say, the introduction of an additional voice. But to the naïve encoder (OMR) it could appear to be an 8th note chord with "funny" note heads. So, according to OMR software, the "proper" encoding could be: and, according to a human: In the first encoding, the half notes do indeed cause the voice to "overlap" itself, but this is of no concern to the OMR program. MEI is flexible enough to allow both encodings without privileging one or the other. Both are "correct", depending on the purpose of the encoding. I believe the second one could be derived from the first, permitting a "smartening up" of the OMR results. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Byrd, Donald A. > Sent: Thursday, October 15, 2015 4:07 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] dots on chords and rests; chords with notes of differing > duration > > Ah yes, we do need to think in terms of the various domains to be clear > about all this. > > Odd you didn't get the attachment; I checked, and this is one of the rare > cases where I failed to forget it :-) . Anyway, it's now available at > > https://drive.google.com/file/d/0B2p91S3Iky- > VZ1hkNXl3MzZncnM/view?usp=sharing > > For case #2, you say "I could imagine a situation where the following chord is > actually only a quarter note in duration and the half note heads indicate…" > Surely you mean "the following chord is actually only a quarter note LATER"? > If so, I've situations -- especially in Chopin -- that could be interpreted this > way. In that case, a voice is overlapping with itself in the logical domain: an > unpleasant situation, and one that could be avoided here by assuming the > presence of an additional voice… But I've also seen (very rarely) situations > where I think the most sensible interpretation really is a voice overlapping > itself :-| . > > --DAB > > > On Oct 15, 2015, at 3:44 PM, "Roland, Perry D. (pdr4h)" > wrote: > > > > > Hi Don, > > > > Thanks for the classification – I think it’s dead on. The situation’s a little > more complex, however, in that we must be mindful of *which* duration > we’re talking about – logical, visual, or gestural. > > > > In any case, MEI can handle all these cases: > > > > 1. The differences in “dotted-ness” of the notes is in the visual domain. > The key word here is “intended”, the scribe just didn’t get around to putting > in all the dots. In MEI, the omitted dots can be encoded using . In > the visual and gestural domains, this is the same as class 2; that is, the > chord’s duration is the longest of its (dotted) notes. > > > > > > > > > > > > > > > > > > > > > > > > 2. As you say, the duration of the *chord* is often equal to that of the > longest note, although I could imagine a situation where the following chord > is actually only a quarter note in duration and the half note heads indicate > some kind of laissez vibrer indication. In this situation, it’s a good idea to > state the duration of the chord explicitly. > > > > > > > > > > > > > > > > > > 3. In this case it makes sense to split the “chord” into multiple layers. > Unfortunately, the attachment didn’t make it through (or perhaps you forgot > it), so I’ll just make up an example: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The visual appearance is / can be the same, but the difference between ex. > 1 and ex. 3 is in the intention of the encoder – to explicitly say that there are > 2 layers / voices here. This has consequences for the encoding depending on > what comes later in the shorter of the two “voices”; that is, whether/how the > difference is “made up”. If the shorter voice has any material following this > chord, say starting on beat 3 in this example, then space has to be inserted to > make the 2 layers the same length, or at least, account for beat 2 in layer 2. > > > > Jo, would you like to draft an explanation for the Guidelines? > > > > -- > > p. > > > > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Byrd, Donald A. > > Sent: Thursday, October 15, 2015 2:14 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] dots on chords and rests; chords with notes of > > differing duration > > > > I expanded the subject line because (IMO) the basic issue here has to do > with _any_ differing durations; there may or may not not be dotted notes. > > > > Good question, Johannes; this is a bit tricky! After looking at a few > examples (Mozart, Chopin, Brahms, Amy Beach, Ysaye), I'd say there are > three situations. The first is the one you mention, involving dotted and > undotted versions of the same duration, where there aren't enough dots for > all the notes (generally because of 2nds) but all notes are intended to be > played with the same duration. > > > > The second situation is where the notes obviously belong to one voice and > some really are intended to be sustained longer than others. Every example > I've seen in music for strings is like this and is a chord of at least three notes, > the obvious reason for the notation being that modern instruments can > sustain only two notes. Anyway, the duration of the chord is simply the > duration of its longest note. > > > > But there's yet another situation, of which the first page of Chopin's > "Raindrop" Prelude (in D-flat, Op. 28 no. 15) has many examples; the > attached excerpt is from a Universal edition. Here there are clearly two > voices, and the longer note(s) (halfs or dotted halfs) are in a different voice > from the shorter one(s) (eighths or dotted eighths). Or it might be better to > think of the longer notes as "really" hiding eighth-note heads at the same > pitch, so there are two notes of the same pitched attacked at the same time. > There are two examples of this situation in m. 1. For tbe one on the 2nd > beat, the duration of the chord in one voice is a half, while in the other voice > it's an eighth. > > > > --Don > > > > > > On Oct 15, 2015, at 11:10 AM, Johannes Kepper > wrote: > > > > > > Dear all, > > > > thanks for the responses. By no means I question that there are chords > with insufficient dots for all contained notes. The point is: Are these lacking > dots just lacking in the visual domains, but contained in the logical domain (~ > intended to be played), or do they really say that the notes should be played > with different durations. Especially in manuscripts, I think it is often the first > case. However, there are certainly cases when chords intentionally have > notes of uneven durations, and they're probably not restricted to printed > music. My question is if these chords should be modeled in MEI using the > element, or if they should be split up into layers. I know this may > result in problems with parallel vs. shared stems, but from a logical point of > view, it seems more faithful to me. If you keep different durations inside a > chord, it seems unclear to me when following notes should start – after the > shortest note in the chord, or after the longest. In essence, this introduces > ambiguity in the encoding which normally isn't found in the original. I kind of > like Perry's approach to say that the chord's attributes specify the logical > duration, while the child notes provide information about the graphical > appearance. That way, one can still "calculate" with the duration, while > tracking the visuals independently from that. This would even allow to have > different durations in chords (even though I still don't like them). > > > > My original concern was that querying the duration from the chord > > element and grandchildren elements seems impractical. If we'd > > clarify the guidelines in the direction above, I'm happy :-) > > > > Johannes > > > > > > Am 15.10.2015 um 06:51 schrieb Christine Siegert > : > > > > > > Dear Johannes and all, > > looking at sources from the time of about 1800, I recognize that there are > many chords with notes of different durations. I think mainly of conventions > of writing music. When a composer is writing a chord, he perhaps has notes > of the same duration in mind (not always), but writes perhaps only one or > two dots instead of three. As far as I see, these notes have to belong to the > same layer. So it seems to me that the dots really are part of the notes. > > All the best, > > Christine > > > > Prof. Dr. Christine Siegert > > Leitung Beethoven-Archiv und Verlag > > Beethoven-Haus Bonn > > Bonngasse 24-26 > > D-53111 Bonn > > Tel.: +49(0)228-98175-22 > > > > ________________________________________ > > Von: mei-l [mei-l-bounces at lists.uni-paderborn.de]" im Auftrag von > > "Johannes Kepper [kepper at edirom.de] > > Gesendet: Mittwoch, 14. Oktober 2015 19:13 > > An: Music Encoding Initiative > > Betreff: Re: [MEI-L] dots on chords and rests > > > > I know this is and endless debate, and eventually, it's just a matter > > of words, or analytical concepts, but I would always argue that chords > > in MEI are always constituted by notes of the same duration. > > Everything else is a matter of splitting things up into layers. This > > can become quite ugly, as it easily results in a bunch of > > elements, but I strongly prefer this very strict approach over a loose > > concept of a chord constituted by arbitrary notes just sharing a stem. > > Again, I'm talking about how to encode things in MEI. I don't care > > much how people call these things on paper… > > > > Just my 2c, > > jo > > > > > > Am 14.10.2015 um 18:42 schrieb Laurent Pugin : > > > > > > Quick question: how would you encode a chord where only some notes > have a dot? > > > > On Oct 14, 2015 5:17 PM, "Byrd, Donald A." > wrote: > > I agree: chords themselves are never dotted. Chords containing a mixture > of dotted and undotted notes have been observed in the music of Bartok and > Brahms; they surely occur in other composers. The essential point is that > chords can contain notes with any mixture of durations. > > > > --Don > > > > > > On Oct 14, 2015, at 10:30 AM, "Roland, Perry D. (pdr4h)" > > > > wrote: > > > > > > > > The lack of within is an oversight that can be easily remedied. > It will be there in the next release. > > > > within , however, is a completely different problem. It > seems to me that chords are never dotted, only the notes within them. It is > true that @dots is allowed on , but it was placed there as a > convenience. However, one cannot extrapolate from its existence the need > to allow within . As Jo has already noted, allowing > within introduces unnecessary complexity and ambiguity, so I advise > against that approach. > > > > I’m not trying to re-ignite the recent discussion re: so-called > > “invisible accidentals” and its focus on redundancy, but since the > > following encoding > > > > > > > > > > > > > > > > is short hand for > > > > > > > > > > > > > > > > and because these attributes are all optional, then there’s nothing > > inherently wrong with > > > > > > > > > > > > > > > > The @dur and @dots attributes on are redundant, but allow the > kind of “one stop” rhythmic query Jo is seeking. > > > > Similarly, there is nothing wrong with the following: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Again, there is redundancy between the @dots attribute on and the > element, but they serve different purposes -- @dots exists in the > logical domain and exists in the visual one. The element is > providing additional information not communicated by the @dots attribute, > not supplanting it. > > > > It’s often difficult to draw a bright line between the logical and > > visual domains. As a general rule, however, when there is only one > > “source of information”, such as note/@dots, then it functions in both > > domains. The addition of another “source”, such as note/dot, > > separates the domains. In other words, the visual domain can often be > > surmised from the logical, but making it explicit requires extra > > information; that is, usually elements. (BTW, the gestural domain can > > also be inferred from the logical/visual, but making it explicit also > > requires additional information, usually attributes.) > > > > is permitted inside in order to capture the ambiguous nature > of dots in the mensural repertoire and probably should be disallowed by the > CMN customization. Using layer/dot in this case would be abuse in my > opinion. > > > > -- > > p. > > > > > > > > > > > > > > _______________________________________________ > > 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 From esfield at stanford.edu Sun Oct 18 06:15:14 2015 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Sun, 18 Oct 2015 04:15:14 +0000 Subject: [MEI-L] Digital Resources for Musicology Message-ID: CCARH is pleased to announce version 1.0 of the weblink tool Digital Resources for Musicology (DRM), which can be found at http://drm.ccarh.org You can help develop this tool by using the "Submit" button at the top of the page. Other comments are welcome. Eleanor Selfridge-Field Consulting Professor, Music 541 Lasuen Mall Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA esfield at stanford.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From atge at kb.dk Wed Oct 21 10:01:53 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 21 Oct 2015 08:01:53 +0000 Subject: [MEI-L] Instrument settings and tunings Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3C00@EXCHANGE-02.kb.dk> Dear list I have a couple of questions related to the recent discussion about the model for describing instrumentations in . Sometimes I need to add more detailed information to an instrument's name, such as transposition or tuning. I simply write this information into , like Clarinet (A) Timpani (C, G) Of course I can add more complex information too: the settings for a prepared piano or electronic instruments; scordatura; or even organ registrations (if they remain the same throughout the piece). My first question is: Is it acceptable to have a rather detailed text within (or , if we decide to rename it), or should we have some other place for a detailed description of settings/tunings/transpositions? My other question is: how would this kind of information be encoded in the score? I know about the transposition attributes on , of course; the timpani case is trivial too. But I wouldn't know how to encode things like organ registrations, scordatura, electronic instruments settings within . Plain text? Or are there some special element for instrument settings? I could also put it this way: Are these settings simply to be regarded as playing techniques like pizzicato or col legno (which I don't know how to encode either, however...)? Best, Axel [http://support.kb.dk/images/kb_logo.jpg] Det Kongelige Bibliotek Nationalbibliotek og Københavns Universitetsbibliotek Axel Teich Geertinger Centerleder | Head of Centre Det Kongelige Bibliotek | The Royal Library Dansk Center for Musikudgivelse | Danish Centre for Music Publication P.O. Box 2149 | DK-1016 København K tel +45 9132 4706 | Fax +45 3393 2218 | atge at kb.dk | www.kb.dk Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1 Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 København K EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42 IBAN DK2002164069032583 | Swiftcode DABADKKK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14433 bytes Desc: image001.jpg URL: From richard at rjlewis.me.uk Wed Oct 21 12:29:19 2015 From: richard at rjlewis.me.uk (Richard Lewis) Date: Wed, 21 Oct 2015 11:29:19 +0100 Subject: [MEI-L] Instrument settings and tunings In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3C00@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3C00@EXCHANGE-02.kb.dk> Message-ID: <87bnbsh5vk.wl-richard@rjlewis.me.uk> Dear Axel, We did some work on the problem of encoding instrument configurations earlier this year. We actually came up with a customisation which is published on github: , specifically, . We took the approach of extending to include and elements. The allows a more structured description of an instrument, while is intended for instrument-specific set up. In our specific case we then provided a further customisation for lute tablature which extended to allow elements for describing the tunings of the courses. Our intention was that this generic provision could be extended for exactly the kinds of things you describe: organ registrations, electronic instruments. We didn't make any provision for your second requirement, however, that of changes of instrument configuration during the course of a piece. We presented this at MEC 2015 but since then we haven't really revised it. I think it's still quite experimental and really could do with some more testing and criticism. Best, Richard On Wed, 21 Oct 2015 09:01:53 +0100, Axel Teich Geertinger wrote: > > Dear list > > I have a couple of questions related to the recent discussion about > the model for describing instrumentations in . Sometimes > I need to add more detailed information to an instrument's name, > such as transposition or tuning. I simply write this information > into , like > > Clarinet (A) > Timpani (C, G) > > Of course I can add more complex information too: the settings for a > prepared piano or electronic instruments; scordatura; or even organ > registrations (if they remain the same throughout the piece). > My first question is: Is it acceptable to have a rather detailed > text within (or , if we decide to rename it), > or should we have some other place for a detailed description of > settings/tunings/transpositions? > > My other question is: how would this kind of information be encoded > in the score? I know about the transposition attributes on > , of course; the timpani case is trivial too. But I > wouldn't know how to encode things like organ registrations, > scordatura, electronic instruments settings within . Plain > text? Or are there some special element for instrument settings? > I could also put it this way: Are these settings simply to be > regarded as playing techniques like pizzicato or col legno (which I > don't know how to encode either, however...)? > > Best, > Axel -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From atge at kb.dk Wed Oct 21 14:12:10 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Wed, 21 Oct 2015 12:12:10 +0000 Subject: [MEI-L] Instrument settings and tunings In-Reply-To: <87bnbsh5vk.wl-richard@rjlewis.me.uk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3C00@EXCHANGE-02.kb.dk> <87bnbsh5vk.wl-richard@rjlewis.me.uk> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3D84@EXCHANGE-02.kb.dk> Hi Richard Oh yes, now I remember! I am sorry! I was actually there to see your presentation, but the question had not occurred to me at that point :-) Could you post a few examples here on the list for illustration and further discussion? I see in your customisation that you can also have an element inside . Do you have an example showing your use of along with other content in ? What values do you give the @family attribute in ? Is there a danger of doubling or conflicting information given in @code on ? Best wishes, Axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Richard Lewis Sendt: 21. oktober 2015 12:29 Til: Music Encoding Initiative Emne: Re: [MEI-L] Instrument settings and tunings Dear Axel, We did some work on the problem of encoding instrument configurations earlier this year. We actually came up with a customisation which is published on github: , specifically, . We took the approach of extending to include and elements. The allows a more structured description of an instrument, while is intended for instrument-specific set up. In our specific case we then provided a further customisation for lute tablature which extended to allow elements for describing the tunings of the courses. Our intention was that this generic provision could be extended for exactly the kinds of things you describe: organ registrations, electronic instruments. We didn't make any provision for your second requirement, however, that of changes of instrument configuration during the course of a piece. We presented this at MEC 2015 but since then we haven't really revised it. I think it's still quite experimental and really could do with some more testing and criticism. Best, Richard On Wed, 21 Oct 2015 09:01:53 +0100, Axel Teich Geertinger wrote: > > Dear list > > I have a couple of questions related to the recent discussion about > the model for describing instrumentations in . Sometimes I > need to add more detailed information to an instrument's name, such as > transposition or tuning. I simply write this information into > , like > > Clarinet (A) > Timpani (C, G) > > Of course I can add more complex information too: the settings for a > prepared piano or electronic instruments; scordatura; or even organ > registrations (if they remain the same throughout the piece). > My first question is: Is it acceptable to have a rather detailed text > within (or , if we decide to rename it), or > should we have some other place for a detailed description of > settings/tunings/transpositions? > > My other question is: how would this kind of information be encoded in > the score? I know about the transposition attributes on , of > course; the timpani case is trivial too. But I wouldn't know how to > encode things like organ registrations, scordatura, electronic > instruments settings within . Plain text? Or are there some > special element for instrument settings? > I could also put it this way: Are these settings simply to be regarded > as playing techniques like pizzicato or col legno (which I don't know > how to encode either, however...)? > > Best, > Axel -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ 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 Sun Oct 25 21:23:52 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Sun, 25 Oct 2015 20:23:52 +0000 Subject: [MEI-L]
in header Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Sun Oct 25 23:00:38 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Sun, 25 Oct 2015 15:00:38 -0700 Subject: [MEI-L]
in header In-Reply-To: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> Message-ID: Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew > On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger wrote: > > Hi > > Is there any particular reason why
elements are not allowed anywhere in the header? > I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. > > I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? > > Best, > Axel > > _______________________________________________ > 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 Mon Oct 26 12:48:01 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Mon, 26 Oct 2015 11:48:01 +0000 Subject: [MEI-L]
in header In-Reply-To: References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk>, Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk> Hi Andrew I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
(division) – Major structural division of text, such as a preface, chapter or section. This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 25. oktober 2015 23:00 Til: Music Encoding Initiative Emne: Re: [MEI-L]

in header Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel _______________________________________________ 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 andrew.hankinson at mail.mcgill.ca Mon Oct 26 17:12:07 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 26 Oct 2015 09:12:07 -0700 Subject: [MEI-L]
in header In-Reply-To: <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk> References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk> Message-ID: <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca> > On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger wrote: > > Hi Andrew > > I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it. > We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "" section. Holding rendering information in the header seems like a recipe for confusion. > But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say: >
(division) – Major structural division of text, such as a preface, chapter or section. > This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Yes, this is problematic. Personally, I would like to see

take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." -Andrew > > Best, > Axel > > > > Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sendt: 25. oktober 2015 23:00 > Til: Music Encoding Initiative > Emne: Re: [MEI-L]
in header > > Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. > > This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 > > -Andrew > >> On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: >> >> Hi >> >> Is there any particular reason why
elements are not allowed anywhere in the header? >> I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. >> >> I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? >> >> Best, >> Axel >> >> _______________________________________________ >> 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 jiobal at yahoo.de Wed Oct 28 13:01:22 2015 From: jiobal at yahoo.de (Beatrix Obal) Date: Wed, 28 Oct 2015 12:01:22 +0000 (UTC) Subject: [MEI-L] Sibelius to MEI 2.0 Beta In-Reply-To: <4973229E-9665-4D1B-A82D-03A94BF81B61@gmail.com> References: <4973229E-9665-4D1B-A82D-03A94BF81B61@gmail.com> Message-ID: <1099794954.6300688.1446033682789.JavaMail.yahoo@mail.yahoo.com> Lieber Hansjörg, ich weiß nicht, ob Du Dich im Moment noch mit Fragen digitaler Edition beschäftigst; dieser Link könnte aber unter Umständen für Dich interessant sein. viele liebe GrüßeBeatrix Von: Andrew Hankinson An: mei-l at lists.uni-paderborn.de Gesendet: 19:18 Samstag, 10.Oktober 2015 Betreff: [MEI-L] Sibelius to MEI 2.0 Beta Hi everyone, I've been putting the finishing touches on a rewrite of the Sibelius to MEI plugin. Today, I'm sending around a preview release of it, to help me shake out any remaining bugs or missing features. So, if you use it or would like to use it, here's your chance to get your favourite feature in! You can download the files here: https://github.com/music-encoding/sibmei/releases/tag/2.0.0-beta Please read the release notes for any 'gotchas.' It's important to note that I'm aiming to support the upcoming MEI 3.0.0 release.  For those who are interested, here is a list of some of the changes that are in this release.  - Switched to using the `plgToMSS` framework by Tido (Thanks Zoltan & crew, you're awesome!)  - Re-organized the code base so that it wasn't just one big loop that did everything  - Also switched to using the `sib-test` plugin and wrote lots of unit tests (again, Tido: thanks!)  - Visible/invisible accidentals are more reliably determined  - Placement of 'spanners' (ties, slurs, cresc., decresc., etc.) are now fairly reliably attached to their note objects  - Support for many new symbols If you notice any problems, please open an issue on the GitHub page. I think you can also attach .mei and .sib files, which would both be helpful for me tracking down problems. Thanks, -Andrew _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From kelnreiter at mozarteum.at Thu Oct 29 19:53:19 2015 From: kelnreiter at mozarteum.at (Franz Kelnreiter) Date: Thu, 29 Oct 2015 19:53:19 +0100 Subject: [MEI-L] Proposals for MEC 2016 Message-ID: <56326B1F.7050507@mozarteum.at> Dear colleagues, This is just a friendly reminder that the deadline for your submissions for the Music Encoding Conference 2016 will run out on Saturday 31 October at 11:59 EST. Please keep in mind to submit your proposals on https://www.conftool.net/music-encoding2016/ in time. For further informations please consult the conference site on http://music-encoding.org/community/conference/call-for-proposals/ With best wishes, --franz -- Franz Kelnreiter Mozart-Institut/ Digitale Mozart-Edition Internationale Stiftung Mozarteum Schwarzstr. 26 5020 Salzburg, Austria T +43 (0) 662 889 40 69 F +43 (0) 662 889 40 68 E kelnreiter at mozarteum.at www.mozarteum.at - http://dme.mozarteum.at Newsletter Stiftung Mozarteum Facebook Stiftung Mozarteum ZVR: 438729131, UID: ATU33977907 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x16DA0218.asc Type: application/pgp-keys Size: 1718 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Thu Oct 29 20:55:08 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 29 Oct 2015 19:55:08 +0000 Subject: [MEI-L]
in header In-Reply-To: <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca> References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk>, <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca> Message-ID: The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that
is to be used in *the text*. That is,
is available for text within the , but not in the header. I'd be grateful for suggestions for improving the definition so it's more clear. Structuring metadata above the paragraph level is the function of the various metadata elements themselves. Allowing the recursively nest-able
element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible. Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a
, such as

or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text. Renditional info in the header is also strictly at the phrase level, when for instance is permitted within and to accommodate typographical features like superscripts and subscripts. I think

already is aligned with its counterpart in HTML. That's another reason why it isn't allowed within the header. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, October 26, 2015 12:12 PM To: Music Encoding Initiative Subject: Re: [MEI-L]
in header On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger > wrote: Hi Andrew I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it. We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "" section. Holding rendering information in the header seems like a recipe for confusion. But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
(division) – Major structural division of text, such as a preface, chapter or section. This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Yes, this is problematic. Personally, I would like to see

take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." -Andrew Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 25. oktober 2015 23:00 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel _______________________________________________ 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 atge at kb.dk Fri Oct 30 10:36:09 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 30 Oct 2015 09:36:09 +0000 Subject: [MEI-L]
in header In-Reply-To: References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk>, <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca>, Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE7F9E@EXCHANGE-02.kb.dk> Hi Perry & Andrew Thanks for clarifying this for me. I understand what you mean. Perry, I think your distinction between "text" and "the text" is an important one which perhaps could make the guidelines clearer on this point. I clearly wanted to wrap text, but not "the (document) text". What causes me headache are header elements that may contain both "structural" or "data-like" as you say, and "text-level" elements. for instance has children like and (structural) and

(text). If only these elements had a "structural" element to wrap the text-like parts, they would be much easier for me to handle. It wouldn't have to be

, which I now understand; we could invent a new one or perhaps use / (though that may possibly require a somewhat broader description of ; the guidelines say that it "collects any notes providing information about a text additional to that recorded in other parts of the bibliographic description"). As I said, I can work around the issue, so it's not a matter of great importance to me. But perhaps it may be worth considering. Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 29. oktober 2015 20:55 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that
is to be used in *the text*. That is,
is available for text within the , but not in the header. I'd be grateful for suggestions for improving the definition so it's more clear. Structuring metadata above the paragraph level is the function of the various metadata elements themselves. Allowing the recursively nest-able
element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible. Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a
, such as

or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text. Renditional info in the header is also strictly at the phrase level, when for instance is permitted within and to accommodate typographical features like superscripts and subscripts. I think

already is aligned with its counterpart in HTML. That's another reason why it isn't allowed within the header. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, October 26, 2015 12:12 PM To: Music Encoding Initiative Subject: Re: [MEI-L]
in header On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger > wrote: Hi Andrew I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it. We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "" section. Holding rendering information in the header seems like a recipe for confusion. But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
(division) – Major structural division of text, such as a preface, chapter or section. This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Yes, this is problematic. Personally, I would like to see

take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." -Andrew Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 25. oktober 2015 23:00 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel _______________________________________________ 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 Fri Oct 30 15:03:02 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 30 Oct 2015 14:03:02 +0000 Subject: [MEI-L]
in header In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE7F9E@EXCHANGE-02.kb.dk> References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk>, <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca>, , <0B6F63F59F405E4C902DFE2C2329D0D1013DEE7F9E@EXCHANGE-02.kb.dk> Message-ID: The model of is which, I believe, clearly separates its content into data-centric (creation) and free-form (eventList and p) components. contains information about the place and date of creation of the text in a fairly rigid way while the and

group offers a wider range of possibilities. I don't think there's a need to wrap the eventList/p constellation because they're already cleanly separated from by the order of the model components. It seems to me that there's little benefit in introducing another level of hierarchy in the markup. But, I've been wrong before and I'm always willing to be convinced. :-) I'd prefer *not* to use

, but wouldn't object to wrapping and

if a suitable name can be found soon. Since we're breaking backward compatibility with the next release, it would be better to make this change sooner than later. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Friday, October 30, 2015 5:36 AM To: Music Encoding Initiative Subject: Re: [MEI-L]

in header Hi Perry & Andrew Thanks for clarifying this for me. I understand what you mean. Perry, I think your distinction between "text" and "the text" is an important one which perhaps could make the guidelines clearer on this point. I clearly wanted to wrap text, but not "the (document) text". What causes me headache are header elements that may contain both "structural" or "data-like" as you say, and "text-level" elements. for instance has children like and (structural) and

(text). If only these elements had a "structural" element to wrap the text-like parts, they would be much easier for me to handle. It wouldn't have to be

, which I now understand; we could invent a new one or perhaps use / (though that may possibly require a somewhat broader description of ; the guidelines say that it "collects any notes providing information about a text additional to that recorded in other parts of the bibliographic description"). As I said, I can work around the issue, so it's not a matter of great importance to me. But perhaps it may be worth considering. Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 29. oktober 2015 20:55 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that
is to be used in *the text*. That is,
is available for text within the , but not in the header. I'd be grateful for suggestions for improving the definition so it's more clear. Structuring metadata above the paragraph level is the function of the various metadata elements themselves. Allowing the recursively nest-able
element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible. Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a
, such as

or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text. Renditional info in the header is also strictly at the phrase level, when for instance is permitted within and to accommodate typographical features like superscripts and subscripts. I think

already is aligned with its counterpart in HTML. That's another reason why it isn't allowed within the header. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, October 26, 2015 12:12 PM To: Music Encoding Initiative Subject: Re: [MEI-L]
in header On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger > wrote: Hi Andrew I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it. We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "" section. Holding rendering information in the header seems like a recipe for confusion. But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
(division) – Major structural division of text, such as a preface, chapter or section. This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Yes, this is problematic. Personally, I would like to see

take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." -Andrew Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 25. oktober 2015 23:00 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel _______________________________________________ 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 atge at kb.dk Fri Oct 30 16:25:01 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 30 Oct 2015 15:25:01 +0000 Subject: [MEI-L]
in header In-Reply-To: References: <28990_1445804655_562D3A6F_28990_47_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5278@EXCHANGE-02.kb.dk> <28371_1445860113_562E1310_28371_400_1_0B6F63F59F405E4C902DFE2C2329D0D1013DEE5696@EXCHANGE-02.kb.dk>, <86EAD1B2-426F-43B7-8763-B3D8F7E22DE9@mail.mcgill.ca>, , <0B6F63F59F405E4C902DFE2C2329D0D1013DEE7F9E@EXCHANGE-02.kb.dk>, Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE80DA@EXCHANGE-02.kb.dk> I meant of course, not :-) Personally, I prefer using rather data-like, but I am aware that it may used in a more loosely-structured manner. O course things are separated as they are; it's just that there isn't a single node I can select to get all the text contained in

elements, which is what I need in order to edit them in a Rich Text Editor. Anyway, let's just leave it as it is; my workaround seems to do the trick. /axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 30. oktober 2015 15:03 Til: Music Encoding Initiative Emne: Re: [MEI-L]

in header The model of is which, I believe, clearly separates its content into data-centric (creation) and free-form (eventList and p) components. contains information about the place and date of creation of the text in a fairly rigid way while the and

group offers a wider range of possibilities. I don't think there's a need to wrap the eventList/p constellation because they're already cleanly separated from by the order of the model components. It seems to me that there's little benefit in introducing another level of hierarchy in the markup. But, I've been wrong before and I'm always willing to be convinced. :-) I'd prefer *not* to use

, but wouldn't object to wrapping and

if a suitable name can be found soon. Since we're breaking backward compatibility with the next release, it would be better to make this change sooner than later. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Friday, October 30, 2015 5:36 AM To: Music Encoding Initiative Subject: Re: [MEI-L]

in header Hi Perry & Andrew Thanks for clarifying this for me. I understand what you mean. Perry, I think your distinction between "text" and "the text" is an important one which perhaps could make the guidelines clearer on this point. I clearly wanted to wrap text, but not "the (document) text". What causes me headache are header elements that may contain both "structural" or "data-like" as you say, and "text-level" elements. for instance has children like and (structural) and

(text). If only these elements had a "structural" element to wrap the text-like parts, they would be much easier for me to handle. It wouldn't have to be

, which I now understand; we could invent a new one or perhaps use / (though that may possibly require a somewhat broader description of ; the guidelines say that it "collects any notes providing information about a text additional to that recorded in other parts of the bibliographic description"). As I said, I can work around the issue, so it's not a matter of great importance to me. But perhaps it may be worth considering. Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu] Sendt: 29. oktober 2015 20:55 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that
is to be used in *the text*. That is,
is available for text within the , but not in the header. I'd be grateful for suggestions for improving the definition so it's more clear. Structuring metadata above the paragraph level is the function of the various metadata elements themselves. Allowing the recursively nest-able
element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible. Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a
, such as

or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text. Renditional info in the header is also strictly at the phrase level, when for instance is permitted within and to accommodate typographical features like superscripts and subscripts. I think

already is aligned with its counterpart in HTML. That's another reason why it isn't allowed within the header. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, October 26, 2015 12:12 PM To: Music Encoding Initiative Subject: Re: [MEI-L]
in header On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger > wrote: Hi Andrew I can do a workaround by wrapping the contents in a
before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page. I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it. We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within

such as font style, size, and color, so header content may already contain some rendering information. I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "" section. Holding rendering information in the header seems like a recipe for confusion. But more important, I do not see why

should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
(division) – Major structural division of text, such as a preface, chapter or section. This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than

. Yes, this is problematic. Personally, I would like to see

take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." -Andrew Best, Axel ________________________________ Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sendt: 25. oktober 2015 23:00 Til: Music Encoding Initiative Emne: Re: [MEI-L]
in header Personally, I think of
being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly. This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272 -Andrew On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger > wrote: Hi Is there any particular reason why
elements are not allowed anywhere in the header? I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in or within . This type of editor requires that the editable content is wrapped in a single element (like

or

). It is not good at handling mixed content. Of course i could use

as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text. I actually think that allowing

in could also make the structure a little clearer. As it is, may contain , , and any number of

s. Perhaps it would be nice to be able to wrap all non-structured text in a single

to separate it from the more structured elements and ? Best, Axel _______________________________________________ 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 Wed Nov 4 15:39:17 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 4 Nov 2015 14:39:17 +0000 Subject: [MEI-L] TEI Facsimile Oxygen XML Editor Plugin Message-ID: Hello everyone, Perhaps some of you were already aware of this tool, but this is the first time I've heard of it. It seems like it ought to be adaptable to MEI facsimile work, but I don't have any idea where to begin. Does anyone on the list have experience with oXygen plugins? -- p. > -----Original Message----- > From: TEI (Text Encoding Initiative) public discussion list [mailto:TEI- > L at LISTSERV.BROWN.EDU] On Behalf Of TEI-L automatic digest system > Sent: Wednesday, November 04, 2015 12:03 AM > To: TEI-L at LISTSERV.BROWN.EDU > Subject: TEI-L Digest - 2 Nov 2015 to 3 Nov 2015 (#2015-225) > > There is 1 message totaling 453 lines in this issue. > > Topics of the day: > > 1. TEI Facsimile Oxygen XML Editor Plugin > > ---------------------------------------------------------------------- > > Date: Tue, 3 Nov 2015 16:28:57 +0200 > From: Alex Jitianu > Subject: Re: TEI Facsimile Oxygen XML Editor Plugin > > Dear all, > > I just want to let you know that the TEI facsimile plugin for Oxygen has a few > new features. For those of you that are working with TEI digital facsimiles > and might be interested in the plugin, the improvements can grouped in a > few categories: > > 1. More flexibility in adding zones/rectangles (for example when using large > images) > - there is now Zoom support. There are buttons on the toolbar and you can > also press CTRL and use the mouse scroll wheel. > - a rectangle/zone can be resized. It means that you can grab an existing > rectangle by one of its corners and resize it. > - you can duplicate an existing rectangle (there is a Duplicate action in the > contextual menu presented over a rectangle, in the view) > > 2. A seamless integration between the document and the view > - for every new rectangle drawn in the view, a new element will be > automatically inserted in the document. > - for every rectangle resized in the view, the corresponding element > will be automatically updated in the document. > - every change in the document will determine the view to automatically > reload all the zones > > 3. Linking a zone with existing transcribed text elements There is a > *Copy/Generate ID* action in the contextual menu presented for an area (in > the image view). What this action does is: > 1. if the zone doesn't have an ID it will generate one. The pattern is read > from the configuration file *etc/id_pattern.txt* and it accepts Oxygen editor > variables. > 2. copy /#id/ to clipboard > The idea is that after invoking this action you will go on an element and just > paste the value inside an @facs. > > A quick way to install the plugin is to unzip the archive from the URL below > inside {oXygenInstallDir}/plugins > > https://github.com/oxygenxml/TEI-Facsimile- > Plugin/blob/master/builds/image-markup-plugin-1.0.0-SNAPSHOT- > plugin.zip?raw=true > > Make sure to remove any previous version of the plugin and not to create > any additional directories when unzipping. The file system should look like > this: > {oxygenInstallDir} > --plugins > ----image-markup-plugin-1.0.0-SNAPSHOT > ------plugin.xml > > Thank you all again for your feedback! > > Best regards, > Alex > -- > Alex Jitianu > XML Editor, Schema Editor and XSLT Editor/Debugger > http://www.oxygenxml.com > > On 1/20/2015 9:33 AM, Alex Jitianu wrote: > > Hello, > > > > Matthew, I am aware that the synchronization between the view and the > > editor is far from perfect. The main issue in that regards is that the > > view doesn't automatically pick up the changes from the editor. I'll > > have to think on a solution on that so I will add an issue on the GIT > > project to tackle this issue. A second issue would be about > > automatically scrolling when you are drawing a rectangle. The fact > > that the view doesn't pick up the zone elements from your file also > > needs investigation. Can you send me the file for debugging? Or you > > could add an issue yourself on the GIT project [1]. > > > > Immanuel, I think I got the the general idea but it would be great if > > you could also send me a sample file. I don't work with TEI on a daily > > basis and sometimes I get lost in all the specific terms and concepts. > > > > [1] https://github.com/oxygenxml/TEI-Facsimile-Plugin > > > > Best regards, > > Alex > > -- > > Alex Jitianu > > XML Editor, Schema Editor and XSLT Editor/Debugger > > http://www.oxygenxml.com > > > > On 1/16/2015 7:44 PM, Matthew Davis wrote: > >> That would be a useful solution. Playing around with the tool there > >> are two issues I’m seeing: first, that there’s no way to draw a > >> bounding box around a large zone when the image file is larger than > >> the screen. While that’s not something that’s likely to happen > >> often, it would be useful to have that functionality. Second (and > >> potentially something that may be a bug in terms of the described > >> functionality in README.md: I do not get any zones in my image files > >> on load, and when I reload the image after creating one that zone’s > >> bounding box disappears on the image (but not in the xml code if I’ve > >> pasted the zone in, obviously). > >> > >> All best, > >> —Matt > >> > >>> On Jan 16, 2015, at 10:59 AM, Immanuel Normann > >>> wrote: > >>> > >>> Hello oXygen team, > >>> > >>> we have just played a bit with your plugin - it really looks very > >>> promising! For whom text-image-linking is a central task having this > >>> feature integrated in a single tool - oxygen - would make life much > >>> easier! > >>> > >>> Yet, the tool probably needs some twaeks to become a real productive > >>> tool in some scenarios. The scenario I have in mind is this: you > >>> already have a TEI-document, i.e. all the zones and lines are > >>> already present, but you have to link the existing zones or lines to > >>> rectangles in the facsimile. If you want to link within a zone a > >>> sequence of lines in the facsimile to their counterparts in TEI it > >>> would be very convenient to do so just be clicking for each line in > >>> the facsimilie on the base line. The system should be intelligent > >>> enough (without image analysis) to choose the suitable length for > >>> the line rectangle (namely like the width of the parent zone) and a > >>> reasonable line height. Having this feature would mean one click per > >>> line for the text-image-link. Whereas in the current plugin linking > >>> a single line are many more steps: 1) click for the upper left > >>> corner of the rectangular, 2) drag for the bottom right corner, 3) > >>> right click for context menu, 4) click to choose "copy" in the > >>> context menu 5) switching the view from image to xml-file and 6) > >>> pasting the line-element. That means 6 times as many interaction as > >>> necessary for the given scenario. If there were the one-click > >>> solution as mentioned above then the plugin would be the first > >>> choice for text-image-linking. It isn't yet, but it may become > >>> without too much development effort. > >>> > >>> Best regards, > >>> Immanuel > >>> > >>> > >>> Am 12/17/2014 um 09:14 AM schrieb Radu Coravu: > >>>> Hello, > >>>> > >>>> At the DIXIT camp that took place in Gratz, Alex Jitianu (a lead > >>>> developer from Oxygen XML Editor) had a presentation on how to > >>>> develop Oxygen plugins for TEI. The sample plugin that we presented > >>>> was intended to help people working with TEI digital facsimiles. > >>>> The idea was to offer a side view in which an user could load an > >>>> image and: > >>>> - see the marked areas (all the zone elements from a TEI document) > >>>> - draw new areas over the image and copy them into the editor > >>>> > >>>> The reason for this email is that we published the source code of > >>>> that plugin as open source on Git. Since the time we presented it > >>>> we did manage to work a little more on it (mainly suggestions > >>>> received from the DIXIT audience) but there are still a lot of > >>>> things to improve. If anyone is interested in testing it (and > >>>> giving us feedback on what it could be improved) or contributing to > >>>> it (it will require Java skills), here is the link from where you > >>>> can get it: > >>>> > >>>> https://github.com/oxygenxml/TEI-Facsimile-Plugin > >>>> > >>>> The README.md file should provide instructions on how to install > >>>> and use the plugin. The plugin is compatible with Oxygen version 15 > >>>> or later. > >>>> > >>>> We look forward for any feedback you may have. > >>>> > >>>> Regards, > >>>> Radu > >>>> > >>>> Radu Coravu > >>>> XML Editor, Schema Editor and XSLT Editor/Debugger > >>>> http://www.oxygenxml.com > > > > ------------------------------ > > End of TEI-L Digest - 2 Nov 2015 to 3 Nov 2015 (#2015-225) > ********************************************************** From fober at grame.fr Fri Nov 6 14:05:20 2015 From: fober at grame.fr (Dominique Fober) Date: Fri, 6 Nov 2015 14:05:20 +0100 Subject: [MEI-L] TENOR 2016 - Deadline reminder Message-ID: <417B71D0-EC3C-4FCE-944C-A7E5BAC0489E@grame.fr> [Apologies for cross postings] [Please distribute] TENOR 2016 International Conference on New Technologies for Music Notation and Representation FINAL CALL FOR PAPERS The deadline for receipt of papers is Monday November 16th 2015 midnight GMT. For any question, please contact : tenor2016[at]tenor-conference.org More information & submission at http://tenor2016.tenor-conference.org From pdr4h at eservices.virginia.edu Mon Nov 9 22:03:19 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 21:03:19 +0000 Subject: [MEI-L] list-related changes Message-ID: I'd like to make it easier to control the formatting of lists from within the document markup rather than pushing it off entirely to CSS or othe, external formatting procedures. To this end, I plan to remove the current @form attribute and create a new att.listrend attribute class containing @mark and @order attributes -- Contains the character string (usually a single character, such as a bullet, box, dash, etc.) that precedes each item in the list. Indicates the system used to generate the character string (usually a single character) that precedes items in an ordered list. Lower case letters. Upper case letters. Arabic numerals. Lower case Roman numerals. Upper case Roman numerals. Any list without one of these attributes (a list cannot have both) should be assumed to be "simple"; that is, without any mark or order. This is NOT procedural markup, just somewhat more descriptive than what used to be allowed. :) -- 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 pdr4h at eservices.virginia.edu Mon Nov 9 22:07:59 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 21:07:59 +0000 Subject: [MEI-L] FW: changes to and Message-ID: I sent this message to the cataloging interest group list earlier. I apologize if you receive it twice, but I thought it would be a good idea to post to this list as well in the interest of generating as much discussion as possible. BTW, this is not a new feature, but rather a remedy for an existing bug. But I think it's finally squashed this time. -- p. From: Roland, Perry D. (pdr4h) Sent: Monday, November 09, 2015 3:46 PM To: 'mei-catalog-ig at lists.uni-paderborn.de' Subject: changes to and I know we've had a few rounds of discussion about the content models of and in the past. I think there are basically 2 issues currently facing us: * eventList contains a bug that doesn't allow grouping events that share the same date * the model of event is too vague I propose to remedy the first problem by using the following content model for : eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) By placing outside the model of , the main content of can be constrained to be any number of pairs of and elements, like so - Or, when multiple events share the same date, like so -- Event 1 Event 2 The new model also introduces listHead, a new formatting element. contains a pair of elements, one for each column in the eventList date-event pair. This makes it possible to treat the list of events as though it were a table with a column heading for the dates and a heading for the descriptions. Of course, eventList/head continues to contain a heading for the entire list -- My List o' Special Events When What I plan to investigate how this might work for other lists as well, such as , , and . Any list that allows a label preceding its "items" could benefit from this treatment, I think. One more change -- is now a member of model.listLike, meaning it can occur not just in the header but anywhere a "regular" list can happen. The element now has the following model (switching to RNG as it's somewhat clearer than DTD syntax) -- English translation is "an optional label, followed by EITHER some data-like elements or nested eventLists OR any number of paragraphs, tables, castLists, eventLists, or lists, followed by any number of lists of bibliographic citations." The central choice (a data-centric organization OR a free-form text one) is the important factor here. In purely practical terms, any file that formerly used a group of data elements followed by a paragraph will have to be translated into -- This element re-naming and re-ordering is not a difficult task and can be made part of the 2013 -> 2015 XSLT transformation. If the re-ordering poses a significant issue (that is, you *must* have the data elements followed by the label), I think it's not a problem to allow that, but please let me know. As always, I apologize for the length of the message and the XML "gobbledy-gook". I just don't know of any other way to communicate. ;-) -- 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 kepper at edirom.de Mon Nov 9 22:08:44 2015 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 9 Nov 2015 22:08:44 +0100 Subject: [MEI-L] list-related changes In-Reply-To: References: Message-ID: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> I'm sorry to say, but I see no need to include that in MEI. If I want to be descriptive, I can include the mark in the encoding itself. But of course you're free to convince me and anyone else who's not convinced yet :-) jo Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) : > > I’d like to make it easier to control the formatting of lists from within the document markup rather than pushing it off entirely to CSS or othe, external formatting procedures. > > To this end, I plan to remove the current @form attribute and create a new att.listrend attribute class containing @mark and @order attributes -- > > > > Contains the character string (usually a single character, such as a bullet, > box, dash, etc.) that precedes each item in the list. > > > > > > Indicates the system used to generate the character string (usually a single > character) that precedes items in an ordered list. > > > > > > Lower case letters. > > > Upper case letters. > > > Arabic numerals. > > > Lower case Roman numerals. > > > Upper case Roman numerals. > > > > > > Any list without one of these attributes (a list cannot have both) should be assumed to be “simple”; that is, without any mark or order. This is NOT procedural markup, just somewhat more descriptive than what used to be allowed. J > > -- > p. > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From kepper at edirom.de Mon Nov 9 22:19:30 2015 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 9 Nov 2015 22:19:30 +0100 Subject: [MEI-L] FW: changes to and In-Reply-To: References: Message-ID: I'm sorry to say, but I'm not convinced by this one either. I see the point to have an eventGroup element, but everything else seems rather dubious to me. By all means, I would like to keep the date inside events, even for free-form text-driven events (in contrast to data-driven events). Also, I hate the idea to have an alternation of events and something, and have to rely on document order to understand the meaning of something – this gets pretty close to MusicXML's concept of chords, doesn't it? Are there any real-world limitations that motivate this proposal? If so, could we discuss it with those examples on the table? jo Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) : > > I sent this message to the cataloging interest group list earlier. I apologize if you receive it twice, but I thought it would be a good idea to post to this list as well in the interest of generating as much discussion as possible. > > BTW, this is not a new feature, but rather a remedy for an existing bug. But I think it’s finally squashed this time. > > -- > p. > > > From: Roland, Perry D. (pdr4h) > Sent: Monday, November 09, 2015 3:46 PM > To: 'mei-catalog-ig at lists.uni-paderborn.de' > Subject: changes to and > > > I know we’ve had a few rounds of discussion about the content models of and in the past. I think there are basically 2 issues currently facing us: > > · eventList contains a bug that doesn’t allow grouping events that share the same date > · the model of event is too vague > > I propose to remedy the first problem by using the following content model for : > > eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > > By placing outside the model of , the main content of can be constrained to be any number of pairs of and elements, like so – > > > > > > > > > > Or, when multiple events share the same date, like so -- > > > > > Event 1 > Event 2 > > > > > The new model also introduces listHead, a new formatting element. contains a pair of elements, one for each column in the eventList date-event pair. This makes it possible to treat the list of events as though it were a table with a column heading for the dates and a heading for the descriptions. Of course, eventList/head continues to contain a heading for the entire list -- > > > My List o’ Special Events > > When > What > > > > > > I plan to investigate how this might work for other lists as well, such as , , and . Any list that allows a label preceding its “items” could benefit from this treatment, I think. > > One more change -- is now a member of model.listLike, meaning it can occur not just in the header but anywhere a “regular” list can happen. > > The element now has the following model (switching to RNG as it’s somewhat clearer than DTD syntax) -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > English translation is “an optional label, followed by EITHER some data-like elements or nested eventLists OR any number of paragraphs, tables, castLists, eventLists, or lists, followed by any number of lists of bibliographic citations.” > > The central choice (a data-centric organization OR a free-form text one) is the important factor here. In purely practical terms, any file that formerly used a group of data elements followed by a paragraph will have to be translated into -- > > > > > This element re-naming and re-ordering is not a difficult task and can be made part of the 2013 -> 2015 XSLT transformation. If the re-ordering poses a significant issue (that is, you *must* have the data elements followed by the label), I think it’s not a problem to allow that, but please let me know. > > As always, I apologize for the length of the message and the XML “gobbledy-gook”. I just don’t know of any other way to communicate. ;-) > > -- > p. > > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From pdr4h at eservices.virginia.edu Mon Nov 9 22:28:47 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 21:28:47 +0000 Subject: [MEI-L] FW: changes to and In-Reply-To: References: Message-ID: An element containing with the current model makes no sense as there's no indication of the grouping criterion. The followed by construct makes it clear that the events are grouped by date. In fact, that's the only way to group them using this model. It is nothing like the concept of chords that you raise. Order is a good thing here as it makes the structure of the data clear. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:20 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] FW: changes to and > > I'm sorry to say, but I'm not convinced by this one either. I see the point to > have an eventGroup element, but everything else seems rather dubious to > me. By all means, I would like to keep the date inside events, even for free- > form text-driven events (in contrast to data-driven events). Also, I hate the > idea to have an alternation of events and something, and have to rely on > document order to understand the meaning of something - this gets pretty > close to MusicXML's concept of chords, doesn't it? Are there any real-world > limitations that motivate this proposal? If so, could we discuss it with those > examples on the table? > > jo > > > Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) > : > > > > > I sent this message to the cataloging interest group list earlier. I apologize if > you receive it twice, but I thought it would be a good idea to post to this list > as well in the interest of generating as much discussion as possible. > > > > BTW, this is not a new feature, but rather a remedy for an existing bug. But > I think it's finally squashed this time. > > > > -- > > p. > > > > > > From: Roland, Perry D. (pdr4h) > > Sent: Monday, November 09, 2015 3:46 PM > > To: 'mei-catalog-ig at lists.uni-paderborn.de' > > Subject: changes to and > > > > > > I know we've had a few rounds of discussion about the content models of > and in the past. I think there are basically 2 issues > currently facing us: > > > > * eventList contains a bug that doesn't allow grouping events that share > the same date > > * the model of event is too vague > > > > I propose to remedy the first problem by using the following content model > for : > > > > eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > > > > By placing outside the model of , the main content of > > can be constrained to be any number of pairs of and > > elements, like so - > > > > > > > > > > > > > > > > > > > > Or, when multiple events share the same date, like so -- > > > > > > > > > > Event 1 > > Event 2 > > > > > > > > > > The new model also introduces listHead, a new formatting element. > > contains a pair of elements, one for each column in > > the eventList date-event pair. This makes it possible to treat the > > list of events as though it were a table with a column heading for the > > dates and a heading for the descriptions. Of course, eventList/head > > continues to contain a heading for the entire list -- > > > > > > My List o' Special Events > > > > When > > What > > > > > > > > > > > > I plan to investigate how this might work for other lists as well, such as > , , and . Any list that allows a label preceding its > "items" could benefit from this treatment, I think. > > > > One more change -- is now a member of model.listLike, > meaning it can occur not just in the header but anywhere a "regular" list can > happen. > > > > The element now has the following model (switching to RNG as > > it's somewhat clearer than DTD syntax) -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > English translation is "an optional label, followed by EITHER some data-like > elements or nested eventLists OR any number of paragraphs, tables, > castLists, eventLists, or lists, followed by any number of lists of bibliographic > citations." > > > > The central choice (a data-centric organization OR a free-form text > > one) is the important factor here. In purely practical terms, any > > file that formerly used a group of data elements followed by a > > paragraph will have to be translated into -- > > > > > > > > > > This element re-naming and re-ordering is not a difficult task and can be > made part of the 2013 -> 2015 XSLT transformation. If the re-ordering poses > a significant issue (that is, you *must* have the data elements followed by > the label), I think it's not a problem to allow that, but please let me know. > > > > As always, I apologize for the length of the message and the XML > > "gobbledy-gook". I just don't know of any other way to communicate. > > ;-) > > > > -- > > p. > > > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > 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 Nov 9 22:31:48 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 21:31:48 +0000 Subject: [MEI-L] list-related changes In-Reply-To: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: Putting the mark in the markup -- [Unicode for bullet] item 1 [Unicode for bullet] item 2 etc. denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:09 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > descriptive, I can include the mark in the encoding itself. But of course you're > free to convince me and anyone else who's not convinced yet :-) > > jo > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > : > > > > > I'd like to make it easier to control the formatting of lists from within the > document markup rather than pushing it off entirely to CSS or othe, external > formatting procedures. > > > > To this end, I plan to remove the current @form attribute and create a new > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > Contains the character string (usually a single character, such as a > bullet, > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > Indicates the system used to generate the character string (usually > a single > > character) that precedes items in an ordered list. > > > > > > > > > > > > Lower case letters. > > > > > > Upper case letters. > > > > > > Arabic numerals. > > > > > > Lower case Roman numerals. > > > > > > Upper case Roman numerals. > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) should be > assumed to be "simple"; that is, without any mark or order. This is NOT > procedural markup, just somewhat more descriptive than what used to be > allowed. J > > > > -- > > p. > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From kepper at edirom.de Mon Nov 9 22:39:50 2015 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 9 Nov 2015 22:39:50 +0100 Subject: [MEI-L] FW: changes to and In-Reply-To: References: Message-ID: <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) : > > An element containing with the current model makes no sense as there's no indication of the grouping criterion. The followed by construct makes it clear that the events are grouped by date. In fact, that's the only way to group them using this model. Ok, what constitutes a group of events? What does it mean to have events grouped? Is there any other grouping mechanism other than by date? Does it make sense to have events grouped by place? If so, why don't we factor in groups (by date, for instance) and subgroups (by place)? Or is it maybe better to let the grouping be done by applications, based on structured markup like @isodate, @resp, @type and similar options? > > It is nothing like the concept of chords that you raise. I need to look into the preceding sibling to fully understand the current element… > Order is a good thing here as it makes the structure of the data clear. > jo > -- > p. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Johannes Kepper >> Sent: Monday, November 09, 2015 4:20 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] FW: changes to and >> >> I'm sorry to say, but I'm not convinced by this one either. I see the point to >> have an eventGroup element, but everything else seems rather dubious to >> me. By all means, I would like to keep the date inside events, even for free- >> form text-driven events (in contrast to data-driven events). Also, I hate the >> idea to have an alternation of events and something, and have to rely on >> document order to understand the meaning of something - this gets pretty >> close to MusicXML's concept of chords, doesn't it? Are there any real-world >> limitations that motivate this proposal? If so, could we discuss it with those >> examples on the table? >> >> jo >> >> >> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) >> : >> >>> >>> I sent this message to the cataloging interest group list earlier. I apologize if >> you receive it twice, but I thought it would be a good idea to post to this list >> as well in the interest of generating as much discussion as possible. >>> >>> BTW, this is not a new feature, but rather a remedy for an existing bug. But >> I think it's finally squashed this time. >>> >>> -- >>> p. >>> >>> >>> From: Roland, Perry D. (pdr4h) >>> Sent: Monday, November 09, 2015 3:46 PM >>> To: 'mei-catalog-ig at lists.uni-paderborn.de' >>> Subject: changes to and >>> >>> >>> I know we've had a few rounds of discussion about the content models of >> and in the past. I think there are basically 2 issues >> currently facing us: >>> >>> * eventList contains a bug that doesn't allow grouping events that share >> the same date >>> * the model of event is too vague >>> >>> I propose to remedy the first problem by using the following content model >> for : >>> >>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) >>> >>> By placing outside the model of , the main content of >>> can be constrained to be any number of pairs of and >>> elements, like so - >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Or, when multiple events share the same date, like so -- >>> >>> >>> >>> >>> Event 1 >>> Event 2 >>> >>> >>> >>> >>> The new model also introduces listHead, a new formatting element. >>> contains a pair of elements, one for each column in >>> the eventList date-event pair. This makes it possible to treat the >>> list of events as though it were a table with a column heading for the >>> dates and a heading for the descriptions. Of course, eventList/head >>> continues to contain a heading for the entire list -- >>> >>> >>> My List o' Special Events >>> >>> When >>> What >>> >>> >>> >>> >>> >>> I plan to investigate how this might work for other lists as well, such as >> , , and . Any list that allows a label preceding its >> "items" could benefit from this treatment, I think. >>> >>> One more change -- is now a member of model.listLike, >> meaning it can occur not just in the header but anywhere a "regular" list can >> happen. >>> >>> The element now has the following model (switching to RNG as >>> it's somewhat clearer than DTD syntax) -- >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> English translation is "an optional label, followed by EITHER some data-like >> elements or nested eventLists OR any number of paragraphs, tables, >> castLists, eventLists, or lists, followed by any number of lists of bibliographic >> citations." >>> >>> The central choice (a data-centric organization OR a free-form text >>> one) is the important factor here. In purely practical terms, any >>> file that formerly used a group of data elements followed by a >>> paragraph will have to be translated into -- >>> >>> >>> >>> >>> This element re-naming and re-ordering is not a difficult task and can be >> made part of the 2013 -> 2015 XSLT transformation. If the re-ordering poses >> a significant issue (that is, you *must* have the data elements followed by >> the label), I think it's not a problem to allow that, but please let me know. >>> >>> As always, I apologize for the length of the message and the XML >>> "gobbledy-gook". I just don't know of any other way to communicate. >>> ;-) >>> >>> -- >>> p. >>> >>> ________________________________ >>> Perry Roland >>> University of Virginia >>> P. O. Box 400874 >>> Charlottesville, VA, 22904 >>> 434-982-2702 (w) >>> pdr4h (at) virginia (dot) edu >>> >>> _______________________________________________ >>> 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From kepper at edirom.de Mon Nov 9 22:49:41 2015 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 9 Nov 2015 22:49:41 +0100 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: I'm not suggesting to do that – I'm just saying that it's possible. And that your well-known naive encode might take this approach anyway. What concerns me is that while you claim your proposal isn't procedural, I strongly believe it is. I have no problem to include something along these lines in MEI, but I wouldn't want to call it descriptive when it's not… Am 09.11.2015 um 22:31 schrieb Roland, Perry D. (pdr4h) : > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Johannes Kepper >> Sent: Monday, November 09, 2015 4:09 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] list-related changes >> >> I'm sorry to say, but I see no need to include that in MEI. If I want to be >> descriptive, I can include the mark in the encoding itself. But of course you're >> free to convince me and anyone else who's not convinced yet :-) >> >> jo >> >> Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) >> : >> >>> >>> I'd like to make it easier to control the formatting of lists from within the >> document markup rather than pushing it off entirely to CSS or othe, external >> formatting procedures. >>> >>> To this end, I plan to remove the current @form attribute and create a new >> att.listrend attribute class containing @mark and @order attributes -- >>> >>> >>> >>> Contains the character string (usually a single character, such as a >> bullet, >>> box, dash, etc.) that precedes each item in the list. >>> >>> >>> >>> >>> >>> Indicates the system used to generate the character string (usually >> a single >>> character) that precedes items in an ordered list. >>> >>> >>> >>> >>> >>> Lower case letters. >>> >>> >>> Upper case letters. >>> >>> >>> Arabic numerals. >>> >>> >>> Lower case Roman numerals. >>> >>> >>> Upper case Roman numerals. >>> >>> >>> >>> >>> >>> Any list without one of these attributes (a list cannot have both) should be >> assumed to be "simple"; that is, without any mark or order. This is NOT >> procedural markup, just somewhat more descriptive than what used to be >> allowed. J >>> >>> -- >>> p. >>> ________________________________ >>> Perry Roland >>> University of Virginia >>> P. O. Box 400874 >>> Charlottesville, VA, 22904 >>> 434-982-2702 (w) >>> pdr4h (at) virginia (dot) edu >>> >>> _______________________________________________ >>> 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From raffaeleviglianti at gmail.com Mon Nov 9 22:59:47 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 9 Nov 2015 16:59:47 -0500 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition (and >). In this way you can have the cake and eat it too. Raff On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item > content. Your suggested approach mixes what is presentational with actual > content. That's generally a bad idea. > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Johannes Kepper > > Sent: Monday, November 09, 2015 4:09 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] list-related changes > > > > I'm sorry to say, but I see no need to include that in MEI. If I want to > be > > descriptive, I can include the mark in the encoding itself. But of > course you're > > free to convince me and anyone else who's not convinced yet :-) > > > > jo > > > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > > : > > > > > > > > I'd like to make it easier to control the formatting of lists from > within the > > document markup rather than pushing it off entirely to CSS or othe, > external > > formatting procedures. > > > > > > To this end, I plan to remove the current @form attribute and create a > new > > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > > > > > Contains the character string (usually a single character, > such as a > > bullet, > > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > > > > > > > Indicates the system used to generate the character string > (usually > > a single > > > character) that precedes items in an ordered list. > > > > > > > > > > > > > > > > > > Lower case letters. > > > > > > > > > Upper case letters. > > > > > > > > > Arabic numerals. > > > > > > > > > Lower case Roman numerals. > > > > > > > > > Upper case Roman numerals. > > > > > > > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) > should be > > assumed to be "simple"; that is, without any mark or order. This is NOT > > procedural markup, just somewhat more descriptive than what used to be > > allowed. J > > > > > > -- > > > p. > > > ________________________________ > > > Perry Roland > > > University of Virginia > > > P. O. Box 400874 > > > Charlottesville, VA, 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > > > > _______________________________________________ > > > 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 Nov 9 23:02:02 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 22:02:02 +0000 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: I’m not sure what you think is a bad idea or what you mean mean by “already compromised”. Can you elaborate please? From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:00 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition (and >). In this way you can have the cake and eat it too. Raff On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) > wrote: Putting the mark in the markup -- [Unicode for bullet] item 1 [Unicode for bullet] item 2 etc. denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:09 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > descriptive, I can include the mark in the encoding itself. But of course you're > free to convince me and anyone else who's not convinced yet :-) > > jo > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > >: > > > > > I'd like to make it easier to control the formatting of lists from within the > document markup rather than pushing it off entirely to CSS or othe, external > formatting procedures. > > > > To this end, I plan to remove the current @form attribute and create a new > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > Contains the character string (usually a single character, such as a > bullet, > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > Indicates the system used to generate the character string (usually > a single > > character) that precedes items in an ordered list. > > > > > > > > > > > > Lower case letters. > > > > > > Upper case letters. > > > > > > Arabic numerals. > > > > > > Lower case Roman numerals. > > > > > > Upper case Roman numerals. > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) should be > assumed to be "simple"; that is, without any mark or order. This is NOT > procedural markup, just somewhat more descriptive than what used to be > allowed. J > > > > -- > > p. > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > 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 raffaeleviglianti at gmail.com Mon Nov 9 23:28:51 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 9 Nov 2015 17:28:51 -0500 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: The bad idea is adding procedural markup to lists. Text encoding in MEI mixes declarative and procedural markup, particularly through . I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files. So I would avoid adding more procedural markup in the text encoding side of MEI. On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > I’m not sure what you think is a bad idea or what you mean mean by > “already compromised”. Can you elaborate please? > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 5:00 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > I think this is a bad idea. Whatever target format / platform will display > the MEI should be able to access a basic text-styling system that can > target, if not the MEI directly, at least a target output. > > > > Text encoding in MEI is already compromised, so we either continue being > careless in that matter, or we can avoid making it worse. > > > > Another approach would be adopting a system that would make it easy to > embed styling, such as TEI's @rendition > > (and >). > In this way you can have the cake and eat it too. > > > > Raff > > > > On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item > content. Your suggested approach mixes what is presentational with actual > content. That's generally a bad idea. > > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Johannes Kepper > > Sent: Monday, November 09, 2015 4:09 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] list-related changes > > > > I'm sorry to say, but I see no need to include that in MEI. If I want to > be > > descriptive, I can include the mark in the encoding itself. But of > course you're > > free to convince me and anyone else who's not convinced yet :-) > > > > jo > > > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > > : > > > > > > > > I'd like to make it easier to control the formatting of lists from > within the > > document markup rather than pushing it off entirely to CSS or othe, > external > > formatting procedures. > > > > > > To this end, I plan to remove the current @form attribute and create a > new > > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > > > > > Contains the character string (usually a single character, > such as a > > bullet, > > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > > > > > > > Indicates the system used to generate the character string > (usually > > a single > > > character) that precedes items in an ordered list. > > > > > > > > > > > > > > > > > > Lower case letters. > > > > > > > > > Upper case letters. > > > > > > > > > Arabic numerals. > > > > > > > > > Lower case Roman numerals. > > > > > > > > > Upper case Roman numerals. > > > > > > > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) > should be > > assumed to be "simple"; that is, without any mark or order. This is NOT > > procedural markup, just somewhat more descriptive than what used to be > > allowed. J > > > > > > -- > > > p. > > > ________________________________ > > > Perry Roland > > > University of Virginia > > > P. O. Box 400874 > > > Charlottesville, VA, 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > > > > _______________________________________________ > > > 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 Nov 9 23:56:23 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 22:56:23 +0000 Subject: [MEI-L] FW: changes to and In-Reply-To: <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> References: <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> Message-ID: Our current handling of is a mess, which reduces its effectiveness for data interchange and interoperability. Clarifying its possible content can counteract this tendency. It's relatively easy to provide alternative grouping mechanisms. For instance, a content model for like -- would allow any member of model.eventPart to act as the organizing "term". For instance, or or are all possible. This is the essentially the model used by HTML for
, by EAD for , and by TEI for of @type "gloss". The difficulty, of course, is ensuring that each event in a list is preceded by the same kind of element. I'm not sure if this is possible using RNG alone, but it can certainly be enforced using Schematron. -- p. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:40 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] FW: changes to and > > > Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) > : > > > > > An element containing with the current model makes > no sense as there's no indication of the grouping criterion. The > followed by construct makes it clear that the events are grouped > by date. In fact, that's the only way to group them using this model. > > Ok, what constitutes a group of events? What does it mean to have events > grouped? Is there any other grouping mechanism other than by date? Does it > make sense to have events grouped by place? If so, why don't we factor in > groups (by date, for instance) and subgroups (by place)? Or is it maybe > better to let the grouping be done by applications, based on structured > markup like @isodate, @resp, @type and similar options? > > > > > It is nothing like the concept of chords that you raise. > > I need to look into the preceding sibling to fully understand the current > element... > > > Order is a good thing here as it makes the structure of the data clear. > > > > jo > > > -- > > p. > > > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Johannes Kepper > >> Sent: Monday, November 09, 2015 4:20 PM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] FW: changes to and > >> > >> I'm sorry to say, but I'm not convinced by this one either. I see the > >> point to have an eventGroup element, but everything else seems rather > >> dubious to me. By all means, I would like to keep the date inside > >> events, even for free- form text-driven events (in contrast to > >> data-driven events). Also, I hate the idea to have an alternation of > >> events and something, and have to rely on document order to > >> understand the meaning of something - this gets pretty close to > >> MusicXML's concept of chords, doesn't it? Are there any real-world > >> limitations that motivate this proposal? If so, could we discuss it with > those examples on the table? > >> > >> jo > >> > >> > >> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) > >> : > >> > >>> > >>> I sent this message to the cataloging interest group list earlier. > >>> I apologize if > >> you receive it twice, but I thought it would be a good idea to post > >> to this list as well in the interest of generating as much discussion as > possible. > >>> > >>> BTW, this is not a new feature, but rather a remedy for an existing > >>> bug. But > >> I think it's finally squashed this time. > >>> > >>> -- > >>> p. > >>> > >>> > >>> From: Roland, Perry D. (pdr4h) > >>> Sent: Monday, November 09, 2015 3:46 PM > >>> To: 'mei-catalog-ig at lists.uni-paderborn.de' > >>> Subject: changes to and > >>> > >>> > >>> I know we've had a few rounds of discussion about the content models > >>> of > >> and in the past. I think there are basically 2 > >> issues currently facing us: > >>> > >>> * eventList contains a bug that doesn't allow grouping events that > share > >> the same date > >>> * the model of event is too vague > >>> > >>> I propose to remedy the first problem by using the following content > >>> model > >> for : > >>> > >>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > >>> > >>> By placing outside the model of , the main content of > >>> can be constrained to be any number of pairs of > >>> and elements, like so - > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Or, when multiple events share the same date, like so -- > >>> > >>> > >>> > >>> > >>> Event 1 > >>> Event 2 > >>> > >>> > >>> > >>> > >>> The new model also introduces listHead, a new formatting element. > >>> contains a pair of elements, one for each column > >>> in the eventList date-event pair. This makes it possible to treat > >>> the list of events as though it were a table with a column heading > >>> for the dates and a heading for the descriptions. Of course, > >>> eventList/head continues to contain a heading for the entire list -- > >>> > >>> > >>> My List o' Special Events > >>> When > >>> What > >>> > >>> > >>> > >>> > >>> > >>> I plan to investigate how this might work for other lists as well, > >>> such as > >> , , and . Any list that allows a label > >> preceding its "items" could benefit from this treatment, I think. > >>> > >>> One more change -- is now a member of model.listLike, > >> meaning it can occur not just in the header but anywhere a "regular" > >> list can happen. > >>> > >>> The element now has the following model (switching to RNG as > >>> it's somewhat clearer than DTD syntax) -- > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> English translation is "an optional label, followed by EITHER some > >>> data-like > >> elements or nested eventLists OR any number of paragraphs, tables, > >> castLists, eventLists, or lists, followed by any number of lists of > >> bibliographic citations." > >>> > >>> The central choice (a data-centric organization OR a free-form text > >>> one) is the important factor here. In purely practical terms, any > >>> file that formerly used a group of data elements followed by a > >>> paragraph will have to be translated into -- > >>> > >>> > >>> > >>> > >>> This element re-naming and re-ordering is not a difficult task and > >>> can be > >> made part of the 2013 -> 2015 XSLT transformation. If the > >> re-ordering poses a significant issue (that is, you *must* have the > >> data elements followed by the label), I think it's not a problem to allow > that, but please let me know. > >>> > >>> As always, I apologize for the length of the message and the XML > >>> "gobbledy-gook". I just don't know of any other way to communicate. > >>> ;-) > >>> > >>> -- > >>> p. > >>> > >>> ________________________________ > >>> Perry Roland > >>> University of Virginia > >>> P. O. Box 400874 > >>> Charlottesville, VA, 22904 > >>> 434-982-2702 (w) > >>> pdr4h (at) virginia (dot) edu > >>> > >>> _______________________________________________ > >>> 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 Nov 10 00:15:42 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Mon, 9 Nov 2015 23:15:42 +0000 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: MEI doesn’t mix declarative and procedural markup any more than TEI, does it? A reasonable mix is necessary for a general-use markup scheme. Furthermore, I don’t agree that what I’m proposing is procedural markup. Saying that an item in a list has a bullet or is marked with a Roman numeral isn’t procedural in nature, it’s descriptive. It’s just as descriptive as using War and Peace to indicate that the content is a title and not a person’s name, just in a different way. I agree that you might not want to use this kind of thing for MEI that describes born-digital material (where the author controls the rendition), but it’s essential for describing already-existing material, especially if it is non-standard in some way, for example if it contains a printing error that caused an item in an otherwise-numbered list to be labelled with an “A”. How could one possibly *describe* this situation without saying anything about the bullets? Putting this kind of information in a CSS file is just moving the problem. The markup no longer contains any information about the bullets, but the CSS does and without it (the CSS) the MEI doesn’t effectively *describe* its source so the two have to be interpreted together. There’s a false sense of having separated the content and presentation in this case. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:29 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes The bad idea is adding procedural markup to lists. Text encoding in MEI mixes declarative and procedural markup, particularly through . I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files. So I would avoid adding more procedural markup in the text encoding side of MEI. On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) > wrote: I’m not sure what you think is a bad idea or what you mean mean by “already compromised”. Can you elaborate please? From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:00 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition (and >). In this way you can have the cake and eat it too. Raff On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) > wrote: Putting the mark in the markup -- [Unicode for bullet] item 1 [Unicode for bullet] item 2 etc. denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:09 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > descriptive, I can include the mark in the encoding itself. But of course you're > free to convince me and anyone else who's not convinced yet :-) > > jo > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > >: > > > > > I'd like to make it easier to control the formatting of lists from within the > document markup rather than pushing it off entirely to CSS or othe, external > formatting procedures. > > > > To this end, I plan to remove the current @form attribute and create a new > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > Contains the character string (usually a single character, such as a > bullet, > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > Indicates the system used to generate the character string (usually > a single > > character) that precedes items in an ordered list. > > > > > > > > > > > > Lower case letters. > > > > > > Upper case letters. > > > > > > Arabic numerals. > > > > > > Lower case Roman numerals. > > > > > > Upper case Roman numerals. > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) should be > assumed to be "simple"; that is, without any mark or order. This is NOT > procedural markup, just somewhat more descriptive than what used to be > allowed. J > > > > -- > > p. > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702 (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > 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 andrew.hankinson at mail.mcgill.ca Tue Nov 10 00:18:23 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Mon, 9 Nov 2015 23:18:23 +0000 Subject: [MEI-L] list-related changes In-Reply-To: <12762_1447103110_56410A85_12762_245_1_BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> References: <12762_1447103110_56410A85_12762_245_1_BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> Message-ID: When do you plan on doing this? Can we punt this until after the MEI 3.0.0 release? > On Nov 9, 2015, at 9:03 PM, Roland, Perry D. (pdr4h) wrote: > > > I’d like to make it easier to control the formatting of lists from within the document markup rather than pushing it off entirely to CSS or othe, external formatting procedures. > > To this end, I plan to remove the current @form attribute and create a new att.listrend attribute class containing @mark and @order attributes -- > > > > Contains the character string (usually a single character, such as a bullet, > box, dash, etc.) that precedes each item in the list. > > > > > > Indicates the system used to generate the character string (usually a single > character) that precedes items in an ordered list. > > > > > > Lower case letters. > > > Upper case letters. > > > Arabic numerals. > > > Lower case Roman numerals. > > > Upper case Roman numerals. > > > > > > Any list without one of these attributes (a list cannot have both) should be assumed to be “simple”; that is, without any mark or order. This is NOT procedural markup, just somewhat more descriptive than what used to be allowed. J > > -- > p. > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > 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 kepper at edirom.de Tue Nov 10 00:19:55 2015 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 10 Nov 2015 00:19:55 +0100 Subject: [MEI-L] FW: changes to and In-Reply-To: References: <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> Message-ID: <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> Hi Perry, I understand (and fully support) your motivation to clean up events. However, could you please refresh my memory and indicate the current / planned content of event? Maybe I understand your proposal to move all these things out of events better with that model in mind. As you know, we use even annots in a data-like way, and while I agree that both annots and events are perfectly valid to take free-form content, I'm still in love with structured things – maybe just a couple of attributes. Or would it be an alternative to provide separate elements for free-form and structured content, like and or and ? Just guessing… jo Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) : > > Our current handling of is a mess, which reduces its effectiveness for data interchange and interoperability. Clarifying its possible content can counteract this tendency. It's relatively easy to provide alternative grouping mechanisms. For instance, a content model for like -- > > > > > > > > > > > > > > > > > > > > > > > > > would allow any member of model.eventPart to act as the organizing "term". For instance, > > > > > > > > or > > > > > > > > or > > > > > > > > are all possible. This is the essentially the model used by HTML for
, by EAD for , and by TEI for of @type "gloss". The difficulty, of course, is ensuring that each event in a list is preceded by the same kind of element. I'm not sure if this is possible using RNG alone, but it can certainly be enforced using Schematron. > > -- > p. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of >> Johannes Kepper >> Sent: Monday, November 09, 2015 4:40 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] FW: changes to and >> >> >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) >> : >> >>> >>> An element containing with the current model makes >> no sense as there's no indication of the grouping criterion. The >> followed by construct makes it clear that the events are grouped >> by date. In fact, that's the only way to group them using this model. >> >> Ok, what constitutes a group of events? What does it mean to have events >> grouped? Is there any other grouping mechanism other than by date? Does it >> make sense to have events grouped by place? If so, why don't we factor in >> groups (by date, for instance) and subgroups (by place)? Or is it maybe >> better to let the grouping be done by applications, based on structured >> markup like @isodate, @resp, @type and similar options? >> >>> >>> It is nothing like the concept of chords that you raise. >> >> I need to look into the preceding sibling to fully understand the current >> element... >> >>> Order is a good thing here as it makes the structure of the data clear. >>> >> >> jo >> >>> -- >>> p. >>> >>> >>>> -----Original Message----- >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >>>> Of Johannes Kepper >>>> Sent: Monday, November 09, 2015 4:20 PM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] FW: changes to and >>>> >>>> I'm sorry to say, but I'm not convinced by this one either. I see the >>>> point to have an eventGroup element, but everything else seems rather >>>> dubious to me. By all means, I would like to keep the date inside >>>> events, even for free- form text-driven events (in contrast to >>>> data-driven events). Also, I hate the idea to have an alternation of >>>> events and something, and have to rely on document order to >>>> understand the meaning of something - this gets pretty close to >>>> MusicXML's concept of chords, doesn't it? Are there any real-world >>>> limitations that motivate this proposal? If so, could we discuss it with >> those examples on the table? >>>> >>>> jo >>>> >>>> >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) >>>> : >>>> >>>>> >>>>> I sent this message to the cataloging interest group list earlier. >>>>> I apologize if >>>> you receive it twice, but I thought it would be a good idea to post >>>> to this list as well in the interest of generating as much discussion as >> possible. >>>>> >>>>> BTW, this is not a new feature, but rather a remedy for an existing >>>>> bug. But >>>> I think it's finally squashed this time. >>>>> >>>>> -- >>>>> p. >>>>> >>>>> >>>>> From: Roland, Perry D. (pdr4h) >>>>> Sent: Monday, November 09, 2015 3:46 PM >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de' >>>>> Subject: changes to and >>>>> >>>>> >>>>> I know we've had a few rounds of discussion about the content models >>>>> of >>>> and in the past. I think there are basically 2 >>>> issues currently facing us: >>>>> >>>>> * eventList contains a bug that doesn't allow grouping events that >> share >>>> the same date >>>>> * the model of event is too vague >>>>> >>>>> I propose to remedy the first problem by using the following content >>>>> model >>>> for : >>>>> >>>>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) >>>>> >>>>> By placing outside the model of , the main content of >>>>> can be constrained to be any number of pairs of >>>>> and elements, like so - >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Or, when multiple events share the same date, like so -- >>>>> >>>>> >>>>> >>>>> >>>>> Event 1 >>>>> Event 2 >>>>> >>>>> >>>>> >>>>> >>>>> The new model also introduces listHead, a new formatting element. >>>>> contains a pair of elements, one for each column >>>>> in the eventList date-event pair. This makes it possible to treat >>>>> the list of events as though it were a table with a column heading >>>>> for the dates and a heading for the descriptions. Of course, >>>>> eventList/head continues to contain a heading for the entire list -- >>>>> >>>>> >>>>> My List o' Special Events >>>>> When >>>>> What >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I plan to investigate how this might work for other lists as well, >>>>> such as >>>> , , and . Any list that allows a label >>>> preceding its "items" could benefit from this treatment, I think. >>>>> >>>>> One more change -- is now a member of model.listLike, >>>> meaning it can occur not just in the header but anywhere a "regular" >>>> list can happen. >>>>> >>>>> The element now has the following model (switching to RNG as >>>>> it's somewhat clearer than DTD syntax) -- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> English translation is "an optional label, followed by EITHER some >>>>> data-like >>>> elements or nested eventLists OR any number of paragraphs, tables, >>>> castLists, eventLists, or lists, followed by any number of lists of >>>> bibliographic citations." >>>>> >>>>> The central choice (a data-centric organization OR a free-form text >>>>> one) is the important factor here. In purely practical terms, any >>>>> file that formerly used a group of data elements followed by a >>>>> paragraph will have to be translated into -- >>>>> >>>>> >>>>> >>>>> >>>>> This element re-naming and re-ordering is not a difficult task and >>>>> can be >>>> made part of the 2013 -> 2015 XSLT transformation. If the >>>> re-ordering poses a significant issue (that is, you *must* have the >>>> data elements followed by the label), I think it's not a problem to allow >> that, but please let me know. >>>>> >>>>> As always, I apologize for the length of the message and the XML >>>>> "gobbledy-gook". I just don't know of any other way to communicate. >>>>> ;-) >>>>> >>>>> -- >>>>> p. >>>>> >>>>> ________________________________ >>>>> Perry Roland >>>>> University of Virginia >>>>> P. O. Box 400874 >>>>> Charlottesville, VA, 22904 >>>>> 434-982-2702 (w) >>>>> pdr4h (at) virginia (dot) edu >>>>> >>>>> _______________________________________________ >>>>> 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From kepper at edirom.de Tue Nov 10 00:27:59 2015 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 10 Nov 2015 00:27:59 +0100 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: <38E72C68-5D4B-4344-9D61-815C60DADDA2@edirom.de> Am 10.11.2015 um 00:15 schrieb Roland, Perry D. (pdr4h) : > > MEI doesn’t mix declarative and procedural markup any more than TEI, does it? A reasonable mix is necessary for a general-use markup scheme. Furthermore, I don’t agree that what I’m proposing is procedural markup. Saying that an item in a list has a bullet or is marked with a Roman numeral isn’t procedural in nature, it’s descriptive. It’s just as descriptive as using War and Peace to indicate that the content is a title and not a person’s name, just in a different way. > > I agree that you might not want to use this kind of thing for MEI that describes born-digital material (where the author controls the rendition), but it’s essential for describing already-existing material, especially if it is non-standard in some way, for example if it contains a printing error that caused an item in an otherwise-numbered list to be labelled with an “A”. How could one possibly *describe* this situation without saying anything about the bullets? Putting this kind of information in a CSS file is just moving the problem. The markup no longer contains any information about the bullets, but the CSS does and without it (the CSS) the MEI doesn’t effectively *describe* its source so the two have to be interpreted together. There’s a false sense of having separated the content and presentation in this case. I see your point, and from a certain point of view, you're right. However, your proposal consists of two attributes, to be attached to the list (if I got that right). I don't understand how these will help to override a general rule in case of a "strange" bullet on one item which doesn't follow the rule. Also, I wonder if we're really able to easily come up with a satisfying list of numbering schemes – especially when we try to describe all kinds of historical manuscripts. Your suggested values cover the creativity of today's CSS specification, but what about the creativity of medieval copyists? Can we really classify that? This was my motivation to put the shape of the bullets into the markup itself. Maybe what we need is an element that identifies its content as bullet – but this feels strange, as we're getting pretty close to TEI land here… > > -- > p. > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti > Sent: Monday, November 09, 2015 5:29 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > The bad idea is adding procedural markup to lists. > > Text encoding in MEI mixes declarative and procedural markup, particularly through . I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files. So I would avoid adding more procedural markup in the text encoding side of MEI. > > On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) wrote: > > I’m not sure what you think is a bad idea or what you mean mean by “already compromised”. Can you elaborate please? > > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti > Sent: Monday, November 09, 2015 5:00 PM > > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. > > Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. > > Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition (and ). In this way you can have the cake and eat it too. > > Raff > > On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) wrote: > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Johannes Kepper > > Sent: Monday, November 09, 2015 4:09 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] list-related changes > > > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > > descriptive, I can include the mark in the encoding itself. But of course you're > > free to convince me and anyone else who's not convinced yet :-) > > > > jo > > > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > > : > > > > > > > > I'd like to make it easier to control the formatting of lists from within the > > document markup rather than pushing it off entirely to CSS or othe, external > > formatting procedures. > > > > > > To this end, I plan to remove the current @form attribute and create a new > > att.listrend attribute class containing @mark and @order attributes -- > > > > > > > > > > > > Contains the character string (usually a single character, such as a > > bullet, > > > box, dash, etc.) that precedes each item in the list. > > > > > > > > > > > > > > > > > > Indicates the system used to generate the character string (usually > > a single > > > character) that precedes items in an ordered list. > > > > > > > > > > > > > > > > > > Lower case letters. > > > > > > > > > Upper case letters. > > > > > > > > > Arabic numerals. > > > > > > > > > Lower case Roman numerals. > > > > > > > > > Upper case Roman numerals. > > > > > > > > > > > > > > > > > > Any list without one of these attributes (a list cannot have both) should be > > assumed to be "simple"; that is, without any mark or order. This is NOT > > procedural markup, just somewhat more descriptive than what used to be > > allowed. J > > > > > > -- > > > p. > > > ________________________________ > > > Perry Roland > > > University of Virginia > > > P. O. Box 400874 > > > Charlottesville, VA, 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > > > > _______________________________________________ > > > 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : From raffaeleviglianti at gmail.com Tue Nov 10 00:56:31 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 9 Nov 2015 18:56:31 -0500 Subject: [MEI-L] list-related changes In-Reply-To: References: <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> Message-ID: On Mon, Nov 9, 2015 at 6:15 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > MEI doesn’t mix declarative and procedural markup any more than TEI, does > it? > When it comes to text encoding it does - I can't think of a procedural element in TEI. If you can, let me know because it shouldn't be there. > A reasonable mix is necessary for a general-use markup scheme. > Furthermore, I don’t agree that what I’m proposing is procedural markup. > Saying that an item in a list has a bullet or is marked with a Roman > numeral isn’t procedural in nature, it’s descriptive. It’s just as > descriptive as using War and Peace to indicate that the > content is a title and not a person’s name, just in a different way. > No, and are of the same kind, but the type of bullet is equivalent to saying that titles need to be underlined or double underlined. (There is certainly a semantic difference between ordered and unordered lists, but how they are rendered on the page is a different matter). > > > I agree that you might not want to use this kind of thing for MEI that > describes born-digital material (where the author controls the rendition), > but it’s essential for describing already-existing material, especially if > it is non-standard in some way, for example if it contains a printing error > that caused an item in an otherwise-numbered list to be labelled with an > “A”. How could one possibly *describe* this situation without saying > anything about the bullets? Putting this kind of information in a CSS file > is just moving the problem. The markup no longer contains any information > about the bullets, but the CSS does and without it (the CSS) the MEI > doesn’t effectively *describe* its source so the two have to be interpreted > together. There’s a false sense of having separated the content and > presentation in this case. > > > I don't disagree, but CSS is a more useful system than mixing in CSS-like values in MEI - which is what has caused my objection to arise. The way TEI handles this is by creating categories: list X is of a special type and has a specific rendition. The rendition is then expressed using adequate systems, not TEI (and the code can be embedded if you want to keep everything in one file). The ODD allows you to document why the special type is needed and how that impacts the rest of your customization. Not saying that this is *the* only way to handle this, but it works. Raff > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 5:29 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > The bad idea is adding procedural markup to lists. > > > > Text encoding in MEI mixes declarative and procedural markup, particularly > through <rend>. I think I understand the overall need for it, for example > as a catch-all when converting from other music notation systems that keep > procedural information about text. But it's not an element that I would > necessarily want to use when creating new MEI files. So I would avoid > adding more procedural markup in the text encoding side of MEI. > > > > On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > I’m not sure what you think is a bad idea or what you mean mean by > “already compromised”. Can you elaborate please? > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 5:00 PM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > I think this is a bad idea. Whatever target format / platform will display > the MEI should be able to access a basic text-styling system that can > target, if not the MEI directly, at least a target output. > > > > Text encoding in MEI is already compromised, so we either continue being > careless in that matter, or we can avoid making it worse. > > > > Another approach would be adopting a system that would make it easy to > embed styling, such as TEI's @rendition > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.rendition.html#tei_att.rendition> > (and <rendition > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rendition.html>>). > In this way you can have the cake and eat it too. > > > > Raff > > > > On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item > content. Your suggested approach mixes what is presentational with actual > content. That's generally a bad idea. > > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Johannes Kepper > > Sent: Monday, November 09, 2015 4:09 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] list-related changes > > > > I'm sorry to say, but I see no need to include that in MEI. If I want to > be > > descriptive, I can include the mark in the encoding itself. But of > course you're > > free to convince me and anyone else who's not convinced yet :-) > > > > jo > > > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > > <pdr4h at eservices.virginia.edu>: > > > > > > > > I'd like to make it easier to control the formatting of lists from > within the > > document markup rather than pushing it off entirely to CSS or othe, > external > > formatting procedures. > > > > > > To this end, I plan to remove the current @form attribute and create a > new > > att.listrend attribute class containing @mark and @order attributes -- > > > > > > <attList> > > > <attDef ident="mark" usage="opt"> > > > <desc>Contains the character string (usually a single character, > such as a > > bullet, > > > box, dash, etc.) that precedes each item in the list.</desc> > > > <datatype> > > > <rng:data type="string"/> > > > </datatype> > > > </attDef> > > > <attDef ident="order" usage="opt"> > > > <desc>Indicates the system used to generate the character string > (usually > > a single > > > character) that precedes items in an ordered list.</desc> > > > <datatype> > > > <rng:data type="NMTOKEN"/> > > > </datatype> > > > <valList type="semi"> > > > <valItem ident="alphalower"> > > > <desc>Lower case letters.</desc> > > > </valItem> > > > <valItem ident="alphaupper"> > > > <desc>Upper case letters.</desc> > > > </valItem> > > > <valItem ident="arabic"> > > > <desc>Arabic numerals.</desc> > > > </valItem> > > > <valItem ident="romanlower"> > > > <desc>Lower case Roman numerals.</desc> > > > </valItem> > > > <valItem ident="romanupper"> > > > <desc>Upper case Roman numerals.</desc> > > > </valItem> > > > </valList> > > > </attDef> > > > </attList> > > > > > > Any list without one of these attributes (a list cannot have both) > should be > > assumed to be "simple"; that is, without any mark or order. This is NOT > > procedural markup, just somewhat more descriptive than what used to be > > allowed. J > > > > > > -- > > > p. > > > ________________________________ > > > Perry Roland > > > University of Virginia > > > P. O. Box 400874 > > > Charlottesville, VA, 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > > > > _______________________________________________ > > > mei-l mailing list > > > mei-l at lists.uni-paderborn.de > > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151109/dd82b1cc/attachment.html> From pdr4h at eservices.virginia.edu Tue Nov 10 04:41:29 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 10 Nov 2015 03:41:29 +0000 Subject: [MEI-L] list-related changes In-Reply-To: <CAMyHAnOf6so-MFYuW+Qk4L5cihZOxu9yaY6UhOnidC0Ctrj_Bw@mail.gmail.com> References: <BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72266A@reagan.eservices.virginia.edu> <CAMyHAnMCTObrMxFTUSsgUTw=Pr5v5tq1DoQXcMtDRC83sWcRWw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C7226DB@reagan.eservices.virginia.edu> <CAMyHAnNOxirm6BzPF_ja2TxZ7vN8EVcBRtDzxRSK_hhQLFACtw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C72278D@reagan.eservices.virginia.edu>, <CAMyHAnOf6so-MFYuW+Qk4L5cihZOxu9yaY6UhOnidC0Ctrj_Bw@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D7C7227E9@reagan.eservices.virginia.edu> OK, I tried. I'm done. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Monday, November 09, 2015 6:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes On Mon, Nov 9, 2015 at 6:15 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: MEI doesn’t mix declarative and procedural markup any more than TEI, does it? When it comes to text encoding it does - I can't think of a procedural element in TEI. If you can, let me know because it shouldn't be there. A reasonable mix is necessary for a general-use markup scheme. Furthermore, I don’t agree that what I’m proposing is procedural markup. Saying that an item in a list has a bullet or is marked with a Roman numeral isn’t procedural in nature, it’s descriptive. It’s just as descriptive as using <title>War and Peace to indicate that the content is a title and not a person’s name, just in a different way. No, and are of the same kind, but the type of bullet is equivalent to saying that titles need to be underlined or double underlined. (There is certainly a semantic difference between ordered and unordered lists, but how they are rendered on the page is a different matter). I agree that you might not want to use this kind of thing for MEI that describes born-digital material (where the author controls the rendition), but it’s essential for describing already-existing material, especially if it is non-standard in some way, for example if it contains a printing error that caused an item in an otherwise-numbered list to be labelled with an “A”. How could one possibly *describe* this situation without saying anything about the bullets? Putting this kind of information in a CSS file is just moving the problem. The markup no longer contains any information about the bullets, but the CSS does and without it (the CSS) the MEI doesn’t effectively *describe* its source so the two have to be interpreted together. There’s a false sense of having separated the content and presentation in this case. I don't disagree, but CSS is a more useful system than mixing in CSS-like values in MEI - which is what has caused my objection to arise. The way TEI handles this is by creating categories: list X is of a special type and has a specific rendition. The rendition is then expressed using adequate systems, not TEI (and the code can be embedded if you want to keep everything in one file). The ODD allows you to document why the special type is needed and how that impacts the rest of your customization. Not saying that this is *the* only way to handle this, but it works. Raff -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:29 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes The bad idea is adding procedural markup to lists. Text encoding in MEI mixes declarative and procedural markup, particularly through <rend>. I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files. So I would avoid adding more procedural markup in the text encoding side of MEI. On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: I’m not sure what you think is a bad idea or what you mean mean by “already compromised”. Can you elaborate please? From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:00 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.rendition.html#tei_att.rendition> (and <rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rendition.html>>). In this way you can have the cake and eat it too. Raff On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Putting the mark in the markup -- [Unicode for bullet] item 1 [Unicode for bullet] item 2 etc. denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:09 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > descriptive, I can include the mark in the encoding itself. But of course you're > free to convince me and anyone else who's not convinced yet :-) > > jo > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>: > > > > > I'd like to make it easier to control the formatting of lists from within the > document markup rather than pushing it off entirely to CSS or othe, external > formatting procedures. > > > > To this end, I plan to remove the current @form attribute and create a new > att.listrend attribute class containing @mark and @order attributes -- > > > > <attList> > > <attDef ident="mark" usage="opt"> > > <desc>Contains the character string (usually a single character, such as a > bullet, > > box, dash, etc.) that precedes each item in the list.</desc> > > <datatype> > > <rng:data type="string"/> > > </datatype> > > </attDef> > > <attDef ident="order" usage="opt"> > > <desc>Indicates the system used to generate the character string (usually > a single > > character) that precedes items in an ordered list.</desc> > > <datatype> > > <rng:data type="NMTOKEN"/> > > </datatype> > > <valList type="semi"> > > <valItem ident="alphalower"> > > <desc>Lower case letters.</desc> > > </valItem> > > <valItem ident="alphaupper"> > > <desc>Upper case letters.</desc> > > </valItem> > > <valItem ident="arabic"> > > <desc>Arabic numerals.</desc> > > </valItem> > > <valItem ident="romanlower"> > > <desc>Lower case Roman numerals.</desc> > > </valItem> > > <valItem ident="romanupper"> > > <desc>Upper case Roman numerals.</desc> > > </valItem> > > </valList> > > </attDef> > > </attList> > > > > Any list without one of these attributes (a list cannot have both) should be > assumed to be "simple"; that is, without any mark or order. This is NOT > procedural markup, just somewhat more descriptive than what used to be > allowed. J > > > > -- > > p. > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702<tel:434-982-2702> (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151110/5490ee0b/attachment.html> From pdr4h at eservices.virginia.edu Tue Nov 10 04:42:35 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 10 Nov 2015 03:42:35 +0000 Subject: [MEI-L] list-related changes In-Reply-To: <FF54F3D2-FD91-4A72-AA70-587370E26948@mail.mcgill.ca> References: <12762_1447103110_56410A85_12762_245_1_BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu>, <FF54F3D2-FD91-4A72-AA70-587370E26948@mail.mcgill.ca> Message-ID: <BBCC497C40D85642B90E9F94FC30343D7C7227F8@reagan.eservices.virginia.edu> Consider it punted. As far as I'm concerned, the work on the next release is done. Someone else can sort it out later. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] Sent: Monday, November 09, 2015 6:18 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes When do you plan on doing this? Can we punt this until after the MEI 3.0.0 release? On Nov 9, 2015, at 9:03 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: I’d like to make it easier to control the formatting of lists from within the document markup rather than pushing it off entirely to CSS or othe, external formatting procedures. To this end, I plan to remove the current @form attribute and create a new att.listrend attribute class containing @mark and @order attributes -- <attList> <attDef ident="mark" usage="opt"> <desc>Contains the character string (usually a single character, such as a bullet, box, dash, etc.) that precedes each item in the list.</desc> <datatype> <rng:data type="string"/> </datatype> </attDef> <attDef ident="order" usage="opt"> <desc>Indicates the system used to generate the character string (usually a single character) that precedes items in an ordered list.</desc> <datatype> <rng:data type="NMTOKEN"/> </datatype> <valList type="semi"> <valItem ident="alphalower"> <desc>Lower case letters.</desc> </valItem> <valItem ident="alphaupper"> <desc>Upper case letters.</desc> </valItem> <valItem ident="arabic"> <desc>Arabic numerals.</desc> </valItem> <valItem ident="romanlower"> <desc>Lower case Roman numerals.</desc> </valItem> <valItem ident="romanupper"> <desc>Upper case Roman numerals.</desc> </valItem> </valList> </attDef> </attList> Any list without one of these attributes (a list cannot have both) should be assumed to be “simple”; that is, without any mark or order. This is NOT procedural markup, just somewhat more descriptive than what used to be allowed. :) -- p. ________________________________ Perry Roland University of Virginia P. O. Box 400874 Charlottesville, VA, 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151110/4ad409ab/attachment.html> From stadler at edirom.de Tue Nov 10 08:22:40 2015 From: stadler at edirom.de (Peter Stadler) Date: Tue, 10 Nov 2015 08:22:40 +0100 Subject: [MEI-L] list-related changes In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D7C7227F8@reagan.eservices.virginia.edu> References: <12762_1447103110_56410A85_12762_245_1_BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> <FF54F3D2-FD91-4A72-AA70-587370E26948@mail.mcgill.ca> <BBCC497C40D85642B90E9F94FC30343D7C7227F8@reagan.eservices.virginia.edu> Message-ID: <D178AABF-C9E4-4C84-9E9F-39EC70527033@edirom.de> BTW, I’d consider it best practice to file issues at GitHub for all your proposed changes. That way we can keep track of the discussion and the decisions. Cheers Peter > Am 10.11.2015 um 04:42 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>: > > > Consider it punted. As far as I'm concerned, the work on the next release is done. Someone else can sort it out later. > > -- > p. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca] > Sent: Monday, November 09, 2015 6:18 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > When do you plan on doing this? > > Can we punt this until after the MEI 3.0.0 release? > > >> On Nov 9, 2015, at 9:03 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu> wrote: >> >> >> I’d like to make it easier to control the formatting of lists from within the document markup rather than pushing it off entirely to CSS or othe, external formatting procedures. >> >> To this end, I plan to remove the current @form attribute and create a new att.listrend attribute class containing @mark and @order attributes -- >> >> <attList> >> <attDef ident="mark" usage="opt"> >> <desc>Contains the character string (usually a single character, such as a bullet, >> box, dash, etc.) that precedes each item in the list.</desc> >> <datatype> >> <rng:data type="string"/> >> </datatype> >> </attDef> >> <attDef ident="order" usage="opt"> >> <desc>Indicates the system used to generate the character string (usually a single >> character) that precedes items in an ordered list.</desc> >> <datatype> >> <rng:data type="NMTOKEN"/> >> </datatype> >> <valList type="semi"> >> <valItem ident="alphalower"> >> <desc>Lower case letters.</desc> >> </valItem> >> <valItem ident="alphaupper"> >> <desc>Upper case letters.</desc> >> </valItem> >> <valItem ident="arabic"> >> <desc>Arabic numerals.</desc> >> </valItem> >> <valItem ident="romanlower"> >> <desc>Lower case Roman numerals.</desc> >> </valItem> >> <valItem ident="romanupper"> >> <desc>Upper case Roman numerals.</desc> >> </valItem> >> </valList> >> </attDef> >> </attList> >> >> Any list without one of these attributes (a list cannot have both) should be assumed to be “simple”; that is, without any mark or order. This is NOT procedural markup, just somewhat more descriptive than what used to be allowed. J >> >> -- >> p. >> ________________________________ >> Perry Roland >> University of Virginia >> P. O. Box 400874 >> Charlottesville, VA, 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> >> _______________________________________________ >> 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 -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151110/f8169008/attachment.sig> From atge at kb.dk Tue Nov 10 14:09:17 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Tue, 10 Nov 2015 13:09:17 +0000 Subject: [MEI-L] FW: changes to <eventList> and <event> In-Reply-To: <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> References: <BBCC497C40D85642B90E9F94FC30343D7C722600@reagan.eservices.virginia.edu> <A348F6E5-1E8B-40FB-BA7A-6372EF374912@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C722651@reagan.eservices.virginia.edu> <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72276F@reagan.eservices.virginia.edu> <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk> Hi Johannes & Perry This discussion is started on both MEI-L and MEI-Catalog-IG; I'm posting my reply to both lists, but in order not to exclude anyone now I suggest we continue the discussion on MEI-L only. I agree with Johannes that an alternating sequence of date and event elements would be a way of looking for trouble. If I want to delete an event or change the order of events, I would have to make sure always to do the same with the preceding date sibling. If there is any. I would definitely prefer being able to address an event or group of events as a single element without having to care about any siblings. Also, Perry's model (if I read your suggestion correctly) implies that it would not be possible to have an <event> without a preceding <date>. But we are not always able to date events. Even if <date> could be left empty, the construct would seem somehow awkward to me. Finally, from a purely practical perspective, the way we handle elements would make it a pain to maintain and edit such a list of alternating elements. If we are introducing <eventGrp>, we have a clear way of distinguishing a list of events (that is, a possibly unordered, non-grouped <eventList>) from a group of events that have something in common. Let's not mix them up. If we want to group events by date, we could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>): <eventList> <event><!-- some single event --></event> <eventGrp> <!-- a group of events --> <date><!-- the grouping parameter - could also be geogName etc. instead --></date> <event><!-- event 1 --></event> <event><!-- event 2 etc. --></event> </eventGrp> </eventList> Alternatively, the @isodate approach could be used on <eventGrp>. /axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Johannes Kepper Sendt: 10. november 2015 00:20 Til: Music Encoding Initiative Emne: Re: [MEI-L] FW: changes to <eventList> and <event> Hi Perry, I understand (and fully support) your motivation to clean up events. However, could you please refresh my memory and indicate the current / planned content of event? Maybe I understand your proposal to move all these things out of events better with that model in mind. As you know, we use even annots in a data-like way, and while I agree that both annots and events are perfectly valid to take free-form content, I'm still in love with structured things - maybe just a couple of attributes. Or would it be an alternative to provide separate elements for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>? Just guessing. jo Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>: > > Our current handling of <eventList> is a mess, which reduces its > effectiveness for data interchange and interoperability. Clarifying > its possible content can counteract this tendency. It's relatively > easy to provide alternative grouping mechanisms. For instance, a > content model for <eventList> like -- > > <content> > <rng:zeroOrMore> > <rng:ref name="model.headLike"/> > </rng:zeroOrMore> > <rng:optional> > <rng:ref name="listHead"/> > </rng:optional> > <rng:zeroOrMore> > <rng:group> > <rng:choice> > <rng:ref name="model.eventPart"/> > </rng:choice> > <rng:choice> > <rng:ref name="event"/> > <rng:ref name="eventGrp"/> > </rng:choice> > </rng:group> > </rng:zeroOrMore> > <rng:zeroOrMore> > <rng:ref name="biblList"/> > </rng:zeroOrMore> > </content> > > would allow any member of model.eventPart to act as the organizing > "term". For instance, > > <eventList> > <date><!-- date of event --></date> > <event><!-- event description --></event> > <!-- and so on --> > </eventList> > > or > > <eventList> > <geogName><!-- place of event --></geogName> > <event><!-- event description --></event> > <!-- and so on --> > </eventList> > > or > > <eventList> > <persName><!-- personal name, of conductor for example --></persName> > <event><!-- event description --></event> > <!-- and so on --> > </eventList> > > are all possible. This is the essentially the model used by HTML for <dl>, by EAD for <chronlist>, and by TEI for <list> of @type "gloss". The difficulty, of course, is ensuring that each event in a list is preceded by the same kind of element. I'm not sure if this is possible using RNG alone, but it can certainly be enforced using Schematron. > > -- > p. > > >> -----Original Message----- >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >> Of Johannes Kepper >> Sent: Monday, November 09, 2015 4:40 PM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> >> >> >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) >> <pdr4h at eservices.virginia.edu>: >> >>> >>> An <eventGrp> element containing <event> with the current model >>> makes >> no sense as there's no indication of the grouping criterion. The >> <date> followed by <eventGrp> construct makes it clear that the >> events are grouped by date. In fact, that's the only way to group them using this model. >> >> Ok, what constitutes a group of events? What does it mean to have >> events grouped? Is there any other grouping mechanism other than by >> date? Does it make sense to have events grouped by place? If so, why >> don't we factor in groups (by date, for instance) and subgroups (by >> place)? Or is it maybe better to let the grouping be done by >> applications, based on structured markup like @isodate, @resp, @type and similar options? >> >>> >>> It is nothing like the concept of chords that you raise. >> >> I need to look into the preceding sibling to fully understand the >> current element... >> >>> Order is a good thing here as it makes the structure of the data clear. >>> >> >> jo >> >>> -- >>> p. >>> >>> >>>> -----Original Message----- >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf >>>> Of Johannes Kepper >>>> Sent: Monday, November 09, 2015 4:20 PM >>>> To: Music Encoding Initiative >>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> >>>> >>>> I'm sorry to say, but I'm not convinced by this one either. I see >>>> the point to have an eventGroup element, but everything else seems >>>> rather dubious to me. By all means, I would like to keep the date >>>> inside events, even for free- form text-driven events (in contrast >>>> to data-driven events). Also, I hate the idea to have an >>>> alternation of events and something, and have to rely on document >>>> order to understand the meaning of something - this gets pretty >>>> close to MusicXML's concept of chords, doesn't it? Are there any >>>> real-world limitations that motivate this proposal? If so, could we >>>> discuss it with >> those examples on the table? >>>> >>>> jo >>>> >>>> >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) >>>> <pdr4h at eservices.virginia.edu>: >>>> >>>>> >>>>> I sent this message to the cataloging interest group list earlier. >>>>> I apologize if >>>> you receive it twice, but I thought it would be a good idea to post >>>> to this list as well in the interest of generating as much >>>> discussion as >> possible. >>>>> >>>>> BTW, this is not a new feature, but rather a remedy for an >>>>> existing bug. But >>>> I think it's finally squashed this time. >>>>> >>>>> -- >>>>> p. >>>>> >>>>> >>>>> From: Roland, Perry D. (pdr4h) >>>>> Sent: Monday, November 09, 2015 3:46 PM >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de' >>>>> Subject: changes to <eventList> and <event> >>>>> >>>>> >>>>> I know we've had a few rounds of discussion about the content >>>>> models of >>>> <eventList> and <event> in the past. I think there are basically 2 >>>> issues currently facing us: >>>>> >>>>> * eventList contains a bug that doesn't allow grouping events that >> share >>>> the same date >>>>> * the model of event is too vague >>>>> >>>>> I propose to remedy the first problem by using the following >>>>> content model >>>> for <eventList>: >>>>> >>>>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) >>>>> >>>>> By placing <date> outside the model of <event>, the main content >>>>> of <eventList> can be constrained to be any number of pairs of >>>>> <date> and <event> elements, like so - >>>>> >>>>> <eventList> >>>>> <date><!-- when "it" happened --></date> >>>>> <event><!-- what happened --> >>>>> <date><!-- another happening --></date> >>>>> <event><!-- another description --> >>>>> <!-- and so on --> >>>>> </eventList> >>>>> >>>>> Or, when multiple events share the same date, like so -- >>>>> >>>>> <eventList> >>>>> <date><!-- the date --></date> >>>>> <eventGrp> <!-- the events occurring on the date --> >>>>> <event>Event 1</event> >>>>> <event> Event 2</event> >>>>> <!-- and so on --> >>>>> </eventGrp> >>>>> </eventList> >>>>> >>>>> The new model also introduces listHead, a new formatting element. >>>>> <listHead> contains a pair of <head> elements, one for each column >>>>> in the eventList date-event pair. This makes it possible to treat >>>>> the list of events as though it were a table with a column heading >>>>> for the dates and a heading for the descriptions. Of course, >>>>> eventList/head continues to contain a heading for the entire list >>>>> -- >>>>> >>>>> <eventList> >>>>> <head>My List o' Special Events</head> <listHead> >>>>> <head>When</head> >>>>> <head>What</head> >>>>> </listHead> >>>>> <event/> >>>>> <event/> >>>>> </eventList> >>>>> >>>>> I plan to investigate how this might work for other lists as well, >>>>> such as >>>> <biblList>, <castList>, and <list>. Any list that allows a label >>>> preceding its "items" could benefit from this treatment, I think. >>>>> >>>>> One more change -- <eventList> is now a member of model.listLike, >>>> meaning it can occur not just in the header but anywhere a "regular" >>>> list can happen. >>>>> >>>>> The <event> element now has the following model (switching to RNG >>>>> as it's somewhat clearer than DTD syntax) -- >>>>> >>>>> <content> >>>>> <rng:optional> >>>>> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> >>>>> <!-- data-like organization --> >>>>> <rng:zeroOrMore> >>>>> <rng:choice> >>>>> <rng:ref name="model.eventPart"/> >>>>> <rng:ref name="eventList"/> >>>>> </rng:choice> >>>>> </rng:zeroOrMore> >>>>> <!-- free-form organization --> >>>>> <rng:zeroOrMore> >>>>> <rng:choice> >>>>> <!-- model.listLike is expanded here in order to disallow biblList --> >>>>> <rng:ref name="model.pLike"/> >>>>> <rng:ref name="model.tableLike"/> >>>>> <rng:ref name="castList"/> >>>>> <rng:ref name="eventList"/> >>>>> <rng:ref name="list"/> >>>>> </rng:choice> >>>>> </rng:zeroOrMore> >>>>> </rng:choice> >>>>> <rng:zeroOrMore> >>>>> <rng:ref name="biblList"/> >>>>> </rng:zeroOrMore> >>>>> </content> >>>>> >>>>> English translation is "an optional label, followed by EITHER some >>>>> data-like >>>> elements or nested eventLists OR any number of paragraphs, tables, >>>> castLists, eventLists, or lists, followed by any number of lists of >>>> bibliographic citations." >>>>> >>>>> The central choice (a data-centric organization OR a free-form >>>>> text >>>>> one) is the important factor here. In purely practical terms, any >>>>> file that formerly used a group of data elements followed by a >>>>> paragraph will have to be translated into -- >>>>> >>>>> <event> >>>>> <label><!-- former paragraph content --> <geogName/><persName/> >>>>> <!-- etc. --> </event> >>>>> >>>>> This element re-naming and re-ordering is not a difficult task and >>>>> can be >>>> made part of the 2013 -> 2015 XSLT transformation. If the >>>> re-ordering poses a significant issue (that is, you *must* have the >>>> data elements followed by the label), I think it's not a problem to >>>> allow >> that, but please let me know. >>>>> >>>>> As always, I apologize for the length of the message and the XML >>>>> "gobbledy-gook". I just don't know of any other way to communicate. >>>>> ;-) >>>>> >>>>> -- >>>>> p. >>>>> >>>>> ________________________________ >>>>> Perry Roland >>>>> University of Virginia >>>>> P. O. Box 400874 >>>>> Charlottesville, VA, 22904 >>>>> 434-982-2702 (w) >>>>> pdr4h (at) virginia (dot) edu >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Nov 11 17:43:14 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Nov 2015 16:43:14 +0000 Subject: [MEI-L] FW: changes to <eventList> and <event> In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk> References: <BBCC497C40D85642B90E9F94FC30343D7C722600@reagan.eservices.virginia.edu> <A348F6E5-1E8B-40FB-BA7A-6372EF374912@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C722651@reagan.eservices.virginia.edu> <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72276F@reagan.eservices.virginia.edu> <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk> Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D338313@grant1.eservices.virginia.edu> Hi Axel, I was coming to a similar conclusion, so thanks for proposing a compromise solution. Your model of eventGrp, however, doesn't allow for continued nesting of <eventGrp> elements. So, I'd like to counter with the following models which merge eventList and eventGrp into a single entity -- For eventList: <content> <rng:zeroOrMore> <rng:ref name="model.headLike"/> </rng:zeroOrMore> <rng:zeroOrMore> <rng:group> <!-- an organizing data element --> <rng:optional> <rng:ref name="model.eventPart"/> </rng:optional> <!-- an event description or another list of events --> <rng:choice> <rng:ref name="event"/> <rng:ref name="eventList"/> </rng:choice> </rng:group> </rng:zeroOrMore> <!-- at the very end, lists of citations --> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> For event: <content> <rng:optional> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> <!-- data-like organization --> <rng:zeroOrMore> <rng:choice> <rng:ref name="model.eventPart"/> <rng:ref name="eventList"/> </rng:choice> </rng:zeroOrMore> <!-- free-form organization --> <rng:zeroOrMore> <rng:choice> <!-- model.listLike is expanded here in order to disallow biblList --> <rng:ref name="model.pLike"/> <rng:ref name="model.tableLike"/> <rng:ref name="castList"/> <rng:ref name="eventList"/> <rng:ref name="list"/> </rng:choice> </rng:zeroOrMore> </rng:choice> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> By making the "grouping key" optional, the model of <eventList> does allow for mixing of events grouped on a date, place, person, etc. and a "simple" list of events, but I see that as a good thing, not an impediment. This makes it possible to eliminate <eventGrp> and matches the behavior of other list-like structures (where a list contains a mixture of item and subordinate lists). Most importantly, the model of <event> now meets the original goal -- a clear distinction between a database-like approach to recording the event description and a free-text approach. I've removed the <listHead> formatting element. We can always take that up again at a later date. I still maintain that they're useful, but I'll also forego the @mark and @order formatting attributes. That battle can wait, too. -- p. > -----Original Message----- > From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni- > paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Tuesday, November 10, 2015 8:10 AM > To: Music Encoding Initiative > Cc: mei-catalog-ig at lists.uni-paderborn.de > Subject: Re: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and <event> > > Hi Johannes & Perry > > This discussion is started on both MEI-L and MEI-Catalog-IG; I'm posting my > reply to both lists, but in order not to exclude anyone now I suggest we > continue the discussion on MEI-L only. > > I agree with Johannes that an alternating sequence of date and event > elements would be a way of looking for trouble. If I want to delete an event > or change the order of events, I would have to make sure always to do the > same with the preceding date sibling. If there is any. I would definitely prefer > being able to address an event or group of events as a single element > without having to care about any siblings. Also, Perry's model (if I read your > suggestion correctly) implies that it would not be possible to have an <event> > without a preceding <date>. But we are not always able to date events. Even > if <date> could be left empty, the construct would seem somehow awkward > to me. > Finally, from a purely practical perspective, the way we handle elements > would make it a pain to maintain and edit such a list of alternating elements. > > If we are introducing <eventGrp>, we have a clear way of distinguishing a list > of events (that is, a possibly unordered, non-grouped <eventList>) from a > group of events that have something in common. Let's not mix them up. If > we want to group events by date, we could do so by allowing <date> or any > eventPart element within <eventGrp> (but not in <eventList>): > > <eventList> > <event><!-- some single event --></event> > <eventGrp> > <!-- a group of events --> > <date><!-- the grouping parameter - could also be geogName etc. instead - > -></date> > <event><!-- event 1 --></event> > <event><!-- event 2 etc. --></event> > </eventGrp> > </eventList> > > Alternatively, the @isodate approach could be used on <eventGrp>. > > /axel > > -----Oprindelig meddelelse----- > Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På > vegne af Johannes Kepper > Sendt: 10. november 2015 00:20 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] FW: changes to <eventList> and <event> > > Hi Perry, > > I understand (and fully support) your motivation to clean up events. > However, could you please refresh my memory and indicate the current / > planned content of event? Maybe I understand your proposal to move all > these things out of events better with that model in mind. As you know, we > use even annots in a data-like way, and while I agree that both annots and > events are perfectly valid to take free-form content, I'm still in love with > structured things - maybe just a couple of attributes. Or would it be an > alternative to provide separate elements for free-form and structured > content, like <annot> and <annotStruct> or <event> and <eventStruct>? > > Just guessing. > jo > > > Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) > <pdr4h at eservices.virginia.edu>: > > > > > Our current handling of <eventList> is a mess, which reduces its > > effectiveness for data interchange and interoperability. Clarifying > > its possible content can counteract this tendency. It's relatively > > easy to provide alternative grouping mechanisms. For instance, a > > content model for <eventList> like -- > > > > <content> > > <rng:zeroOrMore> > > <rng:ref name="model.headLike"/> > > </rng:zeroOrMore> > > <rng:optional> > > <rng:ref name="listHead"/> > > </rng:optional> > > <rng:zeroOrMore> > > <rng:group> > > <rng:choice> > > <rng:ref name="model.eventPart"/> > > </rng:choice> > > <rng:choice> > > <rng:ref name="event"/> > > <rng:ref name="eventGrp"/> > > </rng:choice> > > </rng:group> > > </rng:zeroOrMore> > > <rng:zeroOrMore> > > <rng:ref name="biblList"/> > > </rng:zeroOrMore> > > </content> > > > > would allow any member of model.eventPart to act as the organizing > > "term". For instance, > > > > <eventList> > > <date><!-- date of event --></date> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <geogName><!-- place of event --></geogName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <persName><!-- personal name, of conductor for example -- > ></persName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > are all possible. This is the essentially the model used by HTML for <dl>, by > EAD for <chronlist>, and by TEI for <list> of @type "gloss". The difficulty, of > course, is ensuring that each event in a list is preceded by the same kind of > element. I'm not sure if this is possible using RNG alone, but it can certainly > be enforced using Schematron. > > > > -- > > p. > > > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Johannes Kepper > >> Sent: Monday, November 09, 2015 4:40 PM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >> > >> > >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) > >> <pdr4h at eservices.virginia.edu>: > >> > >>> > >>> An <eventGrp> element containing <event> with the current model > >>> makes > >> no sense as there's no indication of the grouping criterion. The > >> <date> followed by <eventGrp> construct makes it clear that the > >> events are grouped by date. In fact, that's the only way to group them > using this model. > >> > >> Ok, what constitutes a group of events? What does it mean to have > >> events grouped? Is there any other grouping mechanism other than by > >> date? Does it make sense to have events grouped by place? If so, why > >> don't we factor in groups (by date, for instance) and subgroups (by > >> place)? Or is it maybe better to let the grouping be done by > >> applications, based on structured markup like @isodate, @resp, @type > and similar options? > >> > >>> > >>> It is nothing like the concept of chords that you raise. > >> > >> I need to look into the preceding sibling to fully understand the > >> current element... > >> > >>> Order is a good thing here as it makes the structure of the data clear. > >>> > >> > >> jo > >> > >>> -- > >>> p. > >>> > >>> > >>>> -----Original Message----- > >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >>>> Of Johannes Kepper > >>>> Sent: Monday, November 09, 2015 4:20 PM > >>>> To: Music Encoding Initiative > >>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >>>> > >>>> I'm sorry to say, but I'm not convinced by this one either. I see > >>>> the point to have an eventGroup element, but everything else seems > >>>> rather dubious to me. By all means, I would like to keep the date > >>>> inside events, even for free- form text-driven events (in contrast > >>>> to data-driven events). Also, I hate the idea to have an > >>>> alternation of events and something, and have to rely on document > >>>> order to understand the meaning of something - this gets pretty > >>>> close to MusicXML's concept of chords, doesn't it? Are there any > >>>> real-world limitations that motivate this proposal? If so, could we > >>>> discuss it with > >> those examples on the table? > >>>> > >>>> jo > >>>> > >>>> > >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) > >>>> <pdr4h at eservices.virginia.edu>: > >>>> > >>>>> > >>>>> I sent this message to the cataloging interest group list earlier. > >>>>> I apologize if > >>>> you receive it twice, but I thought it would be a good idea to post > >>>> to this list as well in the interest of generating as much > >>>> discussion as > >> possible. > >>>>> > >>>>> BTW, this is not a new feature, but rather a remedy for an > >>>>> existing bug. But > >>>> I think it's finally squashed this time. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> > >>>>> From: Roland, Perry D. (pdr4h) > >>>>> Sent: Monday, November 09, 2015 3:46 PM > >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de' > >>>>> Subject: changes to <eventList> and <event> > >>>>> > >>>>> > >>>>> I know we've had a few rounds of discussion about the content > >>>>> models of > >>>> <eventList> and <event> in the past. I think there are basically 2 > >>>> issues currently facing us: > >>>>> > >>>>> * eventList contains a bug that doesn't allow grouping events that > >> share > >>>> the same date > >>>>> * the model of event is too vague > >>>>> > >>>>> I propose to remedy the first problem by using the following > >>>>> content model > >>>> for <eventList>: > >>>>> > >>>>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > >>>>> > >>>>> By placing <date> outside the model of <event>, the main content > >>>>> of <eventList> can be constrained to be any number of pairs of > >>>>> <date> and <event> elements, like so - > >>>>> > >>>>> <eventList> > >>>>> <date><!-- when "it" happened --></date> > >>>>> <event><!-- what happened --> > >>>>> <date><!-- another happening --></date> > >>>>> <event><!-- another description --> > >>>>> <!-- and so on --> > >>>>> </eventList> > >>>>> > >>>>> Or, when multiple events share the same date, like so -- > >>>>> > >>>>> <eventList> > >>>>> <date><!-- the date --></date> > >>>>> <eventGrp> <!-- the events occurring on the date --> > >>>>> <event>Event 1</event> > >>>>> <event> Event 2</event> > >>>>> <!-- and so on --> > >>>>> </eventGrp> > >>>>> </eventList> > >>>>> > >>>>> The new model also introduces listHead, a new formatting element. > >>>>> <listHead> contains a pair of <head> elements, one for each column > >>>>> in the eventList date-event pair. This makes it possible to treat > >>>>> the list of events as though it were a table with a column heading > >>>>> for the dates and a heading for the descriptions. Of course, > >>>>> eventList/head continues to contain a heading for the entire list > >>>>> -- > >>>>> > >>>>> <eventList> > >>>>> <head>My List o' Special Events</head> <listHead> > >>>>> <head>When</head> > >>>>> <head>What</head> > >>>>> </listHead> > >>>>> <event/> > >>>>> <event/> > >>>>> </eventList> > >>>>> > >>>>> I plan to investigate how this might work for other lists as well, > >>>>> such as > >>>> <biblList>, <castList>, and <list>. Any list that allows a label > >>>> preceding its "items" could benefit from this treatment, I think. > >>>>> > >>>>> One more change -- <eventList> is now a member of model.listLike, > >>>> meaning it can occur not just in the header but anywhere a "regular" > >>>> list can happen. > >>>>> > >>>>> The <event> element now has the following model (switching to RNG > >>>>> as it's somewhat clearer than DTD syntax) -- > >>>>> > >>>>> <content> > >>>>> <rng:optional> > >>>>> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> > >>>>> <!-- data-like organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <rng:ref name="model.eventPart"/> > >>>>> <rng:ref name="eventList"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> <!-- free-form organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <!-- model.listLike is expanded here in order to disallow biblList --> > >>>>> <rng:ref name="model.pLike"/> > >>>>> <rng:ref name="model.tableLike"/> > >>>>> <rng:ref name="castList"/> > >>>>> <rng:ref name="eventList"/> > >>>>> <rng:ref name="list"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> </rng:choice> > >>>>> <rng:zeroOrMore> > >>>>> <rng:ref name="biblList"/> > >>>>> </rng:zeroOrMore> > >>>>> </content> > >>>>> > >>>>> English translation is "an optional label, followed by EITHER some > >>>>> data-like > >>>> elements or nested eventLists OR any number of paragraphs, tables, > >>>> castLists, eventLists, or lists, followed by any number of lists of > >>>> bibliographic citations." > >>>>> > >>>>> The central choice (a data-centric organization OR a free-form > >>>>> text > >>>>> one) is the important factor here. In purely practical terms, any > >>>>> file that formerly used a group of data elements followed by a > >>>>> paragraph will have to be translated into -- > >>>>> > >>>>> <event> > >>>>> <label><!-- former paragraph content --> <geogName/><persName/> > >>>>> <!-- etc. --> </event> > >>>>> > >>>>> This element re-naming and re-ordering is not a difficult task and > >>>>> can be > >>>> made part of the 2013 -> 2015 XSLT transformation. If the > >>>> re-ordering poses a significant issue (that is, you *must* have the > >>>> data elements followed by the label), I think it's not a problem to > >>>> allow > >> that, but please let me know. > >>>>> > >>>>> As always, I apologize for the length of the message and the XML > >>>>> "gobbledy-gook". I just don't know of any other way to communicate. > >>>>> ;-) > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> ________________________________ > >>>>> Perry Roland > >>>>> University of Virginia > >>>>> P. O. Box 400874 > >>>>> Charlottesville, VA, 22904 > >>>>> 434-982-2702 (w) > >>>>> pdr4h (at) virginia (dot) edu > >>>>> > >>>>> _______________________________________________ > >>>>> 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-catalog-ig mailing list > mei-catalog-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig From pdr4h at eservices.virginia.edu Wed Nov 11 23:36:02 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Wed, 11 Nov 2015 22:36:02 +0000 Subject: [MEI-L] list-related changes In-Reply-To: <CAMyHAnOf6so-MFYuW+Qk4L5cihZOxu9yaY6UhOnidC0Ctrj_Bw@mail.gmail.com> References: <BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72266A@reagan.eservices.virginia.edu> <CAMyHAnMCTObrMxFTUSsgUTw=Pr5v5tq1DoQXcMtDRC83sWcRWw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C7226DB@reagan.eservices.virginia.edu> <CAMyHAnNOxirm6BzPF_ja2TxZ7vN8EVcBRtDzxRSK_hhQLFACtw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C72278D@reagan.eservices.virginia.edu> <CAMyHAnOf6so-MFYuW+Qk4L5cihZOxu9yaY6UhOnidC0Ctrj_Bw@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D338BD7@grant1.eservices.virginia.edu> Raff, I understand TEI’s method, but I don’t think it’s feasible in MEI. Musical elements are frequently adjusted in terms of typography and location individually, making it very difficult to use a class-based methodology (even an ad hoc one) like TEI uses. Furthermore, it’s better (i.e., more consistent) if musical and text elements behave in the same way, so it doesn’t make sense to adopt the TEI way for text and not for musical elements. Until a generally useful style language for music notation is available, I believe the current approach is the best option. If we’re going to allow formatting attributes on musical elements, then why not allow them on text elements as well (for consistency’s sake), especially if their use can be contained to <rend> and a few list-like elements? -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 6:57 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes On Mon, Nov 9, 2015 at 6:15 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: MEI doesn’t mix declarative and procedural markup any more than TEI, does it? When it comes to text encoding it does - I can't think of a procedural element in TEI. If you can, let me know because it shouldn't be there. A reasonable mix is necessary for a general-use markup scheme. Furthermore, I don’t agree that what I’m proposing is procedural markup. Saying that an item in a list has a bullet or is marked with a Roman numeral isn’t procedural in nature, it’s descriptive. It’s just as descriptive as using <title>War and Peace to indicate that the content is a title and not a person’s name, just in a different way. No, and are of the same kind, but the type of bullet is equivalent to saying that titles need to be underlined or double underlined. (There is certainly a semantic difference between ordered and unordered lists, but how they are rendered on the page is a different matter). I agree that you might not want to use this kind of thing for MEI that describes born-digital material (where the author controls the rendition), but it’s essential for describing already-existing material, especially if it is non-standard in some way, for example if it contains a printing error that caused an item in an otherwise-numbered list to be labelled with an “A”. How could one possibly *describe* this situation without saying anything about the bullets? Putting this kind of information in a CSS file is just moving the problem. The markup no longer contains any information about the bullets, but the CSS does and without it (the CSS) the MEI doesn’t effectively *describe* its source so the two have to be interpreted together. There’s a false sense of having separated the content and presentation in this case. I don't disagree, but CSS is a more useful system than mixing in CSS-like values in MEI - which is what has caused my objection to arise. The way TEI handles this is by creating categories: list X is of a special type and has a specific rendition. The rendition is then expressed using adequate systems, not TEI (and the code can be embedded if you want to keep everything in one file). The ODD allows you to document why the special type is needed and how that impacts the rest of your customization. Not saying that this is *the* only way to handle this, but it works. Raff -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:29 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes The bad idea is adding procedural markup to lists. Text encoding in MEI mixes declarative and procedural markup, particularly through <rend>. I think I understand the overall need for it, for example as a catch-all when converting from other music notation systems that keep procedural information about text. But it's not an element that I would necessarily want to use when creating new MEI files. So I would avoid adding more procedural markup in the text encoding side of MEI. On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: I’m not sure what you think is a bad idea or what you mean mean by “already compromised”. Can you elaborate please? From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti Sent: Monday, November 09, 2015 5:00 PM To: Music Encoding Initiative Subject: Re: [MEI-L] list-related changes I think this is a bad idea. Whatever target format / platform will display the MEI should be able to access a basic text-styling system that can target, if not the MEI directly, at least a target output. Text encoding in MEI is already compromised, so we either continue being careless in that matter, or we can avoid making it worse. Another approach would be adopting a system that would make it easy to embed styling, such as TEI's @rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.rendition.html#tei_att.rendition> (and <rendition<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rendition.html>>). In this way you can have the cake and eat it too. Raff On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Putting the mark in the markup -- [Unicode for bullet] item 1 [Unicode for bullet] item 2 etc. denies the opportunity to treat the bullet separately from the item content. Your suggested approach mixes what is presentational with actual content. That's generally a bad idea. > -----Original Message----- > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of > Johannes Kepper > Sent: Monday, November 09, 2015 4:09 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] list-related changes > > I'm sorry to say, but I see no need to include that in MEI. If I want to be > descriptive, I can include the mark in the encoding itself. But of course you're > free to convince me and anyone else who's not convinced yet :-) > > jo > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>: > > > > > I'd like to make it easier to control the formatting of lists from within the > document markup rather than pushing it off entirely to CSS or othe, external > formatting procedures. > > > > To this end, I plan to remove the current @form attribute and create a new > att.listrend attribute class containing @mark and @order attributes -- > > > > <attList> > > <attDef ident="mark" usage="opt"> > > <desc>Contains the character string (usually a single character, such as a > bullet, > > box, dash, etc.) that precedes each item in the list.</desc> > > <datatype> > > <rng:data type="string"/> > > </datatype> > > </attDef> > > <attDef ident="order" usage="opt"> > > <desc>Indicates the system used to generate the character string (usually > a single > > character) that precedes items in an ordered list.</desc> > > <datatype> > > <rng:data type="NMTOKEN"/> > > </datatype> > > <valList type="semi"> > > <valItem ident="alphalower"> > > <desc>Lower case letters.</desc> > > </valItem> > > <valItem ident="alphaupper"> > > <desc>Upper case letters.</desc> > > </valItem> > > <valItem ident="arabic"> > > <desc>Arabic numerals.</desc> > > </valItem> > > <valItem ident="romanlower"> > > <desc>Lower case Roman numerals.</desc> > > </valItem> > > <valItem ident="romanupper"> > > <desc>Upper case Roman numerals.</desc> > > </valItem> > > </valList> > > </attDef> > > </attList> > > > > Any list without one of these attributes (a list cannot have both) should be > assumed to be "simple"; that is, without any mark or order. This is NOT > procedural markup, just somewhat more descriptive than what used to be > allowed. J > > > > -- > > p. > > ________________________________ > > Perry Roland > > University of Virginia > > P. O. Box 400874 > > Charlottesville, VA, 22904 > > 434-982-2702<tel:434-982-2702> (w) > > pdr4h (at) virginia (dot) edu > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151111/69536545/attachment.html> From raffaeleviglianti at gmail.com Wed Nov 11 23:59:39 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 11 Nov 2015 17:59:39 -0500 Subject: [MEI-L] list-related changes In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D8D338BD7@grant1.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D7C7225DC@reagan.eservices.virginia.edu> <7E59FA99-E158-4B30-ADCE-AABB584CB951@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72266A@reagan.eservices.virginia.edu> <CAMyHAnMCTObrMxFTUSsgUTw=Pr5v5tq1DoQXcMtDRC83sWcRWw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C7226DB@reagan.eservices.virginia.edu> <CAMyHAnNOxirm6BzPF_ja2TxZ7vN8EVcBRtDzxRSK_hhQLFACtw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D7C72278D@reagan.eservices.virginia.edu> <CAMyHAnOf6so-MFYuW+Qk4L5cihZOxu9yaY6UhOnidC0Ctrj_Bw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D8D338BD7@grant1.eservices.virginia.edu> Message-ID: <CAMyHAnO==WkpRVHoH1WYiC8G3ZbJiyWWzYvZNTfUXvnY9Ct+_w@mail.gmail.com> You're right, TEI's system wouldn't fit well musical systems and indeed I didn't suggest to use it for those. However, I don't think we need consistency between styling of text and music elements: they do behave quite differently as you pointed out. On the other hand, I'm not sure text encoding in MEI really needs to be too all-encompassing. That's also why having an attribute class for list item bullet type seems out of scope to me. Raff On Nov 11, 2015 5:36 PM, "Roland, Perry D. (pdr4h)" < pdr4h at eservices.virginia.edu> wrote: > > > Raff, > > > > I understand TEI’s method, but I don’t think it’s feasible in MEI. > Musical elements are frequently adjusted in terms of typography and > location *individually*, making it very difficult to use a class-based > methodology (even an *ad hoc* one) like TEI uses. Furthermore, it’s > better (i.e., more consistent) if musical and text elements behave in the > same way, so it doesn’t make sense to adopt the TEI way for text and not > for musical elements. Until a generally useful style language for music > notation is available, I believe the current approach is the best option. > > > > If we’re going to allow formatting attributes on musical elements, then > why not allow them on text elements as well (for consistency’s sake), > especially if their use can be contained to <rend> and a few list-like > elements? > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 6:57 PM > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > On Mon, Nov 9, 2015 at 6:15 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > MEI doesn’t mix declarative and procedural markup any more than TEI, does > it? > > > > When it comes to text encoding it does - I can't think of a procedural > element in TEI. If you can, let me know because it shouldn't be there. > > > > A reasonable mix is necessary for a general-use markup scheme. > Furthermore, I don’t agree that what I’m proposing is procedural markup. > Saying that an item in a list has a bullet or is marked with a Roman > numeral isn’t procedural in nature, it’s descriptive. It’s just as > descriptive as using <title>War and Peace to indicate that the > content is a title and not a person’s name, just in a different way. > > > > No, and are of the same kind, but the type of bullet is > equivalent to saying that titles need to be underlined or double > underlined. (There is certainly a semantic difference between ordered and > unordered lists, but how they are rendered on the page is a different > matter). > > > > > > I agree that you might not want to use this kind of thing for MEI that > describes born-digital material (where the author controls the rendition), > but it’s essential for describing already-existing material, especially if > it is non-standard in some way, for example if it contains a printing error > that caused an item in an otherwise-numbered list to be labelled with an > “A”. How could one possibly *describe* this situation without saying > anything about the bullets? Putting this kind of information in a CSS file > is just moving the problem. The markup no longer contains any information > about the bullets, but the CSS does and without it (the CSS) the MEI > doesn’t effectively *describe* its source so the two have to be interpreted > together. There’s a false sense of having separated the content and > presentation in this case. > > > > > > I don't disagree, but CSS is a more useful system than mixing in CSS-like > values in MEI - which is what has caused my objection to arise. The way TEI > handles this is by creating categories: list X is of a special type and has > a specific rendition. The rendition is then expressed using adequate > systems, not TEI (and the code can be embedded if you want to keep > everything in one file). The ODD allows you to document why the special > type is needed and how that impacts the rest of your customization. Not > saying that this is *the* only way to handle this, but it works. > > > > Raff > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 5:29 PM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > The bad idea is adding procedural markup to lists. > > > > Text encoding in MEI mixes declarative and procedural markup, particularly > through <rend>. I think I understand the overall need for it, for example > as a catch-all when converting from other music notation systems that keep > procedural information about text. But it's not an element that I would > necessarily want to use when creating new MEI files. So I would avoid > adding more procedural markup in the text encoding side of MEI. > > > > On Mon, Nov 9, 2015 at 5:02 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > I’m not sure what you think is a bad idea or what you mean mean by > “already compromised”. Can you elaborate please? > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Monday, November 09, 2015 5:00 PM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] list-related changes > > > > I think this is a bad idea. Whatever target format / platform will display > the MEI should be able to access a basic text-styling system that can > target, if not the MEI directly, at least a target output. > > > > Text encoding in MEI is already compromised, so we either continue being > careless in that matter, or we can avoid making it worse. > > > > Another approach would be adopting a system that would make it easy to > embed styling, such as TEI's @rendition > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.global.rendition.html#tei_att.rendition> > (and <rendition > <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rendition.html>>). > In this way you can have the cake and eat it too. > > > > Raff > > > > On Mon, Nov 9, 2015 at 4:31 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > Putting the mark in the markup -- > > [Unicode for bullet] item 1 > [Unicode for bullet] item 2 > etc. > > denies the opportunity to treat the bullet separately from the item > content. Your suggested approach mixes what is presentational with actual > content. That's generally a bad idea. > > > > > -----Original Message----- > > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of > > Johannes Kepper > > Sent: Monday, November 09, 2015 4:09 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] list-related changes > > > > I'm sorry to say, but I see no need to include that in MEI. If I want to > be > > descriptive, I can include the mark in the encoding itself. But of > course you're > > free to convince me and anyone else who's not convinced yet :-) > > > > jo > > > > Am 09.11.2015 um 22:03 schrieb Roland, Perry D. (pdr4h) > > <pdr4h at eservices.virginia.edu>: > > > > > > > > I'd like to make it easier to control the formatting of lists from > within the > > document markup rather than pushing it off entirely to CSS or othe, > external > > formatting procedures. > > > > > > To this end, I plan to remove the current @form attribute and create a > new > > att.listrend attribute class containing @mark and @order attributes -- > > > > > > <attList> > > > <attDef ident="mark" usage="opt"> > > > <desc>Contains the character string (usually a single character, > such as a > > bullet, > > > box, dash, etc.) that precedes each item in the list.</desc> > > > <datatype> > > > <rng:data type="string"/> > > > </datatype> > > > </attDef> > > > <attDef ident="order" usage="opt"> > > > <desc>Indicates the system used to generate the character string > (usually > > a single > > > character) that precedes items in an ordered list.</desc> > > > <datatype> > > > <rng:data type="NMTOKEN"/> > > > </datatype> > > > <valList type="semi"> > > > <valItem ident="alphalower"> > > > <desc>Lower case letters.</desc> > > > </valItem> > > > <valItem ident="alphaupper"> > > > <desc>Upper case letters.</desc> > > > </valItem> > > > <valItem ident="arabic"> > > > <desc>Arabic numerals.</desc> > > > </valItem> > > > <valItem ident="romanlower"> > > > <desc>Lower case Roman numerals.</desc> > > > </valItem> > > > <valItem ident="romanupper"> > > > <desc>Upper case Roman numerals.</desc> > > > </valItem> > > > </valList> > > > </attDef> > > > </attList> > > > > > > Any list without one of these attributes (a list cannot have both) > should be > > assumed to be "simple"; that is, without any mark or order. This is NOT > > procedural markup, just somewhat more descriptive than what used to be > > allowed. J > > > > > > -- > > > p. > > > ________________________________ > > > Perry Roland > > > University of Virginia > > > P. O. Box 400874 > > > Charlottesville, VA, 22904 > > > 434-982-2702 (w) > > > pdr4h (at) virginia (dot) edu > > > > > > _______________________________________________ > > > 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151111/048c584a/attachment.html> From pdr4h at eservices.virginia.edu Thu Nov 12 21:49:07 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Thu, 12 Nov 2015 20:49:07 +0000 Subject: [MEI-L] MEI as XSD or DTD Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> Hello all, The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? -- 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151112/ef11c212/attachment.html> From annplaksin at gmx.net Fri Nov 13 09:18:23 2015 From: annplaksin at gmx.net (Anna Plaksin) Date: Fri, 13 Nov 2015 09:18:23 +0100 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> Message-ID: <00b601d11deb$dd76de50$98649af0$@gmx.net> Hello Perry, I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me. Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Donnerstag, 12. November 2015 21:49 An: mei-l at lists.uni-paderborn.de Betreff: [MEI-L] MEI as XSD or DTD Hello all, The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? -- p. ________________________________ Perry Roland University of Virginia P. O. Box 400874 Charlottesville, VA, 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/c882572a/attachment.html> From andrew.hankinson at mail.mcgill.ca Fri Nov 13 09:23:21 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 13 Nov 2015 08:23:21 +0000 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> Message-ID: <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> Hi Anna, I'm curious to know which tools are in use that don't support RelaxNG -- is there a quick example you can share? -Andrew > On Nov 13, 2015, at 8:18 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hello Perry, > > I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. > So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me… > > Regards, > Anna >   <> > Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de <mailto:mei-l-bounces at lists.uni-paderborn.de>] Im Auftrag von Roland, Perry D. (pdr4h) > Gesendet: Donnerstag, 12. November 2015 21:49 > An: mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> > Betreff: [MEI-L] MEI as XSD or DTD > > > Hello all, > > The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? > > -- > p. > > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/fe7bbce3/attachment.html> From atge at kb.dk Fri Nov 13 09:53:31 2015 From: atge at kb.dk (Axel Teich Geertinger) Date: Fri, 13 Nov 2015 08:53:31 +0000 Subject: [MEI-L] FW: changes to <eventList> and <event> In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D8D338313@grant1.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D7C722600@reagan.eservices.virginia.edu> <A348F6E5-1E8B-40FB-BA7A-6372EF374912@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C722651@reagan.eservices.virginia.edu> <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72276F@reagan.eservices.virginia.edu> <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk> <BBCC497C40D85642B90E9F94FC30343D8D338313@grant1.eservices.virginia.edu> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1013DEED3D2@EXCHANGE-02.kb.dk> Hi Perry Your eventList model looks fine to me. /axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 11. november 2015 17:43 Til: Music Encoding Initiative Emne: Re: [MEI-L] FW: changes to <eventList> and <event> Hi Axel, I was coming to a similar conclusion, so thanks for proposing a compromise solution. Your model of eventGrp, however, doesn't allow for continued nesting of <eventGrp> elements. So, I'd like to counter with the following models which merge eventList and eventGrp into a single entity -- For eventList: <content> <rng:zeroOrMore> <rng:ref name="model.headLike"/> </rng:zeroOrMore> <rng:zeroOrMore> <rng:group> <!-- an organizing data element --> <rng:optional> <rng:ref name="model.eventPart"/> </rng:optional> <!-- an event description or another list of events --> <rng:choice> <rng:ref name="event"/> <rng:ref name="eventList"/> </rng:choice> </rng:group> </rng:zeroOrMore> <!-- at the very end, lists of citations --> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> For event: <content> <rng:optional> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> <!-- data-like organization --> <rng:zeroOrMore> <rng:choice> <rng:ref name="model.eventPart"/> <rng:ref name="eventList"/> </rng:choice> </rng:zeroOrMore> <!-- free-form organization --> <rng:zeroOrMore> <rng:choice> <!-- model.listLike is expanded here in order to disallow biblList --> <rng:ref name="model.pLike"/> <rng:ref name="model.tableLike"/> <rng:ref name="castList"/> <rng:ref name="eventList"/> <rng:ref name="list"/> </rng:choice> </rng:zeroOrMore> </rng:choice> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> By making the "grouping key" optional, the model of <eventList> does allow for mixing of events grouped on a date, place, person, etc. and a "simple" list of events, but I see that as a good thing, not an impediment. This makes it possible to eliminate <eventGrp> and matches the behavior of other list-like structures (where a list contains a mixture of item and subordinate lists). Most importantly, the model of <event> now meets the original goal -- a clear distinction between a database-like approach to recording the event description and a free-text approach. I've removed the <listHead> formatting element. We can always take that up again at a later date. I still maintain that they're useful, but I'll also forego the @mark and @order formatting attributes. That battle can wait, too. -- p. > -----Original Message----- > From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni- > paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Tuesday, November 10, 2015 8:10 AM > To: Music Encoding Initiative > Cc: mei-catalog-ig at lists.uni-paderborn.de > Subject: Re: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and > <event> > > Hi Johannes & Perry > > This discussion is started on both MEI-L and MEI-Catalog-IG; I'm > posting my reply to both lists, but in order not to exclude anyone now > I suggest we continue the discussion on MEI-L only. > > I agree with Johannes that an alternating sequence of date and event > elements would be a way of looking for trouble. If I want to delete an > event or change the order of events, I would have to make sure always > to do the same with the preceding date sibling. If there is any. I > would definitely prefer being able to address an event or group of > events as a single element without having to care about any siblings. > Also, Perry's model (if I read your suggestion correctly) implies that > it would not be possible to have an <event> without a preceding > <date>. But we are not always able to date events. Even if <date> > could be left empty, the construct would seem somehow awkward to me. > Finally, from a purely practical perspective, the way we handle > elements would make it a pain to maintain and edit such a list of alternating elements. > > If we are introducing <eventGrp>, we have a clear way of > distinguishing a list of events (that is, a possibly unordered, > non-grouped <eventList>) from a group of events that have something in > common. Let's not mix them up. If we want to group events by date, we > could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>): > > <eventList> > <event><!-- some single event --></event> > <eventGrp> > <!-- a group of events --> > <date><!-- the grouping parameter - could also be geogName etc. > instead - > -></date> > <event><!-- event 1 --></event> > <event><!-- event 2 etc. --></event> > </eventGrp> > </eventList> > > Alternatively, the @isodate approach could be used on <eventGrp>. > > /axel > > -----Oprindelig meddelelse----- > Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På > vegne af Johannes Kepper > Sendt: 10. november 2015 00:20 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] FW: changes to <eventList> and <event> > > Hi Perry, > > I understand (and fully support) your motivation to clean up events. > However, could you please refresh my memory and indicate the current / > planned content of event? Maybe I understand your proposal to move all > these things out of events better with that model in mind. As you > know, we use even annots in a data-like way, and while I agree that > both annots and events are perfectly valid to take free-form content, > I'm still in love with structured things - maybe just a couple of > attributes. Or would it be an alternative to provide separate elements > for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>? > > Just guessing. > jo > > > Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) > <pdr4h at eservices.virginia.edu>: > > > > > Our current handling of <eventList> is a mess, which reduces its > > effectiveness for data interchange and interoperability. Clarifying > > its possible content can counteract this tendency. It's relatively > > easy to provide alternative grouping mechanisms. For instance, a > > content model for <eventList> like -- > > > > <content> > > <rng:zeroOrMore> > > <rng:ref name="model.headLike"/> > > </rng:zeroOrMore> > > <rng:optional> > > <rng:ref name="listHead"/> > > </rng:optional> > > <rng:zeroOrMore> > > <rng:group> > > <rng:choice> > > <rng:ref name="model.eventPart"/> > > </rng:choice> > > <rng:choice> > > <rng:ref name="event"/> > > <rng:ref name="eventGrp"/> > > </rng:choice> > > </rng:group> > > </rng:zeroOrMore> > > <rng:zeroOrMore> > > <rng:ref name="biblList"/> > > </rng:zeroOrMore> > > </content> > > > > would allow any member of model.eventPart to act as the organizing > > "term". For instance, > > > > <eventList> > > <date><!-- date of event --></date> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <geogName><!-- place of event --></geogName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <persName><!-- personal name, of conductor for example -- > ></persName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > are all possible. This is the essentially the model used by HTML > > for <dl>, by > EAD for <chronlist>, and by TEI for <list> of @type "gloss". The > difficulty, of course, is ensuring that each event in a list is > preceded by the same kind of element. I'm not sure if this is > possible using RNG alone, but it can certainly be enforced using Schematron. > > > > -- > > p. > > > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Johannes Kepper > >> Sent: Monday, November 09, 2015 4:40 PM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >> > >> > >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) > >> <pdr4h at eservices.virginia.edu>: > >> > >>> > >>> An <eventGrp> element containing <event> with the current model > >>> makes > >> no sense as there's no indication of the grouping criterion. The > >> <date> followed by <eventGrp> construct makes it clear that the > >> events are grouped by date. In fact, that's the only way to group > >> them > using this model. > >> > >> Ok, what constitutes a group of events? What does it mean to have > >> events grouped? Is there any other grouping mechanism other than by > >> date? Does it make sense to have events grouped by place? If so, > >> why don't we factor in groups (by date, for instance) and subgroups > >> (by place)? Or is it maybe better to let the grouping be done by > >> applications, based on structured markup like @isodate, @resp, > >> @type > and similar options? > >> > >>> > >>> It is nothing like the concept of chords that you raise. > >> > >> I need to look into the preceding sibling to fully understand the > >> current element... > >> > >>> Order is a good thing here as it makes the structure of the data clear. > >>> > >> > >> jo > >> > >>> -- > >>> p. > >>> > >>> > >>>> -----Original Message----- > >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On > >>>> Behalf Of Johannes Kepper > >>>> Sent: Monday, November 09, 2015 4:20 PM > >>>> To: Music Encoding Initiative > >>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >>>> > >>>> I'm sorry to say, but I'm not convinced by this one either. I see > >>>> the point to have an eventGroup element, but everything else > >>>> seems rather dubious to me. By all means, I would like to keep > >>>> the date inside events, even for free- form text-driven events > >>>> (in contrast to data-driven events). Also, I hate the idea to > >>>> have an alternation of events and something, and have to rely on > >>>> document order to understand the meaning of something - this gets > >>>> pretty close to MusicXML's concept of chords, doesn't it? Are > >>>> there any real-world limitations that motivate this proposal? If > >>>> so, could we discuss it with > >> those examples on the table? > >>>> > >>>> jo > >>>> > >>>> > >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) > >>>> <pdr4h at eservices.virginia.edu>: > >>>> > >>>>> > >>>>> I sent this message to the cataloging interest group list earlier. > >>>>> I apologize if > >>>> you receive it twice, but I thought it would be a good idea to > >>>> post to this list as well in the interest of generating as much > >>>> discussion as > >> possible. > >>>>> > >>>>> BTW, this is not a new feature, but rather a remedy for an > >>>>> existing bug. But > >>>> I think it's finally squashed this time. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> > >>>>> From: Roland, Perry D. (pdr4h) > >>>>> Sent: Monday, November 09, 2015 3:46 PM > >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de' > >>>>> Subject: changes to <eventList> and <event> > >>>>> > >>>>> > >>>>> I know we've had a few rounds of discussion about the content > >>>>> models of > >>>> <eventList> and <event> in the past. I think there are basically > >>>> 2 issues currently facing us: > >>>>> > >>>>> * eventList contains a bug that doesn't allow grouping events that > >> share > >>>> the same date > >>>>> * the model of event is too vague > >>>>> > >>>>> I propose to remedy the first problem by using the following > >>>>> content model > >>>> for <eventList>: > >>>>> > >>>>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > >>>>> > >>>>> By placing <date> outside the model of <event>, the main content > >>>>> of <eventList> can be constrained to be any number of pairs of > >>>>> <date> and <event> elements, like so - > >>>>> > >>>>> <eventList> > >>>>> <date><!-- when "it" happened --></date> > >>>>> <event><!-- what happened --> > >>>>> <date><!-- another happening --></date> > >>>>> <event><!-- another description --> > >>>>> <!-- and so on --> > >>>>> </eventList> > >>>>> > >>>>> Or, when multiple events share the same date, like so -- > >>>>> > >>>>> <eventList> > >>>>> <date><!-- the date --></date> > >>>>> <eventGrp> <!-- the events occurring on the date --> > >>>>> <event>Event 1</event> > >>>>> <event> Event 2</event> > >>>>> <!-- and so on --> > >>>>> </eventGrp> > >>>>> </eventList> > >>>>> > >>>>> The new model also introduces listHead, a new formatting element. > >>>>> <listHead> contains a pair of <head> elements, one for each > >>>>> column in the eventList date-event pair. This makes it possible > >>>>> to treat the list of events as though it were a table with a > >>>>> column heading for the dates and a heading for the descriptions. > >>>>> Of course, eventList/head continues to contain a heading for the > >>>>> entire list > >>>>> -- > >>>>> > >>>>> <eventList> > >>>>> <head>My List o' Special Events</head> <listHead> > >>>>> <head>When</head> > >>>>> <head>What</head> > >>>>> </listHead> > >>>>> <event/> > >>>>> <event/> > >>>>> </eventList> > >>>>> > >>>>> I plan to investigate how this might work for other lists as > >>>>> well, such as > >>>> <biblList>, <castList>, and <list>. Any list that allows a label > >>>> preceding its "items" could benefit from this treatment, I think. > >>>>> > >>>>> One more change -- <eventList> is now a member of > >>>>> model.listLike, > >>>> meaning it can occur not just in the header but anywhere a "regular" > >>>> list can happen. > >>>>> > >>>>> The <event> element now has the following model (switching to > >>>>> RNG as it's somewhat clearer than DTD syntax) -- > >>>>> > >>>>> <content> > >>>>> <rng:optional> > >>>>> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> > >>>>> <!-- data-like organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <rng:ref name="model.eventPart"/> > >>>>> <rng:ref name="eventList"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> <!-- free-form organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <!-- model.listLike is expanded here in order to disallow biblList --> > >>>>> <rng:ref name="model.pLike"/> > >>>>> <rng:ref name="model.tableLike"/> > >>>>> <rng:ref name="castList"/> > >>>>> <rng:ref name="eventList"/> > >>>>> <rng:ref name="list"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> </rng:choice> > >>>>> <rng:zeroOrMore> > >>>>> <rng:ref name="biblList"/> > >>>>> </rng:zeroOrMore> > >>>>> </content> > >>>>> > >>>>> English translation is "an optional label, followed by EITHER > >>>>> some data-like > >>>> elements or nested eventLists OR any number of paragraphs, > >>>> tables, castLists, eventLists, or lists, followed by any number > >>>> of lists of bibliographic citations." > >>>>> > >>>>> The central choice (a data-centric organization OR a free-form > >>>>> text > >>>>> one) is the important factor here. In purely practical terms, > >>>>> any file that formerly used a group of data elements followed by > >>>>> a paragraph will have to be translated into -- > >>>>> > >>>>> <event> > >>>>> <label><!-- former paragraph content --> <geogName/><persName/> > >>>>> <!-- etc. --> </event> > >>>>> > >>>>> This element re-naming and re-ordering is not a difficult task > >>>>> and can be > >>>> made part of the 2013 -> 2015 XSLT transformation. If the > >>>> re-ordering poses a significant issue (that is, you *must* have > >>>> the data elements followed by the label), I think it's not a > >>>> problem to allow > >> that, but please let me know. > >>>>> > >>>>> As always, I apologize for the length of the message and the XML > >>>>> "gobbledy-gook". I just don't know of any other way to communicate. > >>>>> ;-) > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> ________________________________ Perry Roland University of > >>>>> Virginia P. O. Box 400874 Charlottesville, VA, 22904 > >>>>> 434-982-2702 (w) > >>>>> pdr4h (at) virginia (dot) edu > >>>>> > >>>>> _______________________________________________ > >>>>> 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-catalog-ig mailing list > mei-catalog-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig _______________________________________________ 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 Nov 13 12:06:03 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 13 Nov 2015 11:06:03 +0000 Subject: [MEI-L] FW: changes to <eventList> and <event> In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEED3D2@EXCHANGE-02.kb.dk> References: <BBCC497C40D85642B90E9F94FC30343D7C722600@reagan.eservices.virginia.edu> <A348F6E5-1E8B-40FB-BA7A-6372EF374912@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C722651@reagan.eservices.virginia.edu> <5854343F-9D62-4331-8B9B-1CFB1B028214@edirom.de> <BBCC497C40D85642B90E9F94FC30343D7C72276F@reagan.eservices.virginia.edu> <22480CF2-4304-4E79-AC6E-979A245C99B7@edirom.de> <0B6F63F59F405E4C902DFE2C2329D0D1013DEEC20D@EXCHANGE-02.kb.dk> <BBCC497C40D85642B90E9F94FC30343D8D338313@grant1.eservices.virginia.edu>, <0B6F63F59F405E4C902DFE2C2329D0D1013DEED3D2@EXCHANGE-02.kb.dk> Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D33E3C8@grant1.eservices.virginia.edu> Hi Axel, I'm happy we could reach consensus on this. Unless I hear objections in the next couple of days, I'll go ahead with this change. -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu ________________________________________ From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk] Sent: Friday, November 13, 2015 3:53 AM To: Music Encoding Initiative Subject: Re: [MEI-L] FW: changes to <eventList> and <event> Hi Perry Your eventList model looks fine to me. /axel -----Oprindelig meddelelse----- Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Roland, Perry D. (pdr4h) Sendt: 11. november 2015 17:43 Til: Music Encoding Initiative Emne: Re: [MEI-L] FW: changes to <eventList> and <event> Hi Axel, I was coming to a similar conclusion, so thanks for proposing a compromise solution. Your model of eventGrp, however, doesn't allow for continued nesting of <eventGrp> elements. So, I'd like to counter with the following models which merge eventList and eventGrp into a single entity -- For eventList: <content> <rng:zeroOrMore> <rng:ref name="model.headLike"/> </rng:zeroOrMore> <rng:zeroOrMore> <rng:group> <!-- an organizing data element --> <rng:optional> <rng:ref name="model.eventPart"/> </rng:optional> <!-- an event description or another list of events --> <rng:choice> <rng:ref name="event"/> <rng:ref name="eventList"/> </rng:choice> </rng:group> </rng:zeroOrMore> <!-- at the very end, lists of citations --> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> For event: <content> <rng:optional> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> <!-- data-like organization --> <rng:zeroOrMore> <rng:choice> <rng:ref name="model.eventPart"/> <rng:ref name="eventList"/> </rng:choice> </rng:zeroOrMore> <!-- free-form organization --> <rng:zeroOrMore> <rng:choice> <!-- model.listLike is expanded here in order to disallow biblList --> <rng:ref name="model.pLike"/> <rng:ref name="model.tableLike"/> <rng:ref name="castList"/> <rng:ref name="eventList"/> <rng:ref name="list"/> </rng:choice> </rng:zeroOrMore> </rng:choice> <rng:zeroOrMore> <rng:ref name="biblList"/> </rng:zeroOrMore> </content> By making the "grouping key" optional, the model of <eventList> does allow for mixing of events grouped on a date, place, person, etc. and a "simple" list of events, but I see that as a good thing, not an impediment. This makes it possible to eliminate <eventGrp> and matches the behavior of other list-like structures (where a list contains a mixture of item and subordinate lists). Most importantly, the model of <event> now meets the original goal -- a clear distinction between a database-like approach to recording the event description and a free-text approach. I've removed the <listHead> formatting element. We can always take that up again at a later date. I still maintain that they're useful, but I'll also forego the @mark and @order formatting attributes. That battle can wait, too. -- p. > -----Original Message----- > From: mei-catalog-ig [mailto:mei-catalog-ig-bounces at lists.uni- > paderborn.de] On Behalf Of Axel Teich Geertinger > Sent: Tuesday, November 10, 2015 8:10 AM > To: Music Encoding Initiative > Cc: mei-catalog-ig at lists.uni-paderborn.de > Subject: Re: [mei-catalog-ig] [MEI-L] FW: changes to <eventList> and > <event> > > Hi Johannes & Perry > > This discussion is started on both MEI-L and MEI-Catalog-IG; I'm > posting my reply to both lists, but in order not to exclude anyone now > I suggest we continue the discussion on MEI-L only. > > I agree with Johannes that an alternating sequence of date and event > elements would be a way of looking for trouble. If I want to delete an > event or change the order of events, I would have to make sure always > to do the same with the preceding date sibling. If there is any. I > would definitely prefer being able to address an event or group of > events as a single element without having to care about any siblings. > Also, Perry's model (if I read your suggestion correctly) implies that > it would not be possible to have an <event> without a preceding > <date>. But we are not always able to date events. Even if <date> > could be left empty, the construct would seem somehow awkward to me. > Finally, from a purely practical perspective, the way we handle > elements would make it a pain to maintain and edit such a list of alternating elements. > > If we are introducing <eventGrp>, we have a clear way of > distinguishing a list of events (that is, a possibly unordered, > non-grouped <eventList>) from a group of events that have something in > common. Let's not mix them up. If we want to group events by date, we > could do so by allowing <date> or any eventPart element within <eventGrp> (but not in <eventList>): > > <eventList> > <event><!-- some single event --></event> > <eventGrp> > <!-- a group of events --> > <date><!-- the grouping parameter - could also be geogName etc. > instead - > -></date> > <event><!-- event 1 --></event> > <event><!-- event 2 etc. --></event> > </eventGrp> > </eventList> > > Alternatively, the @isodate approach could be used on <eventGrp>. > > /axel > > -----Oprindelig meddelelse----- > Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På > vegne af Johannes Kepper > Sendt: 10. november 2015 00:20 > Til: Music Encoding Initiative > Emne: Re: [MEI-L] FW: changes to <eventList> and <event> > > Hi Perry, > > I understand (and fully support) your motivation to clean up events. > However, could you please refresh my memory and indicate the current / > planned content of event? Maybe I understand your proposal to move all > these things out of events better with that model in mind. As you > know, we use even annots in a data-like way, and while I agree that > both annots and events are perfectly valid to take free-form content, > I'm still in love with structured things - maybe just a couple of > attributes. Or would it be an alternative to provide separate elements > for free-form and structured content, like <annot> and <annotStruct> or <event> and <eventStruct>? > > Just guessing. > jo > > > Am 09.11.2015 um 23:56 schrieb Roland, Perry D. (pdr4h) > <pdr4h at eservices.virginia.edu>: > > > > > Our current handling of <eventList> is a mess, which reduces its > > effectiveness for data interchange and interoperability. Clarifying > > its possible content can counteract this tendency. It's relatively > > easy to provide alternative grouping mechanisms. For instance, a > > content model for <eventList> like -- > > > > <content> > > <rng:zeroOrMore> > > <rng:ref name="model.headLike"/> > > </rng:zeroOrMore> > > <rng:optional> > > <rng:ref name="listHead"/> > > </rng:optional> > > <rng:zeroOrMore> > > <rng:group> > > <rng:choice> > > <rng:ref name="model.eventPart"/> > > </rng:choice> > > <rng:choice> > > <rng:ref name="event"/> > > <rng:ref name="eventGrp"/> > > </rng:choice> > > </rng:group> > > </rng:zeroOrMore> > > <rng:zeroOrMore> > > <rng:ref name="biblList"/> > > </rng:zeroOrMore> > > </content> > > > > would allow any member of model.eventPart to act as the organizing > > "term". For instance, > > > > <eventList> > > <date><!-- date of event --></date> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <geogName><!-- place of event --></geogName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > or > > > > <eventList> > > <persName><!-- personal name, of conductor for example -- > ></persName> > > <event><!-- event description --></event> > > <!-- and so on --> > > </eventList> > > > > are all possible. This is the essentially the model used by HTML > > for <dl>, by > EAD for <chronlist>, and by TEI for <list> of @type "gloss". The > difficulty, of course, is ensuring that each event in a list is > preceded by the same kind of element. I'm not sure if this is > possible using RNG alone, but it can certainly be enforced using Schematron. > > > > -- > > p. > > > > > >> -----Original Message----- > >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf > >> Of Johannes Kepper > >> Sent: Monday, November 09, 2015 4:40 PM > >> To: Music Encoding Initiative > >> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >> > >> > >> Am 09.11.2015 um 22:28 schrieb Roland, Perry D. (pdr4h) > >> <pdr4h at eservices.virginia.edu>: > >> > >>> > >>> An <eventGrp> element containing <event> with the current model > >>> makes > >> no sense as there's no indication of the grouping criterion. The > >> <date> followed by <eventGrp> construct makes it clear that the > >> events are grouped by date. In fact, that's the only way to group > >> them > using this model. > >> > >> Ok, what constitutes a group of events? What does it mean to have > >> events grouped? Is there any other grouping mechanism other than by > >> date? Does it make sense to have events grouped by place? If so, > >> why don't we factor in groups (by date, for instance) and subgroups > >> (by place)? Or is it maybe better to let the grouping be done by > >> applications, based on structured markup like @isodate, @resp, > >> @type > and similar options? > >> > >>> > >>> It is nothing like the concept of chords that you raise. > >> > >> I need to look into the preceding sibling to fully understand the > >> current element... > >> > >>> Order is a good thing here as it makes the structure of the data clear. > >>> > >> > >> jo > >> > >>> -- > >>> p. > >>> > >>> > >>>> -----Original Message----- > >>>> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On > >>>> Behalf Of Johannes Kepper > >>>> Sent: Monday, November 09, 2015 4:20 PM > >>>> To: Music Encoding Initiative > >>>> Subject: Re: [MEI-L] FW: changes to <eventList> and <event> > >>>> > >>>> I'm sorry to say, but I'm not convinced by this one either. I see > >>>> the point to have an eventGroup element, but everything else > >>>> seems rather dubious to me. By all means, I would like to keep > >>>> the date inside events, even for free- form text-driven events > >>>> (in contrast to data-driven events). Also, I hate the idea to > >>>> have an alternation of events and something, and have to rely on > >>>> document order to understand the meaning of something - this gets > >>>> pretty close to MusicXML's concept of chords, doesn't it? Are > >>>> there any real-world limitations that motivate this proposal? If > >>>> so, could we discuss it with > >> those examples on the table? > >>>> > >>>> jo > >>>> > >>>> > >>>> Am 09.11.2015 um 22:07 schrieb Roland, Perry D. (pdr4h) > >>>> <pdr4h at eservices.virginia.edu>: > >>>> > >>>>> > >>>>> I sent this message to the cataloging interest group list earlier. > >>>>> I apologize if > >>>> you receive it twice, but I thought it would be a good idea to > >>>> post to this list as well in the interest of generating as much > >>>> discussion as > >> possible. > >>>>> > >>>>> BTW, this is not a new feature, but rather a remedy for an > >>>>> existing bug. But > >>>> I think it's finally squashed this time. > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> > >>>>> From: Roland, Perry D. (pdr4h) > >>>>> Sent: Monday, November 09, 2015 3:46 PM > >>>>> To: 'mei-catalog-ig at lists.uni-paderborn.de' > >>>>> Subject: changes to <eventList> and <event> > >>>>> > >>>>> > >>>>> I know we've had a few rounds of discussion about the content > >>>>> models of > >>>> <eventList> and <event> in the past. I think there are basically > >>>> 2 issues currently facing us: > >>>>> > >>>>> * eventList contains a bug that doesn't allow grouping events that > >> share > >>>> the same date > >>>>> * the model of event is too vague > >>>>> > >>>>> I propose to remedy the first problem by using the following > >>>>> content model > >>>> for <eventList>: > >>>>> > >>>>> eventList (head*, listHead?, (date, (event | eventGrp))*, biblList*) > >>>>> > >>>>> By placing <date> outside the model of <event>, the main content > >>>>> of <eventList> can be constrained to be any number of pairs of > >>>>> <date> and <event> elements, like so - > >>>>> > >>>>> <eventList> > >>>>> <date><!-- when "it" happened --></date> > >>>>> <event><!-- what happened --> > >>>>> <date><!-- another happening --></date> > >>>>> <event><!-- another description --> > >>>>> <!-- and so on --> > >>>>> </eventList> > >>>>> > >>>>> Or, when multiple events share the same date, like so -- > >>>>> > >>>>> <eventList> > >>>>> <date><!-- the date --></date> > >>>>> <eventGrp> <!-- the events occurring on the date --> > >>>>> <event>Event 1</event> > >>>>> <event> Event 2</event> > >>>>> <!-- and so on --> > >>>>> </eventGrp> > >>>>> </eventList> > >>>>> > >>>>> The new model also introduces listHead, a new formatting element. > >>>>> <listHead> contains a pair of <head> elements, one for each > >>>>> column in the eventList date-event pair. This makes it possible > >>>>> to treat the list of events as though it were a table with a > >>>>> column heading for the dates and a heading for the descriptions. > >>>>> Of course, eventList/head continues to contain a heading for the > >>>>> entire list > >>>>> -- > >>>>> > >>>>> <eventList> > >>>>> <head>My List o' Special Events</head> <listHead> > >>>>> <head>When</head> > >>>>> <head>What</head> > >>>>> </listHead> > >>>>> <event/> > >>>>> <event/> > >>>>> </eventList> > >>>>> > >>>>> I plan to investigate how this might work for other lists as > >>>>> well, such as > >>>> <biblList>, <castList>, and <list>. Any list that allows a label > >>>> preceding its "items" could benefit from this treatment, I think. > >>>>> > >>>>> One more change -- <eventList> is now a member of > >>>>> model.listLike, > >>>> meaning it can occur not just in the header but anywhere a "regular" > >>>> list can happen. > >>>>> > >>>>> The <event> element now has the following model (switching to > >>>>> RNG as it's somewhat clearer than DTD syntax) -- > >>>>> > >>>>> <content> > >>>>> <rng:optional> > >>>>> <rng:ref name="model.labelLike"/> </rng:optional> <rng:choice> > >>>>> <!-- data-like organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <rng:ref name="model.eventPart"/> > >>>>> <rng:ref name="eventList"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> <!-- free-form organization --> > >>>>> <rng:zeroOrMore> > >>>>> <rng:choice> > >>>>> <!-- model.listLike is expanded here in order to disallow biblList --> > >>>>> <rng:ref name="model.pLike"/> > >>>>> <rng:ref name="model.tableLike"/> > >>>>> <rng:ref name="castList"/> > >>>>> <rng:ref name="eventList"/> > >>>>> <rng:ref name="list"/> > >>>>> </rng:choice> > >>>>> </rng:zeroOrMore> > >>>>> </rng:choice> > >>>>> <rng:zeroOrMore> > >>>>> <rng:ref name="biblList"/> > >>>>> </rng:zeroOrMore> > >>>>> </content> > >>>>> > >>>>> English translation is "an optional label, followed by EITHER > >>>>> some data-like > >>>> elements or nested eventLists OR any number of paragraphs, > >>>> tables, castLists, eventLists, or lists, followed by any number > >>>> of lists of bibliographic citations." > >>>>> > >>>>> The central choice (a data-centric organization OR a free-form > >>>>> text > >>>>> one) is the important factor here. In purely practical terms, > >>>>> any file that formerly used a group of data elements followed by > >>>>> a paragraph will have to be translated into -- > >>>>> > >>>>> <event> > >>>>> <label><!-- former paragraph content --> <geogName/><persName/> > >>>>> <!-- etc. --> </event> > >>>>> > >>>>> This element re-naming and re-ordering is not a difficult task > >>>>> and can be > >>>> made part of the 2013 -> 2015 XSLT transformation. If the > >>>> re-ordering poses a significant issue (that is, you *must* have > >>>> the data elements followed by the label), I think it's not a > >>>> problem to allow > >> that, but please let me know. > >>>>> > >>>>> As always, I apologize for the length of the message and the XML > >>>>> "gobbledy-gook". I just don't know of any other way to communicate. > >>>>> ;-) > >>>>> > >>>>> -- > >>>>> p. > >>>>> > >>>>> ________________________________ Perry Roland University of > >>>>> Virginia P. O. Box 400874 Charlottesville, VA, 22904 > >>>>> 434-982-2702 (w) > >>>>> pdr4h (at) virginia (dot) edu > >>>>> > >>>>> _______________________________________________ > >>>>> 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-catalog-ig mailing list > mei-catalog-ig at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-catalog-ig _______________________________________________ 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 maximumspatium at googlemail.com Fri Nov 13 12:26:24 2015 From: maximumspatium at googlemail.com (Max Pole) Date: Fri, 13 Nov 2015 12:26:24 +0100 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> Message-ID: <CAHoqaf+1k33m69=OECf56APkjqnj+kRv16cUxTH+Wst4evFWwA@mail.gmail.com> Hello crews, > Hello all, > > The current content model of <provenance> uses a neat RNG trick that > allows either an <eventList> or a text phrase. No other schema language > allows this kind of thing, so conversion of the RNG to an XSD or DTD form > won't work. Is there a need to maintain compatibility with XML Schema or > DTDs? > > > Our project - Audiveris optical music recognition system (www.audiveris.org) - is currently working on adding a support for MEI. Because Audiveris has been programmed in Java, it depends on the native JDK tool - xjc - for parsing XML schemata. Although xjc has an experimental support for RelaxNG, it currently doesn't work properly so it's unusable in our case. We therefore need to convert MEI RelaxNG schema to XSD by using a third-party converter first, then write a customization file that helps xjc to resolve several conflicts in the resulted MEI schema in order to make it usable by JAXB. Therefore I vote for maintaining compatibility to XSD because I don't know how to make RelaxNG to work in Java without the conversion to XSD. Best regards Max -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/504cdb27/attachment.html> From annplaksin at gmx.net Fri Nov 13 12:58:31 2015 From: annplaksin at gmx.net (Anna Plaksin) Date: Fri, 13 Nov 2015 12:58:31 +0100 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> Message-ID: <00e701d11e0a$9e484e20$dad8ea60$@gmx.net> Hi Andrew, some months ago I was looking for XML editors with schema-based auto-completion and Oxygen is the only one I know with RNG support. Some others, as Rinzo, the TextGrid Lab and the XML Tools Plugin for Notepad++ support only auto-completion based on XSD. And, okay… because C# is the programming language I’m using most, I don’t know how good the RelaxNG support in other frameworks is, but the .net framework provides native support of XML schema without any external libraries. I have to admit that I am a little bit surprised of your question. Apart from the “digital humanities community” I don’t know any person working with XML data that are aware of RelaxNG, they’re all using XML schema. Hm, I feel a little bit confused right now. Maybe in this situation I would feel fine if you just wait for other feedback. Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Andrew Hankinson Gesendet: Freitag, 13. November 2015 09:23 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> Betreff: Re: [MEI-L] MEI as XSD or DTD Hi Anna, I'm curious to know which tools are in use that don't support RelaxNG -- is there a quick example you can share? -Andrew On Nov 13, 2015, at 8:18 AM, Anna Plaksin < <mailto:annplaksin at gmx.net> annplaksin at gmx.net> wrote: Hello Perry, I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me… Regards, Anna Von: mei-l [ <mailto:mei-l-bounces at lists.uni-paderborn.de> mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Donnerstag, 12. November 2015 21:49 An: <mailto:mei-l at lists.uni-paderborn.de> mei-l at lists.uni-paderborn.de Betreff: [MEI-L] MEI as XSD or DTD Hello all, The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? -- p. ________________________________ Perry Roland University of Virginia P. O. Box 400874 Charlottesville, VA, 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu _______________________________________________ mei-l mailing list <mailto:mei-l at lists.uni-paderborn.de> mei-l at lists.uni-paderborn.de <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/4b116cee/attachment.html> From andrew.hankinson at mail.mcgill.ca Fri Nov 13 14:24:22 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 13 Nov 2015 13:24:22 +0000 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> Message-ID: <EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> No, don't be confused! I'm not an "XML person" so my knowledge of the kinds of tools that are out there is somewhat limited. That's why I asked. -Andrew > On Nov 13, 2015, at 11:58 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hi Andrew, > > some months ago I was looking for XML editors with schema-based auto-completion and Oxygen is the only one I know with RNG support. Some others, as Rinzo, the TextGrid Lab and the XML Tools Plugin for Notepad++ support only auto-completion based on XSD. > And, okay… because C# is the programming language I’m using most, I don’t know how good the RelaxNG support in other frameworks is, but the .net framework provides native support of XML schema without any external libraries. > > I have to admit that I am a little bit surprised of your question. Apart from the “digital humanities community” I don’t know any person working with XML data that are aware of RelaxNG, they’re all using XML schema. Hm, I feel a little bit confused right now. > Maybe in this situation I would feel fine if you just wait for other feedback. > > Regards, > Anna >   <> > Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de <mailto:mei-l-bounces at lists.uni-paderborn.de>] Im Auftrag von Andrew Hankinson > Gesendet: Freitag, 13. November 2015 09:23 > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de>> > Betreff: Re: [MEI-L] MEI as XSD or DTD > > Hi Anna, > > I'm curious to know which tools are in use that don't support RelaxNG -- is there a quick example you can share? > > -Andrew > >> On Nov 13, 2015, at 8:18 AM, Anna Plaksin <annplaksin at gmx.net <mailto:annplaksin at gmx.net>> wrote: >> >> Hello Perry, >> >> I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. >> So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me… >> >> Regards, >> Anna >> >> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de <mailto:mei-l-bounces at lists.uni-paderborn.de>] Im Auftrag von Roland, Perry D. (pdr4h) >> Gesendet: Donnerstag, 12. November 2015 21:49 >> An: mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> >> Betreff: [MEI-L] MEI as XSD or DTD >> >> >> Hello all, >> >> The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? >> >> -- >> p. >> >> ________________________________ >> Perry Roland >> University of Virginia >> P. O. Box 400874 >> Charlottesville, VA, 22904 >> 434-982-2702 (w) >> pdr4h (at) virginia (dot) edu >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/68c5ac6f/attachment.html> From andrew.hankinson at mail.mcgill.ca Fri Nov 13 14:36:11 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Fri, 13 Nov 2015 13:36:11 +0000 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <19348_1447421091_5645E4A3_19348_48_1_EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> <19348_1447421091_5645E4A3_19348_48_1_EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> Message-ID: <BD365EF6-6312-422D-8914-E47DD7317345@mail.mcgill.ca> For what it's worth, it's pretty easy to generate an XSD file directly from the MEI source using the TEI Stylesheets. Here are the steps: 1. Get the TEI Stylesheet source: https://github.com/TEIC/Stylesheets 2. In the 'bin' directory there are a number of commands. You should run one to see if it complains -- you may need 'ant', 'jing', or 'trang' (but maybe not...) 3. To generate an XSD from, e.g., the MEI CMN Customization: $> bin/teitoxsd --localsource=/path/to/mei/source/driver.xml /path/to/mei/customizations/mei-CMN.xml This should generate the mei-CMN.xml.xsd file in the customizations directory. Many of the commands can be replaced to produce different outputs, so teitorelaxng or teitodtd. For reference I've attached the most recent (MEI 3.0.0 pre-release) MEI-CMN XSD along with xlink, svg, and xml files as well. -Andrew > On Nov 13, 2015, at 1:24 PM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca> wrote: > > No, don't be confused! I'm not an "XML person" so my knowledge of the kinds of tools that are out there is somewhat limited. That's why I asked. > > -Andrew > >> On Nov 13, 2015, at 11:58 AM, Anna Plaksin <annplaksin at gmx.net <mailto:annplaksin at gmx.net>> wrote: >> >> Hi Andrew, >> >> some months ago I was looking for XML editors with schema-based auto-completion and Oxygen is the only one I know with RNG support. Some others, as Rinzo, the TextGrid Lab and the XML Tools Plugin for Notepad++ support only auto-completion based on XSD. >> And, okay… because C# is the programming language I’m using most, I don’t know how good the RelaxNG support in other frameworks is, but the .net framework provides native support of XML schema without any external libraries. >> >> I have to admit that I am a little bit surprised of your question. Apart from the “digital humanities community” I don’t know any person working with XML data that are aware of RelaxNG, they’re all using XML schema. Hm, I feel a little bit confused right now. >> Maybe in this situation I would feel fine if you just wait for other feedback. >> >> Regards, >> Anna >>   <> >> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de <mailto:mei-l-bounces at lists.uni-paderborn.de>] Im Auftrag von Andrew Hankinson >> Gesendet: Freitag, 13. November 2015 09:23 >> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de>> >> Betreff: Re: [MEI-L] MEI as XSD or DTD >> >> Hi Anna, >> >> I'm curious to know which tools are in use that don't support RelaxNG -- is there a quick example you can share? >> >> -Andrew >> >>> On Nov 13, 2015, at 8:18 AM, Anna Plaksin <annplaksin at gmx.net <mailto:annplaksin at gmx.net>> wrote: >>> >>> Hello Perry, >>> >>> I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. >>> So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me… >>> >>> Regards, >>> Anna >>> >>> Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de <mailto:mei-l-bounces at lists.uni-paderborn.de>] Im Auftrag von Roland, Perry D. (pdr4h) >>> Gesendet: Donnerstag, 12. November 2015 21:49 >>> An: mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> >>> Betreff: [MEI-L] MEI as XSD or DTD >>> >>> >>> Hello all, >>> >>> The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? >>> >>> -- >>> p. >>> >>> ________________________________ >>> Perry Roland >>> University of Virginia >>> P. O. Box 400874 >>> Charlottesville, VA, 22904 >>> 434-982-2702 (w) >>> pdr4h (at) virginia (dot) edu >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l <https://lists.uni-paderborn.de/mailman/listinfo/mei-l> > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/7e44ecec/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: mei-CMN.zip Type: application/zip Size: 83057 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/7e44ecec/attachment.zip> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/7e44ecec/attachment-0001.html> From raffaeleviglianti at gmail.com Fri Nov 13 14:37:33 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 13 Nov 2015 08:37:33 -0500 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> <EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> Message-ID: <CAMyHAnNYom5AMxjLnau1xWThZTud7ezKUK214a3dCfi5HchHcQ@mail.gmail.com> I think support for XSD is highly desirable, especially because it's a W3C recommendation. I agree with Anna that there is generally more support for XSD than Relax. On the other hand, I wouldn't mind dropping DTD support since it's arguably been superseded by schemata and we may run into more problems with it in the future. Max, great to hear that Audioveris is adding support for MEI! If you need XSD, I would recommend generating it from out ODD (our source schema) instead of converting the rng. You'll need to run the TEI Stylesheets ( https://github.com/TEIC/Stylesheets) to do so, but it's not complicated, I can provide instructions if you like. Perry, what about allowing both text and <eventList>? Would it be bad to allowed mixed content in this case? (Sorry I haven't really looked into this too hard). Best, Raff On Fri, Nov 13, 2015 at 8:24 AM, Andrew Hankinson < andrew.hankinson at mail.mcgill.ca> wrote: > No, don't be confused! I'm not an "XML person" so my knowledge of the > kinds of tools that are out there is somewhat limited. That's why I asked. > > -Andrew > > On Nov 13, 2015, at 11:58 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hi Andrew, > > some months ago I was looking for XML editors with schema-based > auto-completion and Oxygen is the only one I know with RNG support. Some > others, as Rinzo, the TextGrid Lab and the XML Tools Plugin for Notepad++ > support only auto-completion based on XSD. > And, okay… because C# is the programming language I’m using most, I don’t > know how good the RelaxNG support in other frameworks is, but the .net > framework provides native support of XML schema without any external > libraries. > > I have to admit that I am a little bit surprised of your question. Apart > from the “digital humanities community” I don’t know any person working > with XML data that are aware of RelaxNG, they’re all using XML schema. Hm, > I feel a little bit confused right now. > Maybe in this situation I would feel fine if you just wait for other > feedback. > > Regards, > Anna > > *Von:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > <mei-l-bounces at lists.uni-paderborn.de>] *Im Auftrag von *Andrew Hankinson > *Gesendet:* Freitag, 13. November 2015 09:23 > *An:* Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > *Betreff:* Re: [MEI-L] MEI as XSD or DTD > > Hi Anna, > > I'm curious to know which tools are in use that don't support RelaxNG -- > is there a quick example you can share? > > -Andrew > > > On Nov 13, 2015, at 8:18 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hello Perry, > > I would appreciate compatibility with XML Schema just because of the > widespread support. Many more Editors and Frameworks natively support XML > processing with automated validation against an XSD file. I experimented > sometimes with a converted RNG file but there occurred false validation > errors. > So, I would be very happy about compatibility but I see your point either. > If I am the only one wishing for it, this topic would seem rather > unimportant to me… > > Regards, > Anna > > *Von:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > <mei-l-bounces at lists.uni-paderborn.de>] *Im Auftrag von *Roland, Perry D. > (pdr4h) > *Gesendet:* Donnerstag, 12. November 2015 21:49 > *An:* mei-l at lists.uni-paderborn.de > *Betreff:* [MEI-L] MEI as XSD or DTD > > > Hello all, > > The current content model of <provenance> uses a neat RNG trick that > allows either an <eventList> or a text phrase. No other schema language > allows this kind of thing, so conversion of the RNG to an XSD or DTD form > won't work. Is there a need to maintain compatibility with XML Schema or > DTDs? > > -- > p. > > ________________________________ > Perry Roland > University of Virginia > P. O. Box 400874 > Charlottesville, VA, 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/b83c5b22/attachment.html> From stadler at edirom.de Fri Nov 13 14:48:58 2015 From: stadler at edirom.de (Peter Stadler) Date: Fri, 13 Nov 2015 14:48:58 +0100 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <BD365EF6-6312-422D-8914-E47DD7317345@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> <19348_1447421091_5645E4A3_19348_48_1_EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> <BD365EF6-6312-422D-8914-E47DD7317345@mail.mcgill.ca> Message-ID: <0F6EA71C-23C0-4335-AC63-DE4BE32C884B@edirom.de> > Am 13.11.2015 um 14:36 schrieb Andrew Hankinson <andrew.hankinson at mail.mcgill.ca>: > > For what it's worth, it's pretty easy to generate an XSD file directly from the MEI source using the TEI Stylesheets. The TEI Stylesheets generate RelaxNG XML Syntax primarily and all other formats are created by calling external tools, e.g. trang. So, you have to take care that your input Relax does not make use of any Relax-specifc tweaks — otherwise the following transformations will fail. Personally, I almost only use Relax but I’d strongly argue for keeping up the support for W3C schemas. DTDs are somewhat different and since MEI has not that history (and legacy data) as TEI has, I’d say: drop it. (TEI Council discusses this issue as well but hasn’t taken the step yet …) Last not least, the TEI’s workaround for all sorts of messy content models is using schematron. Using schematron, the content models can be expressed in a simple, compliant way while all sorts of constraints can be enforced, as well. Cheers Pete -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/f335a9b4/attachment.sig> From pdr4h at eservices.virginia.edu Fri Nov 13 16:52:13 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Fri, 13 Nov 2015 15:52:13 +0000 Subject: [MEI-L] MEI as XSD or DTD In-Reply-To: <BD365EF6-6312-422D-8914-E47DD7317345@mail.mcgill.ca> References: <BBCC497C40D85642B90E9F94FC30343D8D33C174@grant1.eservices.virginia.edu> <4759_1447402724_56459CE4_4759_403_1_00b601d11deb$dd76de50$98649af0$@gmx.net> <3F82841C-32DB-4F54-B858-6C2E005D9789@mail.mcgill.ca> <14605_1447415969_5645D0A0_14605_191_1_00e701d11e0a$9e484e20$dad8ea60$@gmx.net> <19348_1447421091_5645E4A3_19348_48_1_EC1E9A24-A31A-4C79-8521-7C0602E97FBA@mail.mcgill.ca> <BD365EF6-6312-422D-8914-E47DD7317345@mail.mcgill.ca> Message-ID: <BBCC497C40D85642B90E9F94FC30343D8D33E506@grant1.eservices.virginia.edu> Andrew, Thanks for the XSD. If I remember correctly, the TEI process creates an RNG schema and then uses Trang to convert it to XSD. This is the same thing oXygen is doing. In fact, they both result in the same broken XSD. Somehow, Trang has the idea that attributes defined in the included schemas, xml.xsd and xlink.xsd, are required. Editing these files to make all the attributes optional results in a usable XSD. It would be wonderful if someone with more experience with XSD than me (I really don’t have any) investigated why Trang does what it does and made recommendations for changing the ODD to get a better result. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Andrew Hankinson Sent: Friday, November 13, 2015 8:36 AM To: Music Encoding Initiative Subject: Re: [MEI-L] MEI as XSD or DTD For what it's worth, it's pretty easy to generate an XSD file directly from the MEI source using the TEI Stylesheets. Here are the steps: 1. Get the TEI Stylesheet source: https://github.com/TEIC/Stylesheets 2. In the 'bin' directory there are a number of commands. You should run one to see if it complains -- you may need 'ant', 'jing', or 'trang' (but maybe not...) 3. To generate an XSD from, e.g., the MEI CMN Customization: $> bin/teitoxsd --localsource=/path/to/mei/source/driver.xml /path/to/mei/customizations/mei-CMN.xml This should generate the mei-CMN.xml.xsd file in the customizations directory. Many of the commands can be replaced to produce different outputs, so teitorelaxng or teitodtd. For reference I've attached the most recent (MEI 3.0.0 pre-release) MEI-CMN XSD along with xlink, svg, and xml files as well. -Andrew On Nov 13, 2015, at 1:24 PM, Andrew Hankinson <andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>> wrote: No, don't be confused! I'm not an "XML person" so my knowledge of the kinds of tools that are out there is somewhat limited. That's why I asked. -Andrew On Nov 13, 2015, at 11:58 AM, Anna Plaksin <annplaksin at gmx.net<mailto:annplaksin at gmx.net>> wrote: Hi Andrew, some months ago I was looking for XML editors with schema-based auto-completion and Oxygen is the only one I know with RNG support. Some others, as Rinzo, the TextGrid Lab and the XML Tools Plugin for Notepad++ support only auto-completion based on XSD. And, okay… because C# is the programming language I’m using most, I don’t know how good the RelaxNG support in other frameworks is, but the .net framework provides native support of XML schema without any external libraries. I have to admit that I am a little bit surprised of your question. Apart from the “digital humanities community” I don’t know any person working with XML data that are aware of RelaxNG, they’re all using XML schema. Hm, I feel a little bit confused right now. Maybe in this situation I would feel fine if you just wait for other feedback. Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Andrew Hankinson Gesendet: Freitag, 13. November 2015 09:23 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: Re: [MEI-L] MEI as XSD or DTD Hi Anna, I'm curious to know which tools are in use that don't support RelaxNG -- is there a quick example you can share? -Andrew On Nov 13, 2015, at 8:18 AM, Anna Plaksin <annplaksin at gmx.net<mailto:annplaksin at gmx.net>> wrote: Hello Perry, I would appreciate compatibility with XML Schema just because of the widespread support. Many more Editors and Frameworks natively support XML processing with automated validation against an XSD file. I experimented sometimes with a converted RNG file but there occurred false validation errors. So, I would be very happy about compatibility but I see your point either. If I am the only one wishing for it, this topic would seem rather unimportant to me… Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Roland, Perry D. (pdr4h) Gesendet: Donnerstag, 12. November 2015 21:49 An: mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] MEI as XSD or DTD Hello all, The current content model of <provenance> uses a neat RNG trick that allows either an <eventList> or a text phrase. No other schema language allows this kind of thing, so conversion of the RNG to an XSD or DTD form won't work. Is there a need to maintain compatibility with XML Schema or DTDs? -- p. ________________________________ Perry Roland University of Virginia P. O. Box 400874 Charlottesville, VA, 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151113/b2f4cafb/attachment.html> From j.schoepf at musikologie.de Tue Nov 17 11:53:13 2015 From: j.schoepf at musikologie.de (=?UTF-8?B?SsO8cmdlbiBTY2jDtnBm?=) Date: Tue, 17 Nov 2015 11:53:13 +0100 Subject: [MEI-L] Input to MEI Message-ID: <564B0719.4080704@musikologie.de> Dear list, I see a Sibelius plug-in to MEI, but I could not find any information regarding a workflow from Finale/MusicXML to MEI. I would prefer to upgrade my old Finale version if I could get it to work with MEI, otherwise I have to buy Sibelius new. I would appreciate experiences of other Finale users how they work from Finale/MusicXML into MEI. thanks :-J J. Schöpf From andrew.hankinson at mail.mcgill.ca Tue Nov 17 12:12:04 2015 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson) Date: Tue, 17 Nov 2015 11:12:04 +0000 Subject: [MEI-L] Input to MEI In-Reply-To: <656_1447757627_564B073A_656_89_1_564B0719.4080704@musikologie.de> References: <656_1447757627_564B073A_656_89_1_564B0719.4080704@musikologie.de> Message-ID: <7408880C-EEEA-4894-8114-E82D229777A0@mail.mcgill.ca> Hi Jürgen, Unfortunately the development kit for Finale is not publicly available. I was recently pointed in the direction of the JW Lua plugin for Finale, which seems like it might be worthwhile to explore, but I currently don't really have time to undertake it. If someone else out there, however, were so inclined I would be happy to collaborate/advise. Same with MuseScore. -Andrew > On Nov 17, 2015, at 10:53 AM, Jürgen Schöpf <j.schoepf at musikologie.de> wrote: > > Dear list, > > I see a Sibelius plug-in to MEI, but I could not find any information > regarding a workflow from Finale/MusicXML to MEI. I would prefer to > upgrade my old Finale version if I could get it to work with MEI, > otherwise I have to buy Sibelius new. I would appreciate experiences of > other Finale users how they work from Finale/MusicXML into MEI. > > thanks > :-J > J. Schöpf > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From kepper at edirom.de Tue Nov 17 12:31:17 2015 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 17 Nov 2015 12:31:17 +0100 Subject: [MEI-L] Input to MEI In-Reply-To: <564B0719.4080704@musikologie.de> References: <564B0719.4080704@musikologie.de> Message-ID: <99285895-6818-4776-821C-9D3673BC29DE@edirom.de> Dear Herr Schöpf, there is an XSLT that converts MusicXML to MEI, which is available from https://raw.githubusercontent.com/music-encoding/music-encoding/develop/tools/musicxml2mei/musicxml2mei-3.0.xsl We've used that extensively for the Freischütz project to convert files from Finale. When you export from Finale, it will generate a so-called "partwise" MusicXML, which you have to convert to "timewise" MusicXML using the XSLT available from http://www.musicxml.com/for-developers/musicxml-xslt/partwise-to-timewise/. This "timewise" file can then be converted using the musicxml2mei converter mentioned above. If you need further assistance, please let me know. Best, Johannes Am 17.11.2015 um 11:53 schrieb Jürgen Schöpf <j.schoepf at musikologie.de>: > Dear list, > > I see a Sibelius plug-in to MEI, but I could not find any information > regarding a workflow from Finale/MusicXML to MEI. I would prefer to > upgrade my old Finale version if I could get it to work with MEI, > otherwise I have to buy Sibelius new. I would appreciate experiences of > other Finale users how they work from Finale/MusicXML into MEI. > > thanks > :-J > J. Schöpf > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151117/b334ef47/attachment.sig> From j.schoepf at musikologie.de Tue Nov 17 12:58:59 2015 From: j.schoepf at musikologie.de (=?UTF-8?B?SsO8cmdlbiBTY2jDtnBm?=) Date: Tue, 17 Nov 2015 12:58:59 +0100 Subject: [MEI-L] Input to MEI In-Reply-To: <99285895-6818-4776-821C-9D3673BC29DE@edirom.de> References: <564B0719.4080704@musikologie.de> <99285895-6818-4776-821C-9D3673BC29DE@edirom.de> Message-ID: <564B1683.5090106@musikologie.de> Thank you both Johannes and Andrew, it looks like a workaround so far, but I feel not alone :-) So I will continue to work in Finale and if issues arise come back on this helpful list. Thanks again & best regards :-J Am 17.11.15 um 12:31 schrieb Johannes Kepper: > Dear Herr Schöpf, > > there is an XSLT that converts MusicXML to MEI, which is available from https://raw.githubusercontent.com/music-encoding/music-encoding/develop/tools/musicxml2mei/musicxml2mei-3.0.xsl > > We've used that extensively for the Freischütz project to convert files from Finale. When you export from Finale, it will generate a so-called "partwise" MusicXML, which you have to convert to "timewise" MusicXML using the XSLT available from http://www.musicxml.com/for-developers/musicxml-xslt/partwise-to-timewise/. This "timewise" file can then be converted using the musicxml2mei converter mentioned above. > > If you need further assistance, please let me know. > > Best, > Johannes > > Am 17.11.2015 um 11:53 schrieb Jürgen Schöpf <j.schoepf at musikologie.de>: > >> Dear list, >> >> I see a Sibelius plug-in to MEI, but I could not find any information >> regarding a workflow from Finale/MusicXML to MEI. I would prefer to >> upgrade my old Finale version if I could get it to work with MEI, >> otherwise I have to buy Sibelius new. I would appreciate experiences of >> other Finale users how they work from Finale/MusicXML into MEI. >> >> thanks >> :-J >> J. Schöpf >> >> _______________________________________________ >> 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 lxpugin at gmail.com Tue Nov 17 13:07:08 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 17 Nov 2015 13:07:08 +0100 Subject: [MEI-L] Input to MEI In-Reply-To: <564B1683.5090106@musikologie.de> References: <564B0719.4080704@musikologie.de> <99285895-6818-4776-821C-9D3673BC29DE@edirom.de> <564B1683.5090106@musikologie.de> Message-ID: <CAJ306HapZkcGt1=mdi0zGKDnR21fx1MEpy++jUnFJ2e6G+crjQ@mail.gmail.com> Dear Jürgen, The XSLT is indeed the most comprehensive way to convert MusicXML to MEI. We have been working recently on converting MusicXML to MEI in Verovio. Of course, only the features supported in Verovio will be converted, so this is definitely not a replacement solution of the XSLT. However, this can still be useful depending on the data you have and what you would like to achieve, for example if you just want to have a preview. I will put this online hopefully next week. Best, Laurent On Tue, Nov 17, 2015 at 12:58 PM, Jürgen Schöpf <j.schoepf at musikologie.de> wrote: > Thank you both Johannes and Andrew, > > it looks like a workaround so far, but I feel not alone :-) > So I will continue to work in Finale and if issues arise come back on > this helpful list. Thanks again & best regards > :-J > > Am 17.11.15 um 12:31 schrieb Johannes Kepper: > > Dear Herr Schöpf, > > > > there is an XSLT that converts MusicXML to MEI, which is available from > https://raw.githubusercontent.com/music-encoding/music-encoding/develop/tools/musicxml2mei/musicxml2mei-3.0.xsl > > > > We've used that extensively for the Freischütz project to convert files > from Finale. When you export from Finale, it will generate a so-called > "partwise" MusicXML, which you have to convert to "timewise" MusicXML using > the XSLT available from > http://www.musicxml.com/for-developers/musicxml-xslt/partwise-to-timewise/. > This "timewise" file can then be converted using the musicxml2mei converter > mentioned above. > > > > If you need further assistance, please let me know. > > > > Best, > > Johannes > > > > Am 17.11.2015 um 11:53 schrieb Jürgen Schöpf <j.schoepf at musikologie.de>: > > > >> Dear list, > >> > >> I see a Sibelius plug-in to MEI, but I could not find any information > >> regarding a workflow from Finale/MusicXML to MEI. I would prefer to > >> upgrade my old Finale version if I could get it to work with MEI, > >> otherwise I have to buy Sibelius new. I would appreciate experiences of > >> other Finale users how they work from Finale/MusicXML into MEI. > >> > >> thanks > >> :-J > >> J. Schöpf > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151117/aeefc3de/attachment.html> From gdibacco at indiana.edu Sat Nov 21 03:31:00 2015 From: gdibacco at indiana.edu (Giuliano Di Bacco) Date: Fri, 20 Nov 2015 21:31:00 -0500 Subject: [MEI-L] Call for proposals to host MEC 2017 Message-ID: <564FD764.8000406@indiana.edu> Greetings to all MEI-Listeners, The MEI Board invites proposals for the organization of the 5th annual Music Encoding Conference, to be held in 2017. As all members of this list know well, 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 scholarly approaches to music encoding are always welcome, as an opportunity for exchanges between scholars from various research communities, including technologists, librarians, historians, and theorists. Those who attended MEC in the past know already that the first three editions exceeded the expectations of their organizers, and as we are looking forward to the fourth edition in Montréal, we would like to look farther ahead, and contribute to make the organizing process smoother and even more enjoyable. This is the purpose of a document that is now available on the MEI website<http://music-encoding.org/community/conference/hosting/>, which gives some guidelines to prospective organizers. 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 22 February 2016. The Board will reach a decision by 1 April 2016. Please contact<mei-board at music-encoding.org> for all inquiries. With all best wishes, Giuliano Di Bacco on behalf of the MEI Board From annplaksin at gmx.net Tue Nov 24 16:13:38 2015 From: annplaksin at gmx.net (Anna Plaksin) Date: Tue, 24 Nov 2015 16:13:38 +0100 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix Message-ID: <000001d126ca$b2f73610$18e5a230$@gmx.net> Hello all, maybe the ODD experts could help me with this issue: I'm working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn't make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I'm using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I've done but I just don't find it. Is someone able to explain it to me? Thanks, Anna -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/cbf606be/attachment.html> -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : mei-cmo-expression.odd Dateityp : application/octet-stream Dateigröße : 16267 bytes Beschreibung: nicht verfügbar URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/cbf606be/attachment.obj> From annplaksin at gmx.net Tue Nov 24 16:19:28 2015 From: annplaksin at gmx.net (Anna Plaksin) Date: Tue, 24 Nov 2015 16:19:28 +0100 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <000001d126ca$b2f73610$18e5a230$@gmx.net> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> Message-ID: <000501d126cb$83731930$8a594b90$@gmx.net> Hello again, I just added the wrong version of the file to the mail. Sorry for that. Anna Von: mei-l [mailto:mei-l-bounces+annplaksin=gmx.net at lists.uni-paderborn.de] Im Auftrag von Anna Plaksin Gesendet: Dienstag, 24. November 2015 16:14 An: mei-l <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hello all, maybe the ODD experts could help me with this issue: I'm working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn't make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I'm using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I've done but I just don't find it. Is someone able to explain it to me? Thanks, Anna -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/f7bc4620/attachment.html> -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : mei-cmo-expression.odd Dateityp : application/octet-stream Dateigröße : 20653 bytes Beschreibung: nicht verfügbar URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/f7bc4620/attachment.obj> From raffaeleviglianti at gmail.com Tue Nov 24 16:31:02 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 24 Nov 2015 10:31:02 -0500 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <000501d126cb$83731930$8a594b90$@gmx.net> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> Message-ID: <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> Hi Anna, The "mei" prefix is set by the mei element (see code here <https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), therefore you have to make sure the element is included in your customization. By setting schemaSpec/@start to just "expression", I *think* the mei element gets excluded by the ODD processing (because it's not needed). I would suggest to set schemaSpec/@start to "mei expression", which seems to fix the problem and makes the customization more conformant. Hope this helps. Best, Raff On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > Hello again, > > > > I just added the wrong version of the file to the mail… > > > > Sorry for that. > > > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces+annplaksin= > gmx.net at lists.uni-paderborn.de] *Im Auftrag von *Anna Plaksin > *Gesendet:* Dienstag, 24. November 2015 16:14 > *An:* mei-l <mei-l at lists.uni-paderborn.de> > *Betreff:* [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hello all, > > > > maybe the ODD experts could help me with this issue: > > I’m working on a MEI customization and since yesterday I get pattern > syntax errors complaining about an undeclared namespace prefix in the > schematron rules after the compilation from ODD to Relax NG. > > It seems to me a little bit weird because I didn’t make big changes in my > ODD file and the errors occur both at my own schematron rules and the > preexisting. > > I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the > v2.1.1, but it occurs also with the customization web service. It is > possible to correct the errors in the output file by changing the > schematron <ns> from TEI to MEI but this cannot be a proper solution, > because the namespace is always TEI even if the schema works fine. > > > > I think it is most likely a mistake I’ve done but I just don’t find it. Is > someone able to explain it to me? > > > > Thanks, > > Anna > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/1451f734/attachment.html> From richard at rjlewis.me.uk Tue Nov 24 16:51:57 2015 From: richard at rjlewis.me.uk (Richard Lewis) Date: Tue, 24 Nov 2015 15:51:57 +0000 Subject: [MEI-L] Instrument settings and tunings In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3D84@EXCHANGE-02.kb.dk> References: <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3C00@EXCHANGE-02.kb.dk> <87bnbsh5vk.wl-richard@rjlewis.me.uk> <0B6F63F59F405E4C902DFE2C2329D0D1013DEE3D84@EXCHANGE-02.kb.dk> Message-ID: <87poyzwg2q.wl-richard@rjlewis.me.uk> Dear Axel, Apologies for leaving this thread cold for so long. We have some example encodings in our Github repository. <https://github.com/TransformingMusicology/mei-tmus/blob/master/examples/italian.xml> <https://github.com/TransformingMusicology/mei-tmus/blob/master/examples/baroque.xml> The italian.xml example uses the <instrName> element. We haven't specified what the @family attribute might contain and I'm not sure now that I really had a specific use-case in mind when I included it. I'm not aware that @code carries any specific semantics so it doesn't, AFAICT, conflict with our (admittedly vague) @family. The baroque.xml example actually conforms to an earlier version of the schema for <instrDesc>! Although, it does have a more complete example of <instrConfig>. One thing to point out regarding our examples is that we're not encoding information from the sources in our <instrConfig>. This is actually information about musical practice which comes from scholarly authorities. This is partly why, as we mentioned in our MEC paper, we're interested in providing Linked Data versions of this kind of <instrConfig> information (and tweaking our schema to allow that), so that such non-source derived assertions can be backed up. Best, Richard On Wed, 21 Oct 2015 13:12:10 +0100, Axel Teich Geertinger wrote: > > Hi Richard > > Oh yes, now I remember! I am sorry! I was actually there to see your > presentation, but the question had not occurred to me at that point > :-) > > Could you post a few examples here on the list for illustration and > further discussion? I see in your customisation that you can also > have an <instrName> element inside <instrDesc>. Do you have an > example showing your use of <instrName> along with other content in > <instrDesc>? > > What values do you give the @family attribute in <instrName>? Is > there a danger of doubling or conflicting information given in @code > on <instrVoice>? > > Best wishes, > Axel > > > -----Oprindelig meddelelse----- > > Fra: mei-l [mailto:mei-l-bounces+atge=kb.dk at lists.uni-paderborn.de] På vegne af Richard Lewis > > Sendt: 21. oktober 2015 12:29 > > Til: Music Encoding Initiative > > Emne: Re: [MEI-L] Instrument settings and tunings > > > > Dear Axel, > > > > We did some work on the problem of encoding instrument > > configurations earlier this year. We actually came up with a > > customisation which is published on github: > > <https://github.com/TransformingMusicology/mei-tmus>, specifically, > > <https://github.com/TransformingMusicology/mei-tmus/blob/master/schemata/instruments.odd>. > > > > We took the approach of extending <instrVoice> to include > > <instrDesc> and <instrConfig> elements. The <instrDesc> allows a > > more structured description of an instrument, while <instrConfig> is > > intended for instrument-specific set up. In our specific case we > > then provided a further customisation for lute tablature which > > extended <instrConfig> to allow elements for describing the tunings > > of the courses. > > > > Our intention was that this generic provision could be extended for > > exactly the kinds of things you describe: organ registrations, > > electronic instruments. > > > > We didn't make any provision for your second requirement, however, > > that of changes of instrument configuration during the course of a > > piece. > > > > We presented this at MEC 2015 but since then we haven't really > > revised it. I think it's still quite experimental and really could > > do with some more testing and criticism. > > > > Best, > > Richard > > > > On Wed, 21 Oct 2015 09:01:53 +0100, > > Axel Teich Geertinger wrote: > > > > > > Dear list > > > > > > I have a couple of questions related to the recent discussion about > > > the model for describing instrumentations in <perfMedium>. Sometimes I > > > need to add more detailed information to an instrument's name, such as > > > transposition or tuning. I simply write this information into > > > <instrVoice>, like > > > > > > <instrVoice>Clarinet (A)</instrVoice> > > > <instrVoice>Timpani (C, G)</instrVoice> > > > > > > Of course I can add more complex information too: the settings for a > > > prepared piano or electronic instruments; scordatura; or even organ > > > registrations (if they remain the same throughout the piece). > > > My first question is: Is it acceptable to have a rather detailed text > > > within <instrVoice> (or <perfRes>, if we decide to rename it), or > > > should we have some other place for a detailed description of > > > settings/tunings/transpositions? > > > > > > My other question is: how would this kind of information be encoded in > > > the score? I know about the transposition attributes on <staffDef>, of > > > course; the timpani case is trivial too. But I wouldn't know how to > > > encode things like organ registrations, scordatura, electronic > > > instruments settings within <music>. Plain text? Or are there some > > > special element for instrument settings? > > > I could also put it this way: Are these settings simply to be regarded > > > as playing techniques like pizzicato or col legno (which I don't know > > > how to encode either, however...)? > > > > > > Best, > > > Axel -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis j: ironchicken at jabber.earth.li @: lewisrichard http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From annplaksin at gmx.net Tue Nov 24 16:55:15 2015 From: annplaksin at gmx.net (Anna Plaksin) Date: Tue, 24 Nov 2015 16:55:15 +0100 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> Message-ID: <001501d126d0$82f14cc0$88d3e640$@gmx.net> Hi Raff, you're totally right, it works. Now I can see how the schematron works properly in an MEI schema even with a TEI namespace. Thank you very, very much for throwing light on this miracle. :-) Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Raffaele Viglianti Gesendet: Dienstag, 24. November 2015 16:31 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> Betreff: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Anna, The "mei" prefix is set by the mei element (see code here <https://github.com/music-encoding/music-encoding/blob/develop/source/specs/ mei-source.xml#L15325> ), therefore you have to make sure the element is included in your customization. By setting schemaSpec/@start to just "expression", I *think* the mei element gets excluded by the ODD processing (because it's not needed). I would suggest to set schemaSpec/@start to "mei expression", which seems to fix the problem and makes the customization more conformant. Hope this helps. Best, Raff On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net <mailto:annplaksin at gmx.net> > wrote: Hello again, I just added the wrong version of the file to the mail. Sorry for that. Anna Von: mei-l [mailto:mei-l-bounces+annplaksin <mailto:mei-l-bounces%2Bannplaksin> =gmx.net at lists.uni-paderborn.de <mailto:gmx.net at lists.uni-paderborn.de> ] Im Auftrag von Anna Plaksin Gesendet: Dienstag, 24. November 2015 16:14 An: mei-l <mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> > Betreff: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hello all, maybe the ODD experts could help me with this issue: I'm working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn't make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I'm using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I've done but I just don't find it. Is someone able to explain it to me? Thanks, Anna _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de <mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/e3ccfa5a/attachment.html> From pdr4h at eservices.virginia.edu Tue Nov 24 20:45:47 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 24 Nov 2015 19:45:47 +0000 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <001501d126d0$82f14cc0$88d3e640$@gmx.net> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> Message-ID: <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> Hmmmm. I can't reproduce the errors Anna is seeing. But, forcing every customization to include the <mei> element seems like a 'gotcha' to me. Moving the <constraintSpec> that defines the mei prefix for schematron to be the first child of <schemaSpec> seems be the answer. But I can't test that properly since I get no errors either way. I don't see what effect the element -- <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" uri="http://www.tei-c.org/ns/1.0"/> can have on schematron validation when every pattern and every rule is explicitly defined to be in the schematron namespace, e.g., <pattern xmlns="http://purl.oclc.org/dsdl/schematron" id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng="http://relaxng.org/ns/structure/1.0" xmlns:sch="http://purl.oclc.org/dsdl/schematron" context="mei:*[@notationsubtype]"> <sch:assert test="@notationtype">An element with a notationsubtype attribute must have a notationtype attribute.</sch:assert> </sch:rule> </pattern> The @xmlns attribute on <rule> is superfluous since <rule> is explicitly placed in the schematron namespace by the use of the "sch:" prefix and the @xmlns:sch attribute. It seems to me that the TEI namespace is an unnecessary and misleading artifact of using the TEI stylesheets to produce the RNG. But perhaps there's something I'm missing. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Anna Plaksin Sent: Tuesday, November 24, 2015 10:55 AM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Raff, you're totally right, it works. Now I can see how the schematron works properly in an MEI schema even with a TEI namespace. Thank you very, very much for throwing light on this miracle. :-) Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Raffaele Viglianti Gesendet: Dienstag, 24. November 2015 16:31 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Anna, The "mei" prefix is set by the mei element (see code here<https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), therefore you have to make sure the element is included in your customization. By setting schemaSpec/@start to just "expression", I *think* the mei element gets excluded by the ODD processing (because it's not needed). I would suggest to set schemaSpec/@start to "mei expression", which seems to fix the problem and makes the customization more conformant. Hope this helps. Best, Raff On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net<mailto:annplaksin at gmx.net>> wrote: Hello again, I just added the wrong version of the file to the mail... Sorry for that. Anna Von: mei-l [mailto:mei-l-bounces+annplaksin<mailto:mei-l-bounces%2Bannplaksin>=gmx.net at lists.uni-paderborn.de<mailto:gmx.net at lists.uni-paderborn.de>] Im Auftrag von Anna Plaksin Gesendet: Dienstag, 24. November 2015 16:14 An: mei-l <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hello all, maybe the ODD experts could help me with this issue: I'm working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn't make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I'm using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I've done but I just don't find it. Is someone able to explain it to me? Thanks, Anna _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/a8f219e4/attachment.html> From raffaeleviglianti at gmail.com Tue Nov 24 21:07:23 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 24 Nov 2015 15:07:23 -0500 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> Message-ID: <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> Hi Perry, To reproduce Anna's error, I associated the RNG schema with "additional association for embedded schematron rules" in Oxygen. When validating, I got an error on the @context of rules, because they use the "mei" prefix. The schematron engine complains because it doesn't know what the "mei" prefix is. The mei prefix is set (for schematron) in the "mei" elementSpec: <constraintSpec ident="set_ns" scheme="isoschematron"> <constraint> <sch:ns prefix="mei" uri="http://www.music-encoding.org/ns/mei"/> </constraint> </constraintSpec> If the MEI element is not included, this declaration gets dropped. There is another solution to this, now that I think about it: re-instating the namespace declaration on the new root element. For example in Anna's case one could add the constraintSpec above to the "expression"'s elementSpec (I just tested this and the error goes away). I suspect you're right about the TEI stylesheet automagically adding the tei prefix to schematron. It doesn't hurt having it, however. We may still bring this up with TEI folks and see if it's possible to avoid that declaration in a non TEI context. Raff On Tue, Nov 24, 2015 at 2:45 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Hmmmm. I can’t reproduce the errors Anna is seeing. But, forcing every > customization to include the <mei> element seems like a ‘gotcha’ to me. > Moving the <constraintSpec> that defines the mei prefix for schematron to > be the first child of <schemaSpec> seems be the answer. But I can’t test > that properly since I get no errors either way. > > > > I don’t see what effect the element -- > > > > <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" > uri="http://www.tei-c.org/ns/1.0"/> > > > > can have on schematron validation when every pattern and every rule is > explicitly defined to be in the schematron namespace, e.g., > > > > <pattern xmlns="http://purl.oclc.org/dsdl/schematron" > > > id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> > > <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" > > xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng=" > http://relaxng.org/ns/structure/1.0" > > xmlns:sch="http://purl.oclc.org/dsdl/schematron" > context="mei:*[@notationsubtype]"> > > <sch:assert test="@notationtype">An element with a notationsubtype > attribute must have a notationtype attribute.</sch:assert> > > </sch:rule> > > </pattern> > > > > The @xmlns attribute on <rule> is superfluous since <rule> is explicitly > placed in the schematron namespace by the use of the “sch:” prefix and the > @xmlns:sch attribute. > > > > It seems to me that the TEI namespace is an unnecessary and misleading > artifact of using the TEI stylesheets to produce the RNG. But perhaps > there’s something I’m missing. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Anna Plaksin > *Sent:* Tuesday, November 24, 2015 10:55 AM > *To:* 'Music Encoding Initiative' > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Raff, > > > > you’re totally right, it works. > > Now I can see how the schematron works properly in an MEI schema even with > a TEI namespace. > > Thank you very, very much for throwing light on this miracle. :-) > > > > Regards, > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > <mei-l-bounces at lists.uni-paderborn.de>] *Im Auftrag von *Raffaele > Viglianti > *Gesendet:* Dienstag, 24. November 2015 16:31 > *An:* Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > *Betreff:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Anna, > > > > The "mei" prefix is set by the mei element (see code here > <https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), > therefore you have to make sure the element is included in your > customization. By setting schemaSpec/@start to just "expression", I *think* > the mei element gets excluded by the ODD processing (because it's not > needed). > > > > I would suggest to set schemaSpec/@start to "mei expression", which seems > to fix the problem and makes the customization more conformant. > > > > Hope this helps. > > > > Best, > > Raff > > > > On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hello again, > > > > I just added the wrong version of the file to the mail… > > > > Sorry for that. > > > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces+annplaksin= > gmx.net at lists.uni-paderborn.de] *Im Auftrag von *Anna Plaksin > *Gesendet:* Dienstag, 24. November 2015 16:14 > *An:* mei-l <mei-l at lists.uni-paderborn.de> > *Betreff:* [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hello all, > > > > maybe the ODD experts could help me with this issue: > > I’m working on a MEI customization and since yesterday I get pattern > syntax errors complaining about an undeclared namespace prefix in the > schematron rules after the compilation from ODD to Relax NG. > > It seems to me a little bit weird because I didn’t make big changes in my > ODD file and the errors occur both at my own schematron rules and the > preexisting. > > I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the > v2.1.1, but it occurs also with the customization web service. It is > possible to correct the errors in the output file by changing the > schematron <ns> from TEI to MEI but this cannot be a proper solution, > because the namespace is always TEI even if the schema works fine. > > > > I think it is most likely a mistake I’ve done but I just don’t find it. Is > someone able to explain it to me? > > > > Thanks, > > Anna > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/d7510960/attachment.html> From pdr4h at eservices.virginia.edu Tue Nov 24 21:41:16 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 24 Nov 2015 20:41:16 +0000 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D9140CC8E@grant1.eservices.virginia.edu> Thanks, I see the errors now. In the attached ODD, I moved the <constraintSpec> defining the MEI prefix from the <mei> element to the start of the <schemaSpec>. As a result, the RNG contains the namespace definition for MEI as an immediate descendant of <grammar> (although, unlike the TEI namespace declaration, it occurs at the very end of the file) and the errors disappear. I’ll fix this in the MEI source momentarily. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, November 24, 2015 3:08 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Perry, To reproduce Anna's error, I associated the RNG schema with "additional association for embedded schematron rules" in Oxygen. When validating, I got an error on the @context of rules, because they use the "mei" prefix. The schematron engine complains because it doesn't know what the "mei" prefix is. The mei prefix is set (for schematron) in the "mei" elementSpec: <constraintSpec ident="set_ns" scheme="isoschematron"> <constraint> <sch:ns prefix="mei" uri="http://www.music-encoding.org/ns/mei"/> </constraint> </constraintSpec> If the MEI element is not included, this declaration gets dropped. There is another solution to this, now that I think about it: re-instating the namespace declaration on the new root element. For example in Anna's case one could add the constraintSpec above to the "expression"'s elementSpec (I just tested this and the error goes away). I suspect you're right about the TEI stylesheet automagically adding the tei prefix to schematron. It doesn't hurt having it, however. We may still bring this up with TEI folks and see if it's possible to avoid that declaration in a non TEI context. Raff On Tue, Nov 24, 2015 at 2:45 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Hmmmm. I can’t reproduce the errors Anna is seeing. But, forcing every customization to include the <mei> element seems like a ‘gotcha’ to me. Moving the <constraintSpec> that defines the mei prefix for schematron to be the first child of <schemaSpec> seems be the answer. But I can’t test that properly since I get no errors either way. I don’t see what effect the element -- <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" uri="http://www.tei-c.org/ns/1.0"/> can have on schematron validation when every pattern and every rule is explicitly defined to be in the schematron namespace, e.g., <pattern xmlns="http://purl.oclc.org/dsdl/schematron" id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng="http://relaxng.org/ns/structure/1.0" xmlns:sch="http://purl.oclc.org/dsdl/schematron" context="mei:*[@notationsubtype]"> <sch:assert test="@notationtype">An element with a notationsubtype attribute must have a notationtype attribute.</sch:assert> </sch:rule> </pattern> The @xmlns attribute on <rule> is superfluous since <rule> is explicitly placed in the schematron namespace by the use of the “sch:” prefix and the @xmlns:sch attribute. It seems to me that the TEI namespace is an unnecessary and misleading artifact of using the TEI stylesheets to produce the RNG. But perhaps there’s something I’m missing. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Anna Plaksin Sent: Tuesday, November 24, 2015 10:55 AM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Raff, you’re totally right, it works. Now I can see how the schematron works properly in an MEI schema even with a TEI namespace. Thank you very, very much for throwing light on this miracle. :-) Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Raffaele Viglianti Gesendet: Dienstag, 24. November 2015 16:31 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Anna, The "mei" prefix is set by the mei element (see code here<https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), therefore you have to make sure the element is included in your customization. By setting schemaSpec/@start to just "expression", I *think* the mei element gets excluded by the ODD processing (because it's not needed). I would suggest to set schemaSpec/@start to "mei expression", which seems to fix the problem and makes the customization more conformant. Hope this helps. Best, Raff On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net<mailto:annplaksin at gmx.net>> wrote: Hello again, I just added the wrong version of the file to the mail… Sorry for that. Anna Von: mei-l [mailto:mei-l-bounces+annplaksin<mailto:mei-l-bounces%2Bannplaksin>=gmx.net at lists.uni-paderborn.de<mailto:gmx.net at lists.uni-paderborn.de>] Im Auftrag von Anna Plaksin Gesendet: Dienstag, 24. November 2015 16:14 An: mei-l <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hello all, maybe the ODD experts could help me with this issue: I’m working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn’t make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I’ve done but I just don’t find it. Is someone able to explain it to me? Thanks, Anna _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de<mailto: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<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/3d342a78/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: mei-cmo-expression.odd Type: application/octet-stream Size: 23652 bytes Desc: mei-cmo-expression.odd URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/3d342a78/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: mei-cmo-expression.rng Type: application/octet-stream Size: 440525 bytes Desc: mei-cmo-expression.rng URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/3d342a78/attachment-0001.obj> From raffaeleviglianti at gmail.com Tue Nov 24 21:46:02 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 24 Nov 2015 15:46:02 -0500 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D9140CC8E@grant1.eservices.virginia.edu> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D9140CC8E@grant1.eservices.virginia.edu> Message-ID: <CAMyHAnNuePg2dMA77dx2OZRmiVGLoafvmYNby1OUx5tT8VMjtg@mail.gmail.com> Oh, great! I didn't realize that was valid in ODD. Raff On Tue, Nov 24, 2015 at 3:41 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Thanks, I see the errors now. > > > > In the attached ODD, I moved the <constraintSpec> defining the MEI prefix > from the <mei> element to the start of the <schemaSpec>. As a result, the > RNG contains the namespace definition for MEI as an immediate descendant of > <grammar> (although, unlike the TEI namespace declaration, it occurs at the > very end of the file) and the errors disappear. > > > > I’ll fix this in the MEI source momentarily. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, November 24, 2015 3:08 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Perry, > > > > To reproduce Anna's error, I associated the RNG schema with "additional > association for embedded schematron rules" in Oxygen. When validating, I > got an error on the @context of rules, because they use the "mei" prefix. > The schematron engine complains because it doesn't know what the "mei" > prefix is. > > > > The mei prefix is set (for schematron) in the "mei" elementSpec: > > > > <constraintSpec ident="set_ns" scheme="isoschematron"> > > <constraint> > > <sch:ns prefix="mei" uri="http://www.music-encoding.org/ns/mei"/> > > </constraint> > > </constraintSpec> > > > > If the MEI element is not included, this declaration gets dropped. > > > > There is another solution to this, now that I think about it: re-instating > the namespace declaration on the new root element. For example in Anna's > case one could add the constraintSpec above to the "expression"'s > elementSpec (I just tested this and the error goes away). > > > > I suspect you're right about the TEI stylesheet automagically adding the > tei prefix to schematron. It doesn't hurt having it, however. We may still > bring this up with TEI folks and see if it's possible to avoid that > declaration in a non TEI context. > > > > Raff > > > > On Tue, Nov 24, 2015 at 2:45 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > Hmmmm. I can’t reproduce the errors Anna is seeing. But, forcing every > customization to include the <mei> element seems like a ‘gotcha’ to me. > Moving the <constraintSpec> that defines the mei prefix for schematron to > be the first child of <schemaSpec> seems be the answer. But I can’t test > that properly since I get no errors either way. > > > > I don’t see what effect the element -- > > > > <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" > uri="http://www.tei-c.org/ns/1.0"/> > > > > can have on schematron validation when every pattern and every rule is > explicitly defined to be in the schematron namespace, e.g., > > > > <pattern xmlns="http://purl.oclc.org/dsdl/schematron" > > > id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> > > <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" > > xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng=" > http://relaxng.org/ns/structure/1.0" > > xmlns:sch="http://purl.oclc.org/dsdl/schematron" > context="mei:*[@notationsubtype]"> > > <sch:assert test="@notationtype">An element with a notationsubtype > attribute must have a notationtype attribute.</sch:assert> > > </sch:rule> > > </pattern> > > > > The @xmlns attribute on <rule> is superfluous since <rule> is explicitly > placed in the schematron namespace by the use of the “sch:” prefix and the > @xmlns:sch attribute. > > > > It seems to me that the TEI namespace is an unnecessary and misleading > artifact of using the TEI stylesheets to produce the RNG. But perhaps > there’s something I’m missing. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Anna Plaksin > *Sent:* Tuesday, November 24, 2015 10:55 AM > *To:* 'Music Encoding Initiative' > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Raff, > > > > you’re totally right, it works. > > Now I can see how the schematron works properly in an MEI schema even with > a TEI namespace. > > Thank you very, very much for throwing light on this miracle. :-) > > > > Regards, > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > <mei-l-bounces at lists.uni-paderborn.de>] *Im Auftrag von *Raffaele > Viglianti > *Gesendet:* Dienstag, 24. November 2015 16:31 > *An:* Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > *Betreff:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Anna, > > > > The "mei" prefix is set by the mei element (see code here > <https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), > therefore you have to make sure the element is included in your > customization. By setting schemaSpec/@start to just "expression", I *think* > the mei element gets excluded by the ODD processing (because it's not > needed). > > > > I would suggest to set schemaSpec/@start to "mei expression", which seems > to fix the problem and makes the customization more conformant. > > > > Hope this helps. > > > > Best, > > Raff > > > > On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hello again, > > > > I just added the wrong version of the file to the mail… > > > > Sorry for that. > > > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces+annplaksin= > gmx.net at lists.uni-paderborn.de] *Im Auftrag von *Anna Plaksin > *Gesendet:* Dienstag, 24. November 2015 16:14 > *An:* mei-l <mei-l at lists.uni-paderborn.de> > *Betreff:* [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hello all, > > > > maybe the ODD experts could help me with this issue: > > I’m working on a MEI customization and since yesterday I get pattern > syntax errors complaining about an undeclared namespace prefix in the > schematron rules after the compilation from ODD to Relax NG. > > It seems to me a little bit weird because I didn’t make big changes in my > ODD file and the errors occur both at my own schematron rules and the > preexisting. > > I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the > v2.1.1, but it occurs also with the customization web service. It is > possible to correct the errors in the output file by changing the > schematron <ns> from TEI to MEI but this cannot be a proper solution, > because the namespace is always TEI even if the schema works fine. > > > > I think it is most likely a mistake I’ve done but I just don’t find it. Is > someone able to explain it to me? > > > > Thanks, > > Anna > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/cf55a806/attachment.html> From pdr4h at eservices.virginia.edu Tue Nov 24 22:27:17 2015 From: pdr4h at eservices.virginia.edu (Roland, Perry D. (pdr4h)) Date: Tue, 24 Nov 2015 21:27:17 +0000 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <CAMyHAnNuePg2dMA77dx2OZRmiVGLoafvmYNby1OUx5tT8VMjtg@mail.gmail.com> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D9140CC8E@grant1.eservices.virginia.edu> <CAMyHAnNuePg2dMA77dx2OZRmiVGLoafvmYNby1OUx5tT8VMjtg@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D9140DCDD@grant1.eservices.virginia.edu> Hmmmmmmmmmmm. Perhaps we’ve congratulated ourselves a little too soon. Adding the <constraintSpec> that defines the MEI namespace to mei-source has no effect. Since adding it to a customization file *does work*, I assume that the TEI stylesheets ignore any namespace declarations in the “source” file and just “automagically” output a TEI declaration <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" uri="http://www.tei-c.org/ns/1.0"/> Our only option at this point then, is to put the MEI namespace declaration in every customization file. That’s easily done, but isn’t a very satisfying answer. ☹ -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Raffaele Viglianti Sent: Tuesday, November 24, 2015 3:47 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Oh, great! I didn't realize that was valid in ODD. Raff On Tue, Nov 24, 2015 at 3:41 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Thanks, I see the errors now. In the attached ODD, I moved the <constraintSpec> defining the MEI prefix from the <mei> element to the start of the <schemaSpec>. As a result, the RNG contains the namespace definition for MEI as an immediate descendant of <grammar> (although, unlike the TEI namespace declaration, it occurs at the very end of the file) and the errors disappear. I’ll fix this in the MEI source momentarily. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Raffaele Viglianti Sent: Tuesday, November 24, 2015 3:08 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Perry, To reproduce Anna's error, I associated the RNG schema with "additional association for embedded schematron rules" in Oxygen. When validating, I got an error on the @context of rules, because they use the "mei" prefix. The schematron engine complains because it doesn't know what the "mei" prefix is. The mei prefix is set (for schematron) in the "mei" elementSpec: <constraintSpec ident="set_ns" scheme="isoschematron"> <constraint> <sch:ns prefix="mei" uri="http://www.music-encoding.org/ns/mei"/> </constraint> </constraintSpec> If the MEI element is not included, this declaration gets dropped. There is another solution to this, now that I think about it: re-instating the namespace declaration on the new root element. For example in Anna's case one could add the constraintSpec above to the "expression"'s elementSpec (I just tested this and the error goes away). I suspect you're right about the TEI stylesheet automagically adding the tei prefix to schematron. It doesn't hurt having it, however. We may still bring this up with TEI folks and see if it's possible to avoid that declaration in a non TEI context. Raff On Tue, Nov 24, 2015 at 2:45 PM, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Hmmmm. I can’t reproduce the errors Anna is seeing. But, forcing every customization to include the <mei> element seems like a ‘gotcha’ to me. Moving the <constraintSpec> that defines the mei prefix for schematron to be the first child of <schemaSpec> seems be the answer. But I can’t test that properly since I get no errors either way. I don’t see what effect the element -- <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" uri="http://www.tei-c.org/ns/1.0"/> can have on schematron validation when every pattern and every rule is explicitly defined to be in the schematron namespace, e.g., <pattern xmlns="http://purl.oclc.org/dsdl/schematron" id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng="http://relaxng.org/ns/structure/1.0" xmlns:sch="http://purl.oclc.org/dsdl/schematron" context="mei:*[@notationsubtype]"> <sch:assert test="@notationtype">An element with a notationsubtype attribute must have a notationtype attribute.</sch:assert> </sch:rule> </pattern> The @xmlns attribute on <rule> is superfluous since <rule> is explicitly placed in the schematron namespace by the use of the “sch:” prefix and the @xmlns:sch attribute. It seems to me that the TEI namespace is an unnecessary and misleading artifact of using the TEI stylesheets to produce the RNG. But perhaps there’s something I’m missing. -- p. From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Anna Plaksin Sent: Tuesday, November 24, 2015 10:55 AM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Raff, you’re totally right, it works. Now I can see how the schematron works properly in an MEI schema even with a TEI namespace. Thank you very, very much for throwing light on this miracle. :-) Regards, Anna Von: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] Im Auftrag von Raffaele Viglianti Gesendet: Dienstag, 24. November 2015 16:31 An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hi Anna, The "mei" prefix is set by the mei element (see code here<https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), therefore you have to make sure the element is included in your customization. By setting schemaSpec/@start to just "expression", I *think* the mei element gets excluded by the ODD processing (because it's not needed). I would suggest to set schemaSpec/@start to "mei expression", which seems to fix the problem and makes the customization more conformant. Hope this helps. Best, Raff On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net<mailto:annplaksin at gmx.net>> wrote: Hello again, I just added the wrong version of the file to the mail… Sorry for that. Anna Von: mei-l [mailto:mei-l-bounces+annplaksin<mailto:mei-l-bounces%2Bannplaksin>=gmx.net at lists.uni-paderborn.de<mailto:gmx.net at lists.uni-paderborn.de>] Im Auftrag von Anna Plaksin Gesendet: Dienstag, 24. November 2015 16:14 An: mei-l <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> Betreff: [MEI-L] Stylesheet compilation: undeclared namespace prefix Hello all, maybe the ODD experts could help me with this issue: I’m working on a MEI customization and since yesterday I get pattern syntax errors complaining about an undeclared namespace prefix in the schematron rules after the compilation from ODD to Relax NG. It seems to me a little bit weird because I didn’t make big changes in my ODD file and the errors occur both at my own schematron rules and the preexisting. I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the v2.1.1, but it occurs also with the customization web service. It is possible to correct the errors in the output file by changing the schematron <ns> from TEI to MEI but this cannot be a proper solution, because the namespace is always TEI even if the schema works fine. I think it is most likely a mistake I’ve done but I just don’t find it. Is someone able to explain it to me? Thanks, Anna _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de<mailto: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<mailto: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<mailto:mei-l at lists.uni-paderborn.de> https://lists.uni-paderborn.de/mailman/listinfo/mei-l -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151124/619ae6fe/attachment.html> From raffaeleviglianti at gmail.com Wed Nov 25 16:04:55 2015 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Wed, 25 Nov 2015 10:04:55 -0500 Subject: [MEI-L] Stylesheet compilation: undeclared namespace prefix In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D9140DCDD@grant1.eservices.virginia.edu> References: <000001d126ca$b2f73610$18e5a230$@gmx.net> <000501d126cb$83731930$8a594b90$@gmx.net> <CAMyHAnOCUz3kOnKrxD7PjFrZse0A+B9Jc-9_wyCUCRyO6SPWbg@mail.gmail.com> <001501d126d0$82f14cc0$88d3e640$@gmx.net> <BBCC497C40D85642B90E9F94FC30343D9140CC26@grant1.eservices.virginia.edu> <CAMyHAnN=9PTD4z1QdqULZpsKmgRh4NAT91sF4j+XZzVYhXQ+6A@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D9140CC8E@grant1.eservices.virginia.edu> <CAMyHAnNuePg2dMA77dx2OZRmiVGLoafvmYNby1OUx5tT8VMjtg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D9140DCDD@grant1.eservices.virginia.edu> Message-ID: <CAMyHAnPaRJue8WyKpiuY-ve9k_wrWdfgZCSkEe2daKaUHNd8Lw@mail.gmail.com> I'll open an issue on the TEI Stylesheets repository and see if it can be solved there. Raff On Tue, Nov 24, 2015 at 4:27 PM, Roland, Perry D. (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > > > Hmmmmmmmmmmm. Perhaps we’ve congratulated ourselves a little too soon. > > > > Adding the <constraintSpec> that defines the MEI namespace to mei-source > has no effect. Since adding it to a customization file **does work**, I > assume that the TEI stylesheets ignore any namespace declarations in the > “source” file and just “automagically” output a TEI declaration > > > > <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" > uri="http://www.tei-c.org/ns/1.0"/> > > > > Our only option at this point then, is to put the MEI namespace > declaration in every customization file. That’s easily done, but isn’t a > very satisfying answer. L > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, November 24, 2015 3:47 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Oh, great! I didn't realize that was valid in ODD. > > > > Raff > > > > On Tue, Nov 24, 2015 at 3:41 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > Thanks, I see the errors now. > > > > In the attached ODD, I moved the <constraintSpec> defining the MEI prefix > from the <mei> element to the start of the <schemaSpec>. As a result, the > RNG contains the namespace definition for MEI as an immediate descendant of > <grammar> (although, unlike the TEI namespace declaration, it occurs at the > very end of the file) and the errors disappear. > > > > I’ll fix this in the MEI source momentarily. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Raffaele Viglianti > *Sent:* Tuesday, November 24, 2015 3:08 PM > > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Perry, > > > > To reproduce Anna's error, I associated the RNG schema with "additional > association for embedded schematron rules" in Oxygen. When validating, I > got an error on the @context of rules, because they use the "mei" prefix. > The schematron engine complains because it doesn't know what the "mei" > prefix is. > > > > The mei prefix is set (for schematron) in the "mei" elementSpec: > > > > <constraintSpec ident="set_ns" scheme="isoschematron"> > > <constraint> > > <sch:ns prefix="mei" uri="http://www.music-encoding.org/ns/mei"/> > > </constraint> > > </constraintSpec> > > > > If the MEI element is not included, this declaration gets dropped. > > > > There is another solution to this, now that I think about it: re-instating > the namespace declaration on the new root element. For example in Anna's > case one could add the constraintSpec above to the "expression"'s > elementSpec (I just tested this and the error goes away). > > > > I suspect you're right about the TEI stylesheet automagically adding the > tei prefix to schematron. It doesn't hurt having it, however. We may still > bring this up with TEI folks and see if it's possible to avoid that > declaration in a non TEI context. > > > > Raff > > > > On Tue, Nov 24, 2015 at 2:45 PM, Roland, Perry D. (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > > > > Hmmmm. I can’t reproduce the errors Anna is seeing. But, forcing every > customization to include the <mei> element seems like a ‘gotcha’ to me. > Moving the <constraintSpec> that defines the mei prefix for schematron to > be the first child of <schemaSpec> seems be the answer. But I can’t test > that properly since I get no errors either way. > > > > I don’t see what effect the element -- > > > > <sch:ns xmlns:sch="http://purl.oclc.org/dsdl/schematron" prefix="tei" > uri="http://www.tei-c.org/ns/1.0"/> > > > > can have on schematron validation when every pattern and every rule is > explicitly defined to be in the schematron namespace, e.g., > > > > <pattern xmlns="http://purl.oclc.org/dsdl/schematron" > > > id="mei-att.notationtype-notationsubtype-When_notationsubtype-constraint-1"> > > <sch:rule xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" > > xmlns="http://www.tei-c.org/ns/1.0" xmlns:rng=" > http://relaxng.org/ns/structure/1.0" > > xmlns:sch="http://purl.oclc.org/dsdl/schematron" > context="mei:*[@notationsubtype]"> > > <sch:assert test="@notationtype">An element with a notationsubtype > attribute must have a notationtype attribute.</sch:assert> > > </sch:rule> > > </pattern> > > > > The @xmlns attribute on <rule> is superfluous since <rule> is explicitly > placed in the schematron namespace by the use of the “sch:” prefix and the > @xmlns:sch attribute. > > > > It seems to me that the TEI namespace is an unnecessary and misleading > artifact of using the TEI stylesheets to produce the RNG. But perhaps > there’s something I’m missing. > > > > -- > > p. > > > > > > *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *On Behalf Of > *Anna Plaksin > *Sent:* Tuesday, November 24, 2015 10:55 AM > *To:* 'Music Encoding Initiative' > *Subject:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Raff, > > > > you’re totally right, it works. > > Now I can see how the schematron works properly in an MEI schema even with > a TEI namespace. > > Thank you very, very much for throwing light on this miracle. :-) > > > > Regards, > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de > <mei-l-bounces at lists.uni-paderborn.de>] *Im Auftrag von *Raffaele > Viglianti > *Gesendet:* Dienstag, 24. November 2015 16:31 > *An:* Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > *Betreff:* Re: [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hi Anna, > > > > The "mei" prefix is set by the mei element (see code here > <https://github.com/music-encoding/music-encoding/blob/develop/source/specs/mei-source.xml#L15325>), > therefore you have to make sure the element is included in your > customization. By setting schemaSpec/@start to just "expression", I *think* > the mei element gets excluded by the ODD processing (because it's not > needed). > > > > I would suggest to set schemaSpec/@start to "mei expression", which seems > to fix the problem and makes the customization more conformant. > > > > Hope this helps. > > > > Best, > > Raff > > > > On Tue, Nov 24, 2015 at 10:19 AM, Anna Plaksin <annplaksin at gmx.net> wrote: > > Hello again, > > > > I just added the wrong version of the file to the mail… > > > > Sorry for that. > > > > Anna > > > > *Von:* mei-l [mailto:mei-l-bounces+annplaksin= > gmx.net at lists.uni-paderborn.de] *Im Auftrag von *Anna Plaksin > *Gesendet:* Dienstag, 24. November 2015 16:14 > *An:* mei-l <mei-l at lists.uni-paderborn.de> > *Betreff:* [MEI-L] Stylesheet compilation: undeclared namespace prefix > > > > Hello all, > > > > maybe the ODD experts could help me with this issue: > > I’m working on a MEI customization and since yesterday I get pattern > syntax errors complaining about an undeclared namespace prefix in the > schematron rules after the compilation from ODD to Relax NG. > > It seems to me a little bit weird because I didn’t make big changes in my > ODD file and the errors occur both at my own schematron rules and the > preexisting. > > I’m using the TEI framework in Oxygen 17.1 with the driver.xml of the > v2.1.1, but it occurs also with the customization web service. It is > possible to correct the errors in the output file by changing the > schematron <ns> from TEI to MEI but this cannot be a proper solution, > because the namespace is always TEI even if the schema works fine. > > > > I think it is most likely a mistake I’ve done but I just don’t find it. Is > someone able to explain it to me? > > > > Thanks, > > Anna > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151125/32c26eb8/attachment.html> From lxpugin at gmail.com Mon Nov 30 16:47:50 2015 From: lxpugin at gmail.com (Laurent Pugin) Date: Mon, 30 Nov 2015 16:47:50 +0100 Subject: [MEI-L] Input to MEI In-Reply-To: <CAJ306HapZkcGt1=mdi0zGKDnR21fx1MEpy++jUnFJ2e6G+crjQ@mail.gmail.com> References: <564B0719.4080704@musikologie.de> <99285895-6818-4776-821C-9D3673BC29DE@edirom.de> <564B1683.5090106@musikologie.de> <CAJ306HapZkcGt1=mdi0zGKDnR21fx1MEpy++jUnFJ2e6G+crjQ@mail.gmail.com> Message-ID: <CAJ306HZu91OpMRq0BwZfm8Ez3qrPB4Vb7W=dWwMWiyaOZTLzGQ@mail.gmail.com> Dear Jürgen, I put online a new version of Verovio that supports basic conversion from MusicXML to MEI. It is available online here: http://www.verovio.org/musicxml.html You can try it with some example files that are provided or with you own file. As explained, only the features supported by Verovio will be converted, so keep in mind that this is still experimental and work in progress. Best, Laurent On Tue, Nov 17, 2015 at 1:07 PM, Laurent Pugin <lxpugin at gmail.com> wrote: > Dear Jürgen, > > The XSLT is indeed the most comprehensive way to convert MusicXML to MEI. > > We have been working recently on converting MusicXML to MEI in Verovio. Of > course, only the features supported in Verovio will be converted, so this > is definitely not a replacement solution of the XSLT. However, this can > still be useful depending on the data you have and what you would like to > achieve, for example if you just want to have a preview. > > I will put this online hopefully next week. > > Best, > Laurent > > On Tue, Nov 17, 2015 at 12:58 PM, Jürgen Schöpf <j.schoepf at musikologie.de> > wrote: > >> Thank you both Johannes and Andrew, >> >> it looks like a workaround so far, but I feel not alone :-) >> So I will continue to work in Finale and if issues arise come back on >> this helpful list. Thanks again & best regards >> :-J >> >> Am 17.11.15 um 12:31 schrieb Johannes Kepper: >> > Dear Herr Schöpf, >> > >> > there is an XSLT that converts MusicXML to MEI, which is available from >> https://raw.githubusercontent.com/music-encoding/music-encoding/develop/tools/musicxml2mei/musicxml2mei-3.0.xsl >> > >> > We've used that extensively for the Freischütz project to convert files >> from Finale. When you export from Finale, it will generate a so-called >> "partwise" MusicXML, which you have to convert to "timewise" MusicXML using >> the XSLT available from >> http://www.musicxml.com/for-developers/musicxml-xslt/partwise-to-timewise/. >> This "timewise" file can then be converted using the musicxml2mei converter >> mentioned above. >> > >> > If you need further assistance, please let me know. >> > >> > Best, >> > Johannes >> > >> > Am 17.11.2015 um 11:53 schrieb Jürgen Schöpf <j.schoepf at musikologie.de >> >: >> > >> >> Dear list, >> >> >> >> I see a Sibelius plug-in to MEI, but I could not find any information >> >> regarding a workflow from Finale/MusicXML to MEI. I would prefer to >> >> upgrade my old Finale version if I could get it to work with MEI, >> >> otherwise I have to buy Sibelius new. I would appreciate experiences of >> >> other Finale users how they work from Finale/MusicXML into MEI. >> >> >> >> thanks >> >> :-J >> >> J. Schöpf >> >> >> >> _______________________________________________ >> >> mei-l mailing list >> >> mei-l at lists.uni-paderborn.de >> >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> > >> > >> > >> > _______________________________________________ >> > mei-l mailing list >> > mei-l at lists.uni-paderborn.de >> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> > >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151130/a25ac475/attachment.html> From stadler at edirom.de Tue Dec 1 20:51:18 2015 From: stadler at edirom.de (Peter Stadler) Date: Tue, 1 Dec 2015 20:51:18 +0100 Subject: [MEI-L] Fwd: [iaml-l] CfP: IJDL Special Issue on Digital Libraries for Musicology References: <854mg2jk1r.wl-richard.lewis@gold.ac.uk> Message-ID: <C0AE78B1-2E04-4B68-9A50-C5A77809ACD9@edirom.de> This might as well be of interest to this community! Cheers Peter > Anfang der weitergeleiteten Nachricht: > > Von: Richard Lewis <richard.lewis at gold.ac.uk> > Datum: 1. Dezember 2015 um 15:54:56 MEZ > An: iaml-l at cornell.edu > Betreff: [iaml-l] CfP: IJDL Special Issue on Digital Libraries for Musicology > > International Journal on Digital Libraries > CALL FOR PAPERS > > SPECIAL ISSUE ON: > Digital Libraries for Musicology (DLfM) > > <https://www.springer.com/?SGWID=0-102-2-1435147-preview> > <http://www.t-mus.org/news/2015-12-01_special-issue-of-ijdl-on-dlfm/> > > Many Digital Libraries have long offered facilities to provide > multimedia content, including music. However there is now an ever more > urgent need to specifically support the distinct multiple forms of > music, the links between them, and the surrounding scholarly context, > as required by the transformed and extended methods being applied to > musicology and the wider Digital Humanities. > > The Digital Libraries for Musicology (DLfM) special issue presents a > venue specifically for those working on, and with, Digital Library > systems and content in the domain of music and musicology. This > includes Music Digital Library systems, their application and use in > musicology, technologies for enhanced access and organisation of > musics in Digital Libraries, bibliographic and metadata for music, > intersections with music Linked Data, and the challenges of working > with the multiple representations of music across large­scale digital > collections such as the Internet Archive and HathiTrust. > > The DLfM special issue will focus on the implications of music on > Digital Libraries and Digital Libraries research when pushing the > boundaries of contemporary musicology, including the application of > techniques as reported in more technologically oriented fora such as > ISMIR and ICMC. > > This issue follows two years of similarly themed and named > workshops. These workshops were co­located with, respectively, Digital > Libraries 2014 and the Joint Conference on Digital Libraries (JCDL) > 2015. This call aims to continue a conversation that began in 2002 > with the "Music Information Retrieval (MIR) and Music Digital Library > (MDL) Evaluation", held at JCDL 2002, which was instrumental in the > development and evaluation of technical methods now widespread in > these research communities. > > This focused issue seeks to act as a forum for reporting, presenting, > and evaluating this work and disseminating new approaches to advance > the discipline; to create a venue for critically and constructively > evaluating and verifying the operation of Music Digital Libraries and > the applications and findings that flow from them; to consider the > suitability of existing Music Digital Libraries, particularly in light > of the transformative methods and applications emerging from > musicology and "Large, Dynamic, and Ubiquitous" collections of both > audio and music related data; to set the agenda for work in the field > to address these new challenges and opportunities. > > This focused issue will solicit high quality papers that demonstrate > exceptional achievements in Digital Libraries for Musicology, > including but not limited to: > > - Music Digital Libraries. > - Digital Libraries in consideration of "Large, Dynamic and > Ubiquitous" collections of audio and music related data. > - Techniques for locating and accessing music in Very Large Digital > Libraries (e.g. HathiTrust, Internet Archive). > - Music data representations, including manuscripts/scores and audio > - Interfaces and access mechanisms for Music Digital Libraries. > - Digital Libraries in support of musicology and other scholarly > study; novel requirements and methodologies therein. > - Digital Libraries for combination of resources in support of > musicology (e.g. combining audio, scores, bibliographic, > geographic, ethnomusicology, performance, etc.) > - User information needs and behaviour for Music Digital > Libraries. Identification/location of music (in all forms) in > generic Digital Libraries. > - Mechanisms for combining multi­form music content within and > between Digital Libraries and other digital resources. > - Information literacies for Music Digital Libraries. > - Metadata and metadata schemas for music. > - Application of Linked Data and Semantic Web techniques to Music > Digital Libraries, and for their access and organisation. > - Optical Music Recognition. > - Ontologies and categorisation of musics and music artefacts. > > > IMPORTANT DATES > > January 29, 2016 Paper Submission deadline > April 5, 2016 First notification > May 27, 2016 Revision submission > July 1, 2016 Second notification > September 9, 2016 Final version submission > > > GUEST EDITORS > > - J. Stephen Downie <jdownie at illinois.edu> Graduate School of Library > and Information Science University of Illinois > - Ben Fields <me at benfields.net> Department of Computing, Goldsmiths > University of London > - Kevin Page <kevin.page at oerc.ox.ac.uk> Oxford e­Research Centre, > University of Oxford > > > PAPER SUBMISSION > > Papers submitted to this special issue for possible publication must > be original and must not be under consideration for publication in any > other journal or conference. Previously published or accepted > conference papers must contain at least 30% new material to be > considered for the special issue. > > All papers are to be submitted by referring to > <http://www.springer.com/799>. At the beginning of the submission > process, under "Article Type", please select the appropriate special > issue. All manuscripts must be prepared according to the journal > publication guidelines which can also be found on the website provided > above. Papers will be reviewed following the journal's standard review > process. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Richard Lewis > Computing, Goldsmiths' College > t: +44 (0)20 7078 5203 > @: lewisrichard > http://www.transforming-musicology.org/ > 905C D796 12CD 4C6E CBFB 69DA EFCE DCDF 71D7 D455 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > ~~~~~~~~ > IAML-L is the mailing list of IAML (International Association of Music Libraries, Archives, and Documentation Centres). > Any use of communications or subscriber contact information for commercial purposes is unacceptable and will result in removal from the list. > -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 455 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151201/c296410f/attachment.sig> From christopher at antila.ca Sun Dec 6 21:24:55 2015 From: christopher at antila.ca (Christopher Antila) Date: Sun, 6 Dec 2015 15:24:55 -0500 Subject: [MEI-L] MEI Support for the Atom Text Editor Message-ID: <56649997.20508@antila.ca> Greetings: I just published a package for the Atom text editor that adds support for MEI files with the ".mei" extension. At the moment, this extension is an exact copy of the built-in support for XML, so if all your MEI files end with ".xml" it won't make a difference. In the future, I hope to add a few MEI-specific features that wouldn't make sense in a generic XML plugin. You can install the package from the commandline (run "apm install language-mei") or from Atom's GUI package manager. https://atom.io/packages/language-mei Christopher -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151206/287795df/attachment.sig> From kepper at edirom.de Thu Dec 17 11:35:48 2015 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 17 Dec 2015 11:35:48 +0100 Subject: [MEI-L] multiple manuscripts Message-ID: <FE1C116B-65CD-4DA8-8765-0DCC36D5CAEC@edirom.de> Dear all, with the Beethoven project, we're starting to deal with situations laid out across multiple manuscripts. While Edirom and other related / dependent projects use separate files for each encoding, we're trying to deal with this in one shared encoding, using <app> / <rdg> (or similar) to differentiate between the documents involved. I would like to know if and how other projects have dealt with the connection to facsimiles in this setup. Happily, MEI allows multiple <facsimile> elements side by side, so it's quite easy to separate those sources in the XML. However, there is no strong connection between any particular <facsimile> and a <source> element, except using @decls on <facsimile> to point to the <source>. Before requesting to add the (in my eyes) more appropriate @source on <facsimile>, I'd like to hear what others have done in this regard. Thanks for the feedback, jo -------------- nächster Teil -------------- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 496 bytes Beschreibung: Message signed with OpenPGP using GPGMail URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151217/2a7b0ae4/attachment.sig>