</titleStmt> <pubStmt/> </fileDesc> </meiHead> <music> <body> <mdiv> <score> <section> <measure> <staff> <layer> <note> <choice> <orig> <syl>Ms.</syl> </orig> <reg> <syl>Miss</syl> </reg> </choice> </note> </layer> </staff> </measure> </section> </score> </mdiv> </body> </music> </mei> I let oXygen validate against the RNG that the web service gave me, and it complains about <syl> in <orig> or <reg>. Indeed, the documentation says, <syl> is only allowed inside <lem>, <rdg>, <verse>, <syllable> and <note>. Why is this so? Bug or feature? Thomas From zupftom at googlemail.com Thu Mar 8 18:10:19 2012 From: zupftom at googlemail.com (TW) Date: Thu, 8 Mar 2012 18:10:19 +0100 Subject: [MEI-L] <syl> inside <choice> In-Reply-To: <CAEB1mApswRW92C1u2WjSMX2_soUHme0q4uCKyVo+eBNHyg99Sw@mail.gmail.com> References: <CAEB1mApswRW92C1u2WjSMX2_soUHme0q4uCKyVo+eBNHyg99Sw@mail.gmail.com> Message-ID: <CAEB1mAqhdRVpuPSpOq8XxKUPHd0HJnapytTAvU867jCuz96nug@mail.gmail.com> It seems the following is legal: <?xml version="1.0" encoding="UTF-8"?> <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> </fileDesc> </meiHead> <music> <body> <mdiv> <score> <section> <measure> <staff> <layer> <note> <syl> <orig>Ms.</orig> <reg>Miss</reg> </syl> </note> </layer> </staff> </measure> </section> </score> </mdiv> </body> </music> </mei> But why like this and not with <choice>? Thomas 2012/3/8 TW <zupftom at googlemail.com>: > I just tried something like: > > <?xml version="1.0" encoding="UTF-8"?> > <mei xmlns="http://www.music-encoding.org/ns/mei"> > ?<meiHead> > ? ?<fileDesc> > ? ? ?<titleStmt> > ? ? ? ?<title/> > ? ? ?</titleStmt> > ? ? ?<pubStmt/> > ? ?</fileDesc> > ?</meiHead> > ?<music> > ? ?<body> > ? ? ?<mdiv> > ? ? ? ?<score> > ? ? ? ? ?<section> > ? ? ? ? ? ?<measure> > ? ? ? ? ? ? ?<staff> > ? ? ? ? ? ? ? ?<layer> > ? ? ? ? ? ? ? ? ?<note> > ? ? ? ? ? ? ? ? ? ?<choice> > ? ? ? ? ? ? ? ? ? ? ?<orig> > ? ? ? ? ? ? ? ? ? ? ? ?<syl>Ms.</syl> > ? ? ? ? ? ? ? ? ? ? ?</orig> > ? ? ? ? ? ? ? ? ? ? ?<reg> > ? ? ? ? ? ? ? ? ? ? ? ?<syl>Miss</syl> > ? ? ? ? ? ? ? ? ? ? ?</reg> > ? ? ? ? ? ? ? ? ? ?</choice> > ? ? ? ? ? ? ? ? ?</note> > ? ? ? ? ? ? ? ?</layer> > ? ? ? ? ? ? ?</staff> > ? ? ? ? ? ?</measure> > ? ? ? ? ?</section> > ? ? ? ?</score> > ? ? ?</mdiv> > ? ?</body> > ?</music> > </mei> > > > I let oXygen validate against the RNG that the web service gave me, > and it complains about <syl> in <orig> or <reg>. ?Indeed, the > documentation says, <syl> is only allowed inside <lem>, <rdg>, > <verse>, <syllable> and <note>. ?Why is this so? ?Bug or feature? > > Thomas From pdr4h at eservices.virginia.edu Thu Mar 8 20:57:40 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 8 Mar 2012 19:57:40 +0000 Subject: [MEI-L] <syl> inside <choice> In-Reply-To: <CAEB1mAqhdRVpuPSpOq8XxKUPHd0HJnapytTAvU867jCuz96nug@mail.gmail.com> References: <CAEB1mApswRW92C1u2WjSMX2_soUHme0q4uCKyVo+eBNHyg99Sw@mail.gmail.com>, <CAEB1mAqhdRVpuPSpOq8XxKUPHd0HJnapytTAvU867jCuz96nug@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01150759@GRANT.eservices.virginia.edu> Hi, Thomas, I just validated your examples against /trunk/schemata/mei-all.rng, which I believe reflects the proper behavior expressed in the current version of mei-source. Because <choice> is a member of model.editLike, it is allowed in the content of <syl>.  <content> <rng:zeroOrMore> <rng:choice> <rng:text/> <rng:ref name="model.textphraseLike.limited"/> <rng:ref name="model.editLike"/> <rng:ref name="model.transcriptionLike"/> </rng:choice> </rng:zeroOrMore> </content> So, this should validate: <syl> <choice> <orig></orig> <reg></orig> </choice> </syl> The following is (perhaps unfortuntely) also permitted <syl> <orig/> <reg/> </syl> because <syl> also allows model.transcriptionLike members, one of which is <orig>, as do many elements that allow mixed content. In this case, no choice between the 2 things is suggested. The assumption is that the members of transcriptionLike, most usefully <add>, <del>, <sic>, <corr>, etc., will be used to mark parts of the text phrase, as in <syl>glare<add>d</add></syl> which indicates that the 'd' was added later. The <orig> and <reg> elements come as part of the transcriptionLike class -- it's too hard to exclude them. The <syl> element is *not allowed* in any of the transcriptionLike elements, such as <orig> or <reg> because <choice> <orig> <syl>Ms.</syl> </orig> <reg> <syl>Miss</syl> </reg> </choice> can be expressed more succinctly as <syl> <choice> <orig>Ms.</orig> <reg>Miss</reg> </choice> </syl> and, unlike some other things under discussion recently, in this case the decision was to allow only one way to do it. (MEI, like most other things in the real world, is not completely self-consistent -- sue me.) Unless the customization service is using an outdated/cached version of mei-source.xml, I can't say why you're getting different behavior. Maybe this is a question for Daniel R. Hope this helps, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Thursday, March 08, 2012 12:10 PM To: Music Encoding Initiative Subject: Re: [MEI-L] <syl> inside <choice> It seems the following is legal: <?xml version="1.0" encoding="UTF-8"?> <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> </fileDesc> </meiHead> <music> <body> <mdiv> <score> <section> <measure> <staff> <layer> <note> <syl> <orig>Ms.</orig> <reg>Miss</reg> </syl> </note> </layer> </staff> </measure> </section> </score> </mdiv> </body> </music> </mei> But why like this and not with <choice>? Thomas 2012/3/8 TW <zupftom at googlemail.com>: > I just tried something like: > > <?xml version="1.0" encoding="UTF-8"?> > <mei xmlns="http://www.music-encoding.org/ns/mei"> > <meiHead> > <fileDesc> > <titleStmt> > <title/> > </titleStmt> > <pubStmt/> > </fileDesc> > </meiHead> > <music> > <body> > <mdiv> > <score> > <section> > <measure> > <staff> > <layer> > <note> > <choice> > <orig> > <syl>Ms.</syl> > </orig> > <reg> > <syl>Miss</syl> > </reg> > </choice> > </note> > </layer> > </staff> > </measure> > </section> > </score> > </mdiv> > </body> > </music> > </mei> > > > I let oXygen validate against the RNG that the web service gave me, > and it complains about <syl> in <orig> or <reg>. Indeed, the > documentation says, <syl> is only allowed inside <lem>, <rdg>, > <verse>, <syllable> and <note>. Why is this so? Bug or feature? > > Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Thu Mar 8 22:03:52 2012 From: zupftom at googlemail.com (TW) Date: Thu, 8 Mar 2012 22:03:52 +0100 Subject: [MEI-L] <syl> inside <choice> In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01150759@GRANT.eservices.virginia.edu> References: <CAEB1mApswRW92C1u2WjSMX2_soUHme0q4uCKyVo+eBNHyg99Sw@mail.gmail.com> <CAEB1mAqhdRVpuPSpOq8XxKUPHd0HJnapytTAvU867jCuz96nug@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01150759@GRANT.eservices.virginia.edu> Message-ID: <CAEB1mAobR8BeOoaeeXmDcd396kRVyi-TG6_a2fFYCFhHBLEa7Q@mail.gmail.com> 2012/3/8 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > Because <choice> is a member of model.editLike, it is allowed in the content of <syl>. > >  > <content> > ?<rng:zeroOrMore> > ? ?<rng:choice> > ? ? ?<rng:text/> > ? ? ?<rng:ref name="model.textphraseLike.limited"/> > ? ? ?<rng:ref name="model.editLike"/> > ? ? ?<rng:ref name="model.transcriptionLike"/> > ? ?</rng:choice> > ?</rng:zeroOrMore> > </content> > > So, this should validate: > > <syl> > ?<choice> > ? ?<orig></orig> > ? ?<reg></orig> > ?</choice> > </syl> > Ah, that's the way to go! Thanks! Thomas From pdr4h at eservices.virginia.edu Thu Mar 8 22:25:44 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 8 Mar 2012 21:25:44 +0000 Subject: [MEI-L] <syl> inside <choice> In-Reply-To: <CAEB1mAobR8BeOoaeeXmDcd396kRVyi-TG6_a2fFYCFhHBLEa7Q@mail.gmail.com> References: <CAEB1mApswRW92C1u2WjSMX2_soUHme0q4uCKyVo+eBNHyg99Sw@mail.gmail.com> <CAEB1mAqhdRVpuPSpOq8XxKUPHd0HJnapytTAvU867jCuz96nug@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01150759@GRANT.eservices.virginia.edu>, <CAEB1mAobR8BeOoaeeXmDcd396kRVyi-TG6_a2fFYCFhHBLEa7Q@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0115078C@GRANT.eservices.virginia.edu> Thomas, Don't let my hastily-chosen example mislead you. I wasn't saying that this <syl> <choice> <orig></orig> <reg></reg> </choice> </syl> would always necessarily be the best way to encode multi-lingual texts. This markup would be useful for those cases where an editor wants to offer a German translation of, say, a song with English text. In the case where the source material contains both English and German in alternate verses, the following would be better <note> <verse n="1" xml:lang="eng"> <syl></syl> </verse> <verse n="2" xml:lang="ger"> <syl></syl> </verse> </note> -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Thursday, March 08, 2012 4:03 PM To: Music Encoding Initiative Subject: Re: [MEI-L] <syl> inside <choice> 2012/3/8 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > Because <choice> is a member of model.editLike, it is allowed in the content of <syl>. > >  > <content> > <rng:zeroOrMore> > <rng:choice> > <rng:text/> > <rng:ref name="model.textphraseLike.limited"/> > <rng:ref name="model.editLike"/> > <rng:ref name="model.transcriptionLike"/> > </rng:choice> > </rng:zeroOrMore> > </content> > > So, this should validate: > > <syl> > <choice> > <orig></orig> > <reg></orig> > </choice> > </syl> > Ah, that's the way to go! Thanks! Thomas _______________________________________________ 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 Fri Mar 9 08:13:37 2012 From: bohl at edirom.de (=?utf-8?B?QmVuamFtaW4gVy4gQm9obA==?=) Date: Fri, 09 Mar 2012 08:13:37 +0100 Subject: [MEI-L] =?utf-8?q?Antw=2E=3A__trills_within_beams?= Message-ID: <0LnDWH-1SZBuK3ueb-00h5d9@mrelayeu.kundenserver.de> Hi LISTeners, hi Perry! What you wrote about the trill question on second thought is exactly what kept nagging in my mind having followed the discussion for the last few days. As I always understood MEI was/is being designed by scientists for scientists in order to being able to capture music phenomena that one was not able to in "common" notation software, at least because its development was not bound to that of a certain software. Moreover there was no big notion of replacing/taking the position of a interchange-format for different software. Considering this it is VERY important to listen to the needs of hand encoders and keep in mind that straight forward encoding possibilities are features that capture attention of future editors and users of MEI; of course that's what sophisticated software might accomplish as well. But to the day there is no such thing for MEI-all or ans other subset thereof. Of course the needs of software developers is equally important because we want them to make real that sophisticated thing. Perry, I greatly appreciate you "stepping back" and looking on what's happening from a greater distance. You proposal sounds to me like a sound plan. Best wishes, Benjamin ----- Reply message ----- Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] trills within beams Datum: Do., M?r. 8, 2012 17:06 Hi, everyone, You know, I was almost persuaded by the deprecation argument. But, thinking more about Kristina's original question and Eleanor and Andrew's responses, I think that's not the best way to go. My first response to Kristina was written in a moment of weakness and Eleanor was correct to call me on it. :-) As I've said many times, I sympathize with developers who want "the one, true, correct way". But, that can lead one down a rocky road. For example, you know that place where ships are docked? What's the word for that in English? Is the "one, true, correct" word "harbor" (as we spell it in America) or is it "harbour" (as it is spelled/spelt by our British cousins)? Then there are the Old and Middle English spellings. Of course, all are correct in the appropriate context. Writing a word processor that checks spelling would be a lot easier if there were one "right" answer, but ... MEI is designed for multiple contexts. What is true and correct for one use or user, may not be for another. For example, MEI supports printing but it is not designed exclusively for that purpose. I think the practical result of this philosophical approach is that each use / user must define the context in which it / he operates. This means making choices. Kristina identified a need for a trill attribute in the context of hand encoding (or one-pass encoding, as much as that's possible in MEI), which was seconded by Eleanor and Andrew. MEI already provides attributes that function similarly, so the question, "Why can't I ...?", was legitimate. Surely, the answer is not to define the question out of existence. When I said before that I could imagine a future in which these attributes didn't exist, I was thinking of the time when sophisticated MEI authoring tools exist. And that time may come someday soon, but it's not here yet. And even if no one authored or edited MEI in oXygen, there would still be the analytical uses to consider -- see below. In spite of my temporary lapse, I still believe the appropriate answer is to accommodate these multiple contexts. Software, of course, then must also be able to deal with multiple contexts, probably by switching between them rather than supporting them all simultaneously. (In the word processor example, one switches contexts between British and American spelling by selecting different dictionaries.) What are the options for software? 1. Silently ignore anything it doesn't understand. 2. Ignore anything it doesn't understand, but alert the user to its "deafness". 3. Refuse to work with anything it doesn't understand. All of these options conform with the notion of "supporting MEI". Anything less, such as deprecating one context or another in MEI itself, isn't acceptable. I think that if we deprecated @tie, @slur, etc. it wouldn't be long before the cry went out to add them back. Or worse yet, individuals would start extending the schema *each in their own way* to get them back because they are useful in both simple input systems (that is, using an XML editor) and in the analytical context where one often needs to tightly couple an entity (in this, a note) and its properties for ease of conceptualization and for efficiency (it takes resources -- time and memory -- to navigate down into the document to find a trill that might be associated with a given note). In order to avoid putting them back later or virtually assuring uncontrolled extension, I believe it's better to allow these attributes (and even add more; that is, @ornam or similar, in this case). Doing so steers modifications toward restrictions, which are easier to create, maintain, and enforce. I believe this places MEI in the same philosophical space as TEI. That is, one should not use TEI straight out-of-the-box without making some choices. The mei-all schema (like tei-all) is only the first step in defining any particular use of MEI. So, I want to 1. leave the current crop of attributes in place (no deprecation, but *explanation* of their proper uses), 2. add @ornam with appropriate values, 3. devise methods of converting between attribute- and element-centered markup, 4. create customizations of mei-all that make it easier for users/agents to declare what they're ready to accept and conversely what they will ignore / refuse, for example, a customization that emphasizes attributes and one that emphasizes elements. This plan is not new. With the addition of no. 2, it's what I think we've been working toward for quite some time. We just momentarily stepped off the path. :-) -- 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120309/e0d1db7a/attachment.html> From laurent at music.mcgill.ca Sun Mar 11 12:02:58 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Sun, 11 Mar 2012 11:02:58 +0000 Subject: [MEI-L] trills within beams In-Reply-To: <11002_1331222920_4F58D987_11002_214_2_BBCC497C40D85642B90E9F94FC30343D01150684@GRANT.eservices.virginia.edu> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <BBCC497C40D85642B90E9F94FC30343D0114FB72@GRANT.eservices.virginia.edu> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de> <E2C7EFD2-0485-48EB-8453-C0C0667E854C@mail.mcgill.ca> <BBCC497C40D85642B90E9F94FC30343D0114FE33@GRANT.eservices.virginia.edu> <C053F977-7433-4ED5-848E-24D2C968558E@edirom.de> <BBCC497C40D85642B90E9F94FC30343D0114FE8C@GRANT.eservices.virginia.edu> <07B81BC7-2C56-4C51-BCA3-FC7A274036C4@edirom.de> <CAMyHAnMVTbvoS=62jVfGSBE=KTR+EPXRj5KUv8HX7HdFoOjS1g@mail.gmail.com> <CAEB1mAr+-Np9_tJLUXaWeyRyEMOuqxH2iDnVwogXG3JnGayMsw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D0114FEB8@GRANT.eservices.virginia.edu> <CAEB1mAqDky2XxPsHt1E3wQg3fc2i3tfeDb+_ttuOt_6MVPCeMw@mail.gmail.com> <22803_1331058782_4F56585E_22803_116_1_BBCC497C40D85642B90E9F94FC30343D0114FEF6@GRANT.eservices.virginia.edu> <CAJ306HZdyhiEY93c5Lmbx1RBsF9X+69zQrnR8dJzt5hzEBHyAg@mail.gmail.com> <14554848-F3C7-43A0-A688-7BF7B2A46A4E@edirom.de> <11002_1331222920_4F58D987_11002_214_2_BBCC497C40D85642B90E9F94FC30343D01150684@GRANT.eservices.virginia.edu> Message-ID: <CAJ306HawBt1U=j4wV0Z4+3gYS=VYFkK_C1kGB63AJ2V2-xanZA@mail.gmail.com> Sorry for my ignorance, but wouldn't schematron be more appropriate for no 4.? Laurent On Thu, Mar 8, 2012 at 4:06 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi, everyone, > > You know, I was almost persuaded by the deprecation argument. But, > thinking more about Kristina's original question and Eleanor and Andrew's > responses, I think that's not the best way to go. My first response to > Kristina was written in a moment of weakness and Eleanor was correct to > call me on it. :-) > > As I've said many times, I sympathize with developers who want "the one, > true, correct way". But, that can lead one down a rocky road. For > example, you know that place where ships are docked? What's the word for > that in English? Is the "one, true, correct" word "harbor" (as we spell it > in America) or is it "harbour" (as it is spelled/spelt by our British > cousins)? Then there are the Old and Middle English spellings. Of course, > all are correct in the appropriate context. Writing a word processor that > checks spelling would be a lot easier if there were one "right" answer, but > ... > > MEI is designed for multiple contexts. What is true and correct for one > use or user, may not be for another. For example, MEI supports printing > but it is not designed exclusively for that purpose. I think the practical > result of this philosophical approach is that each use / user must define > the context in which it / he operates. This means making choices. > > Kristina identified a need for a trill attribute in the context of hand > encoding (or one-pass encoding, as much as that's possible in MEI), which > was seconded by Eleanor and Andrew. MEI already provides attributes that > function similarly, so the question, "Why can't I ...?", was legitimate. > Surely, the answer is not to define the question out of existence. > > When I said before that I could imagine a future in which these attributes > didn't exist, I was thinking of the time when sophisticated MEI authoring > tools exist. And that time may come someday soon, but it's not here yet. > And even if no one authored or edited MEI in oXygen, there would still be > the analytical uses to consider -- see below. > > In spite of my temporary lapse, I still believe the appropriate answer is > to accommodate these multiple contexts. Software, of course, then must > also be able to deal with multiple contexts, probably by switching between > them rather than supporting them all simultaneously. (In the word > processor example, one switches contexts between British and American > spelling by selecting different dictionaries.) > > What are the options for software? > > 1. Silently ignore anything it doesn't understand. > 2. Ignore anything it doesn't understand, but alert the user to its > "deafness". > 3. Refuse to work with anything it doesn't understand. > > All of these options conform with the notion of "supporting MEI". > > Anything less, such as deprecating one context or another in MEI itself, > isn't acceptable. I think that if we deprecated @tie, @slur, etc. it > wouldn't be long before the cry went out to add them back. Or worse yet, > individuals would start extending the schema *each in their own way* to get > them back because they are useful in both simple input systems (that is, > using an XML editor) and in the analytical context where one often needs to > tightly couple an entity (in this, a note) and its properties for ease of > conceptualization and for efficiency (it takes resources -- time and memory > -- to navigate down into the document to find a trill that might be > associated with a given note). > > In order to avoid putting them back later or virtually assuring > uncontrolled extension, I believe it's better to allow these attributes > (and even add more; that is, @ornam or similar, in this case). Doing so > steers modifications toward restrictions, which are easier to create, > maintain, and enforce. > > I believe this places MEI in the same philosophical space as TEI. That > is, one should not use TEI straight out-of-the-box without making some > choices. The mei-all schema (like tei-all) is only the first step in > defining any particular use of MEI. > > So, I want to > > 1. leave the current crop of attributes in place (no deprecation, but > *explanation* of their proper uses), > 2. add @ornam with appropriate values, > 3. devise methods of converting between attribute- and element-centered > markup, > 4. create customizations of mei-all that make it easier for users/agents > to declare what they're ready to accept and conversely what they will > ignore / refuse, for example, a customization that emphasizes attributes > and one that emphasizes elements. > > This plan is not new. With the addition of no. 2, it's what I think we've > been working toward for quite some time. We just momentarily stepped off > the path. :-) > > -- > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120311/502e3065/attachment.html> From laurent at music.mcgill.ca Mon Mar 12 09:21:21 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Mon, 12 Mar 2012 08:21:21 +0000 Subject: [MEI-L] Events inside events In-Reply-To: <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de> References: <BBCC497C40D85642B90E9F94FC30343D094FDC@WILSON.eservices.virginia.edu> <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de> Message-ID: <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> Hi Perry, I am confused. In the following example: <choice> <orig> <turn></turn> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> Where is given for the original the note to which the turn applies. Am I overlooking something? Sorry about it. Laurent On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de> wrote: > As I mentioned earlier, here is an eMail that Perry wrote last year. We've > never discussed his proposal so far, and his initial intention was to bring > this to MEI-L. I modified only the beginning and end, there's no comment > from me yet (I will "respond" to this in another mail). > > ------- > > > Currently, a few elements (bend, gliss, mordent, trill, turn, note, > ineume, uneume are the most pertinent ones here) permit other events in > their content, e.g., > > <turn> > <note/> > <note/> > <note/> > </turn> > > The original purpose of this was to allow for interpretative data to be > record "in-line". This preceded the introduction of the editorial > elements, such as app and choice. Now that we have these elements (app and > choice), I believe allowing event content in these situations is not only > redundant, but confusing. It immediately raises a question of whether to > encode the interpretative info directly inside, say, the turn element (as > above) or use > > <choice> > <orig> > <turn></turn> > </orig> > <reg> > <note/> > <note/> > <note/> > <note/> > </reg> > </choice> > > when marking up a single source, or if the turn and its "resolution" exist > in different sources > > <app> > <rdg source="A"> > <turn/> > </rdg> > <rdg souce="B"> > <note/> > <note/> > <note/> > <note/> > </rdg> > </app> > > In some cases; that is, in diastemmatic neume notation, such as Solesmes, > this feature is still necessary in order to record the actual, > uninterpreted pitch values of the neumes. It has also already been used to > capture interpreted pitch values in non-diastemmatic neume notation, such > as for Hildegard's works. Although this last use might be worth to > reconsider, we can't disallow it for earlier, unheighted notation if we > allow it for diastemmatic neumes. > > In spite of the fact that removing the feature doesn't completely remove > any possibility of its mis-use, I think it should be removed for elements > in the CMN repertoire (bend, gliss, mordent, trill, turn, note). This will > steer users toward a "proper" encoding using <app> and <choice>. > > This is a significant enough change (much like the camelCasing of element > names) to warrant making it now rather than later. I don't want to make > any change to the source file now, but I think it should be done for the > next release. > > Comments? > > -- > p. > > > -------------- > > Johannes again. What I wanted to add is that this discussion may not aim > at changing the upcoming 2012 release, as the schema for this has already > been fixed by a Council decision. What we can do now is to announce future > changes in the 2012 Guidelines we're currently writing. I think a > discussion of this thread is desperately needed, but we need to be clear > about the schedule for any changes we might come up with. > > Johannes > > > > _______________________________________________ > 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120312/d163afd5/attachment.html> From pdr4h at eservices.virginia.edu Mon Mar 12 14:57:52 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 12 Mar 2012 13:57:52 +0000 Subject: [MEI-L] trills within beams In-Reply-To: <CAJ306HawBt1U=j4wV0Z4+3gYS=VYFkK_C1kGB63AJ2V2-xanZA@mail.gmail.com> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <BBCC497C40D85642B90E9F94FC30343D0114FB72@GRANT.eservices.virginia.edu> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de> <E2C7EFD2-0485-48EB-8453-C0C0667E854C@mail.mcgill.ca> <BBCC497C40D85642B90E9F94FC30343D0114FE33@GRANT.eservices.virginia.edu> <C053F977-7433-4ED5-848E-24D2C968558E@edirom.de> <BBCC497C40D85642B90E9F94FC30343D0114FE8C@GRANT.eservices.virginia.edu> <07B81BC7-2C56-4C51-BCA3-FC7A274036C4@edirom.de> <CAMyHAnMVTbvoS=62jVfGSBE=KTR+EPXRj5KUv8HX7HdFoOjS1g@mail.gmail.com> <CAEB1mAr+-Np9_tJLUXaWeyRyEMOuqxH2iDnVwogXG3JnGayMsw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D0114FEB8@GRANT.eservices.virginia.edu> <CAEB1mAqDky2XxPsHt1E3wQg3fc2i3tfeDb+_ttuOt_6MVPCeMw@mail.gmail.com> <22803_1331058782_4F56585E_22803_116_1_BBCC497C40D85642B90E9F94FC30343D0114FEF6@GRANT.eservices.virginia.edu> <CAJ306HZdyhiEY93c5Lmbx1RBsF9X+69zQrnR8dJzt5hzEBHyAg@mail.gmail.com> <14554848-F3C7-43A0-A688-7BF7B2A46A4E@edirom.de> <11002_1331222920_4F58D987_11002_214_2_BBCC497C40D85642B90E9F94FC30343D01150684@GRANT.eservices.virginia.edu>, <CAJ306HawBt1U=j4wV0Z4+3gYS=VYFkK_C1kGB63AJ2V2-xanZA@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D011513A3@GRANT.eservices.virginia.edu> Hi, Laurent, I was assuming that, especially with the development of assistive software, a customized schema would be the first choice. But, schematron that places limits on a general schema is a viable option as well. The choice depends on the user and the uses, of course. -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Sunday, March 11, 2012 7:02 AM To: Music Encoding Initiative Subject: Re: [MEI-L] trills within beams Sorry for my ignorance, but wouldn't schematron be more appropriate for no 4.? Laurent On Thu, Mar 8, 2012 at 4:06 PM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Hi, everyone, You know, I was almost persuaded by the deprecation argument. But, thinking more about Kristina's original question and Eleanor and Andrew's responses, I think that's not the best way to go. My first response to Kristina was written in a moment of weakness and Eleanor was correct to call me on it. :-) As I've said many times, I sympathize with developers who want "the one, true, correct way". But, that can lead one down a rocky road. For example, you know that place where ships are docked? What's the word for that in English? Is the "one, true, correct" word "harbor" (as we spell it in America) or is it "harbour" (as it is spelled/spelt by our British cousins)? Then there are the Old and Middle English spellings. Of course, all are correct in the appropriate context. Writing a word processor that checks spelling would be a lot easier if there were one "right" answer, but ... MEI is designed for multiple contexts. What is true and correct for one use or user, may not be for another. For example, MEI supports printing but it is not designed exclusively for that purpose. I think the practical result of this philosophical approach is that each use / user must define the context in which it / he operates. This means making choices. Kristina identified a need for a trill attribute in the context of hand encoding (or one-pass encoding, as much as that's possible in MEI), which was seconded by Eleanor and Andrew. MEI already provides attributes that function similarly, so the question, "Why can't I ...?", was legitimate. Surely, the answer is not to define the question out of existence. When I said before that I could imagine a future in which these attributes didn't exist, I was thinking of the time when sophisticated MEI authoring tools exist. And that time may come someday soon, but it's not here yet. And even if no one authored or edited MEI in oXygen, there would still be the analytical uses to consider -- see below. In spite of my temporary lapse, I still believe the appropriate answer is to accommodate these multiple contexts. Software, of course, then must also be able to deal with multiple contexts, probably by switching between them rather than supporting them all simultaneously. (In the word processor example, one switches contexts between British and American spelling by selecting different dictionaries.) What are the options for software? 1. Silently ignore anything it doesn't understand. 2. Ignore anything it doesn't understand, but alert the user to its "deafness". 3. Refuse to work with anything it doesn't understand. All of these options conform with the notion of "supporting MEI". Anything less, such as deprecating one context or another in MEI itself, isn't acceptable. I think that if we deprecated @tie, @slur, etc. it wouldn't be long before the cry went out to add them back. Or worse yet, individuals would start extending the schema *each in their own way* to get them back because they are useful in both simple input systems (that is, using an XML editor) and in the analytical context where one often needs to tightly couple an entity (in this, a note) and its properties for ease of conceptualization and for efficiency (it takes resources -- time and memory -- to navigate down into the document to find a trill that might be associated with a given note). In order to avoid putting them back later or virtually assuring uncontrolled extension, I believe it's better to allow these attributes (and even add more; that is, @ornam or similar, in this case). Doing so steers modifications toward restrictions, which are easier to create, maintain, and enforce. I believe this places MEI in the same philosophical space as TEI. That is, one should not use TEI straight out-of-the-box without making some choices. The mei-all schema (like tei-all) is only the first step in defining any particular use of MEI. So, I want to 1. leave the current crop of attributes in place (no deprecation, but *explanation* of their proper uses), 2. add @ornam with appropriate values, 3. devise methods of converting between attribute- and element-centered markup, 4. create customizations of mei-all that make it easier for users/agents to declare what they're ready to accept and conversely what they will ignore / refuse, for example, a customization that emphasizes attributes and one that emphasizes elements. This plan is not new. With the addition of no. 2, it's what I think we've been working toward for quite some time. We just momentarily stepped off the path. :-) -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120312/8ec75aa9/attachment.html> From pdr4h at eservices.virginia.edu Mon Mar 12 15:37:13 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 12 Mar 2012 14:37:13 +0000 Subject: [MEI-L] Events inside events In-Reply-To: <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> References: <BBCC497C40D85642B90E9F94FC30343D094FDC@WILSON.eservices.virginia.edu> <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de>, <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D011513B3@GRANT.eservices.virginia.edu> Laurent, My example wasn't very clear, was it? Sorry about that. I was assuming that the encoding of the <note> to which the turn applies was previously encoded in the appropriate measure/staff/layer, like so: <measure n="1"> <staff n="1"> <layer> <note pname="c" oct="4" dur="4"/> <note pname="d"/> <note pname="e"/> <note pname="f"/> </layer> </staff>  <choice> <orig> <turn tstamp="2"/> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> </measure> But, you know, now that I see it written out, I don't like it; that is, for the control events -- bend, gliss, mordent, trill, and turn. The following still feels more intuitively correct: <measure n="1"> <staff n="1"> <layer> <note pname="c" oct="4" dur="4"/> <note pname="d"/> <note pname="e"/> <note pname="f"/> </layer> </staff> <turn tstamp="2">  <note/> <note/> <note/> <note/> </turn> </measure> because the turn and its interpretation are more closely linked together. If there were to be more than one interpretation of how the turn should be performed, <choice> (or <app>, maybe <ossia> ?) could be allowed *within <turn>*: <turn tstamp="2">  <choice> <reg> <note/> <note/> <note/> <note/> </reg> <reg> <note/> <note/> <note/> <note/> <note/> <note/> </reg> </turn> However, I still think the following is an abomination: <note> <note/> <note/> </note> It seems like I'm going in circles, (at least partially) talking myself out of my own suggestion. Everyone, please feel free to jump into the fray at any 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Monday, March 12, 2012 4:21 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Events inside events Hi Perry, I am confused. In the following example: <choice> <orig> <turn></turn> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> Where is given for the original the note to which the turn applies. Am I overlooking something? Sorry about it. Laurent On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de> wrote: As I mentioned earlier, here is an eMail that Perry wrote last year. We've never discussed his proposal so far, and his initial intention was to bring this to MEI-L. I modified only the beginning and end, there's no comment from me yet (I will "respond" to this in another mail). ------- Currently, a few elements (bend, gliss, mordent, trill, turn, note, ineume, uneume are the most pertinent ones here) permit other events in their content, e.g., <turn> <note/> <note/> <note/> </turn> The original purpose of this was to allow for interpretative data to be record "in-line". This preceded the introduction of the editorial elements, such as app and choice. Now that we have these elements (app and choice), I believe allowing event content in these situations is not only redundant, but confusing. It immediately raises a question of whether to encode the interpretative info directly inside, say, the turn element (as above) or use <choice> <orig> <turn></turn> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> when marking up a single source, or if the turn and its "resolution" exist in different sources <app> <rdg source="A"> <turn/> </rdg> <rdg souce="B"> <note/> <note/> <note/> <note/> </rdg> </app> In some cases; that is, in diastemmatic neume notation, such as Solesmes, this feature is still necessary in order to record the actual, uninterpreted pitch values of the neumes. It has also already been used to capture interpreted pitch values in non-diastemmatic neume notation, such as for Hildegard's works. Although this last use might be worth to reconsider, we can't disallow it for earlier, unheighted notation if we allow it for diastemmatic neumes. In spite of the fact that removing the feature doesn't completely remove any possibility of its mis-use, I think it should be removed for elements in the CMN repertoire (bend, gliss, mordent, trill, turn, note). This will steer users toward a "proper" encoding using <app> and <choice>. This is a significant enough change (much like the camelCasing of element names) to warrant making it now rather than later. I don't want to make any change to the source file now, but I think it should be done for the next release. Comments? -- p. -------------- Johannes again. What I wanted to add is that this discussion may not aim at changing the upcoming 2012 release, as the schema for this has already been fixed by a Council decision. What we can do now is to announce future changes in the 2012 Guidelines we're currently writing. I think a discussion of this thread is desperately needed, but we need to be clear about the schedule for any changes we might come up with. Johannes _______________________________________________ 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 Mon Mar 12 21:58:28 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Mon, 12 Mar 2012 20:58:28 +0000 Subject: [MEI-L] Events inside events In-Reply-To: <23357_1331563047_4F5E0A27_23357_361_21_BBCC497C40D85642B90E9F94FC30343D011513B3@GRANT.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D094FDC@WILSON.eservices.virginia.edu> <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de> <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> <23357_1331563047_4F5E0A27_23357_361_21_BBCC497C40D85642B90E9F94FC30343D011513B3@GRANT.eservices.virginia.edu> Message-ID: <CAJ306HYD0s4xSvjXTmQKyA0BjQAq8UX_Q6-HmiAbssEuqL4JLg@mail.gmail.com> Thanks for the clarification. I had forgotten that turn would have a @timestamp. I agree that the second option is more intuitive and I also like it better. If we still want to allow the first one, wouldn't the first <note> within <reg> also have to have a @timestamp? One more reason to prefer the second option, I guess. Now I don't want to perpetuate the circular discussion, but do we want to always use the @timestamp solution (i.e., that requires double pass decoding) even for cases where <turn> (or other) applies to one single note? That is, couldn't the following solution be acceptable? <note> <turn>  <note/> <note/> <note/> <note/> </turn> <note> I am sure you already answered it before, sorry about it. Or is this what you mean by abomination? Laurent On Mon, Mar 12, 2012 at 2:37 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Laurent, > > My example wasn't very clear, was it? Sorry about that. > > I was assuming that the encoding of the <note> to which the turn applies > was previously encoded in the appropriate measure/staff/layer, like so: > > <measure n="1"> > <staff n="1"> > <layer> > <note pname="c" oct="4" dur="4"/> > <note pname="d"/> > <note pname="e"/> > <note pname="f"/> > </layer> > </staff> >  > <choice> > <orig> > <turn tstamp="2"/> > </orig> > <reg> > <note/> > <note/> > <note/> > <note/> > </reg> > </choice> > </measure> > > But, you know, now that I see it written out, I don't like it; that is, > for the control events -- bend, gliss, mordent, trill, and turn. > > The following still feels more intuitively correct: > > <measure n="1"> > <staff n="1"> > <layer> > <note pname="c" oct="4" dur="4"/> > <note pname="d"/> > <note pname="e"/> > <note pname="f"/> > </layer> > </staff> > <turn tstamp="2"> >  > <note/> > <note/> > <note/> > <note/> > </turn> > </measure> > > because the turn and its interpretation are more closely linked together. > > If there were to be more than one interpretation of how the turn should be > performed, <choice> (or <app>, maybe <ossia> ?) could be allowed *within > <turn>*: > > <turn tstamp="2"> >  > <choice> > <reg> > <note/> > <note/> > <note/> > <note/> > </reg> > <reg> > <note/> > <note/> > <note/> > <note/> > <note/> > <note/> > </reg> > </turn> > > However, I still think the following is an abomination: > > <note> > <note/> > <note/> > </note> > > It seems like I'm going in circles, (at least partially) talking myself > out of my own suggestion. Everyone, please feel free to jump into the fray > at any 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-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [ > laurent at music.mcgill.ca] > Sent: Monday, March 12, 2012 4:21 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Events inside events > > > Hi Perry, > > > I am confused. In the following example: > > > <choice> > <orig> > <turn></turn> > </orig> > <reg> > <note/> > <note/> > <note/> > <note/> > </reg> > </choice> > > > Where is given for the original the note to which the turn applies. Am I > overlooking something? Sorry about it. > > > Laurent > > > On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de> wrote: > > As I mentioned earlier, here is an eMail that Perry wrote last year. We've > never discussed his proposal so far, and his initial intention was to bring > this to MEI-L. I modified only the beginning and end, there's no comment > from me yet (I will "respond" to this in another mail). > > ------- > > > Currently, a few elements (bend, gliss, mordent, trill, turn, note, > ineume, uneume are the most pertinent ones here) permit other events in > their content, e.g., > > <turn> > <note/> > <note/> > <note/> > </turn> > > The original purpose of this was to allow for interpretative data to be > record "in-line". This preceded the introduction of the editorial > elements, such as app and choice. Now that we have these elements (app and > choice), I believe allowing event content in these situations is not only > redundant, but confusing. It immediately raises a question of whether to > encode the interpretative info directly inside, say, the turn element (as > above) or use > > <choice> > <orig> > <turn></turn> > </orig> > <reg> > <note/> > <note/> > <note/> > <note/> > </reg> > </choice> > > when marking up a single source, or if the turn and its "resolution" exist > in different sources > > <app> > <rdg source="A"> > <turn/> > </rdg> > <rdg souce="B"> > <note/> > <note/> > <note/> > <note/> > </rdg> > </app> > > In some cases; that is, in diastemmatic neume notation, such as Solesmes, > this feature is still necessary in order to record the actual, > uninterpreted pitch values of the neumes. It has also already been used to > capture interpreted pitch values in non-diastemmatic neume notation, such > as for Hildegard's works. Although this last use might be worth to > reconsider, we can't disallow it for earlier, unheighted notation if we > allow it for diastemmatic neumes. > > In spite of the fact that removing the feature doesn't completely remove > any possibility of its mis-use, I think it should be removed for elements > in the CMN repertoire (bend, gliss, mordent, trill, turn, note). This will > steer users toward a "proper" encoding using <app> and <choice>. > > This is a significant enough change (much like the camelCasing of element > names) to warrant making it now rather than later. I don't want to make > any change to the source file now, but I think it should be done for the > next release. > > Comments? > > -- > p. > > > -------------- > > Johannes again. What I wanted to add is that this discussion may not aim > at changing the upcoming 2012 release, as the schema for this has already > been fixed by a Council decision. What we can do now is to announce future > changes in the 2012 Guidelines we're currently writing. I think a > discussion of this thread is desperately needed, but we need to be clear > about the schedule for any changes we might come up with. > > 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 > > -------------- section suivante -------------- Une pi?ce jointe HTML a ?t? nettoy?e... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120312/561baa18/attachment.html> From pdr4h at eservices.virginia.edu Tue Mar 13 15:02:52 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 13 Mar 2012 14:02:52 +0000 Subject: [MEI-L] Events inside events In-Reply-To: <CAJ306HYD0s4xSvjXTmQKyA0BjQAq8UX_Q6-HmiAbssEuqL4JLg@mail.gmail.com> References: <BBCC497C40D85642B90E9F94FC30343D094FDC@WILSON.eservices.virginia.edu> <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de> <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> <23357_1331563047_4F5E0A27_23357_361_21_BBCC497C40D85642B90E9F94FC30343D011513B3@GRANT.eservices.virginia.edu>, <CAJ306HYD0s4xSvjXTmQKyA0BjQAq8UX_Q6-HmiAbssEuqL4JLg@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D011514E3@GRANT.eservices.virginia.edu> Laurent, Yep, the first "option" (which really isn't an option now) has several problems. Allowing <turn>, <trill>, etc. to occur inside <note> (and other things) *and* following all events, not only means each of these elements could occur in multiple places, but more importantly that they will have slightly different semantics depending on the context of their occurrence. Maybe this isn't so bad for turns because they always apply to single notes, but 2 different ways of encoding trills ("single note" vs. "wavy line" or "instaneous" vs. "continuing") seems to me to be asking for trouble. Or so I'm always told by my developer friends. :-) My other objection to allowing <turn> inside <note> is that it opens the possibility that eventually someone will suggest we have a <turn type="start"> and a <turn type="end"> (or some such construction). Milestones such as these are what the stand-off markup is intended to avoid. In addition, since a turn and its friends can be attached to chords, maybe rests, and God-knows-what-else, in order to remain consistent, all these other things would have to allow <turn> and such as well. So, this is one place where I believe consistency is our friend, even if it's a not-so-beautiful, slightly difficult to deal with friend. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Monday, March 12, 2012 4:58 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Events inside events Thanks for the clarification. I had forgotten that turn would have a @timestamp. I agree that the second option is more intuitive and I also like it better. If we still want to allow the first one, wouldn't the first <note> within <reg> also have to have a @timestamp? One more reason to prefer the second option, I guess. Now I don't want to perpetuate the circular discussion, but do we want to always use the @timestamp solution (i.e., that requires double pass decoding) even for cases where <turn> (or other) applies to one single note? That is, couldn't the following solution be acceptable? <note> <turn>  <note/> <note/> <note/> <note/> </turn> <note> I am sure you already answered it before, sorry about it. Or is this what you mean by abomination? Laurent On Mon, Mar 12, 2012 at 2:37 PM, Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote: Laurent, My example wasn't very clear, was it? Sorry about that. I was assuming that the encoding of the <note> to which the turn applies was previously encoded in the appropriate measure/staff/layer, like so: <measure n="1"> <staff n="1"> <layer> <note pname="c" oct="4" dur="4"/> <note pname="d"/> <note pname="e"/> <note pname="f"/> </layer> </staff>  <choice> <orig> <turn tstamp="2"/> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> </measure> But, you know, now that I see it written out, I don't like it; that is, for the control events -- bend, gliss, mordent, trill, and turn. The following still feels more intuitively correct: <measure n="1"> <staff n="1"> <layer> <note pname="c" oct="4" dur="4"/> <note pname="d"/> <note pname="e"/> <note pname="f"/> </layer> </staff> <turn tstamp="2">  <note/> <note/> <note/> <note/> </turn> </measure> because the turn and its interpretation are more closely linked together. If there were to be more than one interpretation of how the turn should be performed, <choice> (or <app>, maybe <ossia> ?) could be allowed *within <turn>*: <turn tstamp="2">  <choice> <reg> <note/> <note/> <note/> <note/> </reg> <reg> <note/> <note/> <note/> <note/> <note/> <note/> </reg> </turn> However, I still think the following is an abomination: <note> <note/> <note/> </note> It seems like I'm going in circles, (at least partially) talking myself out of my own suggestion. Everyone, please feel free to jump into the fray at any time. :-) -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702<tel:434-982-2702> (w) pdr4h (at) virginia (dot) edu From: mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] on behalf of Laurent Pugin [laurent at music.mcgill.ca<mailto:laurent at music.mcgill.ca>] Sent: Monday, March 12, 2012 4:21 AM To: Music Encoding Initiative Subject: Re: [MEI-L] Events inside events Hi Perry, I am confused. In the following example: <choice> <orig> <turn></turn> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> Where is given for the original the note to which the turn applies. Am I overlooking something? Sorry about it. Laurent On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> wrote: As I mentioned earlier, here is an eMail that Perry wrote last year. We've never discussed his proposal so far, and his initial intention was to bring this to MEI-L. I modified only the beginning and end, there's no comment from me yet (I will "respond" to this in another mail). ------- Currently, a few elements (bend, gliss, mordent, trill, turn, note, ineume, uneume are the most pertinent ones here) permit other events in their content, e.g., <turn> <note/> <note/> <note/> </turn> The original purpose of this was to allow for interpretative data to be record "in-line". This preceded the introduction of the editorial elements, such as app and choice. Now that we have these elements (app and choice), I believe allowing event content in these situations is not only redundant, but confusing. It immediately raises a question of whether to encode the interpretative info directly inside, say, the turn element (as above) or use <choice> <orig> <turn></turn> </orig> <reg> <note/> <note/> <note/> <note/> </reg> </choice> when marking up a single source, or if the turn and its "resolution" exist in different sources <app> <rdg source="A"> <turn/> </rdg> <rdg souce="B"> <note/> <note/> <note/> <note/> </rdg> </app> In some cases; that is, in diastemmatic neume notation, such as Solesmes, this feature is still necessary in order to record the actual, uninterpreted pitch values of the neumes. It has also already been used to capture interpreted pitch values in non-diastemmatic neume notation, such as for Hildegard's works. Although this last use might be worth to reconsider, we can't disallow it for earlier, unheighted notation if we allow it for diastemmatic neumes. In spite of the fact that removing the feature doesn't completely remove any possibility of its mis-use, I think it should be removed for elements in the CMN repertoire (bend, gliss, mordent, trill, turn, note). This will steer users toward a "proper" encoding using <app> and <choice>. This is a significant enough change (much like the camelCasing of element names) to warrant making it now rather than later. I don't want to make any change to the source file now, but I think it should be done for the next release. Comments? -- p. -------------- Johannes again. What I wanted to add is that this discussion may not aim at changing the upcoming 2012 release, as the schema for this has already been fixed by a Council decision. What we can do now is to announce future changes in the 2012 Guidelines we're currently writing. I think a discussion of this thread is desperately needed, but we need to be clear about the schedule for any changes we might come up with. Johannes _______________________________________________ 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/20120313/33389d0f/attachment.html> From laurent at music.mcgill.ca Thu Mar 15 12:10:18 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Thu, 15 Mar 2012 12:10:18 +0100 Subject: [MEI-L] Events inside events In-Reply-To: <25211_1331647386_4F5F539A_25211_72_2_BBCC497C40D85642B90E9F94FC30343D011514E3@GRANT.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D094FDC@WILSON.eservices.virginia.edu> <766_1331130368_4F577000_766_173_1_64179483-CB63-4008-92B4-D8F77A1BB30A@edirom.de> <CAJ306HbTnZp4y=5MB_E8BRyqT0jdjb=m2HPO=AkxEubX1Sku+Q@mail.gmail.com> <23357_1331563047_4F5E0A27_23357_361_21_BBCC497C40D85642B90E9F94FC30343D011513B3@GRANT.eservices.virginia.edu> <CAJ306HYD0s4xSvjXTmQKyA0BjQAq8UX_Q6-HmiAbssEuqL4JLg@mail.gmail.com> <25211_1331647386_4F5F539A_25211_72_2_BBCC497C40D85642B90E9F94FC30343D011514E3@GRANT.eservices.virginia.edu> Message-ID: <CAJ306HbtuAJ_X3P3FqV9dRGTXxcUs+8T0Fjc7F-s8pSHq66-jA@mail.gmail.com> On Tue, Mar 13, 2012 at 3:02 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Laurent, > > > > Yep, the first "option" (which really isn't an option now) has several > problems. > > > > Allowing <turn>, <trill>, etc. to occur inside <note> (and other things) > *and* following all events, not only means each of these elements could > occur in multiple places, but more importantly that they will have slightly > different semantics depending on the context of their occurrence. > > > > Maybe this isn't so bad for turns because they always apply to single > notes, but 2 different ways of encoding trills ("single note" vs. "wavy > line" or "instaneous" vs. "continuing") seems to me to be asking for > trouble. Or so I'm always told by my developer friends. :-) > I see your point. I know developers who will say that not having to deal with timestamps is easier, so they would be ready in that case to deal with 2 different ways of encoding. But these are lazy developers... > > My other objection to allowing <turn> inside <note> is that it opens the > possibility that eventually someone will suggest we have a <turn > type="start"> and a <turn type="end"> (or some such construction). > Milestones such as these are what the stand-off markup is intended to > avoid. In addition, since a turn and its friends can be attached to > chords, maybe rests, and God-knows-what-else, in order to remain > consistent, all these other things would have to allow <turn> and such as > well. > > > > So, this is one place where I believe consistency is our friend, even if > it's a not-so-beautiful, slightly difficult to deal with friend. > > > > -- > > 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-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [ > laurent at music.mcgill.ca] > *Sent:* Monday, March 12, 2012 4:58 PM > > *To:* Music Encoding Initiative > *Subject:* Re: [MEI-L] Events inside events > > Thanks for the clarification. I had forgotten that turn would have a > @timestamp. I agree that the second option is more intuitive and I also > like it better. If we still want to allow the first one, wouldn't the first > <note> within <reg> also have to have a @timestamp? One more reason to > prefer the second option, I guess. > > Now I don't want to perpetuate the circular discussion, but do we want > to always use the @timestamp solution (i.e., that requires double pass > decoding) even for cases where <turn> (or other) applies to one single > note? That is, couldn't the following solution be acceptable? > > <note> > <turn> >  > <note/> > <note/> > <note/> > <note/> > </turn> > <note> > > I am sure you already answered it before, sorry about it. Or is this > what you mean by abomination? > > Laurent > > On Mon, Mar 12, 2012 at 2:37 PM, Roland, Perry (pdr4h) < > pdr4h at eservices.virginia.edu> wrote: > >> Laurent, >> >> My example wasn't very clear, was it? Sorry about that. >> >> I was assuming that the encoding of the <note> to which the turn applies >> was previously encoded in the appropriate measure/staff/layer, like so: >> >> <measure n="1"> >> <staff n="1"> >> <layer> >> <note pname="c" oct="4" dur="4"/> >> <note pname="d"/> >> <note pname="e"/> >> <note pname="f"/> >> </layer> >> </staff> >>  >> <choice> >> <orig> >> <turn tstamp="2"/> >> </orig> >> <reg> >> <note/> >> <note/> >> <note/> >> <note/> >> </reg> >> </choice> >> </measure> >> >> But, you know, now that I see it written out, I don't like it; that is, >> for the control events -- bend, gliss, mordent, trill, and turn. >> >> The following still feels more intuitively correct: >> >> <measure n="1"> >> <staff n="1"> >> <layer> >> <note pname="c" oct="4" dur="4"/> >> <note pname="d"/> >> <note pname="e"/> >> <note pname="f"/> >> </layer> >> </staff> >> <turn tstamp="2"> >>  >> <note/> >> <note/> >> <note/> >> <note/> >> </turn> >> </measure> >> >> because the turn and its interpretation are more closely linked together. >> >> If there were to be more than one interpretation of how the turn should >> be performed, <choice> (or <app>, maybe <ossia> ?) could be allowed *within >> <turn>*: >> >> <turn tstamp="2"> >>  >> <choice> >> <reg> >> <note/> >> <note/> >> <note/> >> <note/> >> </reg> >> <reg> >> <note/> >> <note/> >> <note/> >> <note/> >> <note/> >> <note/> >> </reg> >> </turn> >> >> However, I still think the following is an abomination: >> >> <note> >> <note/> >> <note/> >> </note> >> >> It seems like I'm going in circles, (at least partially) talking myself >> out of my own suggestion. Everyone, please feel free to jump into the fray >> at any 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-bounces at lists.uni-paderborn.de [ >> mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [ >> laurent at music.mcgill.ca] >> Sent: Monday, March 12, 2012 4:21 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] Events inside events >> >> >> Hi Perry, >> >> >> I am confused. In the following example: >> >> >> <choice> >> <orig> >> <turn></turn> >> </orig> >> <reg> >> <note/> >> <note/> >> <note/> >> <note/> >> </reg> >> </choice> >> >> >> Where is given for the original the note to which the turn applies. Am I >> overlooking something? Sorry about it. >> >> >> Laurent >> >> >> On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <kepper at edirom.de> wrote: >> >> As I mentioned earlier, here is an eMail that Perry wrote last year. >> We've never discussed his proposal so far, and his initial intention was to >> bring this to MEI-L. I modified only the beginning and end, there's no >> comment from me yet (I will "respond" to this in another mail). >> >> ------- >> >> >> Currently, a few elements (bend, gliss, mordent, trill, turn, note, >> ineume, uneume are the most pertinent ones here) permit other events in >> their content, e.g., >> >> <turn> >> <note/> >> <note/> >> <note/> >> </turn> >> >> The original purpose of this was to allow for interpretative data to be >> record "in-line". This preceded the introduction of the editorial >> elements, such as app and choice. Now that we have these elements (app and >> choice), I believe allowing event content in these situations is not only >> redundant, but confusing. It immediately raises a question of whether to >> encode the interpretative info directly inside, say, the turn element (as >> above) or use >> >> <choice> >> <orig> >> <turn></turn> >> </orig> >> <reg> >> <note/> >> <note/> >> <note/> >> <note/> >> </reg> >> </choice> >> >> when marking up a single source, or if the turn and its "resolution" >> exist in different sources >> >> <app> >> <rdg source="A"> >> <turn/> >> </rdg> >> <rdg souce="B"> >> <note/> >> <note/> >> <note/> >> <note/> >> </rdg> >> </app> >> >> In some cases; that is, in diastemmatic neume notation, such as Solesmes, >> this feature is still necessary in order to record the actual, >> uninterpreted pitch values of the neumes. It has also already been used to >> capture interpreted pitch values in non-diastemmatic neume notation, such >> as for Hildegard's works. Although this last use might be worth to >> reconsider, we can't disallow it for earlier, unheighted notation if we >> allow it for diastemmatic neumes. >> >> In spite of the fact that removing the feature doesn't completely remove >> any possibility of its mis-use, I think it should be removed for elements >> in the CMN repertoire (bend, gliss, mordent, trill, turn, note). This will >> steer users toward a "proper" encoding using <app> and <choice>. >> >> This is a significant enough change (much like the camelCasing of element >> names) to warrant making it now rather than later. I don't want to make >> any change to the source file now, but I think it should be done for the >> next release. >> >> Comments? >> >> -- >> p. >> >> >> -------------- >> >> Johannes again. What I wanted to add is that this discussion may not aim >> at changing the upcoming 2012 release, as the schema for this has already >> been fixed by a Council decision. What we can do now is to announce future >> changes in the 2012 Guidelines we're currently writing. I think a >> discussion of this thread is desperately needed, but we need to be clear >> about the schedule for any changes we might come up with. >> >> 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 >> >> > > _______________________________________________ > 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120315/0d2fea0d/attachment.html> From zupftom at googlemail.com Fri Mar 16 08:54:15 2012 From: zupftom at googlemail.com (TW) Date: Fri, 16 Mar 2012 08:54:15 +0100 Subject: [MEI-L] symbol/symbolDef Message-ID: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> I'd like to ask for your opinion on some aspects of the usersymbols module as I'm in charge of its guidelines. I'm not particularly clear how the relationship between <symbolDef> and <symbol> is meant to work. <symbolDef> mustn't be an empty element, so I might want to put a <symbol> element inside that might have a @facs attribute to point to a graphical example representation of the symbol. But this <symbol> element is required to have a @ref attribute which must be "a reference to a previously-declared user-defined symbol". The dog seems to chase its tail, right? One use case I see for <symbol> is if we have a scribe who uses some unusual symbols that might possibly not be fully understood. Then I might want to give some textual information about what meaning my research has suggested or what use pattern can be recognized. Would I do this with an <annot>, pointing to <symbolDef> by means of @plist? Thanks for your help! Thomas Weber From pdr4h at eservices.virginia.edu Sun Mar 18 20:04:46 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Sun, 18 Mar 2012 19:04:46 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> Hi, Thomas, The <symbolDef> element is intended to allow the inclusion of arbitrary symbols/signs. Using <symbolDef>, one can say how a symbol should be drawn in terms of its graphic components; that is, text, curves, and lines. After defining the symbol's coordinate space (using @ulx, @uly, @lrx, and @lry), the <anchoredText>, <curve>, and <line> elements (with appropriate x, y, x2, and y2 attributes) can be used to construct the symbol. The <symbol> element can then be used to make reference to this user-defined sign. For example, one could define a new sign within <scoreDef> -- <scoreDef> <symbolTable> <symbolDef xml:id="mySign" ulx="0" uly="0" lrx="20" lry="20"> <line x="10" y="0" x2="10" y2="10"/> <line x="10" y="10" x2="20" y2="10"/> <line x="20" y="10" x2="20" y2="20"/> </symbolDef> </symbolTable> </scoreDef> then later in the document data invoke this symbol -- <measure> <staff n="1"> <layer> <note xml:id="n1" .../> ... </layer> </staff> <symbol ref="mySign"/> </measure> <symbolDef> may contain references to other <symbol> elements. If a line of a certain length and style is a common component, it can be defined once and re-used. The symbol can be placed relative to elements in the notation (using some combination of ho, vo , and to attributes) -- <symbol startid="n1" ho="5"/> (This example indicates the symbol is placed at the same vertical position as, but 5 half-step units above, n1.) <symbol> and <symbolDef> cannot be used to point to a feature in a facsimile image because they have no @facs attribute. This was done purposefully in order to encourage the use of elements of the notation; that is, <note>, <chord>, <staff>, etc., for this purpose. <annot> can be used to record commentary on symbols just as it can with other elements of notation. It's technically possible make a <symbolDef> element a target (using @plist), but I think <symbol> is the proper target. In other words, <symbol> is a generic placeholder for an "unknown" notational sign. <symbolDef> is "just" the instructions for drawing it. Does that help? -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Friday, March 16, 2012 3:54 AM To: Music Encoding Initiative Subject: [MEI-L] symbol/symbolDef I'd like to ask for your opinion on some aspects of the usersymbols module as I'm in charge of its guidelines. I'm not particularly clear how the relationship between <symbolDef> and <symbol> is meant to work. <symbolDef> mustn't be an empty element, so I might want to put a <symbol> element inside that might have a @facs attribute to point to a graphical example representation of the symbol. But this <symbol> element is required to have a @ref attribute which must be "a reference to a previously-declared user-defined symbol". The dog seems to chase its tail, right? One use case I see for <symbol> is if we have a scribe who uses some unusual symbols that might possibly not be fully understood. Then I might want to give some textual information about what meaning my research has suggested or what use pattern can be recognized. Would I do this with an <annot>, pointing to <symbolDef> by means of @plist? Thanks for your help! Thomas Weber _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Mon Mar 19 11:20:17 2012 From: zupftom at googlemail.com (TW) Date: Mon, 19 Mar 2012 11:20:17 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> Message-ID: <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> 2012/3/18 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > Hi, Thomas, > > The <symbolDef> element is intended to allow the inclusion of arbitrary symbols/signs. ?Using <symbolDef>, one can say how a symbol should be drawn in terms of its graphic components; that is, text, curves, and lines. After defining the symbol's coordinate space (using @ulx, @uly, @lrx, and @lry), the <anchoredText>, <curve>, and <line> elements (with appropriate x, y, x2, and y2 attributes) can be used to construct the symbol. > > The <symbol> element can then be used to make reference to this user-defined sign. > > For example, one could define a new sign within <scoreDef> -- > > <scoreDef> > ?<symbolTable> > ? ?<symbolDef xml:id="mySign" ulx="0" uly="0" lrx="20" lry="20"> > ? ? ?<line x="10" y="0" x2="10" y2="10"/> > ? ? ?<line x="10" y="10" x2="20" y2="10"/> > ? ? ?<line x="20" y="10" x2="20" y2="20"/> > ? ?</symbolDef> > ?</symbolTable> > </scoreDef> > > then later in the document data invoke this symbol -- > > <measure> > ?<staff n="1"> > ? ?<layer> > ? ? ?<note xml:id="n1" .../> > ? ? ? ?... > ? ?</layer> > ?</staff> > ?<symbol ref="mySign"/> > </measure> > > <symbolDef> may contain references to other <symbol> elements. ?If a line of a certain length and style is a common component, it can be defined once and re-used. > > The symbol can be placed relative to elements in the notation (using some combination of ho, vo , and to attributes) -- > > <symbol startid="n1" ho="5"/> > > (This example indicates the symbol is placed at the same vertical position as, but 5 half-step units above, n1.) > > <symbol> and <symbolDef> cannot be used to point to a feature in a facsimile image because they have no @facs attribute. ?This was done purposefully in order to encourage the use of elements of the notation; that is, <note>, <chord>, <staff>, etc., for this purpose. > > <annot> can be used to record commentary on symbols just as it can with other elements of notation. ?It's technically possible make a <symbolDef> element a target (using @plist), but I think <symbol> is the proper target. ?In other words, <symbol> is a generic placeholder for an "unknown" notational sign. ?<symbolDef> is "just" the instructions for drawing it. > I see, so the module is meant for rendering purposes only. Then <symbol> inside <symbolDef> is intended for "composite" symbols, right? <curve> and <line> elements would obviously describe the strokes to create a symbol. I think I can make up some examples for the guidelines. But for defining decent symbols, <curve> and <line> seem pretty crude to me, especially because they can only describe lines and not filled areas. I'll think about this. Thomas From kepper at edirom.de Mon Mar 19 11:25:48 2012 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 19 Mar 2012 11:25:48 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> Message-ID: <CA57C88A-7D62-4B47-9278-57C5804C3762@edirom.de> maybe we discovered another spot in MEI where including SVG might be helpful?? jo Am 19.03.2012 um 11:20 schrieb TW: > 2012/3/18 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> Hi, Thomas, >> >> The <symbolDef> element is intended to allow the inclusion of arbitrary symbols/signs. Using <symbolDef>, one can say how a symbol should be drawn in terms of its graphic components; that is, text, curves, and lines. After defining the symbol's coordinate space (using @ulx, @uly, @lrx, and @lry), the <anchoredText>, <curve>, and <line> elements (with appropriate x, y, x2, and y2 attributes) can be used to construct the symbol. >> >> The <symbol> element can then be used to make reference to this user-defined sign. >> >> For example, one could define a new sign within <scoreDef> -- >> >> <scoreDef> >> <symbolTable> >> <symbolDef xml:id="mySign" ulx="0" uly="0" lrx="20" lry="20"> >> <line x="10" y="0" x2="10" y2="10"/> >> <line x="10" y="10" x2="20" y2="10"/> >> <line x="20" y="10" x2="20" y2="20"/> >> </symbolDef> >> </symbolTable> >> </scoreDef> >> >> then later in the document data invoke this symbol -- >> >> <measure> >> <staff n="1"> >> <layer> >> <note xml:id="n1" .../> >> ... >> </layer> >> </staff> >> <symbol ref="mySign"/> >> </measure> >> >> <symbolDef> may contain references to other <symbol> elements. If a line of a certain length and style is a common component, it can be defined once and re-used. >> >> The symbol can be placed relative to elements in the notation (using some combination of ho, vo , and to attributes) -- >> >> <symbol startid="n1" ho="5"/> >> >> (This example indicates the symbol is placed at the same vertical position as, but 5 half-step units above, n1.) >> >> <symbol> and <symbolDef> cannot be used to point to a feature in a facsimile image because they have no @facs attribute. This was done purposefully in order to encourage the use of elements of the notation; that is, <note>, <chord>, <staff>, etc., for this purpose. >> >> <annot> can be used to record commentary on symbols just as it can with other elements of notation. It's technically possible make a <symbolDef> element a target (using @plist), but I think <symbol> is the proper target. In other words, <symbol> is a generic placeholder for an "unknown" notational sign. <symbolDef> is "just" the instructions for drawing it. >> > > I see, so the module is meant for rendering purposes only. Then > <symbol> inside <symbolDef> is intended for "composite" symbols, > right? <curve> and <line> elements would obviously describe the > strokes to create a symbol. I think I can make up some examples for > the guidelines. But for defining decent symbols, <curve> and <line> > seem pretty crude to me, especially because they can only describe > lines and not filled areas. > > I'll think about this. > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Mon Mar 19 13:34:41 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 19 Mar 2012 12:34:41 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CA57C88A-7D62-4B47-9278-57C5804C3762@edirom.de> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com>, <CA57C88A-7D62-4B47-9278-57C5804C3762@edirom.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01151D3A@GRANT.eservices.virginia.edu> Hi, Johannes, > maybe we discovered another spot in MEI where including SVG might be helpful?? Placing SVG inside <symbolDef> is fine with me. But we need to investigate exactly how this might work, particularly with regard to "invoking" the SVG with symbol/@ref. Also, should we *add SVG* or *replace the primitives with SVG*? I admit I don't know enough about SVG to make good arguments either way. This is somewhat related to the issue of TEI in MEI. Or *any other XML* in MEI. Honestly, it makes my head spin. Will you create an issue in the tracker please? -- 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 kepper at edirom.de Mon Mar 19 13:53:48 2012 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 19 Mar 2012 13:53:48 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01151D3A@GRANT.eservices.virginia.edu> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com>, <CA57C88A-7D62-4B47-9278-57C5804C3762@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01151D3A@GRANT.eservices.virginia.edu> Message-ID: <36F1D685-C084-48D4-9218-B43933F54CD8@edirom.de> Am 19.03.2012 um 13:34 schrieb Roland, Perry (pdr4h): > Hi, Johannes, > >> maybe we discovered another spot in MEI where including SVG might be helpful?? > > Placing SVG inside <symbolDef> is fine with me. But we need to investigate exactly how this might work, particularly with regard to "invoking" the SVG with symbol/@ref. Also, should we *add SVG* or *replace the primitives with SVG*? I admit I don't know enough about SVG to make good arguments either way. > > This is somewhat related to the issue of TEI in MEI. Or *any other XML* in MEI. Honestly, it makes my head spin. > > Will you create an issue in the tracker please? will do. regarding the replacement of MEI primitives, I'd vote against for consistency's sake. The best way to include SVG seems to make it model.graphicLike, as it happens in TEI+SVG. I've done this mod for Edirom, and it works as expected. Basically, it allows SVG inside a surface (among other spots). Doing this, we surely don't want to loose mei:zone. If we allow mei:zone and svg:* within surface, why should we disallow lines and such in symbols? jo > > -- > 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 From pdr4h at eservices.virginia.edu Mon Mar 19 13:55:46 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 19 Mar 2012 12:55:46 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu>, <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> Thomas, > I see, so the module is meant for rendering purposes only. Then > <symbol> inside <symbolDef> is intended for "composite" symbols, > right? <curve> and <line> elements would obviously describe the > strokes to create a symbol. I think I can make up some examples for > the guidelines. But for defining decent symbols, <curve> and <line> > seem pretty crude to me, especially because they can only describe > lines and not filled areas. Yes, the module is meant for rendering. And, yes, <symbol> inside <symbolDef> is for composite symbols. My intent was to provide basic MEI functionality *in the absence of* a special-purpose drawing language. So, I would lean toward augmenting the MEI line, curve, and text graphic primitives (perhaps by adding an element for filled areas/paths) rather than replacing them. However, it may be more advantageous to replace the content of <symbolDef> with SVG or define <symbolDef> as a placeholder whose content must be declared before it can be used. The latter would permit the use of any drawing language (SVG, PostScript, etc.), but would have a detrimental effect on interoperability. I'd like to hear from the "rendering team" (Laurent, Craig, Thomas) whether SVG is so widely-used and widely-accepted that we should import its elements here exclusively. How important is it to allow other "markup", such as PostScript or other existing schemes? -- 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 zupftom at googlemail.com Mon Mar 19 18:14:46 2012 From: zupftom at googlemail.com (TW) Date: Mon, 19 Mar 2012 18:14:46 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> Message-ID: <CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> 2012/3/19 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > I'd like to hear from the "rendering team" (Laurent, Craig, Thomas) whether SVG is so widely-used and widely-accepted that we should import its elements here exclusively. ?How important is it to allow other "markup", such as PostScript or other existing schemes? > I hesitated to dig into this when writing my last mail, but as you're asking for it: In case I'll be losing myself in an excessive monologous vector graphics discussion, I'll put the blame on you, alright? As PostScript is a programming language and not markup, I'd vote against putting that into MEI. (If I had to pick my favorite programming language, I might choose PostScript, but I think MEI is the wrong place for it.) I feel that SVG is the only viable choice as it's the only open vector graphics standard I'm aware of. Of course, there's PDF, but I think that's hardly possible to "inline", and SVG is XML and therefore feels pretty comfortable inside XML. The graphics model behind SVG is basically identical to the one that PostScript and PDF use, and I think that pretty much any more recent 2D graphics technology copied from Adobe's model. So in the end, it's only about parsing, the rendering should not be too problematic (within reasonable bounds). When I wrote my last mail, I thought about replacing <line> and <curve> with something along the lines of <svg:path>. Not full SVG, just <svg:path>. To allow composite symbols, maybe also <svg:use>. That should be fully sufficient for music--we don't need all this fancy stuff like masks, patterns, clipping, gradients, animation and the like. SVG's line, polyline, polygon, circle, ellipse and rect elements are convience elements that don't really give you anything that path can't give you. PostScript is happy without those. I'd also lean towards a stricter subset of the path syntax that can easily be parsed and rendered using any available 2D graphics technology (PostScript/PDF, Windows' GDI+ or whatever they are using nowadays, Apple's Quartz, Cairo, HTML canvas, whatever). I'd maybe restrict paths to the operators M,L, C and Z. All other operators are, again, convenience operators, except maybe for A/a. However A/a is omitted from the SVG Tiny/Mobile profile because it's the most complex of the operators to implement[1]. On the rendering level, A/a are usually broken down to approximating C operations anyway, so in that sense it *is* a convenience operator. I'd also maybe restrict the filling rule to non-zero-winding, which seems to be the more common one. To facilitate parsing, I'd demand whitespace between each operator and number. SVG allows things like "M.5-4.1.2 3", but this compressed syntax (which is legal) isn't always parsed correctly--namely by librsvg, the SVG library that e.g. Wikipedia uses. Subsetting of course has two sides: On the one hand it greatly facilitates processing, but on the other hand you can't throw in any SVG you might have generated. So I'm not sure what's the best solution, full SVG (or SVG Tiny) or only <path> with restrictions to the path syntax. Is it sufficient if <symbolDef> can specify outlines of symbols, like they are defined in a font? Otherwise, we'd also have to consider stroke widths, dash patterns, line caps and line joins. Not to forget stroke and fill color. I think that's it. I don't think we'd need transparency effects, would we? I'm not sure if we'd need SVG transformations. <symbolDef> seems more like defining glyphs of a font rather than painting fancy graphics. For simple glyph outlines, we wouldn't even have to consider fill colors, stroking, dash patterns, line caps and line joins. Once again, I might be seeing this too much from the implementor's perspective with all this subsetting and stripping convenience functionality... Thomas [1] http://www.w3.org/TR/SVGMobile/#paths From laurent at music.mcgill.ca Tue Mar 20 07:33:37 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 20 Mar 2012 07:33:37 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> Message-ID: <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> I agree with Thomas that SVG is probably the best choice. I also think that it would be a good idea to have <symbolDef> as a placeholder for SVG rather than defining our own shapes. I guess we are not directly talking about rendering MEI here, but more about including the encoding of shapes within a MEI document, so I don't see any reason why we should restrict the use to a subset of SVG. Laurent On Mon, Mar 19, 2012 at 6:14 PM, TW <zupftom at googlemail.com> wrote: > 2012/3/19 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> >> I'd like to hear from the "rendering team" (Laurent, Craig, Thomas) whether SVG is so widely-used and widely-accepted that we should import its elements here exclusively. ?How important is it to allow other "markup", such as PostScript or other existing schemes? >> > > I hesitated to dig into this when writing my last mail, but as you're > asking for it: ?In case I'll be losing myself in an excessive > monologous vector graphics discussion, I'll put the blame on you, > alright? > > As PostScript is a programming language and not markup, I'd vote > against putting that into MEI. ?(If I had to pick my favorite > programming language, I might choose PostScript, but I think MEI is > the wrong place for it.) ?I feel that SVG is the only viable choice as > it's the only open vector graphics standard I'm aware of. ?Of course, > there's PDF, but I think that's hardly possible to "inline", and SVG > is XML and therefore feels pretty comfortable inside XML. > > The graphics model behind SVG is basically identical to the one that > PostScript and PDF use, and I think that pretty much any more recent > 2D graphics technology copied from Adobe's model. ?So in the end, it's > only about parsing, the rendering should not be too problematic > (within reasonable bounds). > > When I wrote my last mail, I thought about replacing <line> and > <curve> with something along the lines of <svg:path>. ?Not full SVG, > just <svg:path>. ?To allow composite symbols, maybe also <svg:use>. > That should be fully sufficient for music--we don't need all this > fancy stuff like masks, patterns, clipping, gradients, animation and > the like. ?SVG's line, polyline, polygon, circle, ellipse and rect > elements are convience elements that don't really give you anything > that path can't give you. ?PostScript is happy without those. > > I'd also lean towards a stricter subset of the path syntax that can > easily be parsed and rendered using any available 2D graphics > technology (PostScript/PDF, Windows' GDI+ or whatever they are using > nowadays, Apple's Quartz, Cairo, HTML canvas, whatever). ?I'd maybe > restrict paths to the operators M,L, C and Z. ?All other operators > are, again, convenience operators, except maybe for A/a. ?However A/a > is omitted from the SVG Tiny/Mobile profile because it's the most > complex of the operators to implement[1]. ?On the rendering level, A/a > are usually broken down to approximating C operations anyway, so in > that sense it *is* a convenience operator. > > I'd also maybe restrict the filling rule to non-zero-winding, which > seems to be the more common one. > > To facilitate parsing, I'd demand whitespace between each operator and > number. ?SVG allows things like "M.5-4.1.2 3", but this compressed > syntax (which is legal) isn't always parsed correctly--namely by > librsvg, the SVG library that e.g. Wikipedia uses. > > Subsetting of course has two sides: ?On the one hand it greatly > facilitates processing, but on the other hand you can't throw in any > SVG you might have generated. ?So I'm not sure what's the best > solution, full SVG (or SVG Tiny) or only <path> with restrictions to > the path syntax. > > Is it sufficient if <symbolDef> can specify outlines of symbols, like > they are defined in a font? ?Otherwise, we'd also have to consider > stroke widths, dash patterns, line caps and line joins. ?Not to forget > stroke and fill color. ?I think that's it. ?I don't think we'd need > transparency effects, would we? ?I'm not sure if we'd need SVG > transformations. ?<symbolDef> seems more like defining glyphs of a > font rather than painting fancy graphics. ?For simple glyph outlines, > we wouldn't even have to consider fill colors, stroking, dash > patterns, line caps and line joins. > > Once again, I might be seeing this too much from the implementor's > perspective with all this subsetting and stripping convenience > functionality... > > Thomas > > > [1] http://www.w3.org/TR/SVGMobile/#paths > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > From zupftom at googlemail.com Tue Mar 20 07:50:24 2012 From: zupftom at googlemail.com (TW) Date: Tue, 20 Mar 2012 07:50:24 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> Message-ID: <CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> 2012/3/20 Laurent Pugin <laurent at music.mcgill.ca>: > I agree with Thomas that SVG is probably the best choice. I also think > that it would be a good idea to have <symbolDef> as a placeholder for > SVG rather than defining our own shapes. I guess we are not directly > talking about rendering MEI here, but more about including the > encoding of shapes within a MEI document, so I don't see any reason > why we should restrict the use to a subset of SVG. > >From Perry's post I got the impression that the module's intent indeed was to provide symbols for rendering. If not, then we'd only be saying something like "See, this is how this symbol looks like", and the symbol's dimensions and origin wouldn't be significant. In this case, I'd think it would be more (or at least similarly) adequate to link to an example in the facsimile rather than redrawing the symbol. This was my initial understanding that I expressed in the original post. It would basically provide a means of classifying and identifying different kinds of symbols, especially ones that aren't covered by MEI (and maybe shouldn't be because they are only used by a certain scribe/composer/very special notation or only in a single work). Thomas From laurent at music.mcgill.ca Tue Mar 20 09:05:16 2012 From: laurent at music.mcgill.ca (Laurent Pugin) Date: Tue, 20 Mar 2012 09:05:16 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> Message-ID: <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> On Tue, Mar 20, 2012 at 7:50 AM, TW <zupftom at googlemail.com> wrote: > 2012/3/20 Laurent Pugin <laurent at music.mcgill.ca>: >> I agree with Thomas that SVG is probably the best choice. I also think >> that it would be a good idea to have <symbolDef> as a placeholder for >> SVG rather than defining our own shapes. I guess we are not directly >> talking about rendering MEI here, but more about including the >> encoding of shapes within a MEI document, so I don't see any reason >> why we should restrict the use to a subset of SVG. >> > > >From Perry's post I got the impression that the module's intent indeed > was to provide symbols for rendering. ?If not, then we'd only be > saying something like "See, this is how this symbol looks like", and > the symbol's dimensions and origin wouldn't be significant. ?In this > case, I'd think it would be more (or at least similarly) adequate to > link to an example in the facsimile rather than redrawing the symbol. > This was my initial understanding that I expressed in the original > post. ?It would basically provide a means of classifying and > identifying different kinds of symbols, especially ones that aren't > covered by MEI (and maybe shouldn't be because they are only used by a > certain scribe/composer/very special notation or only in a single > work). I think we agree. What I meant was not for rendering other MEI elements (e.g., a <note>). SVG for special symbols would of course be used for rendering. That is, we would take benefit from the fact that SVG is a self-rendered (or "renderable", sorry for the neologism?) encoding. Laurent From pdr4h at eservices.virginia.edu Tue Mar 20 17:04:12 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 20 Mar 2012 16:04:12 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com>, <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu> Just to clarify: The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered. This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which can/should be handled using @facs on MEI elements. Just a reminder: Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca] Sent: Tuesday, March 20, 2012 4:05 AM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef On Tue, Mar 20, 2012 at 7:50 AM, TW <zupftom at googlemail.com> wrote: > 2012/3/20 Laurent Pugin <laurent at music.mcgill.ca>: >> I agree with Thomas that SVG is probably the best choice. I also think >> that it would be a good idea to have <symbolDef> as a placeholder for >> SVG rather than defining our own shapes. I guess we are not directly >> talking about rendering MEI here, but more about including the >> encoding of shapes within a MEI document, so I don't see any reason >> why we should restrict the use to a subset of SVG. >> > > >From Perry's post I got the impression that the module's intent indeed > was to provide symbols for rendering. If not, then we'd only be > saying something like "See, this is how this symbol looks like", and > the symbol's dimensions and origin wouldn't be significant. In this > case, I'd think it would be more (or at least similarly) adequate to > link to an example in the facsimile rather than redrawing the symbol. > This was my initial understanding that I expressed in the original > post. It would basically provide a means of classifying and > identifying different kinds of symbols, especially ones that aren't > covered by MEI (and maybe shouldn't be because they are only used by a > certain scribe/composer/very special notation or only in a single > work). I think we agree. What I meant was not for rendering other MEI elements (e.g., a <note>). SVG for special symbols would of course be used for rendering. That is, we would take benefit from the fact that SVG is a self-rendered (or "renderable", sorry for the neologism?) encoding. Laurent _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Tue Mar 20 19:23:25 2012 From: zupftom at googlemail.com (TW) Date: Tue, 20 Mar 2012 19:23:25 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu> Message-ID: <CAEB1mAr2oXMHaL31Gk1k1D3jNZkuEOp=3MHMtWu5NqPeOpv_tg@mail.gmail.com> 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered. > > This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which ?can/should be handled using @facs on MEI elements. > > Just a reminder: > > Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>. > When talking with the Corpus monodicum people from W?rzburg about encoding their data in MEI, the problem occured that occansionally they find neumes that they cannot interpret (yet). However, those neumes aren't just sloppily written, they clearly manifest a certain kind of symbol as it is found repeatedly (for example within the works of a certain scribe). @facs doesn't express this, while @altsym could do. Would this be misuse as this would not be targeting rendering? If not, why force them by means of the Schema to draw a vector version of a symbol? Just the classification and one or more facsimile references would pretty much say everything that can be said, I think. Thomas From pdr4h at eservices.virginia.edu Tue Mar 20 20:13:52 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 20 Mar 2012 19:13:52 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAEB1mAr2oXMHaL31Gk1k1D3jNZkuEOp=3MHMtWu5NqPeOpv_tg@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu>, <CAEB1mAr2oXMHaL31Gk1k1D3jNZkuEOp=3MHMtWu5NqPeOpv_tg@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0115201A@GRANT.eservices.virginia.edu> > When talking with the Corpus monodicum people from W?rzburg about > encoding their data in MEI, the problem occured that occansionally > they find neumes that they cannot interpret (yet). However, those > neumes aren't just sloppily written, they clearly manifest a certain > kind of symbol as it is found repeatedly (for example within the works > of a certain scribe). @facs doesn't express this, while @altsym could > do. Please forgive me, but I don't understand what you're trying to say. @facs doesn't express what? The fact that they can't / don't want to say what a certain symbol is / means? What does @altsym do in this case that @facs doesn't? Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". Neither of these attributes has anything to do with interpretation. Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. So, for a neume one can say <neume @facs="d1" altsym="us1"/>  Are you wanting <symbol> to function as a generic marker for an unknown sign? That is, if a symbol's meaning is unknown, then are you looking for markup like -- <symbol @facs="d1 d2 d3 d4 d5"/> saying, in effect, "I don't know what this thing is, but it occurs 5 times"? This doesn't sound right to me because you already said they have *neumes* that can't yet be interpreted. But at the very least they can be called "neumes", right? So what's wrong with calling them neumes by using the <neume> element? Am I completely off the track here? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Tuesday, March 20, 2012 2:23 PM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered. > > This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which can/should be handled using @facs on MEI elements. > > Just a reminder: > > Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>. > When talking with the Corpus monodicum people from W?rzburg about encoding their data in MEI, the problem occured that occansionally they find neumes that they cannot interpret (yet). However, those neumes aren't just sloppily written, they clearly manifest a certain kind of symbol as it is found repeatedly (for example within the works of a certain scribe). @facs doesn't express this, while @altsym could do. Would this be misuse as this would not be targeting rendering? If not, why force them by means of the Schema to draw a vector version of a symbol? Just the classification and one or more facsimile references would pretty much say everything that can be said, I think. Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From bohl at edirom.de Wed Mar 21 07:53:39 2012 From: bohl at edirom.de (=?utf-8?B?QmVuamFtaW4gVy4gQm9obA==?=) Date: Wed, 21 Mar 2012 07:53:39 +0100 Subject: [MEI-L] =?utf-8?q?Antw=2E=3A__symbol/symbolDef?= Message-ID: <0M2Wmb-1SSkFM3PpV-00snnH@mrelayeu.kundenserver.de> Hi all! I don't think that you're off track Perry ;-) Thomas, what you're describing sounds to me like the occasion for a critical note (annotation); @plist could refer to the occurrences of the uninterpreted neume or even the user defined symbol. I don't see any necessity or use in describing the fact that the neume is unknown or or occurs in other places directly in the music body. Benjamin ----- Reply message ----- Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] symbol/symbolDef Datum: Di., M?r. 20, 2012 20:13 > When talking with the Corpus monodicum people from W?rzburg about > encoding their data in MEI, the problem occured that occansionally > they find neumes that they cannot interpret (yet). However, those > neumes aren't just sloppily written, they clearly manifest a certain > kind of symbol as it is found repeatedly (for example within the works > of a certain scribe). @facs doesn't express this, while @altsym could > do. Please forgive me, but I don't understand what you're trying to say. @facs doesn't express what? The fact that they can't / don't want to say what a certain symbol is / means? What does @altsym do in this case that @facs doesn't? Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". Neither of these attributes has anything to do with interpretation. Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. So, for a neume one can say <neume @facs="d1" altsym="us1"/>  Are you wanting <symbol> to function as a generic marker for an unknown sign? That is, if a symbol's meaning is unknown, then are you looking for markup like -- <symbol @facs="d1 d2 d3 d4 d5"/> saying, in effect, "I don't know what this thing is, but it occurs 5 times"? This doesn't sound right to me because you already said they have *neumes* that can't yet be interpreted. But at the very least they can be called "neumes", right? So what's wrong with calling them neumes by using the <neume> element? Am I completely off the track here? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Tuesday, March 20, 2012 2:23 PM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: > > The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered. > > This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which can/should be handled using @facs on MEI elements. > > Just a reminder: > > Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>. > When talking with the Corpus monodicum people from W?rzburg about encoding their data in MEI, the problem occured that occansionally they find neumes that they cannot interpret (yet). However, those neumes aren't just sloppily written, they clearly manifest a certain kind of symbol as it is found repeatedly (for example within the works of a certain scribe). @facs doesn't express this, while @altsym could do. Would this be misuse as this would not be targeting rendering? If not, why force them by means of the Schema to draw a vector version of a symbol? Just the classification and one or more facsimile references would pretty much say everything that can be said, I think. Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120321/fe7a2278/attachment.html> From zupftom at googlemail.com Wed Mar 21 08:54:55 2012 From: zupftom at googlemail.com (TW) Date: Wed, 21 Mar 2012 08:54:55 +0100 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0115201A@GRANT.eservices.virginia.edu> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu> <CAEB1mAr2oXMHaL31Gk1k1D3jNZkuEOp=3MHMtWu5NqPeOpv_tg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D0115201A@GRANT.eservices.virginia.edu> Message-ID: <CAEB1mAqdQ+h-50YN7eZjy0s9sMR4eA5e11k=FDLyo5MCu=RmOw@mail.gmail.com> 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> When talking with the Corpus monodicum people from W?rzburg about >> encoding their data in MEI, the problem occured that occansionally >> they find neumes that they cannot interpret (yet). ?However, those >> neumes aren't just sloppily written, they clearly manifest a certain >> kind of symbol as it is found repeatedly (for example within the works >> of a certain scribe). ?@facs doesn't express this, while @altsym could >> do. > > Please forgive me, but I don't understand what you're trying to say. ?@facs doesn't express what? ?The fact that they can't / don't want to say what a certain symbol is / means? ?What does @altsym do in this case that @facs doesn't? > > Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". ?Neither of these attributes has anything to do with interpretation. > > Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. ?So, for a neume one can say > > <neume @facs="d1" altsym="us1"/> >  > > Are you wanting <symbol> to function as a generic marker for an unknown sign? ?That is, if a symbol's meaning is unknown, then are you looking for markup like -- > > <symbol @facs="d1 d2 d3 d4 d5"/> > > saying, in effect, "I don't know what this thing is, but it occurs 5 times"? No, I was more thinking about something like this: <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef> <symbolTable> <symbolDef xml:id="symbolAB123"> <symbol facs="#symbolAB123_example"/> </symbolDef> <symbolDef xml:id="symbolCD456"> <symbol facs="#symbolCD456_description"/> </symbolDef> </symbolTable> </scoreDef> <annot startid="#symbolAB123"> This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot startid="#symbolCD456">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> <uneume altsym="#symbolCD456"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Does it at least make some sense? It's not valid MEI as I gave the <symbol> elements inside symbolDef only a @facs rather than a @ref. (Unfortunately, there aren't any examples for <annot>, <handList>, <creation> or <facsimile> on Google Code, so I'm using them as I understand them. But they're only meant as illustrative background actors, anyway.) > > This doesn't sound right to me because you already said they have *neumes* that can't yet be interpreted. ?But at the very least they can be called "neumes", right? ?So what's wrong with calling them neumes by using the <neume> element? > Of course <uneume> would have to be used. <uneume> has the @name attribute that can be used to classify the symbol. If there is a symbol that doesn't fall in any of the categories that @name offers, but still can be identified as a certain symbol, I would have used an @altsym to point to the symbol, like shown above. Of course one could use <annot> or something to say "This is the neume of special type pink-dog-with-green-tail", but I think @altsym is more accessible and less cluttered. For example, it's very straightforward to formulate a search query "Find me all occurrences of pink-dog-with-green-tail". Or if it should be found out that this is just a strange way of writing a torculus, then @altsym can be replaced with the proper @name. But back to the original question: It seems that using <symbol> or @altsym for classifying unknown symbols (in any context) isn't something that I should encourage in the guidelines. At least that's my interim conclusion of the discussion so far. Thomas From pdr4h at eservices.virginia.edu Wed Mar 21 15:01:30 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 21 Mar 2012 14:01:30 +0000 Subject: [MEI-L] symbol/symbolDef In-Reply-To: <CAEB1mAqdQ+h-50YN7eZjy0s9sMR4eA5e11k=FDLyo5MCu=RmOw@mail.gmail.com> References: <CAEB1mArXkBm17TR8FpAMyD3wSZm4W1qd42zm6RVRw2dugx898Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151CEB@GRANT.eservices.virginia.edu> <CAEB1mAoow3znx-j3bqw9YnD1zyoB9SArBp-wrnJLLhsQNxCO=Q@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151D51@GRANT.eservices.virginia.edu> <29155_1332177366_4F6769D4_29155_127_1_CAEB1mApzwRBtkt_uoJnpBb1OX4ov7XQxDWLLP-Gr0JEgpgEpHQ@mail.gmail.com> <CAJ306HbgHmkuOeKzmU_XJqahGT4wNHuep_FS7pYi+ac3Vw_zpw@mail.gmail.com> <25118_1332226231_4F6828B7_25118_393_1_CAEB1mArwRgEu3NXNKruJLA42GuEMZ9bxe=OBTxAU2p3ZhRXpeg@mail.gmail.com> <CAJ306HYVEJKoH+5i-x1ziYGf=0HcnNjA-WEQmOgiFJgux4aDcg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D01151F2A@GRANT.eservices.virginia.edu> <CAEB1mAr2oXMHaL31Gk1k1D3jNZkuEOp=3MHMtWu5NqPeOpv_tg@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D0115201A@GRANT.eservices.virginia.edu>, <CAEB1mAqdQ+h-50YN7eZjy0s9sMR4eA5e11k=FDLyo5MCu=RmOw@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01152179@GRANT.eservices.virginia.edu> > But back to the original question: It seems that using <symbol> or > @altsym for classifying unknown symbols (in any context) isn't > something that I should encourage in the guidelines. At least that's > my interim conclusion of the discussion so far. Correct. Especially since your example can be simplified, as in the following: <?xml version="1.0" encoding="UTF-8"?> <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef>  </scoreDef> <annot xml:id="symbolAB123_description" plist="#symbolAB123_example">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB" >Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot xml:id="symbolCD456_description" plist="#symbolCD456_example">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> <uneume facs="#symbolCD456_example"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Instead of using <symbolDef> as an intermediary, uneume/@facs points directly to the facsimile/zone. annot/@plist also points to the zone so that every uneume doesn't have to be enumerated, however, I think this is somewhat suspect. It's better to just pick one neume as an exemplar: ... <annot xml:id="symbolAB123_description" plist="#symbolAB123">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> ... <uneume xml:id="symbolAB123" facs="#symbolAB123_example"/> ... -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Wednesday, March 21, 2012 3:54 AM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> When talking with the Corpus monodicum people from W?rzburg about >> encoding their data in MEI, the problem occured that occansionally >> they find neumes that they cannot interpret (yet). However, those >> neumes aren't just sloppily written, they clearly manifest a certain >> kind of symbol as it is found repeatedly (for example within the works >> of a certain scribe). @facs doesn't express this, while @altsym could >> do. > > Please forgive me, but I don't understand what you're trying to say. @facs doesn't express what? The fact that they can't / don't want to say what a certain symbol is / means? What does @altsym do in this case that @facs doesn't? > > Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". Neither of these attributes has anything to do with interpretation. > > Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. So, for a neume one can say > > <neume @facs="d1" altsym="us1"/> >  > > Are you wanting <symbol> to function as a generic marker for an unknown sign? That is, if a symbol's meaning is unknown, then are you looking for markup like -- > > <symbol @facs="d1 d2 d3 d4 d5"/> > > saying, in effect, "I don't know what this thing is, but it occurs 5 times"? No, I was more thinking about something like this: <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef> <symbolTable> <symbolDef xml:id="symbolAB123"> <symbol facs="#symbolAB123_example"/> </symbolDef> <symbolDef xml:id="symbolCD456"> <symbol facs="#symbolCD456_description"/> </symbolDef> </symbolTable> </scoreDef> <annot startid="#symbolAB123"> This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot startid="#symbolCD456">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> <uneume altsym="#symbolCD456"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Does it at least make some sense? It's not valid MEI as I gave the <symbol> elements inside symbolDef only a @facs rather than a @ref. (Unfortunately, there aren't any examples for <annot>, <handList>, <creation> or <facsimile> on Google Code, so I'm using them as I understand them. But they're only meant as illustrative background actors, anyway.) > > This doesn't sound right to me because you already said they have *neumes* that can't yet be interpreted. But at the very least they can be called "neumes", right? So what's wrong with calling them neumes by using the <neume> element? > Of course <uneume> would have to be used. <uneume> has the @name attribute that can be used to classify the symbol. If there is a symbol that doesn't fall in any of the categories that @name offers, but still can be identified as a certain symbol, I would have used an @altsym to point to the symbol, like shown above. Of course one could use <annot> or something to say "This is the neume of special type pink-dog-with-green-tail", but I think @altsym is more accessible and less cluttered. For example, it's very straightforward to formulate a search query "Find me all occurrences of pink-dog-with-green-tail". Or if it should be found out that this is just a strange way of writing a torculus, then @altsym can be replaced with the proper @name. But back to the original question: It seems that using <symbol> or @altsym for classifying unknown symbols (in any context) isn't something that I should encourage in the guidelines. At least that's my interim conclusion of the discussion so far. Thomas _______________________________________________ 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 Mar 22 08:05:11 2012 From: bohl at edirom.de (=?utf-8?B?QmVuamFtaW4gVy4gQm9obA==?=) Date: Thu, 22 Mar 2012 08:05:11 +0100 Subject: [MEI-L] =?utf-8?q?Antw=2E=3A__symbol/symbolDef?= Message-ID: <0MOVST-1SGOqX2RJV-005str@mrelayeu.kundenserver.de> Ok, this all seems plausible. But warming up the second issue: How would I go about supplying rendition information for the unknown neume? That should happen in the symbolDef, shouldn't it? How do I give a reference size, indicating how big the symbol is in comparison to other symbols or e.g. the line distance? B ----- Reply message ----- Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] symbol/symbolDef Datum: Mi., M?r. 21, 2012 15:01 > But back to the original question: It seems that using <symbol> or > @altsym for classifying unknown symbols (in any context) isn't > something that I should encourage in the guidelines. At least that's > my interim conclusion of the discussion so far. Correct. Especially since your example can be simplified, as in the following: <?xml version="1.0" encoding="UTF-8"?> <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef>  </scoreDef> <annot xml:id="symbolAB123_description" plist="#symbolAB123_example">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB" >Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot xml:id="symbolCD456_description" plist="#symbolCD456_example">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> <uneume facs="#symbolCD456_example"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Instead of using <symbolDef> as an intermediary, uneume/@facs points directly to the facsimile/zone. annot/@plist also points to the zone so that every uneume doesn't have to be enumerated, however, I think this is somewhat suspect. It's better to just pick one neume as an exemplar: ... <annot xml:id="symbolAB123_description" plist="#symbolAB123">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> ... <uneume xml:id="symbolAB123" facs="#symbolAB123_example"/> ... -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Wednesday, March 21, 2012 3:54 AM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> When talking with the Corpus monodicum people from W?rzburg about >> encoding their data in MEI, the problem occured that occansionally >> they find neumes that they cannot interpret (yet). However, those >> neumes aren't just sloppily written, they clearly manifest a certain >> kind of symbol as it is found repeatedly (for example within the works >> of a certain scribe). @facs doesn't express this, while @altsym could >> do. > > Please forgive me, but I don't understand what you're trying to say. @facs doesn't express what? The fact that they can't / don't want to say what a certain symbol is / means? What does @altsym do in this case that @facs doesn't? > > Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". Neither of these attributes has anything to do with interpretation. > > Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. So, for a neume one can say > > <neume @facs="d1" altsym="us1"/> >  > > Are you wanting <symbol> to function as a generic marker for an unknown sign? That is, if a symbol's meaning is unknown, then are you looking for markup like -- > > <symbol @facs="d1 d2 d3 d4 d5"/> > > saying, in effect, "I don't know what this thing is, but it occurs 5 times"? No, I was more thinking about something like this: <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef> <symbolTable> <symbolDef xml:id="symbolAB123"> <symbol facs="#symbolAB123_example"/> </symbolDef> <symbolDef xml:id="symbolCD456"> <symbol facs="#symbolCD456_description"/> </symbolDef> </symbolTable> </scoreDef> <annot startid="#symbolAB123"> This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot startid="#symbolCD456">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> <uneume altsym="#symbolCD456"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Does it at least make some sense? It's not valid MEI as I gave the <symbol> elements inside symbolDef only a @facs rather than a @ref. (Unfortunately, there aren't any examples for <annot>, <handList>, <creation> or <facsimile> on Google Code, so I'm using them as I understand them. But they're only meant as illustrative background actors, anyway.) > > This doesn't sound right to me because you already said they have *neumes"neumes", right? So what's wrong with calling them neumes by using the <neume> element? > Of course <uneume> would have to be used. <uneume> has the @name attribute that can be used to classify the symbol. If there is a symbol that doesn't fall in any of the categories that @name offers, but still can be identified as a certain symbol, I would have used an @altsym to point to the symbol, like shown above. Of course one could use <annot> or something to say "This is the neume of special type pink-dog-with-green-tail", but I think @altsym is more accessible and less cluttered. For example, it's very straightforward to formulate a search query "Find me all occurrences of pink-dog-with-green-tail". Or if it should be found out that this is just a strange way of writing a torculus, then @altsym can be replaced with the proper @name. But back to the original question: It seems that using <symbol> or @altsym for classifying unknown symbols (in any context) isn't something that I should encourage in the guidelines. At least that's my interim conclusion of the discussion so far. Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120322/ef6eff7b/attachment.html> From pdr4h at eservices.virginia.edu Thu Mar 22 14:54:11 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 22 Mar 2012 13:54:11 +0000 Subject: [MEI-L] Antw.: symbol/symbolDef In-Reply-To: <0MOVST-1SGOqX2RJV-005str@mrelayeu.kundenserver.de> References: <0MOVST-1SGOqX2RJV-005str@mrelayeu.kundenserver.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D011522CA@GRANT.eservices.virginia.edu> Hi, Benni, Instructions for "drawing" the symbol go in <symbolDef>. The simple answer to your question is, Use @scale on <symbol> to specify the size of a particular occurrence of the symbol. The more complex answer is, Rendering is a coordinated (pun intended) dance between/amongst the values of @page.units and @page.scale (found in att.scoreDef.vis), the values of <symbolDef>'s @ulx, @uly, @lrx, and @lry attributes (from att.coordinated), and <symbol>'s @scale attribute (in att.scalable). Does that help? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Benjamin W. Bohl [bohl at edirom.de] Sent: Thursday, March 22, 2012 3:05 AM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] Antw.: symbol/symbolDef Ok, this all seems plausible. But warming up the second issue: How would I go about supplying rendition information for the unknown neume? That should happen in the symbolDef, shouldn't it? How do I give a reference size, indicating how big the symbol is in comparison to other symbols or e.g. the line distance? B ----- Reply message ----- Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] symbol/symbolDef Datum: Mi., M?r. 21, 2012 15:01 > But back to the original question: It seems that using <symbol> or > @altsym for classifying unknown symbols (in any context) isn't > something that I should encourage in the guidelines. At least that's > my interim conclusion of the discussion so far. Correct. Especially since your example can be simplified, as in the following: <?xml version="1.0" encoding="UTF-8"?> <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef>  </scoreDef> <annot xml:id="symbolAB123_description" plist="#symbolAB123_example">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB" >Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot xml:id="symbolCD456_description" plist="#symbolCD456_example">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume facs="#symbolAB123_example"/> <uneume facs="#symbolCD456_example"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Instead of using <symbolDef> as an intermediary, uneume/@facs points directly to the facsimile/zone. annot/@plist also points to the zone so that every uneume doesn't have to be enumerated, however, I think this is somewhat suspect. It's better to just pick one neume as an exemplar: ... <annot xml:id="symbolAB123_description" plist="#symbolAB123">This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> ... <uneume xml:id="symbolAB123" facs="#symbolAB123_example"/> ... -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Wednesday, March 21, 2012 3:54 AM To: Music Encoding Initiative Subject: Re: [MEI-L] symbol/symbolDef 2012/3/20 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>: >> When talking with the Corpus monodicum people from W?rzburg about >> encoding their data in MEI, the problem occured that occansionally >> they find neumes that they cannot interpret (yet). However, those >> neumes aren't just sloppily written, they clearly manifest a certain >> kind of symbol as it is found repeatedly (for example within the works >> of a certain scribe). @facs doesn't express this, while @altsym could >> do. > > Please forgive me, but I don't understand what you're trying to say. @facs doesn't express what? The fact that they can't / don't want to say what a certain symbol is / means? What does @altsym do in this case that @facs doesn't? > > Whatever "it" is, @facs points to a region of an image and says "there it is", while @altsym points to a vector graphic and says "this is how you draw it". Neither of these attributes has anything to do with interpretation. > > Both of these require the encoder to make a decision about what "it" is by choosing an MEI element. So, for a neume one can say > > <neume @facs="d1" altsym="us1"/> >  > > Are you wanting <symbol> to function as a generic marker for an unknown sign? That is, if a symbol's meaning is unknown, then are you looking for markup like -- > > <symbol @facs="d1 d2 d3 d4 d5"/> > > saying, in effect, "I don't know what this thing is, but it occurs 5 times"? No, I was more thinking about something like this: <mei xmlns="http://www.music-encoding.org/ns/mei"> <meiHead> <fileDesc> <titleStmt> <title/> </titleStmt> <pubStmt/> <sourceDesc> <source> <physDesc> <handList> <hand xml:id="handB"> <name>Beta</name> </hand> <hand xml:id="handC"> <name>Gamma</name> </hand> </handList> </physDesc> <history> <creation> <geogName xml:id="mon_Alpha">monastery Alpha</geogName> </creation> </history> </source> </sourceDesc> </fileDesc> </meiHead> <music> <facsimile> <surface> <graphic target="facsimile00001.jpg"/> <zone data="#symbolAB123_description" xml:id="symbolAB123_example" ulx="180" uly="66" lrx="220" lry="81"/> <zone data="#symbolCD456_description" xml:id="symbolCD456_example" ulx="3475" uly="1290" lrx="3510" lry="1302"/> </surface> </facsimile> <body> <mdiv> <score> <scoreDef> <symbolTable> <symbolDef xml:id="symbolAB123"> <symbol facs="#symbolAB123_example"/> </symbolDef> <symbolDef xml:id="symbolCD456"> <symbol facs="#symbolCD456_description"/> </symbolDef> </symbolTable> </scoreDef> <annot startid="#symbolAB123"> This symbol can be found in sources stemming from <ref target="#mon_Alpha">monastery Alpha</ref> and is used by hands <ref target="#handB">Beta</ref> and <ref target="#handC">Gamma</ref>. It frequently appears after a clivis. It's meaning is unknown. </annot> <annot startid="#symbolCD456">  </annot> <section> <staff> <layer> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> </syllable> <syllable> <syl>bla</syl> <uneume name="clivis"/> <uneume altsym="#symbolAB123"/> <uneume altsym="#symbolCD456"/> </syllable>  </layer> </staff> </section> </score> </mdiv> </body> </music> </mei> Does it at least make some sense? It's not valid MEI as I gave the <symbol> elements inside symbolDef only a @facs rather than a @ref. (Unfortunately, there aren't any examples for <annot>, <handList>, <creation> or <facsimile> on Google Code, so I'm using them as I understand them. But they're only meant as illustrative background actors, anyway.) > > This doesn't sound right to me because you already said they have *neumes"neumes", right? So what's wrong with calling them neumes by using the <neume> element? > Of course <uneume> would have to be used. <uneume> has the @name attribute that can be used to classify the symbol. If there is a symbol that doesn't fall in any of the categories that @name offers, but still can be identified as a certain symbol, I would have used an @altsym to point to the symbol, like shown above. Of course one could use <annot> or something to say "This is the neume of special type pink-dog-with-green-tail", but I think @altsym is more accessible and less cluttered. For example, it's very straightforward to formulate a search query "Find me all occurrences of pink-dog-with-green-tail". Or if it should be found out that this is just a strange way of writing a torculus, then @altsym can be replaced with the proper @name. But back to the original question: It seems that using <symbol> or @altsym for classifying unknown symbols (in any context) isn't something that I should encourage in the guidelines. At least that's my interim conclusion of the discussion so far. Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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 Maja.Hartwig at gmx.de Mon Mar 26 09:43:54 2012 From: Maja.Hartwig at gmx.de (Maja Hartwig) Date: Mon, 26 Mar 2012 09:43:54 +0200 Subject: [MEI-L] del in chord Message-ID: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> Dear List, I wanted to encode a deleted note within a chord: <chord> <note/> <del><note/></del> <note/> <note/> <chord/> And I wondered that this is not allowed, while encoding deleted notes within a beam for instance, seems to be no problem. Are there any other solutions or ideas? Best, Maja -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120326/b3075357/attachment.html> -------------- n?chster Teil -------------- Ein Dateianhang mit Bin?rdaten wurde abgetrennt... Dateiname : Pasted Graphic.tiff Dateityp : image/tiff Dateigr??e : 235990 bytes Beschreibung: nicht verf?gbar URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120326/b3075357/attachment.tiff> From pdr4h at eservices.virginia.edu Mon Mar 26 14:48:12 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 26 Mar 2012 12:48:12 +0000 Subject: [MEI-L] del in chord In-Reply-To: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> References: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01152ACF@GRANT.eservices.virginia.edu> Hi, Maja, The only solution I see is to allow model.transcriptionLike inside <chord>. I'll add an issue in the tracker. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [Maja.Hartwig at gmx.de] Sent: Monday, March 26, 2012 3:43 AM To: Music Encoding Initiative Subject: [MEI-L] del in chord Dear List, I wanted to encode a deleted note within a chord: <chord> <note/> <del><note/></del> <note/> <note/> <chord/> And I wondered that this is not allowed, while encoding deleted notes within a beam for instance, seems to be no problem. Are there any other solutions or ideas? Best, Maja -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120326/1a3cdc9b/attachment.html> From atge at kb.dk Thu Mar 29 13:28:08 2012 From: atge at kb.dk (Axel Teich Geertinger) Date: Thu, 29 Mar 2012 11:28:08 +0000 Subject: [MEI-L] physLoc & provenance In-Reply-To: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> References: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D13A4BF3C4@EXCHANGE-02.kb.dk> Hi all, working with source metadata encodings, my colleague Sigge and I are wondering why <physLoc> and <provenance> are children of <physDesc>, not its siblings. From our point of view, the physical description of an item focuses on describing the object itself, i.e. its dimensions, the medium etc. independently of its location or history. Where it is located or who has owned it does not change the physical object in this sense (except that the circumstances may have left some physical traces on the object itself, of course, but that is hardly the point...). It seems like <physDesc>, as it is, is to be understood somewhat like the FRBR "item" level, containing all item-specific data, but then the tag name "physDesc" does not seem very accurate. The issue becomes even more apparent in our current customization of the schema, which actually introduces the FRBR item level in <source> (as <itemList><item>, where <item> has almost the same content model as <source>). What would be the arguments against moving <physLoc> and <provenance> out of <physDesc>? All the best, Axel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120329/e6cb49fb/attachment.html> From pdr4h at eservices.virginia.edu Thu Mar 29 15:26:49 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 29 Mar 2012 13:26:49 +0000 Subject: [MEI-L] Who are the Digital Humanities? Message-ID: <BBCC497C40D85642B90E9F94FC30343D01152FB4@GRANT.eservices.virginia.edu> Hello, all, Just wanted to pass along this message which was posted to TEI-L. If you consider yourself a member of the digital humanities community, you might want to respond to this survey. -- p. > Date: Wed, 28 Mar 2012 09:46:42 +0100 > From: Lou Burnard <lou.burnard at RETIRED.OX.AC.UK> > Subject: Who are the Digital Humanities? > > Slightly off topic, but not without interest for readers of this list: > http://t.co/bH2Gri3u -- a broad-based attempt to find out who considers > themselves to be doing "digital humanities" __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu From kepper at edirom.de Thu Mar 29 15:38:25 2012 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 29 Mar 2012 15:38:25 +0200 Subject: [MEI-L] physLoc & provenance In-Reply-To: <0B6F63F59F405E4C902DFE2C2329D0D13A4BF3C4@EXCHANGE-02.kb.dk> References: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> <0B6F63F59F405E4C902DFE2C2329D0D13A4BF3C4@EXCHANGE-02.kb.dk> Message-ID: <343E1AF4-28B2-47FE-9DD4-28EF1C4203D9@edirom.de> Hi Axel, what you describe seems right and convincing, especially in the light of FRBR. I'm not sure if we can change it in the regular MEI model, though. The regular model is very open and has more or less the same content model for works and sources, which is obviously even without FRBR questionable. I wonder if we should really change this model, or instead tighten up our FRBR proposal. At some point, we will have to specify the models of works, expressions, sources (manifestations) and items anyway, so I think this could be another opportunity. If we can come up with a convincing model that works in this context, we can propose it for regular MEI as well (and who knows, maybe at some point 'regular' MEI will be a simplified FRBR-MEI?). Also, we have agreed that the current model won't be changed for the upcoming release anymore, so this couldn't be adopted before summer. At the same time, there is no such restriction for our FRBR-ODD, we may change it as often as necessary without worrying other's breaking software? So unless there is a consensus on this list that we should adopt your proposal in regular MEI as soon as possible, I would suggest to try it out in our own customization first. As soon as we have something debatable, we may re-present it here. But as always, that's just my first impression? Best regards, Johannes Am 29.03.2012 um 13:28 schrieb Axel Teich Geertinger: > Hi all, > > working with source metadata encodings, my colleague Sigge and I are wondering why <physLoc> and <provenance> are children of <physDesc>, not its siblings. From our point of view, the physical description of an item focuses on describing the object itself, i.e. its dimensions, the medium etc. independently of its location or history. Where it is located or who has owned it does not change the physical object in this sense (except that the circumstances may have left some physical traces on the object itself, of course, but that is hardly the point...). > It seems like <physDesc>, as it is, is to be understood somewhat like the FRBR ?item? level, containing all item-specific data, but then the tag name ?physDesc? does not seem very accurate. The issue becomes even more apparent in our current customization of the schema, which actually introduces the FRBR item level in <source> (as <itemList><item>, where <item> has almost the same content model as <source>). > What would be the arguments against moving <physLoc> and <provenance> out of <physDesc>? > > All the best, > Axel > > > _______________________________________________ > 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 Thu Mar 29 16:24:26 2012 From: atge at kb.dk (Axel Teich Geertinger) Date: Thu, 29 Mar 2012 14:24:26 +0000 Subject: [MEI-L] physLoc & provenance In-Reply-To: <343E1AF4-28B2-47FE-9DD4-28EF1C4203D9@edirom.de> References: <279EDEDD-C7C5-423E-8F4E-563B015B1F88@gmx.de> <0B6F63F59F405E4C902DFE2C2329D0D13A4BF3C4@EXCHANGE-02.kb.dk> <343E1AF4-28B2-47FE-9DD4-28EF1C4203D9@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D13A4BF4BC@EXCHANGE-02.kb.dk> Hi Johannes, yes, that was the plan I had in mind too. I was just curious to know whether we had overlooked some good reason for the way it is done in the existing model. We can consider changing it in our customization and let it be part of some future MEI-FRBR proposal. Best, Axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper Sendt: 29. marts 2012 15:38 Til: Music Encoding Initiative Emne: Re: [MEI-L] physLoc & provenance Hi Axel, what you describe seems right and convincing, especially in the light of FRBR. I'm not sure if we can change it in the regular MEI model, though. The regular model is very open and has more or less the same content model for works and sources, which is obviously even without FRBR questionable. I wonder if we should really change this model, or instead tighten up our FRBR proposal. At some point, we will have to specify the models of works, expressions, sources (manifestations) and items anyway, so I think this could be another opportunity. If we can come up with a convincing model that works in this context, we can propose it for regular MEI as well (and who knows, maybe at some point 'regular' MEI will be a simplified FRBR-MEI?). Also, we have agreed that the current model won't be changed for the upcoming release anymore, so this couldn't be adopted before summer. At the same time, there is no such restriction for our FRBR-ODD, we may change it as often as necessary without worrying other's breaking software. So unless there is a consensus on this list that we should adopt your proposal in regular MEI as soon as possible, I would suggest to try it out in our own customization first. As soon as we have something debatable, we may re-present it here. But as always, that's just my first impression. Best regards, Johannes Am 29.03.2012 um 13:28 schrieb Axel Teich Geertinger: > Hi all, > > working with source metadata encodings, my colleague Sigge and I are wondering why <physLoc> and <provenance> are children of <physDesc>, not its siblings. From our point of view, the physical description of an item focuses on describing the object itself, i.e. its dimensions, the medium etc. independently of its location or history. Where it is located or who has owned it does not change the physical object in this sense (except that the circumstances may have left some physical traces on the object itself, of course, but that is hardly the point...). > It seems like <physDesc>, as it is, is to be understood somewhat like the FRBR "item" level, containing all item-specific data, but then the tag name "physDesc" does not seem very accurate. The issue becomes even more apparent in our current customization of the schema, which actually introduces the FRBR item level in <source> (as <itemList><item>, where <item> has almost the same content model as <source>). > What would be the arguments against moving <physLoc> and <provenance> out of <physDesc>? > > All the 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 From raffaeleviglianti at gmail.com Thu Mar 29 16:58:00 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 29 Mar 2012 15:58:00 +0100 Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay Message-ID: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com> Hello all, I've just noticed that MEI is mentioned in "XSLT 2.0 and XPath 2.0 Programmer's Reference" by Michael Kay. Here's the page on Google Books: http://j.mp/HjmAqq Best, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120329/5be93c2b/attachment.html> From kepper at edirom.de Thu Mar 29 17:07:07 2012 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 29 Mar 2012 17:07:07 +0200 Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay In-Reply-To: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com> References: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com> Message-ID: <A40E0E55-1CB9-49A1-B4A8-E14124578CBE@edirom.de> Hi Raffaele, good catch. I must have missed something, though ? I didn't know we provide a working stylesheet from MEI to MusicXML yet (or is this provided by Michael since he's working for MakeMusic?). And I have to admit I haven't ever thought about converting to SMDL ;-) Thanks, Johannes Am 29.03.2012 um 16:58 schrieb Raffaele Viglianti: > Hello all, > > I've just noticed that MEI is mentioned in "XSLT 2.0 and XPath 2.0 Programmer's Reference" by Michael Kay. Here's the page on Google Books: http://j.mp/HjmAqq > > Best, > Raffaele > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Thu Mar 29 17:19:13 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 29 Mar 2012 15:19:13 +0000 Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay In-Reply-To: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com> References: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01153035@GRANT.eservices.virginia.edu> Hi, Raffaele, Actually, Kay mentioned MEI in XSLT 2.0 Programmer's Reference, 3rd edition (p. 4), which we called attention to in our grant applications. I like that he says that MEI and SMDL are "really serious contenders". Coverage of MusicXML has been added, as it didn't appear in the earlier edition. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Thursday, March 29, 2012 10:58 AM To: Music Encoding Initiative Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay Hello all, I've just noticed that MEI is mentioned in "XSLT 2.0 and XPath 2.0 Programmer's Reference" by Michael Kay. Here's the page on Google Books: http://j.mp/HjmAqq Best, Raffaele From pdr4h at eservices.virginia.edu Thu Mar 29 17:23:15 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 29 Mar 2012 15:23:15 +0000 Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay In-Reply-To: <A40E0E55-1CB9-49A1-B4A8-E14124578CBE@edirom.de> References: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com>, <A40E0E55-1CB9-49A1-B4A8-E14124578CBE@edirom.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01153049@GRANT.eservices.virginia.edu> Johannes, We haven't written mei2musicxml.xsl yet, but have talked about it extensively. I'll let your SMDL comment pass without adding comment of my own. ;-) -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Thursday, March 29, 2012 11:07 AM To: Music Encoding Initiative Subject: Re: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay Hi Raffaele, good catch. I must have missed something, though ? I didn't know we provide a working stylesheet from MEI to MusicXML yet (or is this provided by Michael since he's working for MakeMusic?). And I have to admit I haven't ever thought about converting to SMDL ;-) Thanks, Johannes Am 29.03.2012 um 16:58 schrieb Raffaele Viglianti: > Hello all, > > I've just noticed that MEI is mentioned in "XSLT 2.0 and XPath 2.0 Programmer's Reference" by Michael Kay. Here's the page on Google Books: http://j.mp/HjmAqq > > Best, > Raffaele > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 kepper at edirom.de Thu Mar 29 17:27:33 2012 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 29 Mar 2012 17:27:33 +0200 Subject: [MEI-L] XSLT 2.0 and XPath 2.0 by Michael Kay In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01153049@GRANT.eservices.virginia.edu> References: <CAMyHAnPNKzsw7ESNxm6qvVGgx5spSO+dq80mq5ONvesL+1Y=KQ@mail.gmail.com>, <A40E0E55-1CB9-49A1-B4A8-E14124578CBE@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01153049@GRANT.eservices.virginia.edu> Message-ID: <A6244AFD-83CE-498A-9471-82408D1FE9CF@edirom.de> Am 29.03.2012 um 17:23 schrieb Roland, Perry (pdr4h): > Johannes, > > We haven't written mei2musicxml.xsl yet, but have talked about it extensively. That's true. And now, as we have a strategy for flattening MEI by XSLT and / or MEISE, we can actually start working on it by providing a reduced schema of MEI that serves as filter for things that can go into MusicXML. But honestly, that's something the Technical Team should discuss _after_ the upcoming release? jo From stadler at edirom.de Mon Apr 9 17:00:15 2012 From: stadler at edirom.de (Peter Stadler) Date: Mon, 9 Apr 2012 17:00:15 +0200 Subject: [MEI-L] Fwd: [MUSIC-IR] ME Summer Workshop, "Introduction to MEI" References: <sympa.1333835383.32436.463@listes.ircam.fr> Message-ID: <2626C1E2-826A-4CE7-A800-4E117DC39749@edirom.de> This might be of interest to this group as well ;-) All the best Peter Anfang der weitergeleiteten E-Mail: > Von: Perry Roland <pdr4h at eservices.virginia.edu> > Datum: 7. April 2012 23:54:18 MESZ > An: music-ir at listes.ircam.fr > Betreff: [MUSIC-IR] ME Summer Workshop, "Introduction to MEI" > > > MEI SUMMER WORKSHOP > > The University of Virginia Library and the University of Paderborn are offering > an opportunity to learn about the Music Encoding Initiative (MEI), an > increasingly important tool for digital humanities music research. Spend three > days learning the fundamentals of using MEI for research, teaching, electronic > publishing, and management of digital music collections. > > "Introduction to MEI," an intensive, three-day, hands-on workshop, will be > offered Wednesday, August 22nd, 2012 through Friday, August 24th, 2012 at the > University of Virginia Library. Experts from the Music Encoding Initiative > Council will teach the workshop, during which participants will learn about MEI > history and design principles, tools for creating, editing, and rendering MEI, > and techniques for customizing the MEI schema. Each day will include lectures, > plenty of hands-on practice, and opportunities to address participant-specific > issues. Attendees are encouraged to bring example material that they would > like to encode. > > No previous experience with MEI or XML is required, but an understanding of > music notation and other markup schemes, such as HTML and TEI, will be helpful. > There are also no fees associated with this workshop, but participants must > bear travel, housing, and food costs. > > To apply, visit http://tinyurl.com/bs9e6oe before June 1, 2012. The number of > participants is limited, so apply early! Successful applicants will be > notified of acceptance as soon as possible after June 1. > > For more information on MEI, visit http://www.music-encoding.org. Please > address questions to info at music-encoding.org. > > GETTING THERE > The University of Virginia is located in Charlottesville, VA, 110 miles > southwest of Washington, D.C. and 68 miles west of Richmond. > > The city of Charlottesville is served by five airports: >> Charlottesville (CHO) (http://www.gocho.com/) >> Richmond International (RIC) (http://www.flyrichmond.com/) >> Washington-Dulles (IAD)(http://www.metwashairports.com/dulles/dulles.htm) >> Reagan National (DCA) (http://www.metwashairports.com/reagan/reagan.htm) >> Baltimore Washington International (BWI) (http://www.bwiairport.com) > > The Amtrak station (http://www.amtrak.com) is conveniently located one > half-mile from the University. > > A map showing UVA's libraries and driving directions to Alderman Library are > available at http://www2.lib.virginia.edu/map/. Additional maps of the > University, such as accessibility and University Transit Service maps, are > available at http://www.virginia.edu/Map/. > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > From raffaeleviglianti at gmail.com Thu Apr 12 12:48:52 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 12 Apr 2012 11:48:52 +0100 Subject: [MEI-L] Digital Humanities @ Oxford Summer School Message-ID: <CAMyHAnPPQzyFRFoWx216_eS=axBUd9HNbL5u5D_erYB2K9E4mw@mail.gmail.com> Dear all, The Digital Humanities at Oxford Summer School is now open for registration. http://digital.humanities.ox.ac.uk/dhoxss/ Delegates will be introduced to a range of topics suitable for researchers, project managers, research assistants, and students who are interested in the creation, management, or publication of digital data in the humanities. The course is very XML- and TEI-centric, but I have been invited to provide a training session about music encoding and MEI: http://digital.humanities.ox.ac.uk/dhoxss/programme.html#session4 Please circulate this to anyone who you think might be interested. Many thanks and best regards, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120412/5d3fbe69/attachment.html> From maja.hartwig at gmx.de Thu Apr 19 09:33:47 2012 From: maja.hartwig at gmx.de (Maja Hartwig) Date: Thu, 19 Apr 2012 09:33:47 +0200 Subject: [MEI-L] analysis Message-ID: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> Dear List, writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. In my opinion it would make sense to use the @hfunc also on chords for describing the function of it in a musical work, such as a "tonic" or something like that. So I think the att.chord.anl should be memberOf att.harmonicfunction. Is it a bug or any other opinions? Best regards, Maja -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120419/62510e46/attachment.html> From pdr4h at eservices.virginia.edu Mon Apr 23 21:11:00 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 23 Apr 2012 19:11:00 +0000 Subject: [MEI-L] analysis In-Reply-To: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu> Hi, Maja, We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] Sent: Thursday, April 19, 2012 3:33 AM To: Music Encoding Initiative Subject: [MEI-L] analysis Dear List, writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. In my opinion it would make sense to use the @hfunc also on chords for describing the function of it in a musical work, such as a "tonic" or something like that. So I think the att.chord.anl should be memberOf att.harmonicfunction. Is it a bug or any other opinions? Best regards, Maja -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120423/7e4a0c1e/attachment.html> From kepper at edirom.de Mon Apr 23 22:30:37 2012 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 23 Apr 2012 22:30:37 +0200 Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu> Message-ID: <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> Hi both, I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? jo Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > Hi, Maja, > > We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > Sent: Thursday, April 19, 2012 3:33 AM > To: Music Encoding Initiative > Subject: [MEI-L] analysis > > Dear List, > > writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. > It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. > But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. > In my opinion it would make sense to use the @hfunc also on chords for describing the function of it > in a musical work, such as a "tonic" or something like that. > So I think the att.chord.anl should be memberOf att.harmonicfunction. > Is it a bug or any other opinions? > > Best regards, > Maja > > > _______________________________________________ > 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 Mon Apr 23 22:56:21 2012 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 23 Apr 2012 13:56:21 -0700 (PDT) Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu> Message-ID: <b6f430a0.00001e00.0000002a@CCARH-ADM-2.su.win.stanford.edu> I had intended to respond to Maja: I'm so accustomed to Humdrum, which allows multiple labels to be assigned, that I find the either/or question difficult. In the Humdrum files themselves, multiple harmonic labels may be used (and have been very useful in comparative studies). A single chord can have one function in the designated key but quite another in a modulatory context. That distinction enables Craig to generate keyscapes reconciled to one key (good for comparison between works) or to see key-specific usage (good for understanding how individual composers operate). There is also chord quality: major/minor/augmented/diminished, plus inversion types, plus extended harmonies (7th, 9th, et al). How much of all this MEI wants will depend on whether or not it wants to support harmonic analysis, basso continuo realization (let's say in sound; but don't stage too much on this-the printed labels are often full of errors and impossibilities), etc. For now, it could be left fairly simple, provided that nothing interferes with expansion of capabilities later. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA <http://www.stanford.edu/~esfield/> http://www.stanford.edu/~esfield/ From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, April 23, 2012 12:11 PM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi, Maja, We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] Sent: Thursday, April 19, 2012 3:33 AM To: Music Encoding Initiative Subject: [MEI-L] analysis Dear List, writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. In my opinion it would make sense to use the @hfunc also on chords for describing the function of it in a musical work, such as a "tonic" or something like that. So I think the att.chord.anl should be memberOf att.harmonicfunction. Is it a bug or any other opinions? Best regards, Maja -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120423/af245648/attachment.html> From pdr4h at eservices.virginia.edu Mon Apr 23 23:08:25 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 23 Apr 2012 21:08:25 +0000 Subject: [MEI-L] analysis In-Reply-To: <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0116471F@GRANT.eservices.virginia.edu> Johannes, Your argument is convincing. But, there's also the possibility of moving @mfunc to an element similar to <harm>. Of course, this would require more extended planning and execution. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Monday, April 23, 2012 4:30 PM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi both, I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? jo Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > Hi, Maja, > > We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > Sent: Thursday, April 19, 2012 3:33 AM > To: Music Encoding Initiative > Subject: [MEI-L] analysis > > Dear List, > > writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. > It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. > But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. > In my opinion it would make sense to use the @hfunc also on chords for describing the function of it > in a musical work, such as a "tonic" or something like that. > So I think the att.chord.anl should be memberOf att.harmonicfunction. > Is it a bug or any other opinions? > > Best regards, > Maja > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Mon Apr 23 23:26:06 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 23 Apr 2012 21:26:06 +0000 Subject: [MEI-L] analysis In-Reply-To: <b6f430a0.00001e00.0000002a@CCARH-ADM-2.su.win.stanford.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <b6f430a0.00001e00.0000002a@CCARH-ADM-2.su.win.stanford.edu> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01164729@GRANT.eservices.virginia.edu> Eleanor, By using multiple <harm> elements, one can assign multiple harmonic labels, even the incorrect, printed ones you refer to. Using @hfunc, however, (should we add it) one could assign only one. I think the choice is up to the encoder. There are many reasons why one would choose an attribute over an element or vice versa. For some encoders, a simple file structure where only one label can be assigned and/or values can be easily contrained is important. For others, in order to perform the kind of analysis you mention, multiple labels will be the way to go. Neither path hinders further development. -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Eleanor Selfridge-Field [esfield at stanford.edu] Sent: Monday, April 23, 2012 4:56 PM To: 'Music Encoding Initiative' Subject: Re: [MEI-L] analysis I had intended to respond to Maja: I?m so accustomed to Humdrum, which allows multiple labels to be assigned, that I find the either/or question difficult. In the Humdrum files themselves, multiple harmonic labels may be used (and have been very useful in comparative studies). A single chord can have one function in the designated key but quite another in a modulatory context. That distinction enables Craig to generate keyscapes reconciled to one key (good for comparison between works) or to see key-specific usage (good for understanding how individual composers operate). There is also chord quality: major/minor/augmented/diminished, plus inversion types, plus extended harmonies (7th, 9th, et al). How much of all this MEI wants will depend on whether or not it wants to support harmonic analysis, basso continuo realization (let?s say in sound; but don?t stage too much on this?the printed labels are often full of errors and impossibilities), etc. For now, it could be left fairly simple, provided that nothing interferes with expansion of capabilities later. Eleanor Eleanor Selfridge-Field Consulting Professor, Music (and, by courtesy, Symbolic Systems) Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, April 23, 2012 12:11 PM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi, Maja, We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? -- 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-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de> [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] Sent: Thursday, April 19, 2012 3:33 AM To: Music Encoding Initiative Subject: [MEI-L] analysis Dear List, writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. In my opinion it would make sense to use the @hfunc also on chords for describing the function of it in a musical work, such as a "tonic" or something like that. So I think the att.chord.anl should be memberOf att.harmonicfunction. Is it a bug or any other opinions? Best regards, Maja -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120423/af10b094/attachment.html> From pdr4h at eservices.virginia.edu Mon Apr 23 23:41:04 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 23 Apr 2012 21:41:04 +0000 Subject: [MEI-L] analysis In-Reply-To: <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu> Given the current definition of hfunc one should not "do his analysis" of chords using the hfunc attribute. The att.harmonicfunction class is for attributes describing the harmonic function *of a single pitch* in a chord. It was intended for labels such as "root", "third", "fifth", etc. This is why it's available on note but not on chord. <classSpec ident="att.harmonicfunction" module="MEI.analysis" type="atts"> <desc>Attributes describing the harmonic function of a single pitch</desc> <attList> <attDef ident="hfunc" usage="opt"> <desc>describes harmonic function in any convenient typology.</desc> <datatype> <rng:data type="NMTOKEN"/> </datatype> </attDef> </attList> </classSpec> Chord labels, like "Cm7", or indications of harmonic functionality, like "ii7", belong in <harm>, unless we expand the definition of att.harmonicfunction and, in all likelihood, its datatype. It seems to me that we need right now is better documentation in the Guidelines, not more changes to the schema. We can consider this topic again at a later date. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Monday, April 23, 2012 4:30 PM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi both, I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? jo Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > Hi, Maja, > > We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > Sent: Thursday, April 19, 2012 3:33 AM > To: Music Encoding Initiative > Subject: [MEI-L] analysis > > Dear List, > > writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. > It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. > But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. > In my opinion it would make sense to use the @hfunc also on chords for describing the function of it > in a musical work, such as a "tonic" or something like that. > So I think the att.chord.anl should be memberOf att.harmonicfunction. > Is it a bug or any other opinions? > > Best regards, > Maja > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 maja.hartwig at gmx.de Tue Apr 24 09:32:02 2012 From: maja.hartwig at gmx.de (Maja Hartwig) Date: Tue, 24 Apr 2012 09:32:02 +0200 Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu> Message-ID: <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de> Hi all, thanks for the responses. I understand that we don?t want to make more changes to the schema. I would also use the @hfunc on a note for labels such as "root" or "keynote". But I think harmonic functions of chords encoded with the @hfunc should also be possible, because it would allow to describe the chords function in a harmonic context such as "tonic" and so on, without switching to the harm element. In my opinion the <harm> is used to give the chords a name but not a function, or to describe figured bass numbers. I also think, that it should be the decision of the encoder which way he uses for his analysis. But isn?t it a good thing to have the choice between more than one option? I would describe the labels "third" and "fifth" etc. with the @inth. Or for what is the use of @inth intended? The question came up when I was writing the analysis chapter of the guidelines and I would like to avoid any misunderstandings! Best regards, Maja P.S.: And why again is the @mfunc allowed on a chord? :-) Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h): > Given the current definition of hfunc one should not "do his analysis" of chords using the hfunc attribute. > > The att.harmonicfunction class is for attributes describing the harmonic function *of a single pitch* in a chord. It was intended for labels such as "root", "third", "fifth", etc. This is why it's available on note but not on chord. > > <classSpec ident="att.harmonicfunction" module="MEI.analysis" type="atts"> > <desc>Attributes describing the harmonic function of a single pitch</desc> > <attList> > <attDef ident="hfunc" usage="opt"> > <desc>describes harmonic function in any convenient typology.</desc> > <datatype> > <rng:data type="NMTOKEN"/> > </datatype> > </attDef> > </attList> > </classSpec> > > Chord labels, like "Cm7", or indications of harmonic functionality, like "ii7", belong in <harm>, unless we expand the definition of att.harmonicfunction and, in all likelihood, its datatype. > > It seems to me that we need right now is better documentation in the Guidelines, not more changes to the schema. We can consider this topic again at a later date. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Monday, April 23, 2012 4:30 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] analysis > > Hi both, > > I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? > > jo > > > Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > >> Hi, Maja, >> >> We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? >> >> -- >> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] >> Sent: Thursday, April 19, 2012 3:33 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] analysis >> >> Dear List, >> >> writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. >> It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. >> But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. >> In my opinion it would make sense to use the @hfunc also on chords for describing the function of it >> in a musical work, such as a "tonic" or something like that. >> So I think the att.chord.anl should be memberOf att.harmonicfunction. >> Is it a bug or any other opinions? >> >> Best regards, >> Maja >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Apr 24 14:31:20 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 24 Apr 2012 12:31:20 +0000 Subject: [MEI-L] analysis In-Reply-To: <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu>, <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de> Message-ID: <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> Maja, @inth was intended to carry numeric values (half-steps above the root), even though it seems that intention didn't get expressed properly in the move from the original RNG to ODD. The datatype of @inth should be a list of numbers, not NMTOKENS. This is an error that should be corrected even now in the frozen 2012 release. Though its use would be somewhat rare, @mfunc is allowed on chords because they can have a melodic function as well as a harmonic one, as in the case of so-called "passing chords". I suppose this could be subsumed into @hfunc, now that I think about it. That is, a chord's harmonic function could be "non-harmonic". If @hfunc were allowed on chords, it should have exactly the function (no pun intended) that you describe -- labeling chords with a general label, such as "tonic", "dominant", etc., not with chord labels transcribed from the document, like "Cm7". I am still conflicted, however, whether "functional harmony" labeled with Roman numerals goes in <harm> or @hfunc. The answer to your question about choices depends on who's answering. :-) Choices are often a good thing, but not when they duplicate each other -- "Would you like vanilla ice or vanilla ice cream?" There should be a difference between how @hfunc is used and how <harm> is used. If there's no difference, then we probably don't need both. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] Sent: Tuesday, April 24, 2012 3:32 AM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi all, thanks for the responses. I understand that we don?t want to make more changes to the schema. I would also use the @hfunc on a note for labels such as "root" or "keynote". But I think harmonic functions of chords encoded with the @hfunc should also be possible, because it would allow to describe the chords function in a harmonic context such as "tonic" and so on, without switching to the harm element. In my opinion the <harm> is used to give the chords a name but not a function, or to describe figured bass numbers. I also think, that it should be the decision of the encoder which way he uses for his analysis. But isn?t it a good thing to have the choice between more than one option? I would describe the labels "third" and "fifth" etc. with the @inth. Or for what is the use of @inth intended? The question came up when I was writing the analysis chapter of the guidelines and I would like to avoid any misunderstandings! Best regards, Maja P.S.: And why again is the @mfunc allowed on a chord? :-) Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h): > Given the current definition of hfunc one should not "do his analysis" of chords using the hfunc attribute. > > The att.harmonicfunction class is for attributes describing the harmonic function *of a single pitch* in a chord. It was intended for labels such as "root", "third", "fifth", etc. This is why it's available on note but not on chord. > > <classSpec ident="att.harmonicfunction" module="MEI.analysis" type="atts"> > <desc>Attributes describing the harmonic function of a single pitch</desc> > <attList> > <attDef ident="hfunc" usage="opt"> > <desc>describes harmonic function in any convenient typology.</desc> > <datatype> > <rng:data type="NMTOKEN"/> > </datatype> > </attDef> > </attList> > </classSpec> > > Chord labels, like "Cm7", or indications of harmonic functionality, like "ii7", belong in <harm>, unless we expand the definition of att.harmonicfunction and, in all likelihood, its datatype. > > It seems to me that we need right now is better documentation in the Guidelines, not more changes to the schema. We can consider this topic again at a later date. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Monday, April 23, 2012 4:30 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] analysis > > Hi both, > > I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? > > jo > > > Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > >> Hi, Maja, >> >> We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? >> >> -- >> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] >> Sent: Thursday, April 19, 2012 3:33 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] analysis >> >> Dear List, >> >> writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. >> It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. >> But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. >> In my opinion it would make sense to use the @hfunc also on chords for describing the function of it >> in a musical work, such as a "tonic" or something like that. >> So I think the att.chord.anl should be memberOf att.harmonicfunction. >> Is it a bug or any other opinions? >> >> Best regards, >> Maja >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Apr 24 15:24:15 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 24 Apr 2012 13:24:15 +0000 Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu>, <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de>, <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0116489B@GRANT.eservices.virginia.edu> The last paragraph should read: "The answer to your question about choices depends on who's answering. :-) Choices are often a good thing, but not when they duplicate each other -- "Would you like vanilla ice cream or vanilla ice cream?" There should be a difference between how @hfunc is used and how <harm> is used. If there's no difference, then we probably don't need both." I should stop using analogies if I can't get 'em right. :-) -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Roland, Perry (pdr4h) [pdr4h at eservices.virginia.edu] Sent: Tuesday, April 24, 2012 8:31 AM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Maja, @inth was intended to carry numeric values (half-steps above the root), even though it seems that intention didn't get expressed properly in the move from the original RNG to ODD. The datatype of @inth should be a list of numbers, not NMTOKENS. This is an error that should be corrected even now in the frozen 2012 release. Though its use would be somewhat rare, @mfunc is allowed on chords because they can have a melodic function as well as a harmonic one, as in the case of so-called "passing chords". I suppose this could be subsumed into @hfunc, now that I think about it. That is, a chord's harmonic function could be "non-harmonic". If @hfunc were allowed on chords, it should have exactly the function (no pun intended) that you describe -- labeling chords with a general label, such as "tonic", "dominant", etc., not with chord labels transcribed from the document, like "Cm7". I am still conflicted, however, whether "functional harmony" labeled with Roman numerals goes in <harm> or @hfunc. The answer to your question about choices depends on who's answering. :-) Choices are often a good thing, but not when they duplicate each other -- "Would you like vanilla ice or vanilla ice cream?" There should be a difference between how @hfunc is used and how <harm> is used. If there's no difference, then we probably don't need both. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] Sent: Tuesday, April 24, 2012 3:32 AM To: Music Encoding Initiative Subject: Re: [MEI-L] analysis Hi all, thanks for the responses. I understand that we don?t want to make more changes to the schema. I would also use the @hfunc on a note for labels such as "root" or "keynote". But I think harmonic functions of chords encoded with the @hfunc should also be possible, because it would allow to describe the chords function in a harmonic context such as "tonic" and so on, without switching to the harm element. In my opinion the <harm> is used to give the chords a name but not a function, or to describe figured bass numbers. I also think, that it should be the decision of the encoder which way he uses for his analysis. But isn?t it a good thing to have the choice between more than one option? I would describe the labels "third" and "fifth" etc. with the @inth. Or for what is the use of @inth intended? The question came up when I was writing the analysis chapter of the guidelines and I would like to avoid any misunderstandings! Best regards, Maja P.S.: And why again is the @mfunc allowed on a chord? :-) Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h): > Given the current definition of hfunc one should not "do his analysis" of chords using the hfunc attribute. > > The att.harmonicfunction class is for attributes describing the harmonic function *of a single pitch* in a chord. It was intended for labels such as "root", "third", "fifth", etc. This is why it's available on note but not on chord. > > <classSpec ident="att.harmonicfunction" module="MEI.analysis" type="atts"> > <desc>Attributes describing the harmonic function of a single pitch</desc> > <attList> > <attDef ident="hfunc" usage="opt"> > <desc>describes harmonic function in any convenient typology.</desc> > <datatype> > <rng:data type="NMTOKEN"/> > </datatype> > </attDef> > </attList> > </classSpec> > > Chord labels, like "Cm7", or indications of harmonic functionality, like "ii7", belong in <harm>, unless we expand the definition of att.harmonicfunction and, in all likelihood, its datatype. > > It seems to me that we need right now is better documentation in the Guidelines, not more changes to the schema. We can consider this topic again at a later date. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > Sent: Monday, April 23, 2012 4:30 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] analysis > > Hi both, > > I would argue that for consistency's sake we should add @hfunc to chords. If one does his analysis using this attribute on notes, why should he switch to <harm> on chords? > > jo > > > Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > >> Hi, Maja, >> >> We could add @hfunc to <chord>, but I've always thought that it would duplicate the function of <harm>, which is to assign harmonic labels. I could be wrong though, if <harm> were defined only to be used for transcription and not analysis. Anyone else have thoughts on this? >> >> -- >> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] >> Sent: Thursday, April 19, 2012 3:33 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] analysis >> >> Dear List, >> >> writing the guidelines of the analysis module, I am wondering about the use of the @hfunc. >> It is allowed within a <note> for describing a note as a "keynote" or "root" or anything else. >> But the @hfunc is not permitted wtihin the <chord>, although the @mfunc e.g. is allowed. >> In my opinion it would make sense to use the @hfunc also on chords for describing the function of it >> in a musical work, such as a "tonic" or something like that. >> So I think the att.chord.anl should be memberOf att.harmonicfunction. >> Is it a bug or any other opinions? >> >> Best regards, >> Maja >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Maja.Hartwig at gmx.de Tue Apr 24 19:36:46 2012 From: Maja.Hartwig at gmx.de (Maja Hartwig) Date: Tue, 24 Apr 2012 19:36:46 +0200 Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu>, <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de> <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> Message-ID: <20120424173646.27070@gmx.net> Hi, ok that clarifies the issue with the @inth and the @mfunc. Isn?t it difference enough to encode harmonic function on the one hand with an attribute and on the other to have the possibility to encode it with the harm element? We have this opportunity with other elements/attributes, too. I still think the @hfunc would make sense on chords when it would be used for describing functions. Another difference might be, that using the @hfunc is only intended for analytical purposes. But I know, the schema is still frozen! Maja P.S.: Yes, I really like vanilla ice cream...:-) -------- Original-Nachricht -------- > Datum: Tue, 24 Apr 2012 12:31:20 +0000 > Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > Betreff: Re: [MEI-L] analysis > Maja, > > @inth was intended to carry numeric values (half-steps above the root), > even though it seems that intention didn't get expressed properly in the move > from the original RNG to ODD. The datatype of @inth should be a list of > numbers, not NMTOKENS. This is an error that should be corrected even now > in the frozen 2012 release. > > Though its use would be somewhat rare, @mfunc is allowed on chords because > they can have a melodic function as well as a harmonic one, as in the case > of so-called "passing chords". I suppose this could be subsumed into > @hfunc, now that I think about it. That is, a chord's harmonic function could > be "non-harmonic". > > If @hfunc were allowed on chords, it should have exactly the function (no > pun intended) that you describe -- labeling chords with a general label, > such as "tonic", "dominant", etc., not with chord labels transcribed from the > document, like "Cm7". I am still conflicted, however, whether "functional > harmony" labeled with Roman numerals goes in <harm> or @hfunc. > > The answer to your question about choices depends on who's answering. :-) > Choices are often a good thing, but not when they duplicate each other -- > "Would you like vanilla ice or vanilla ice cream?" There should be a > difference between how @hfunc is used and how <harm> is used. If there's no > difference, then we probably don't need both. > > -- > 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > Sent: Tuesday, April 24, 2012 3:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] analysis > > Hi all, > thanks for the responses. > I understand that we don?t want to make more changes to the schema. I > would also use the @hfunc on a note for labels such as "root" or "keynote". > But I think harmonic functions of chords encoded with the @hfunc should > also be possible, because it would allow to describe the chords function > in a harmonic context such as "tonic" and so on, without switching to the > harm element. In my opinion the <harm> is used to give the chords a name but > not a function, or to describe figured bass numbers. > I also think, that it should be the decision of the encoder which way he > uses for his analysis. But isn?t it a good thing to have the choice between > more than one option? > > I would describe the labels "third" and "fifth" etc. with the @inth. Or > for what is the use of @inth intended? > The question came up when I was writing the analysis chapter of the > guidelines and I would like to avoid any misunderstandings! > Best regards, > Maja > > P.S.: And why again is the @mfunc allowed on a chord? :-) > > > Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h): > > > Given the current definition of hfunc one should not "do his analysis" > of chords using the hfunc attribute. > > > > The att.harmonicfunction class is for attributes describing the harmonic > function *of a single pitch* in a chord. It was intended for labels such > as "root", "third", "fifth", etc. This is why it's available on note but > not on chord. > > > > <classSpec ident="att.harmonicfunction" module="MEI.analysis" > type="atts"> > > <desc>Attributes describing the harmonic function of a single > pitch</desc> > > <attList> > > <attDef ident="hfunc" usage="opt"> > > <desc>describes harmonic function in any convenient > typology.</desc> > > <datatype> > > <rng:data type="NMTOKEN"/> > > </datatype> > > </attDef> > > </attList> > > </classSpec> > > > > Chord labels, like "Cm7", or indications of harmonic functionality, like > "ii7", belong in <harm>, unless we expand the definition of > att.harmonicfunction and, in all likelihood, its datatype. > > > > It seems to me that we need right now is better documentation in the > Guidelines, not more changes to the schema. We can consider this topic again > at a later date. > > > > -- > > 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > > Sent: Monday, April 23, 2012 4:30 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] analysis > > > > Hi both, > > > > I would argue that for consistency's sake we should add @hfunc to > chords. If one does his analysis using this attribute on notes, why should he > switch to <harm> on chords? > > > > jo > > > > > > Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > > > >> Hi, Maja, > >> > >> We could add @hfunc to <chord>, but I've always thought that it would > duplicate the function of <harm>, which is to assign harmonic labels. I > could be wrong though, if <harm> were defined only to be used for > transcription and not analysis. Anyone else have thoughts on this? > >> > >> -- > >> 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > >> Sent: Thursday, April 19, 2012 3:33 AM > >> To: Music Encoding Initiative > >> Subject: [MEI-L] analysis > >> > >> Dear List, > >> > >> writing the guidelines of the analysis module, I am wondering about the > use of the @hfunc. > >> It is allowed within a <note> for describing a note as a "keynote" or > "root" or anything else. > >> But the @hfunc is not permitted wtihin the <chord>, although the @mfunc > e.g. is allowed. > >> In my opinion it would make sense to use the @hfunc also on chords for > describing the function of it > >> in a musical work, such as a "tonic" or something like that. > >> So I think the att.chord.anl should be memberOf att.harmonicfunction. > >> Is it a bug or any other opinions? > >> > >> Best regards, > >> Maja > >> > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a From Maja.Hartwig at gmx.de Tue Apr 24 19:36:46 2012 From: Maja.Hartwig at gmx.de (Maja Hartwig) Date: Tue, 24 Apr 2012 19:36:46 +0200 Subject: [MEI-L] analysis In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> References: <0FFC1623-C25E-4EA1-9A4C-6839D2F64305@gmx.de> <BBCC497C40D85642B90E9F94FC30343D011646D1@GRANT.eservices.virginia.edu>, <AE231485-8300-43BF-B9B6-D315D7810100@edirom.de> <BBCC497C40D85642B90E9F94FC30343D01164742@GRANT.eservices.virginia.edu>, <4309C00A-3BA5-4BD8-A8FD-1295A54CBED2@gmx.de> <BBCC497C40D85642B90E9F94FC30343D01164854@GRANT.eservices.virginia.edu> Message-ID: <20120424173646.27070@gmx.net> Hi, ok that clarifies the issue with the @inth and the @mfunc. Isn?t it difference enough to encode harmonic function on the one hand with an attribute and on the other to have the possibility to encode it with the harm element? We have this opportunity with other elements/attributes, too. I still think the @hfunc would make sense on chords when it would be used for describing functions. Another difference might be, that using the @hfunc is only intended for analytical purposes. But I know, the schema is still frozen! Maja P.S.: Yes, I really like vanilla ice cream...:-) -------- Original-Nachricht -------- > Datum: Tue, 24 Apr 2012 12:31:20 +0000 > Von: "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > Betreff: Re: [MEI-L] analysis > Maja, > > @inth was intended to carry numeric values (half-steps above the root), > even though it seems that intention didn't get expressed properly in the move > from the original RNG to ODD. The datatype of @inth should be a list of > numbers, not NMTOKENS. This is an error that should be corrected even now > in the frozen 2012 release. > > Though its use would be somewhat rare, @mfunc is allowed on chords because > they can have a melodic function as well as a harmonic one, as in the case > of so-called "passing chords". I suppose this could be subsumed into > @hfunc, now that I think about it. That is, a chord's harmonic function could > be "non-harmonic". > > If @hfunc were allowed on chords, it should have exactly the function (no > pun intended) that you describe -- labeling chords with a general label, > such as "tonic", "dominant", etc., not with chord labels transcribed from the > document, like "Cm7". I am still conflicted, however, whether "functional > harmony" labeled with Roman numerals goes in <harm> or @hfunc. > > The answer to your question about choices depends on who's answering. :-) > Choices are often a good thing, but not when they duplicate each other -- > "Would you like vanilla ice or vanilla ice cream?" There should be a > difference between how @hfunc is used and how <harm> is used. If there's no > difference, then we probably don't need both. > > -- > 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > Sent: Tuesday, April 24, 2012 3:32 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] analysis > > Hi all, > thanks for the responses. > I understand that we don?t want to make more changes to the schema. I > would also use the @hfunc on a note for labels such as "root" or "keynote". > But I think harmonic functions of chords encoded with the @hfunc should > also be possible, because it would allow to describe the chords function > in a harmonic context such as "tonic" and so on, without switching to the > harm element. In my opinion the <harm> is used to give the chords a name but > not a function, or to describe figured bass numbers. > I also think, that it should be the decision of the encoder which way he > uses for his analysis. But isn?t it a good thing to have the choice between > more than one option? > > I would describe the labels "third" and "fifth" etc. with the @inth. Or > for what is the use of @inth intended? > The question came up when I was writing the analysis chapter of the > guidelines and I would like to avoid any misunderstandings! > Best regards, > Maja > > P.S.: And why again is the @mfunc allowed on a chord? :-) > > > Am 23.04.2012 um 23:41 schrieb Roland, Perry (pdr4h): > > > Given the current definition of hfunc one should not "do his analysis" > of chords using the hfunc attribute. > > > > The att.harmonicfunction class is for attributes describing the harmonic > function *of a single pitch* in a chord. It was intended for labels such > as "root", "third", "fifth", etc. This is why it's available on note but > not on chord. > > > > <classSpec ident="att.harmonicfunction" module="MEI.analysis" > type="atts"> > > <desc>Attributes describing the harmonic function of a single > pitch</desc> > > <attList> > > <attDef ident="hfunc" usage="opt"> > > <desc>describes harmonic function in any convenient > typology.</desc> > > <datatype> > > <rng:data type="NMTOKEN"/> > > </datatype> > > </attDef> > > </attList> > > </classSpec> > > > > Chord labels, like "Cm7", or indications of harmonic functionality, like > "ii7", belong in <harm>, unless we expand the definition of > att.harmonicfunction and, in all likelihood, its datatype. > > > > It seems to me that we need right now is better documentation in the > Guidelines, not more changes to the schema. We can consider this topic again > at a later date. > > > > -- > > 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] > > Sent: Monday, April 23, 2012 4:30 PM > > To: Music Encoding Initiative > > Subject: Re: [MEI-L] analysis > > > > Hi both, > > > > I would argue that for consistency's sake we should add @hfunc to > chords. If one does his analysis using this attribute on notes, why should he > switch to <harm> on chords? > > > > jo > > > > > > Am 23.04.2012 um 21:11 schrieb Roland, Perry (pdr4h): > > > >> Hi, Maja, > >> > >> We could add @hfunc to <chord>, but I've always thought that it would > duplicate the function of <harm>, which is to assign harmonic labels. I > could be wrong though, if <harm> were defined only to be used for > transcription and not analysis. Anyone else have thoughts on this? > >> > >> -- > >> 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-bounces at lists.uni-paderborn.de > [mei-l-bounces at lists.uni-paderborn.de] on behalf of Maja Hartwig [maja.hartwig at gmx.de] > >> Sent: Thursday, April 19, 2012 3:33 AM > >> To: Music Encoding Initiative > >> Subject: [MEI-L] analysis > >> > >> Dear List, > >> > >> writing the guidelines of the analysis module, I am wondering about the > use of the @hfunc. > >> It is allowed within a <note> for describing a note as a "keynote" or > "root" or anything else. > >> But the @hfunc is not permitted wtihin the <chord>, although the @mfunc > e.g. is allowed. > >> In my opinion it would make sense to use the @hfunc also on chords for > describing the function of it > >> in a musical work, such as a "tonic" or something like that. > >> So I think the att.chord.anl should be memberOf att.harmonicfunction. > >> Is it a bug or any other opinions? > >> > >> Best regards, > >> Maja > >> > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/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 -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a From zupftom at googlemail.com Sun May 6 22:42:47 2012 From: zupftom at googlemail.com (TW) Date: Sun, 6 May 2012 22:42:47 +0200 Subject: [MEI-L] @dur on <beamSpan> Message-ID: <CAEB1mAoY0LU5+ZvHUGnn+AJ4WjsCmOiSwMpNn4h9x6Adipmreg@mail.gmail.com> I'm wondering why @dur on <beamSpan> is from att.duration.timestamp rather than att.duration.musical or something along the lines of att.tupletSpan.log. AFAICS, using @tstamp and @dur, it's not possible to define start and end points of constellations like a group of three beamed eighths as the "musical" @dur can only describe powers of two. Shouldn't this be possible? Thomas From Julian.Dabbert at gmail.com Fri May 18 12:05:37 2012 From: Julian.Dabbert at gmail.com (Julian Dabbert) Date: Fri, 18 May 2012 12:05:37 +0200 Subject: [MEI-L] Release of MEISE 1.0 Message-ID: <4FB61EF1.4090307@gmail.com> Dear MEI-List, I am happy to announce the first official release of the MEI Score Editor (MEISE) as standalone version on SourceForge. Requirements for the application are an installed Java Runtime Environment (JRE) in version 6 and a computer that is running Windows (XP and above), Linux (tested on Ubunto 10.04 and above) or Mac 10.5 (intel only) and above. You will find guidance for your first steps in the MEISE on Sourceforge (http://sourceforge.net/p/meise/wiki/Quickstart%20MEISE/). Sourceforge also offers bugtracking and the subversion repository with the current source code. MEISE is released under the LGPL 3.0. Since I will be leaving the MEI project by the end of May, the further development will be assigned to Niko Beer at the Musikwissenschaftliches Seminar in Detmold. If you have additional questions about using MEISE or its development, you may also contact Johannes Kepper (kepper at edirom.de). I would like to thank you all for providing a cooperative and friendly work atmosphere during my work at this project. Best regards, -Julian Dabbert -------------- next part -------------- A non-text attachment was scrubbed... Name: Julian_Dabbert.vcf Type: text/x-vcard Size: 314 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120518/ebcfd29e/attachment.vcf> From raffaeleviglianti at gmail.com Mon May 21 11:58:51 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 21 May 2012 10:58:51 +0100 Subject: [MEI-L] Release of MEISE 1.0 In-Reply-To: <4FB61EF1.4090307@gmail.com> References: <4FB61EF1.4090307@gmail.com> Message-ID: <CAMyHAnPC3rKPCP3Uo6M=HHf=vvVum854Pra3ZfZ3dGgJusXPhw@mail.gmail.com> Excellent news! Well done. Best, Raffaele On Fri, May 18, 2012 at 11:05 AM, Julian Dabbert <Julian.Dabbert at gmail.com>wrote: > Dear MEI-List, > > I am happy to announce the first official release of the MEI Score Editor > (MEISE) as standalone version on SourceForge. > Requirements for the application are an installed Java Runtime Environment > (JRE) in version 6 and a computer that is running Windows (XP and above), > Linux (tested on Ubunto 10.04 and above) or Mac 10.5 (intel only) and > above. You will find guidance for your first steps in the MEISE on > Sourceforge (http://sourceforge.net/p/**meise/wiki/Quickstart%20MEISE/<http://sourceforge.net/p/meise/wiki/Quickstart%20MEISE/> > **). Sourceforge also offers bugtracking and the subversion repository > with the current source code. MEISE is released under the LGPL 3.0. > > Since I will be leaving the MEI project by the end of May, the further > development will be assigned to Niko Beer at the Musikwissenschaftliches > Seminar in Detmold. If you have additional questions about using MEISE or > its development, you may also contact Johannes Kepper (kepper at edirom.de). > > I would like to thank you all for providing a cooperative and friendly > work atmosphere during my work at this project. > > Best regards, > -Julian Dabbert > > > _______________________________________________ > 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/20120521/50cb9885/attachment.html> From bohl at edirom.de Wed May 23 14:23:20 2012 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Wed, 23 May 2012 14:23:20 +0200 Subject: [MEI-L] =?windows-1252?q?=5BANN=5D_Edirom-Summer-School_2012_=96_?= =?windows-1252?q?SAVE_THE_DATE?= Message-ID: <07491CA4-9A08-4BFB-BD5A-08FEB6EF1D63@edirom.de> Dear colleagues, it is our great pleasure to announce the third Edirom-Summer-School, to be held at the **University of Paderborn from September 24 to 28, 2012.** As in past years there will be introductory classes on the encoding standards TEI and MEI, related X-Technologies as well as tools. Further information will soon be available on http://www.edirom.de/summerschool2012. Hope to see you in Paderborn! Best wishes, Peter Stadler and Benjamin W. Bohl *********************************************************** Edirom - Projekt "Digitale Musikedition" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 http://www.edirom.de *********************************************************** From kepper at edirom.de Thu May 31 10:31:31 2012 From: kepper at edirom.de (Johannes Kepper) Date: Thu, 31 May 2012 10:31:31 +0200 Subject: [MEI-L] Current work on the Guidelines Message-ID: <EBCEC538-515A-495D-BC39-8F02202A2EF0@edirom.de> Dear MEI Council and other MEI-L subscribers, it's been a (too) long time since our last report from the Technical Team. As you might remember, we're still preparing the upcoming release of MEI. Whereas the schema itself is already fixed, we're currently working on the guidelines for this release, which shall mimic the purpose and functionality of the TEI guidelines. We're already in the lucky position of having some text for almost every chapter (each chapter deals with one of MEI's modules). This was only possible with the help of Benjamin Bohl, Andrew Hankinson, Maja Hartwig, Laurent Pugin, Kristina Richts, Craig Sapp, Raffaele Viglianti, Thomas Weber and Perry Roland. Although we haven't finished it yet, I would like to thank all of them for their hard and continuous work on this. As you all know, collaboratively writing a text with ten authors leads to some differences, so right now Perry and me are reviewing those chapters and try to edit them as good as possible, while always staying in dialogue with the original authors. It is our plan to finish our review and have a first draft of the complete Guidelines by June 11th. Then, we would like to make that available to the subscribers of this list, which includes the whole MEI Council. We would ask you to have a thorough look at least to the chapters you're most interested in, and give us some feedback on it. Maybe we need to explain some features better, maybe you're missing an example for something, or maybe we did something completely wrong. All of this criticism will be helpful for us to improve the Guidelines. But: We don't have much time left for this release. Basically we offer you two weeks of time to review our draft (deadline: June 24th), and then we have the rest of June to work in as much as is possible. This means that we might not be able to react on fundamental criticism this time. but the Guidelines will probably stay a work in progress for the next few years ? TEI hasn't finished work on theirs, and they started more than 25 years ago? Our plan is to have everything ready for release by the end of July. This includes the Guidelines, the schema, an updated website, and our sample collection of MEI files. If we want this to come true, we need your help. Please reserve some time to review the Guidelines in the two weeks starting on June 11th. Feel free to criticize everything you regard as improbable, but please forgive us if we can't react on everything you say. We will keep track on these issues and will regard them for the next revision of the Guidelines. If you have some time to work on the text on your own, we're happy to introduce you to the technical workflows necessary. With best regards from the text smithery, Johannes From richard.lewis at gold.ac.uk Wed Jun 13 11:24:44 2012 From: richard.lewis at gold.ac.uk (Richard Lewis) Date: Wed, 13 Jun 2012 10:24:44 +0100 Subject: [MEI-L] Current work on the Guidelines In-Reply-To: <EBCEC538-515A-495D-BC39-8F02202A2EF0@edirom.de> References: <EBCEC538-515A-495D-BC39-8F02202A2EF0@edirom.de> Message-ID: <87ipevimxv.wl%richard.lewis@gold.ac.uk> Dear MEI-L, At Thu, 31 May 2012 10:31:31 +0200, Johannes Kepper wrote: > If we want this to come true, we need your help. Please reserve some > time to review the Guidelines in the two weeks starting on June > 11th. Apologies if I've just missed something really obvious, but where is the document you'd like us to review? Is it <http://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/>? Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis ISMS, Computing Goldsmiths, University of London t: +44 (0)20 7078 5134 j: ironchicken at jabber.earth.li @: lewisrichard s: richardjlewis http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From kepper at edirom.de Wed Jun 13 11:45:59 2012 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 13 Jun 2012 11:45:59 +0200 Subject: [MEI-L] Current work on the Guidelines In-Reply-To: <87ipevimxv.wl%richard.lewis@gold.ac.uk> References: <EBCEC538-515A-495D-BC39-8F02202A2EF0@edirom.de> <87ipevimxv.wl%richard.lewis@gold.ac.uk> Message-ID: <9A8A5C10-8666-4D26-BF4D-3CE9D2928680@edirom.de> Hi Richard, as I noticed while reading your mail, we got the wrong mailing list with an updated notification. Sorry for that! Right now, there is nothing to review for you. As I've been ill for some time now, we're slightly delayed and will come back to you with a document to review later. It is not absolutely clear yet when this will be, and I try to resist to announce something right now. Just wait for another mail on this list. In this mail, you will find a compiled document, preferably as PDF, which contains everything you need. We're also still working on the formatting, which seems to require some changes to the TEI processors, so the extra time here might help us to provide a better formatted document. Thanks for the reminder, jo Am 13.06.2012 um 11:24 schrieb Richard Lewis: > Dear MEI-L, > > At Thu, 31 May 2012 10:31:31 +0200, > Johannes Kepper wrote: > >> If we want this to come true, we need your help. Please reserve some >> time to review the Guidelines in the two weeks starting on June >> 11th. > > Apologies if I've just missed something really obvious, but where is > the document you'd like us to review? > > Is it <http://code.google.com/p/music-encoding/source/browse/trunk/source/guidelines/>? > > Richard > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Richard Lewis > ISMS, Computing > Goldsmiths, University of London > t: +44 (0)20 7078 5134 > j: ironchicken at jabber.earth.li > @: lewisrichard > s: richardjlewis > 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 richard.lewis at gold.ac.uk Wed Jun 13 12:02:09 2012 From: richard.lewis at gold.ac.uk (Richard Lewis) Date: Wed, 13 Jun 2012 11:02:09 +0100 Subject: [MEI-L] Current work on the Guidelines In-Reply-To: <9A8A5C10-8666-4D26-BF4D-3CE9D2928680@edirom.de> References: <EBCEC538-515A-495D-BC39-8F02202A2EF0@edirom.de> <87ipevimxv.wl%richard.lewis@gold.ac.uk> <9A8A5C10-8666-4D26-BF4D-3CE9D2928680@edirom.de> Message-ID: <87haufil7i.wl%richard.lewis@gold.ac.uk> At Wed, 13 Jun 2012 11:45:59 +0200, Johannes Kepper wrote: > Am 13.06.2012 um 11:24 schrieb Richard Lewis: > > > At Thu, 31 May 2012 10:31:31 +0200, > > Johannes Kepper wrote: > > > > > If we want this to come true, we need your help. Please reserve > > > some time to review the Guidelines in the two weeks starting on > > > June 11th. > > > > Apologies if I've just missed something really obvious, but where is > > the document you'd like us to review? > > Right now, there is nothing to review for you. As I've been ill for > some time now, we're slightly delayed and will come back to you with > a document to review later. Thanks for the update. I look forward to hearing. Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis ISMS, Computing Goldsmiths, University of London t: +44 (0)20 7078 5134 j: ironchicken at jabber.earth.li @: lewisrichard s: richardjlewis http://www.richardlewis.me.uk/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From lxpugin at gmail.com Tue Jun 26 12:56:00 2012 From: lxpugin at gmail.com (Laurent Pugin) Date: Tue, 26 Jun 2012 12:56:00 +0200 Subject: [MEI-L] beamspan Message-ID: <CAJ306HZ=AE5=xTFUSb2c-oVx01w9YZS1o5RM76pCBWO=uL=ytg@mail.gmail.com> Hi, I am looking for examples of beams encoded with beamspans. Does anybody know where I can find some? Thanks! Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120626/c81384e6/attachment.html> From kepper at edirom.de Tue Jun 26 13:13:22 2012 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 26 Jun 2012 13:13:22 +0200 Subject: [MEI-L] beamspan In-Reply-To: <CAJ306HZ=AE5=xTFUSb2c-oVx01w9YZS1o5RM76pCBWO=uL=ytg@mail.gmail.com> References: <CAJ306HZ=AE5=xTFUSb2c-oVx01w9YZS1o5RM76pCBWO=uL=ytg@mail.gmail.com> Message-ID: <34F4E221-9813-4906-84A6-5FCA18DE3B73@edirom.de> Hi Laurent, I remember at least one (piece from Webern). Will look for that and send it to you. If not included yet, we will add it to the samples. Johannes Am 26.06.2012 um 12:56 schrieb Laurent Pugin: > Hi, > > I am looking for examples of beams encoded with beamspans. Does anybody know where I can find some? > > Thanks! > Laurent > _______________________________________________ > 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 Wed Jun 27 07:54:40 2012 From: lxpugin at gmail.com (Laurent Pugin) Date: Wed, 27 Jun 2012 07:54:40 +0200 Subject: [MEI-L] Conversion to MusicXML Message-ID: <CAJ306HbbsobgskrJUjzn95FdjAJLfZo08xnGKdMCBBpos98Esw@mail.gmail.com> Hi, I am looking for a tool (XSL stylesheet or script) for converting a MEI file to MusicXML. Does anybody know about something like this? Thanks! Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120627/76b5cb4f/attachment.html> From kepper at edirom.de Wed Jun 27 08:02:27 2012 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 27 Jun 2012 08:02:27 +0200 Subject: [MEI-L] Conversion to MusicXML In-Reply-To: <CAJ306HbbsobgskrJUjzn95FdjAJLfZo08xnGKdMCBBpos98Esw@mail.gmail.com> References: <CAJ306HbbsobgskrJUjzn95FdjAJLfZo08xnGKdMCBBpos98Esw@mail.gmail.com> Message-ID: <3D82E1D2-32BF-4DA2-9783-A814037FEC6E@edirom.de> Hi Laurent, we haven't addressed this yet, but it's scheduled for the last year of the NEH/DFG project (which is about to start). Problem was ambiguity and variation in MEI files that needs to be resolved. Now that MEISE allows to export a unified version of an MEI file that follows just one source, we have something to start the conversion from. Development will start sometime after our upcoming release, and in the same run we're going to improve the existing MusicXML->MEI (which is completely outdated and still produces pre-2010-05 code). Sorry for that answer ;-) Johannes Am 27.06.2012 um 07:54 schrieb Laurent Pugin: > Hi, > > I am looking for a tool (XSL stylesheet or script) for converting a MEI file to MusicXML. Does anybody know about something like this? > > Thanks! > Laurent > _______________________________________________ > 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 Fri Jul 6 18:16:41 2012 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 6 Jul 2012 18:16:41 +0200 Subject: [MEI-L] datatype [imt][1-6] Message-ID: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> Dear MEI-L, this is a somewhat technical question that I still would like to ask all of you, although it's particularly interesting to hear developer's opinions. MEI offers several attributes with a datatype of [imt][1-6], that is one letter out of i, m or t, follwed by a digit from 1 to 6. It is used to indicate the beginning ("i"), middle ("m") or end ("t") of a feature which may overlap. The number distinguishes between those overlapping occurences. For instance a <note beam="i1"> indicates the beginning of a beam. If a second, independent beam would start before the first ends, it would be start with a value of "i2". If it would start after the end of the first one, it would reuse the "i1" value. Trying to clarify such details in the Guidelines, Perry and me are wondering if this behaviour is particularly comprehensible, or if we should take this feature away completely. You may encode beams using either the <beam> or <beamSpan> element, the first one being extremely comfortable, the second extremely flexible. Besides beams, the same datatype is available for tuplets and slurs, which also offer other encoding possibilities. Is anyone actually using the functionality of this datatype, or do you have strong opinions for other reasons? It would be great if we could get some feedback in the next couple of days in order to make a decision about this soon. Thanks very much, Perry and Johannes From andrew.hankinson at mail.mcgill.ca Fri Jul 6 18:30:32 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Fri, 6 Jul 2012 16:30:32 +0000 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <29074_1341591417_4FF70F78_29074_14_1_D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> References: <29074_1341591417_4FF70F78_29074_14_1_D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> Message-ID: <CC3E1EAB6662EA4A95FC6E498314808B10B523BD@EXMBX2010-5.campus.MCGILL.CA> I didn't know what those were for, but now that I do I think the numerical indication is quite confusing for overlapping elements. It would be clearer and easier to use the @staff and @layer attributes on the spanning elements to indicate which particular staff and layer (or "voice") they apply to, and then the @tstamp, @dur, @startid & @endid for start and end points. I wouldn't do away with the 'i', 'm', and 't' completely, though. That would be particularly useful for things like @wordpos in lyric syllables. You wouldn't need the numbers, though. -Andrew On 2012-07-06, at 12:16 PM, Johannes Kepper wrote: > Dear MEI-L, > > this is a somewhat technical question that I still would like to ask all of you, although it's particularly interesting to hear developer's opinions. > > MEI offers several attributes with a datatype of [imt][1-6], that is one letter out of i, m or t, follwed by a digit from 1 to 6. It is used to indicate the beginning ("i"), middle ("m") or end ("t") of a feature which may overlap. The number distinguishes between those overlapping occurences. For instance a > > <note beam="i1"> > > indicates the beginning of a beam. If a second, independent beam would start before the first ends, it would be start with a value of "i2". If it would start after the end of the first one, it would reuse the "i1" value. Trying to clarify such details in the Guidelines, Perry and me are wondering if this behaviour is particularly comprehensible, or if we should take this feature away completely. You may encode beams using either the <beam> or <beamSpan> element, the first one being extremely comfortable, the second extremely flexible. Besides beams, the same datatype is available for tuplets and slurs, which also offer other encoding possibilities. Is anyone actually using the functionality of this datatype, or do you have strong opinions for other reasons? > > It would be great if we could get some feedback in the next couple of days in order to make a decision about this soon. > > Thanks very much, > Perry and Johannes > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 1054 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120706/c2e2a6cc/attachment.bin> From Maja.Hartwig at gmx.de Fri Jul 6 18:48:04 2012 From: Maja.Hartwig at gmx.de (Maja Hartwig) Date: Fri, 06 Jul 2012 18:48:04 +0200 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> Message-ID: <20120706164804.181210@gmx.net> Dear Johannes and Perry! Actually I used this datatype, but never for encoding beams, rather for slurs, though my understanding was a different one. I used the "i1" for the first slur in a measure, "i2" for the second one also when the first beam ended before. So I didn?t use the "i1" twice in one measure, because I think that would be confusing to get the appropriate "i?s" and "t?s" together. I was always wondering about the limit of 1-6, because in my way of using that datatype, I couldn?t encode more than 6 slurs in a measure. Now I switched over to encode slurs with @tstamp and duration or @startid and @endid. To encode beams, I always use the <beam>/<beamSpan>, and I think I wouldn?t miss the i/m/t 1-6! Best, Maja -------- Original-Nachricht -------- > Datum: Fri, 6 Jul 2012 18:16:41 +0200 > Von: Johannes Kepper <kepper at edirom.de> > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > Betreff: [MEI-L] datatype [imt][1-6] > Dear MEI-L, > > this is a somewhat technical question that I still would like to ask all > of you, although it's particularly interesting to hear developer's opinions. > > MEI offers several attributes with a datatype of [imt][1-6], that is one > letter out of i, m or t, follwed by a digit from 1 to 6. It is used to > indicate the beginning ("i"), middle ("m") or end ("t") of a feature which may > overlap. The number distinguishes between those overlapping occurences. For > instance a > > <note beam="i1"> > > indicates the beginning of a beam. If a second, independent beam would > start before the first ends, it would be start with a value of "i2". If it > would start after the end of the first one, it would reuse the "i1" value. > Trying to clarify such details in the Guidelines, Perry and me are wondering > if this behaviour is particularly comprehensible, or if we should take this > feature away completely. You may encode beams using either the <beam> or > <beamSpan> element, the first one being extremely comfortable, the second > extremely flexible. Besides beams, the same datatype is available for tuplets > and slurs, which also offer other encoding possibilities. Is anyone > actually using the functionality of this datatype, or do you have strong opinions > for other reasons? > > It would be great if we could get some feedback in the next couple of days > in order to make a decision about this soon. > > Thanks very much, > Perry and Johannes > _______________________________________________ > 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 Jul 6 22:14:50 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Fri, 6 Jul 2012 21:14:50 +0100 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <20120706164804.181210@gmx.net> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> Message-ID: <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> Dear all, In general, I would agree with both of Andrew's points: - get rid of the datatype for beam and other "spanners" like slurs and tuplets (and the related attributes); - keep i/m/t for wordpos (can't think of any other places where this could be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might be worth keeping. Best, Raffaele On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> wrote: > Dear Johannes and Perry! > > Actually I used this datatype, but never for encoding beams, rather for > slurs, though my understanding was a different one. > I used the "i1" for the first slur in a measure, "i2" for the second one > also when the first beam ended before. > So I didn?t use the "i1" twice in one measure, because I think that would > be confusing to get the appropriate "i?s" and "t?s" together. > I was always wondering about the limit of 1-6, because in my way of using > that datatype, I couldn?t encode more than 6 slurs in a measure. > Now I switched over to encode slurs with @tstamp and duration or @startid > and @endid. > To encode beams, I always use the <beam>/<beamSpan>, and I think I > wouldn?t miss the i/m/t 1-6! > Best, > > Maja > > > -------- Original-Nachricht -------- > > Datum: Fri, 6 Jul 2012 18:16:41 +0200 > > Von: Johannes Kepper <kepper at edirom.de> > > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > > Betreff: [MEI-L] datatype [imt][1-6] > > > Dear MEI-L, > > > > this is a somewhat technical question that I still would like to ask all > > of you, although it's particularly interesting to hear developer's > opinions. > > > > MEI offers several attributes with a datatype of [imt][1-6], that is one > > letter out of i, m or t, follwed by a digit from 1 to 6. It is used to > > indicate the beginning ("i"), middle ("m") or end ("t") of a feature > which may > > overlap. The number distinguishes between those overlapping occurences. > For > > instance a > > > > <note beam="i1"> > > > > indicates the beginning of a beam. If a second, independent beam would > > start before the first ends, it would be start with a value of "i2". If > it > > would start after the end of the first one, it would reuse the "i1" > value. > > Trying to clarify such details in the Guidelines, Perry and me are > wondering > > if this behaviour is particularly comprehensible, or if we should take > this > > feature away completely. You may encode beams using either the <beam> or > > <beamSpan> element, the first one being extremely comfortable, the second > > extremely flexible. Besides beams, the same datatype is available for > tuplets > > and slurs, which also offer other encoding possibilities. Is anyone > > actually using the functionality of this datatype, or do you have strong > opinions > > for other reasons? > > > > It would be great if we could get some feedback in the next couple of > days > > in order to make a decision about this soon. > > > > Thanks very much, > > Perry and 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120706/ede55dd7/attachment.html> From zupftom at googlemail.com Fri Jul 6 23:17:36 2012 From: zupftom at googlemail.com (TW) Date: Fri, 6 Jul 2012 23:17:36 +0200 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> Message-ID: <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> I agree with this, as well. I never felt comfortable with this kind of beam/slur indication as it scatters information about a single object over several others, and the object itself doesn't even exist as an entity of its own. @beam/@slur attributes would make sense to me if they were plists/idrefs pointing to the beam/beamSpan/slur element they belong to. For lyrics however, i|m|t totally convinces me as it indicates the relationship between different entities. Thomas 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>: > Dear all, > > In general, I would agree with both of Andrew's points: > - get rid of the datatype for beam and other "spanners" like slurs and > tuplets (and the related attributes); > - keep i/m/t for wordpos (can't think of any other places where this could > be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might > be worth keeping. > > Best, > Raffaele > > > > On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> wrote: >> >> Dear Johannes and Perry! >> >> Actually I used this datatype, but never for encoding beams, rather for >> slurs, though my understanding was a different one. >> I used the "i1" for the first slur in a measure, "i2" for the second one >> also when the first beam ended before. >> So I didn?t use the "i1" twice in one measure, because I think that would >> be confusing to get the appropriate "i?s" and "t?s" together. >> I was always wondering about the limit of 1-6, because in my way of using >> that datatype, I couldn?t encode more than 6 slurs in a measure. >> Now I switched over to encode slurs with @tstamp and duration or @startid >> and @endid. >> To encode beams, I always use the <beam>/<beamSpan>, and I think I >> wouldn?t miss the i/m/t 1-6! >> Best, >> >> Maja >> >> >> -------- Original-Nachricht -------- >> > Datum: Fri, 6 Jul 2012 18:16:41 +0200 >> > Von: Johannes Kepper <kepper at edirom.de> >> > An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> >> > Betreff: [MEI-L] datatype [imt][1-6] >> >> > Dear MEI-L, >> > >> > this is a somewhat technical question that I still would like to ask all >> > of you, although it's particularly interesting to hear developer's >> > opinions. >> > >> > MEI offers several attributes with a datatype of [imt][1-6], that is one >> > letter out of i, m or t, follwed by a digit from 1 to 6. It is used to >> > indicate the beginning ("i"), middle ("m") or end ("t") of a feature >> > which may >> > overlap. The number distinguishes between those overlapping occurences. >> > For >> > instance a >> > >> > <note beam="i1"> >> > >> > indicates the beginning of a beam. If a second, independent beam would >> > start before the first ends, it would be start with a value of "i2". If >> > it >> > would start after the end of the first one, it would reuse the "i1" >> > value. >> > Trying to clarify such details in the Guidelines, Perry and me are >> > wondering >> > if this behaviour is particularly comprehensible, or if we should take >> > this >> > feature away completely. You may encode beams using either the <beam> or >> > <beamSpan> element, the first one being extremely comfortable, the >> > second >> > extremely flexible. Besides beams, the same datatype is available for >> > tuplets >> > and slurs, which also offer other encoding possibilities. Is anyone >> > actually using the functionality of this datatype, or do you have strong >> > opinions >> > for other reasons? >> > >> > It would be great if we could get some feedback in the next couple of >> > days >> > in order to make a decision about this soon. >> > >> > Thanks very much, >> > Perry and 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 > > > > _______________________________________________ > 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 Sat Jul 7 00:23:58 2012 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 7 Jul 2012 00:23:58 +0200 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> Message-ID: <0B19E3D8-4529-439C-BA8D-CCF33104E542@edirom.de> Dear all, thanks for the answers so far, they are really helpful. Just to clarify: We don't want to touch [imt], that's a completely different datatype which is used not only for @wordpos, but also for @tie. As these can't overlap, there is no risk for confusion. We also regard this datatype as undoubtedly handy, so it won't go away, no matter what we will do with [imt][1-6]. Basically, this change would mean that we drop the possibility for a one-pass encoding here and require a second pass. That's certainly a drawback, but it seems like the current solution for single-pass is at least misleading and should therefore go away before causing more trouble. We might want to think about introducing a different one-pass method later, though. Thanks again, and still listening to other opinions, Johannes Am 06.07.2012 um 23:17 schrieb TW: > I agree with this, as well. I never felt comfortable with this kind > of beam/slur indication as it scatters information about a single > object over several others, and the object itself doesn't even exist > as an entity of its own. @beam/@slur attributes would make sense to > me if they were plists/idrefs pointing to the beam/beamSpan/slur > element they belong to. > > For lyrics however, i|m|t totally convinces me as it indicates the > relationship between different entities. > > Thomas > > > 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>: >> Dear all, >> >> In general, I would agree with both of Andrew's points: >> - get rid of the datatype for beam and other "spanners" like slurs and >> tuplets (and the related attributes); >> - keep i/m/t for wordpos (can't think of any other places where this could >> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might >> be worth keeping. >> >> Best, >> Raffaele >> >> >> >> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> wrote: >>> >>> Dear Johannes and Perry! >>> >>> Actually I used this datatype, but never for encoding beams, rather for >>> slurs, though my understanding was a different one. >>> I used the "i1" for the first slur in a measure, "i2" for the second one >>> also when the first beam ended before. >>> So I didn?t use the "i1" twice in one measure, because I think that would >>> be confusing to get the appropriate "i?s" and "t?s" together. >>> I was always wondering about the limit of 1-6, because in my way of using >>> that datatype, I couldn?t encode more than 6 slurs in a measure. >>> Now I switched over to encode slurs with @tstamp and duration or @startid >>> and @endid. >>> To encode beams, I always use the <beam>/<beamSpan>, and I think I >>> wouldn?t miss the i/m/t 1-6! >>> Best, >>> >>> Maja >>> >>> >>> -------- Original-Nachricht -------- >>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200 >>>> Von: Johannes Kepper <kepper at edirom.de> >>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> >>>> Betreff: [MEI-L] datatype [imt][1-6] >>> >>>> Dear MEI-L, >>>> >>>> this is a somewhat technical question that I still would like to ask all >>>> of you, although it's particularly interesting to hear developer's >>>> opinions. >>>> >>>> MEI offers several attributes with a datatype of [imt][1-6], that is one >>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to >>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature >>>> which may >>>> overlap. The number distinguishes between those overlapping occurences. >>>> For >>>> instance a >>>> >>>> <note beam="i1"> >>>> >>>> indicates the beginning of a beam. If a second, independent beam would >>>> start before the first ends, it would be start with a value of "i2". If >>>> it >>>> would start after the end of the first one, it would reuse the "i1" >>>> value. >>>> Trying to clarify such details in the Guidelines, Perry and me are >>>> wondering >>>> if this behaviour is particularly comprehensible, or if we should take >>>> this >>>> feature away completely. You may encode beams using either the <beam> or >>>> <beamSpan> element, the first one being extremely comfortable, the >>>> second >>>> extremely flexible. Besides beams, the same datatype is available for >>>> tuplets >>>> and slurs, which also offer other encoding possibilities. Is anyone >>>> actually using the functionality of this datatype, or do you have strong >>>> opinions >>>> for other reasons? >>>> >>>> It would be great if we could get some feedback in the next couple of >>>> days >>>> in order to make a decision about this soon. >>>> >>>> Thanks very much, >>>> Perry and 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 >> >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Sat Jul 7 12:07:02 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sat, 7 Jul 2012 11:07:02 +0100 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <0B19E3D8-4529-439C-BA8D-CCF33104E542@edirom.de> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> <0B19E3D8-4529-439C-BA8D-CCF33104E542@edirom.de> Message-ID: <CAMyHAnN6ZQ07YWzbwibkbYRGRjLvJb43Q6pRg4psuh3q-+ixmw@mail.gmail.com> Hello, On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de> wrote: > > > Basically, this change would mean that we drop the possibility for a > one-pass encoding here and require a second pass. That's certainly a > drawback A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) . I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me. Best, Raffaele > . > > Thanks again, and still listening to other opinions, > Johannes > > > > Am 06.07.2012 um 23:17 schrieb TW: > > > I agree with this, as well. I never felt comfortable with this kind > > of beam/slur indication as it scatters information about a single > > object over several others, and the object itself doesn't even exist > > as an entity of its own. @beam/@slur attributes would make sense to > > me if they were plists/idrefs pointing to the beam/beamSpan/slur > > element they belong to. > > > > For lyrics however, i|m|t totally convinces me as it indicates the > > relationship between different entities. > > > > Thomas > > > > > > 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>: > >> Dear all, > >> > >> In general, I would agree with both of Andrew's points: > >> - get rid of the datatype for beam and other "spanners" like slurs and > >> tuplets (and the related attributes); > >> - keep i/m/t for wordpos (can't think of any other places where this > could > >> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t > might > >> be worth keeping. > >> > >> Best, > >> Raffaele > >> > >> > >> > >> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> > wrote: > >>> > >>> Dear Johannes and Perry! > >>> > >>> Actually I used this datatype, but never for encoding beams, rather for > >>> slurs, though my understanding was a different one. > >>> I used the "i1" for the first slur in a measure, "i2" for the second > one > >>> also when the first beam ended before. > >>> So I didn?t use the "i1" twice in one measure, because I think that > would > >>> be confusing to get the appropriate "i?s" and "t?s" together. > >>> I was always wondering about the limit of 1-6, because in my way of > using > >>> that datatype, I couldn?t encode more than 6 slurs in a measure. > >>> Now I switched over to encode slurs with @tstamp and duration or > @startid > >>> and @endid. > >>> To encode beams, I always use the <beam>/<beamSpan>, and I think I > >>> wouldn?t miss the i/m/t 1-6! > >>> Best, > >>> > >>> Maja > >>> > >>> > >>> -------- Original-Nachricht -------- > >>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200 > >>>> Von: Johannes Kepper <kepper at edirom.de> > >>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > >>>> Betreff: [MEI-L] datatype [imt][1-6] > >>> > >>>> Dear MEI-L, > >>>> > >>>> this is a somewhat technical question that I still would like to ask > all > >>>> of you, although it's particularly interesting to hear developer's > >>>> opinions. > >>>> > >>>> MEI offers several attributes with a datatype of [imt][1-6], that is > one > >>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to > >>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature > >>>> which may > >>>> overlap. The number distinguishes between those overlapping > occurences. > >>>> For > >>>> instance a > >>>> > >>>> <note beam="i1"> > >>>> > >>>> indicates the beginning of a beam. If a second, independent beam would > >>>> start before the first ends, it would be start with a value of "i2". > If > >>>> it > >>>> would start after the end of the first one, it would reuse the "i1" > >>>> value. > >>>> Trying to clarify such details in the Guidelines, Perry and me are > >>>> wondering > >>>> if this behaviour is particularly comprehensible, or if we should take > >>>> this > >>>> feature away completely. You may encode beams using either the <beam> > or > >>>> <beamSpan> element, the first one being extremely comfortable, the > >>>> second > >>>> extremely flexible. Besides beams, the same datatype is available for > >>>> tuplets > >>>> and slurs, which also offer other encoding possibilities. Is anyone > >>>> actually using the functionality of this datatype, or do you have > strong > >>>> opinions > >>>> for other reasons? > >>>> > >>>> It would be great if we could get some feedback in the next couple of > >>>> days > >>>> in order to make a decision about this soon. > >>>> > >>>> Thanks very much, > >>>> Perry and 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 > >> > >> > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/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/20120707/d88ff22a/attachment.html> From pdr4h at eservices.virginia.edu Sat Jul 7 12:38:42 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Sat, 7 Jul 2012 10:38:42 +0000 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <CAMyHAnN6ZQ07YWzbwibkbYRGRjLvJb43Q6pRg4psuh3q-+ixmw@mail.gmail.com> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> <0B19E3D8-4529-439C-BA8D-CCF33104E542@edirom.de>, <CAMyHAnN6ZQ07YWzbwibkbYRGRjLvJb43Q6pRg4psuh3q-+ixmw@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0118DDB8@GRANT.eservices.virginia.edu> Raffaele, In this context "one pass encoding" means capturing all information available at any given point in the encoding at one time. For example, while you're on a given note, it means capturing info about any ties, slurs, beams, etc. that start on that note. MEI accomplishes this primarily with attributes; that is, @beam, @slur, @tie. "Two pass encoding" means capturing the note information first and the beam, tie, and slur data later, relating the second pass to the first, of course. This method results in note, chord, etc. elements followed later by tie, slur, etc. elements with @tstamp or @startid attributes. The beam element is slightly anomalous in that it encloses notes, but it's really part of the one-pass method. It's difficult to treat other things, like slur, tie, etc. that might overlap each other the same way as beams. And even for beams, when overlapping occurs one must switch to beamSpan. I still believe one-pass encoding has a place in MEI, at least until any hand encoding (meaning editing of the MEI file in a non-graphical environment) is no longer necessary. However, these attributes should certainly be better documented and perhaps moved to a separate module instead of being eliminated altogether. We could even go so far as to define them as unacceptable in "canonical" MEI as long as we provide conversion from the attribute method to the element method. In addition to their usefulness in hand-coding, these attributes are helpful when transforming data already in a one-pass-oriented form, such as MuseData and to some extent MusicXML, to MEI. I agree that keeping @tie while eliminating the other "one-pass attributes" is inconsistent. This is another reason for not getting rid of @slur, etc. entirely. When hand-coding is no longer necessary, then @slur, etc. including @tie can go away, but I don't think we're completely there yet. Just my two cents, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] Sent: Saturday, July 07, 2012 6:07 AM To: Music Encoding Initiative Subject: Re: [MEI-L] datatype [imt][1-6] Hello, On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> wrote: Basically, this change would mean that we drop the possibility for a one-pass encoding here and require a second pass. That's certainly a drawback A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) . I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me. Best, Raffaele . Thanks again, and still listening to other opinions, Johannes Am 06.07.2012 um 23:17 schrieb TW: > I agree with this, as well. I never felt comfortable with this kind > of beam/slur indication as it scatters information about a single > object over several others, and the object itself doesn't even exist > as an entity of its own. @beam/@slur attributes would make sense to > me if they were plists/idrefs pointing to the beam/beamSpan/slur > element they belong to. > > For lyrics however, i|m|t totally convinces me as it indicates the > relationship between different entities. > > Thomas > > > 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com<mailto:raffaeleviglianti at gmail.com>>: >> Dear all, >> >> In general, I would agree with both of Andrew's points: >> - get rid of the datatype for beam and other "spanners" like slurs and >> tuplets (and the related attributes); >> - keep i/m/t for wordpos (can't think of any other places where this could >> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might >> be worth keeping. >> >> Best, >> Raffaele >> >> >> >> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de<mailto:Maja.Hartwig at gmx.de>> wrote: >>> >>> Dear Johannes and Perry! >>> >>> Actually I used this datatype, but never for encoding beams, rather for >>> slurs, though my understanding was a different one. >>> I used the "i1" for the first slur in a measure, "i2" for the second one >>> also when the first beam ended before. >>> So I didn?t use the "i1" twice in one measure, because I think that would >>> be confusing to get the appropriate "i?s" and "t?s" together. >>> I was always wondering about the limit of 1-6, because in my way of using >>> that datatype, I couldn?t encode more than 6 slurs in a measure. >>> Now I switched over to encode slurs with @tstamp and duration or @startid >>> and @endid. >>> To encode beams, I always use the <beam>/<beamSpan>, and I think I >>> wouldn?t miss the i/m/t 1-6! >>> Best, >>> >>> Maja >>> >>> >>> -------- Original-Nachricht -------- >>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200 >>>> Von: Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> >>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>> >>>> Betreff: [MEI-L] datatype [imt][1-6] >>> >>>> Dear MEI-L, >>>> >>>> this is a somewhat technical question that I still would like to ask all >>>> of you, although it's particularly interesting to hear developer's >>>> opinions. >>>> >>>> MEI offers several attributes with a datatype of [imt][1-6], that is one >>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to >>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature >>>> which may >>>> overlap. The number distinguishes between those overlapping occurences. >>>> For >>>> instance a >>>> >>>> <note beam="i1"> >>>> >>>> indicates the beginning of a beam. If a second, independent beam would >>>> start before the first ends, it would be start with a value of "i2". If >>>> it >>>> would start after the end of the first one, it would reuse the "i1" >>>> value. >>>> Trying to clarify such details in the Guidelines, Perry and me are >>>> wondering >>>> if this behaviour is particularly comprehensible, or if we should take >>>> this >>>> feature away completely. You may encode beams using either the <beam> or >>>> <beamSpan> element, the first one being extremely comfortable, the >>>> second >>>> extremely flexible. Besides beams, the same datatype is available for >>>> tuplets >>>> and slurs, which also offer other encoding possibilities. Is anyone >>>> actually using the functionality of this datatype, or do you have strong >>>> opinions >>>> for other reasons? >>>> >>>> It would be great if we could get some feedback in the next couple of >>>> days >>>> in order to make a decision about this soon. >>>> >>>> Thanks very much, >>>> Perry and Johannes >>>> _______________________________________________ >>>> 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 _______________________________________________ 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/20120707/6d0606dd/attachment.html> From kepper at edirom.de Sun Jul 8 00:39:02 2012 From: kepper at edirom.de (Johannes Kepper) Date: Sun, 8 Jul 2012 00:39:02 +0200 Subject: [MEI-L] datatype [imt][1-6] In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0118DDB8@GRANT.eservices.virginia.edu> References: <D6F26033-7EAE-4C8B-9BA5-475EFAA0F10F@edirom.de> <20120706164804.181210@gmx.net> <CAMyHAnOiob_Le17_dr27UWsouY8q+dHh_8HxDuTCMP4KMnRYqg@mail.gmail.com> <CAEB1mAptk9Sxg=-Qgg5pdxCGDeqQQ8NRERm4dLJNwFe0-KGdgg@mail.gmail.com> <0B19E3D8-4529-439C-BA8D-CCF33104E542@edirom.de>, <CAMyHAnN6ZQ07YWzbwibkbYRGRjLvJb43Q6pRg4psuh3q-+ixmw@mail.gmail.com> <BBCC497C40D85642B90E9F94FC30343D0118DDB8@GRANT.eservices.virginia.edu> Message-ID: <033AAAD5-891C-4BB2-B8CE-9940828AFD4F@edirom.de> comments inline? Am 07.07.2012 um 12:38 schrieb Roland, Perry (pdr4h): > Raffaele, > > In this context "one pass encoding" means capturing all information available at any given point in the encoding at one time. For example, while you're on a given note, it means capturing info about any ties, slurs, beams, etc. that start on that note. MEI accomplishes this primarily with attributes; that is, @beam, @slur, @tie. > > "Two pass encoding" means capturing the note information first and the beam, tie, and slur data later, relating the second pass to the first, of course. This method results in note, chord, etc. elements followed later by tie, slur, etc. elements with @tstamp or @startid attributes. > > The beam element is slightly anomalous in that it encloses notes, but it's really part of the one-pass method. It's difficult to treat other things, like slur, tie, etc. that might overlap each other the same way as beams. And even for beams, when overlapping occurs one must switch to beamSpan. > > I still believe one-pass encoding has a place in MEI, at least until any hand encoding (meaning editing of the MEI file in a non-graphical environment) is no longer necessary. However, these attributes should certainly be better documented and perhaps moved to a separate module instead of being eliminated altogether. We could even go so far as to define them as unacceptable in "canonical" MEI as long as we provide conversion from the attribute method to the element method. In addition to their usefulness in hand-coding, these attributes are helpful when transforming data already in a one-pass-oriented form, such as MuseData and to some extent MusicXML, to MEI. > > I agree that keeping @tie while eliminating the other "one-pass attributes" is inconsistent. This is another reason for not getting rid of @slur, etc. entirely. It would be inconsistent if our aim would be to eliminate all one-pass solutions, which is not the case. We're trying to solve an apparent problem arising from a certain datatype. It's just a side-effect that this means we loose a one-pass on these things. If we'd know an unambiguous one-pass, we'd certainly implement that one instead (suggestions welcome?). > > When hand-coding is no longer necessary, then @slur, etc. including @tie can go away, but I don't think we're completely there yet. > Dropping all mentioned one-passes shouldn't be our goal at any time. MEI aims at people who should really care about their data, meaning they should know about MEI good enough to be able to check what applications do for them. Not everyone will encode by hand, but that's certainly a possibility we don't want to loose at any time! I'm not arguing to throw away these attributes without further notice, I just want to get them "out of the way" to prevent future confusion about how to use them, which will eventually result in confusion on how to interpret MEI files using them. There is still sufficiently little use of MEI to do such changes right now, but that's certainly a closing time slot? > Just my two cents, > > -- > p. > > and my two euro-cents, jo > > __________________________ > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Raffaele Viglianti [raffaeleviglianti at gmail.com] > Sent: Saturday, July 07, 2012 6:07 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] datatype [imt][1-6] > > Hello, > > On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de> wrote: > > Basically, this change would mean that we drop the possibility for a one-pass encoding here and require a second pass. That's certainly a drawback > > A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) . > > I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me. > > Best, > Raffaele > > . > > Thanks again, and still listening to other opinions, > Johannes > > > > Am 06.07.2012 um 23:17 schrieb TW: > > > I agree with this, as well. I never felt comfortable with this kind > > of beam/slur indication as it scatters information about a single > > object over several others, and the object itself doesn't even exist > > as an entity of its own. @beam/@slur attributes would make sense to > > me if they were plists/idrefs pointing to the beam/beamSpan/slur > > element they belong to. > > > > For lyrics however, i|m|t totally convinces me as it indicates the > > relationship between different entities. > > > > Thomas > > > > > > 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com>: > >> Dear all, > >> > >> In general, I would agree with both of Andrew's points: > >> - get rid of the datatype for beam and other "spanners" like slurs and > >> tuplets (and the related attributes); > >> - keep i/m/t for wordpos (can't think of any other places where this could > >> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might > >> be worth keeping. > >> > >> Best, > >> Raffaele > >> > >> > >> > >> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de> wrote: > >>> > >>> Dear Johannes and Perry! > >>> > >>> Actually I used this datatype, but never for encoding beams, rather for > >>> slurs, though my understanding was a different one. > >>> I used the "i1" for the first slur in a measure, "i2" for the second one > >>> also when the first beam ended before. > >>> So I didn?t use the "i1" twice in one measure, because I think that would > >>> be confusing to get the appropriate "i?s" and "t?s" together. > >>> I was always wondering about the limit of 1-6, because in my way of using > >>> that datatype, I couldn?t encode more than 6 slurs in a measure. > >>> Now I switched over to encode slurs with @tstamp and duration or @startid > >>> and @endid. > >>> To encode beams, I always use the <beam>/<beamSpan>, and I think I > >>> wouldn?t miss the i/m/t 1-6! > >>> Best, > >>> > >>> Maja > >>> > >>> > >>> -------- Original-Nachricht -------- > >>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200 > >>>> Von: Johannes Kepper <kepper at edirom.de> > >>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de> > >>>> Betreff: [MEI-L] datatype [imt][1-6] > >>> > >>>> Dear MEI-L, > >>>> > >>>> this is a somewhat technical question that I still would like to ask all > >>>> of you, although it's particularly interesting to hear developer's > >>>> opinions. > >>>> > >>>> MEI offers several attributes with a datatype of [imt][1-6], that is one > >>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to > >>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature > >>>> which may > >>>> overlap. The number distinguishes between those overlapping occurences. > >>>> For > >>>> instance a > >>>> > >>>> <note beam="i1"> > >>>> > >>>> indicates the beginning of a beam. If a second, independent beam would > >>>> start before the first ends, it would be start with a value of "i2". If > >>>> it > >>>> would start after the end of the first one, it would reuse the "i1" > >>>> value. > >>>> Trying to clarify such details in the Guidelines, Perry and me are > >>>> wondering > >>>> if this behaviour is particularly comprehensible, or if we should take > >>>> this > >>>> feature away completely. You may encode beams using either the <beam> or > >>>> <beamSpan> element, the first one being extremely comfortable, the > >>>> second > >>>> extremely flexible. Besides beams, the same datatype is available for > >>>> tuplets > >>>> and slurs, which also offer other encoding possibilities. Is anyone > >>>> actually using the functionality of this datatype, or do you have strong > >>>> opinions > >>>> for other reasons? > >>>> > >>>> It would be great if we could get some feedback in the next couple of > >>>> days > >>>> in order to make a decision about this soon. > >>>> > >>>> Thanks very much, > >>>> Perry and 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 > >> > >> > >> > >> _______________________________________________ > >> mei-l mailing list > >> mei-l at lists.uni-paderborn.de > >> https://lists.uni-paderborn.de/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 zupftom at googlemail.com Sun Jul 15 08:24:58 2012 From: zupftom at googlemail.com (TW) Date: Sun, 15 Jul 2012 08:24:58 +0200 Subject: [MEI-L] More "precise" <app>s Message-ID: <CAEB1mAp2P2Lh4mCNpmwJs86TMpfbUnZ8mtCsrsTzHxAO67JMoA@mail.gmail.com> Dear MEI family, how does one encode variant readings that only affect a certain "strand" of events? For example, if we have a full orchestral score where there are different readings of the flute's measures 1 and 2, I see the following options: 1a) One big <app> around measure 1 and 2, containing all staffs twice, like so: <app> <rdg> <measure n="1"> <staff n="1">  </staff> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> <measure n="2"> <staff n="1">  </staff> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> </rdg> <rdg> <measure n="1"> <staff n="1">  </staff> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> <measure n="2"> <staff n="1">  </staff> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> </rdg> </app> This already seems like overkill, although I didn't even fill the staffs with music. And facing such a monster, you'd have to look very closely to spot the actual variant readings, so this is certainly not the way to go. 1b) To avoid filling the staffs twice, one could of course use @copyof the second time. But this might break ID references. 2) Split this in two <app>s, like so: <measure n="1"> <app> <rdg> <staff n="1">  </staff> </rdg> <rdg> <staff n="1">  </staff> </rdg> </app> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> <measure n="2"> <app> <rdg> <staff n="1">  </staff> </rdg> <rdg> <staff n="1">  </staff> </rdg> </app> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> This looks preferable to me, especially because it allows "overlapping" variants, e.g. when there is another phrase with variant readings, but this time for the basses from measure 2 to 3. Unfortunately, I don't see a really good way to indicate that any two or more <app> elements form a logical unit. I think that the att.common.anl family of attributes might be useful for this, especially the @prev and @next attributes because they imply the concept of a "collection". The next best solution might be to use @prev and @next on the contained <lem> and <rdg> elements, but providing them on <app> would make things much clearer and easier. Therefore, shouldn't att.common.anl be allowed on <app>? Thomas From andrew.hankinson at mail.mcgill.ca Sun Jul 15 14:53:04 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Sun, 15 Jul 2012 12:53:04 +0000 Subject: [MEI-L] More "precise" <app>s In-Reply-To: <19585_1342333512_50026248_19585_2490_1_CAEB1mAp2P2Lh4mCNpmwJs86TMpfbUnZ8mtCsrsTzHxAO67JMoA@mail.gmail.com> References: <19585_1342333512_50026248_19585_2490_1_CAEB1mAp2P2Lh4mCNpmwJs86TMpfbUnZ8mtCsrsTzHxAO67JMoA@mail.gmail.com> Message-ID: <CC3E1EAB6662EA4A95FC6E498314808B10B6497D@EXMBX2010-5.campus.MCGILL.CA> Hi Thomas, I think you're looking for @source on <rdg>. <meiHead> .... <sourceDesc> <source xml:id="sourceA"> <pubStmt/> </source> <source xml:id="sourceB"> <pubStmt/> </source> </sourceDesc> .... </meiHead> ... <measure n="1"> <app> <rdg source="sourceA"> <staff n="1">  </staff> </rdg> <rdg source="sourceB"> <staff n="1">  </staff> </rdg> </app> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> <measure n="2"> <app> <rdg source="sourceA"> <staff n="1">  </staff> </rdg> <rdg source="sourceB"> <staff n="1">  </staff> </rdg> </app> <staff n="2"/> <staff n="3"/> <staff n="4"/> <staff n="5"/> <staff n="6"/> <staff n="7"/> <staff n="8"/> <staff n="9"/> <staff n="10"/> </measure> @source can take a space-delimited list of xml:ids too. -Andrew On 2012-07-15, at 2:24 AM, TW wrote: > Dear MEI family, > > how does one encode variant readings that only affect a certain > "strand" of events? For example, if we have a full orchestral score > where there are different readings of the flute's measures 1 and 2, I > see the following options: > 1a) One big <app> around measure 1 and 2, containing all staffs twice, like so: > <app> > <rdg> > <measure n="1"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > </rdg> > <rdg> > <measure n="1"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > </rdg> > </app> > This already seems like overkill, although I didn't even fill the > staffs with music. And facing such a monster, you'd have to look very > closely to spot the actual variant readings, so this is certainly not > the way to go. > > 1b) To avoid filling the staffs twice, one could of course use @copyof > the second time. But this might break ID references. > > 2) Split this in two <app>s, like so: > <measure n="1"> > <app> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <app> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > This looks preferable to me, especially because it allows > "overlapping" variants, e.g. when there is another phrase with variant > readings, but this time for the basses from measure 2 to 3. > Unfortunately, I don't see a really good way to indicate that any two > or more <app> elements form a logical unit. I think that the > att.common.anl family of attributes might be useful for this, > especially the @prev and @next attributes because they imply the > concept of a "collection". The next best solution might be to use > @prev and @next on the contained <lem> and <rdg> elements, but > providing them on <app> would make things much clearer and easier. > > Therefore, shouldn't att.common.anl be allowed on <app>? > > Thomas > > _______________________________________________ > 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/20120715/9c785e5d/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1054 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120715/9c785e5d/attachment.bin> From raffaeleviglianti at gmail.com Sun Jul 15 16:17:41 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Sun, 15 Jul 2012 15:17:41 +0100 Subject: [MEI-L] More "precise" <app>s In-Reply-To: <CC3E1EAB6662EA4A95FC6E498314808B10B6497D@EXMBX2010-5.campus.MCGILL.CA> References: <19585_1342333512_50026248_19585_2490_1_CAEB1mAp2P2Lh4mCNpmwJs86TMpfbUnZ8mtCsrsTzHxAO67JMoA@mail.gmail.com> <CC3E1EAB6662EA4A95FC6E498314808B10B6497D@EXMBX2010-5.campus.MCGILL.CA> Message-ID: <CAMyHAnOJX9R-G8rWUN8G5pUHMUc1ahUqTXN-QJbd5-k1gqOxvw@mail.gmail.com> Hello, As Andrew said, @source helps, as it expresses the fact that both readings are from one source. Though if I understand Thomas' issue correctly, he's also interested in encoding the fact that the two apps can form one apparatus entry. Imagine for example an apparatus entry that says: Measures 1-2; System: Flutes; Comment: values of rests are incorrect in source A; source B has correct values. This can be split in two apps, like in the example that Andrew wrote. However, using only @source wouldn't reflect the fact that the two apps are part of one editorial statement. A use case for using @prev and @next would be to be able to generate the apparatus entry above from the encoding (I have seen this done in TEI). I don't think it's particularly urgent, but I can definitely see value in having @prev and @next on app. At least it would compensates for the fact that one app can contain several staves in one measure at once, but not multiple measures in one staff. Best, Raffaele On Sun, Jul 15, 2012 at 1:53 PM, Andrew Hankinson, Mr < andrew.hankinson at mail.mcgill.ca> wrote: > Hi Thomas, > > I think you're looking for @source on <rdg>. > > <meiHead> > .... > <sourceDesc> > <source xml:id="sourceA"> > <pubStmt/> > </source> > <source xml:id="sourceB"> > <pubStmt/> > </source> > </sourceDesc> > .... > </meiHead> > ... > <measure n="1"> > <app> > <rdg source="sourceA"> > > <staff n="1"> >  > </staff> > </rdg> > <rdg source="sourceB"> > > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <app> > <rdg source="sourceA"> > > <staff n="1"> >  > </staff> > </rdg> > <rdg source="sourceB"> > > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > > @source can take a space-delimited list of xml:ids too. > > -Andrew > > On 2012-07-15, at 2:24 AM, TW wrote: > > Dear MEI family, > > how does one encode variant readings that only affect a certain > "strand" of events? For example, if we have a full orchestral score > where there are different readings of the flute's measures 1 and 2, I > see the following options: > 1a) One big <app> around measure 1 and 2, containing all staffs twice, > like so: > <app> > <rdg> > <measure n="1"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > </rdg> > <rdg> > <measure n="1"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <staff n="1"> >  > </staff> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > </rdg> > </app> > This already seems like overkill, although I didn't even fill the > staffs with music. And facing such a monster, you'd have to look very > closely to spot the actual variant readings, so this is certainly not > the way to go. > > 1b) To avoid filling the staffs twice, one could of course use @copyof > the second time. But this might break ID references. > > 2) Split this in two <app>s, like so: > <measure n="1"> > <app> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > <measure n="2"> > <app> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > <rdg> > <staff n="1"> >  > </staff> > </rdg> > </app> > <staff n="2"/> > <staff n="3"/> > <staff n="4"/> > <staff n="5"/> > <staff n="6"/> > <staff n="7"/> > <staff n="8"/> > <staff n="9"/> > <staff n="10"/> > </measure> > This looks preferable to me, especially because it allows > "overlapping" variants, e.g. when there is another phrase with variant > readings, but this time for the basses from measure 2 to 3. > Unfortunately, I don't see a really good way to indicate that any two > or more <app> elements form a logical unit. I think that the > att.common.anl family of attributes might be useful for this, > especially the @prev and @next attributes because they imply the > concept of a "collection". The next best solution might be to use > @prev and @next on the contained <lem> and <rdg> elements, but > providing them on <app> would make things much clearer and easier. > > Therefore, shouldn't att.common.anl be allowed on <app>? > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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/20120715/570147fc/attachment.html> From zupftom at googlemail.com Sun Jul 15 21:27:27 2012 From: zupftom at googlemail.com (TW) Date: Sun, 15 Jul 2012 21:27:27 +0200 Subject: [MEI-L] More "precise" <app>s In-Reply-To: <CAMyHAnOJX9R-G8rWUN8G5pUHMUc1ahUqTXN-QJbd5-k1gqOxvw@mail.gmail.com> References: <19585_1342333512_50026248_19585_2490_1_CAEB1mAp2P2Lh4mCNpmwJs86TMpfbUnZ8mtCsrsTzHxAO67JMoA@mail.gmail.com> <CC3E1EAB6662EA4A95FC6E498314808B10B6497D@EXMBX2010-5.campus.MCGILL.CA> <CAMyHAnOJX9R-G8rWUN8G5pUHMUc1ahUqTXN-QJbd5-k1gqOxvw@mail.gmail.com> Message-ID: <CAEB1mAqKKV-xNeVtszvR_6yX8P9FCwGxfRmR4Oun_qMyPGzo0w@mail.gmail.com> Hi Raphaele, 2012/7/15 Raffaele Viglianti <raffaeleviglianti at gmail.com>: > Though if I understand Thomas' issue correctly, he's also interested in > encoding the fact that the two apps can form one apparatus entry. > Exactly. > > A use case for using @prev and @next would be to be able to generate the > apparatus entry above from the encoding (I have seen this done in TEI). > Thanks for the hint. I see that TEI's <app> (and also <choice>) indeed have @next and @prev. I think I'll create a feature request issue. And yes, I'm thinking about the automatic generation of apparatus entries. It would be messy to have things chopped up in multiple entries that actually are logically one entry (like one entry for measure 1 and a second one for measure two of the flute, although they form one melodic phrase together). It would be equally messy to get one huge entry that contains a lot of "noise" (like a two measure <app> that presents the whole orchestra, although only the flute varies). Wish you a good start into the week ahead Thomas From lxpugin at gmail.com Mon Jul 16 14:58:43 2012 From: lxpugin at gmail.com (Laurent Pugin) Date: Mon, 16 Jul 2012 14:58:43 +0200 Subject: [MEI-L] SVG Message-ID: <CAJ306HYs1bD4Y6TKXwoTUeP=mCy46tstmThdiDTvcdq=dPpRNQ@mail.gmail.com> Hi, I am looking for a way to include a SVG figure in the /workDesc/work/incip element in the header. The <graphic> element does not seem to be usable for this. Am I wrong? Is there a workaround to do it without using a customization? Thanks, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120716/157b1d02/attachment.html> From pdr4h at eservices.virginia.edu Mon Jul 16 15:21:07 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 16 Jul 2012 13:21:07 +0000 Subject: [MEI-L] SVG In-Reply-To: <CAJ306HYs1bD4Y6TKXwoTUeP=mCy46tstmThdiDTvcdq=dPpRNQ@mail.gmail.com> References: <CAJ306HYs1bD4Y6TKXwoTUeP=mCy46tstmThdiDTvcdq=dPpRNQ@mail.gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF61CE4@GRANT.eservices.virginia.edu> Laurent, Currently, there's no way to do it without a customization. But, there's an open issue (#53) regarding SVG and other XML markup in MEI. Any comments you have on the topic would be greatly appreciated. Can you add them to the issue please, so we don't forget? -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [lxpugin at gmail.com] Sent: Monday, July 16, 2012 8:58 AM To: MEI-list Subject: [MEI-L] SVG Hi, I am looking for a way to include a SVG figure in the /workDesc/work/incip element in the header. The <graphic> element does not seem to be usable for this. Am I wrong? Is there a workaround to do it without using a customization? Thanks, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120716/45d29f87/attachment.html> From pdr4h at eservices.virginia.edu Wed Jul 18 22:24:43 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 18 Jul 2012 20:24:43 +0000 Subject: [MEI-L] MEI workshop at 2012 AMS meeting Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF63381@GRANT.eservices.virginia.edu> Hello, everyone, Please pardon any duplicate posts and forward liberally. :-) "Introduction to MEI," an intensive, hands-on workshop, will be offered Wednesday, 31 October from 9:00 a.m. to 5:30 p.m. Experts from the Music Encoding Initiative Council will teach the workshop, during which participants will learn about MEI history and design principles, tools for creating, editing, and rendering MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and opportunities to address participant-specific issues. There are no fees associated with this workshop and no previous experience with MEI or XML is required; however, an understanding of music notation and other markup schemes, such as HTML and TEI, will be helpful. Participants are encouraged to bring a laptop computer for hands-on exercises. The number of participants is limited to 25. Register early at http://tinyurl.com/2012meiWorkshopAMS. Registration for the AMS meeting is not required. Please address questions to info at music-encoding.org. -- 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 pdr4h at eservices.virginia.edu Wed Jul 18 22:48:24 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 18 Jul 2012 20:48:24 +0000 Subject: [MEI-L] MEI workshop at 2012 AMS meeting In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0EF63381@GRANT.eservices.virginia.edu> References: <BBCC497C40D85642B90E9F94FC30343D0EF63381@GRANT.eservices.virginia.edu> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF633BA@GRANT.eservices.virginia.edu> Hello again, Sorry, the URL I sent before points to the administrative page. http://tinyurl.com/2012MEIAMS points to the registration form. Sorry for the confusion, -- 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: Roland, Perry (pdr4h) Sent: Wednesday, July 18, 2012 4:24 PM To: mei-l at lists.uni-paderborn.de Subject: MEI workshop at 2012 AMS meeting Hello, everyone, Please pardon any duplicate posts and forward liberally. :-) "Introduction to MEI," an intensive, hands-on workshop, will be offered Wednesday, 31 October from 9:00 a.m. to 5:30 p.m. Experts from the Music Encoding Initiative Council will teach the workshop, during which participants will learn about MEI history and design principles, tools for creating, editing, and rendering MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and opportunities to address participant-specific issues. There are no fees associated with this workshop and no previous experience with MEI or XML is required; however, an understanding of music notation and other markup schemes, such as HTML and TEI, will be helpful. Participants are encouraged to bring a laptop computer for hands-on exercises. The number of participants is limited to 25. Register early at http://tinyurl.com/2012meiWorkshopAMS. Registration for the AMS meeting is not required. Please address questions to info at music-encoding.org. -- 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 bohl at edirom.de Mon Jul 23 09:13:46 2012 From: bohl at edirom.de (=?utf-8?B?QmVuamFtaW4gVy4gQm9obA==?=) Date: Mon, 23 Jul 2012 09:13:46 +0200 Subject: [MEI-L] =?utf-8?b?QW50dy46ICBNb3JlICJwcmVjaXNlIiA8YXBwPnM=?= Message-ID: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> Hi evbdy! Discussing the lacking possibility to aggregate multiple app elements by means of an attribute, which could be very handy indeed, I'd like to put into consideration that @prev and @next imply an order. This might exactly be what One is looking for, especially when thinking of genetic editions, but something like @corresp might be more applicable in other situations. Cheers, Benjamin ----- Reply message ----- Von: "TW" <zupftom at googlemail.com> An: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Betreff: [MEI-L] More "precise" <app>s Datum: So., Jul. 15, 2012 21:27 Hi Raphaele, 2012/7/15 Raffaele Viglianti <raffaeleviglianti at gmail.com>: > Though if I understand Thomas' issue correctly, he's also interested in > encoding the fact that the two apps can form one apparatus entry. > Exactly. > > A use case for using @prev and @next would be to be able to generate the > apparatus entry above from the encoding (I have seen this done in TEI). > Thanks for the hint. I see that TEI's <app> (and also <choice>) indeed have @next and @prev. I think I'll create a feature request issue. And yes, I'm thinking about the automatic generation of apparatus entries. It would be messy to have things chopped up in multiple entries that actually are logically one entry (like one entry for measure 1 and a second one for measure two of the flute, although they form one melodic phrase together). It would be equally messy to get one huge entry that contains a lot of "noise" (like a two measure <app> that presents the whole orchestra, although only the flute varies). Wish you a good start into the week ahead Thomas _______________________________________________ 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: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120723/c9fac796/attachment.html> From zupftom at googlemail.com Mon Jul 23 13:14:37 2012 From: zupftom at googlemail.com (TW) Date: Mon, 23 Jul 2012 13:14:37 +0200 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> Message-ID: <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>: > Hi evbdy! > Discussing the lacking possibility to aggregate multiple app elements by > means of an attribute, which could be very handy indeed, I'd like to put > into consideration that @prev and @next imply an order. This might exactly > be what One is looking for, especially when thinking of genetic editions, > but something like @corresp might be more applicable in other situations. > @corresp would be covered by my suggestion to allow att.common.anl on <app> and <choice>. However, @corresp always felt a bit vague to me. I guess it could legitimately be used to point to an independent <app> element, meaning something like "Look, this is the same *kind* of difference" rather than "This belongs to one virtual entity that has been split because we can't break the hierarchy". @prev and @next are a bit more definite, implying a "user-defined collection". @sameas (also in att.common.anl) "sounds" like the most precise way of saying everything belongs to the same logical <app>, but I see that this meaning would be inconsistent with other uses of @sameas. Other options I can think of: - Having @plist on a "master" <app>, pointing to the subordinate <app>s. This is very clear, but it's rather arbitrary what becomes the master <app>. At first sight, a subordinate <app> can not be distinguished from a standalone <app>. - Some kind of stand-off markup? In any case, I think having att.common.anl would already be a really useful improvement. Thomas From kepper at edirom.de Tue Jul 24 11:30:05 2012 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 24 Jul 2012 11:30:05 +0200 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> Message-ID: <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> Hi all, as others have argued before, I don't like @next / @prev on <app>. It seems like there is no order of differences between sources. There is only a list of differences, which might be ordered following some criteria, but there is no natural order of variants. Using @next to indicate that a separate <app> deals with the _same_ situation seems absolutely awkward. @sameas would require an inconsistent usage, as Thomas already pointed out. @corresp is a generic attribute that should be left open for analytical purposes. If we give it a specific meaning on <app>, we're adding another exception to MEI (the otherwise generic @label has a specific meaning on <staffDef> already?). For me, this situation is another argument to a feature request I've been talking about quite a while. In my opinion, MEI will need a generic <grp> (group) element to address issues like this. This new element would have a @plist to point to a set of other elements which are to be regarded as one conceptual unit for some reason. A hint to this reason could be provided using @type. More specific variations of this element could be used for specific purposes: A <damageGrp> would point to <damage> elements which may spread across all levels of hierarchy etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies on a linear encoding of a base text, which is just interrupted by additional, "strippable" markup. A similar solution seems not possible for MEI. Perry has often argued that <annot> does exactly this: It allows to group a set of other elements using @plist, and to provide additional information about this group using text inside the <annot>. This is definitely an option, and works out of the box with the current schema. However, I think this approach is too generic, especially since it encourages the use of <annot> for each and everything in MEI. Maybe I'm not convinced because <annot> has a very specific meaning for me (which might lead to a feature request for <annotStruct> in the future), but I would like to see a more specific solution for problems like this. Otherwise we would recommend the use of extremely powerful elements. In my eyes, doing so would significantly increase the risk of different encoding styles for the same problem, leading to incompatibility etc. However, I don't see all this for the upcoming release. The problem is definitely more fundamental than just a missing connection between related <app>s, and I would like to avoid rushing into a quick solution too hastily. I would suggest to not add anything to <app> right now, but instead to rely on the existing <annot> for the moment (yes, I still remember my arguments?). This is nothing we're able to cope with for the upcoming release, but it's definitely something we should discuss for the next release (scheduled for 2013). Until then, I'd prefer to live with the existing compromises instead of adding new ones (which we'd have to clean up later?). Just my two cents, Johannes Am 23.07.2012 um 13:14 schrieb TW: > 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>: >> Hi evbdy! >> Discussing the lacking possibility to aggregate multiple app elements by >> means of an attribute, which could be very handy indeed, I'd like to put >> into consideration that @prev and @next imply an order. This might exactly >> be what One is looking for, especially when thinking of genetic editions, >> but something like @corresp might be more applicable in other situations. >> > > @corresp would be covered by my suggestion to allow att.common.anl on > <app> and <choice>. However, @corresp always felt a bit vague to me. > I guess it could legitimately be used to point to an independent <app> > element, meaning something like "Look, this is the same *kind* of > difference" rather than "This belongs to one virtual entity that has > been split because we can't break the hierarchy". @prev and @next are > a bit more definite, implying a "user-defined collection". > > @sameas (also in att.common.anl) "sounds" like the most precise way of > saying everything belongs to the same logical <app>, but I see that > this meaning would be inconsistent with other uses of @sameas. > > Other options I can think of: > - Having @plist on a "master" <app>, pointing to the subordinate > <app>s. This is very clear, but it's rather arbitrary what becomes > the master <app>. At first sight, a subordinate <app> can not be > distinguished from a standalone <app>. > - Some kind of stand-off markup? > > In any case, I think having att.common.anl would already be a really > useful improvement. > > Thomas > > _______________________________________________ > 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 Tue Jul 24 16:35:25 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Tue, 24 Jul 2012 15:35:25 +0100 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> Message-ID: <CAMyHAnPsd=2mLvHzKmMQ=gUZjFEWj=8F5gAw-NQDegHyLy+Eew@mail.gmail.com> Hi Johannes, Thanks for these very insightful comments! I agree with your arguments for a grouping element to help escape hierarchy (given that, one could imagine a stand-off approach to apparatus entries that might be quite interesting to work with). Nonetheless, I still see value in having @next and @prev. On Tue, Jul 24, 2012 at 10:30 AM, Johannes Kepper <kepper at edirom.de> wrote: > I don't like @next / @prev on <app>. It seems like there is no order of > differences between sources. Is the order of sources defined at app level? The @source attribute on rdg should allow you to list your rdgs in whatever order; information in the header dictates the relevance of each source over another. > Using @next to indicate that a separate <app> deals with the _same_ > situation seems absolutely awkward. > Although I can see why using @corresp or @sameas would be wrong, I don't see why using @next is awkward. @prev and @next don't indicate a sequence, but indicate an aggregation, which is what Thomas needed in his example. > For me, this situation is another argument to a feature request I've been > talking about quite a while. In my opinion, MEI will need a generic <grp> > (group) element to address issues like this. [...] A <damageGrp> would > point to <damage> elements which may spread across all levels of hierarchy > etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies > on a linear encoding of a base text, which is just interrupted by > additional, "strippable" markup. A similar solution seems not possible for > MEI. > This is true, and as I've said I like this idea. There still is value to embedded markup, though, particularly for apparatus entries. Still, I can see how it wouldn't work with damage, add, del, etc. in advanced manuscript transcription. Best, Raffaele > > Am 23.07.2012 um 13:14 schrieb TW: > > > 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>: > >> Hi evbdy! > >> Discussing the lacking possibility to aggregate multiple app elements by > >> means of an attribute, which could be very handy indeed, I'd like to put > >> into consideration that @prev and @next imply an order. This might > exactly > >> be what One is looking for, especially when thinking of genetic > editions, > >> but something like @corresp might be more applicable in other > situations. > >> > > > > @corresp would be covered by my suggestion to allow att.common.anl on > > <app> and <choice>. However, @corresp always felt a bit vague to me. > > I guess it could legitimately be used to point to an independent <app> > > element, meaning something like "Look, this is the same *kind* of > > difference" rather than "This belongs to one virtual entity that has > > been split because we can't break the hierarchy". @prev and @next are > > a bit more definite, implying a "user-defined collection". > > > > @sameas (also in att.common.anl) "sounds" like the most precise way of > > saying everything belongs to the same logical <app>, but I see that > > this meaning would be inconsistent with other uses of @sameas. > > > > Other options I can think of: > > - Having @plist on a "master" <app>, pointing to the subordinate > > <app>s. This is very clear, but it's rather arbitrary what becomes > > the master <app>. At first sight, a subordinate <app> can not be > > distinguished from a standalone <app>. > > - Some kind of stand-off markup? > > > > In any case, I think having att.common.anl would already be a really > > useful improvement. > > > > Thomas > > > > _______________________________________________ > > mei-l mailing list > > mei-l at lists.uni-paderborn.de > > https://lists.uni-paderborn.de/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/20120724/1b750574/attachment.html> From zupftom at googlemail.com Tue Jul 24 22:35:29 2012 From: zupftom at googlemail.com (TW) Date: Tue, 24 Jul 2012 22:35:29 +0200 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> Message-ID: <CAEB1mAoheyMg2VxM=QLxeZP-wppsGHnuqnaTwisL_+ijnr=q5g@mail.gmail.com> Hi Johannes, thanks for your elaboration, this is all very well reasoned. Using <annot> with a specific @type and @plist indeed seems like a good intermediary solution that can later be migrated to a proper solution. If such a proper solution would be able to group <app>s in a way that makes clear they are to be understood as a single logical <app> containing a continuous strand of events (like @prev and @next would), then we could close issue 88 as WontFix and supersede it by a new issue. If nobody objects against this, I'll formulate such a new issue. Thomas 2012/7/24 Johannes Kepper <kepper at edirom.de>: > Hi all, > > as others have argued before, I don't like @next / @prev on <app>. It seems like there is no order of differences between sources. There is only a list of differences, which might be ordered following some criteria, but there is no natural order of variants. Using @next to indicate that a separate <app> deals with the _same_ situation seems absolutely awkward. @sameas would require an inconsistent usage, as Thomas already pointed out. @corresp is a generic attribute that should be left open for analytical purposes. If we give it a specific meaning on <app>, we're adding another exception to MEI (the otherwise generic @label has a specific meaning on <staffDef> already?). > > For me, this situation is another argument to a feature request I've been talking about quite a while. In my opinion, MEI will need a generic <grp> (group) element to address issues like this. This new element would have a @plist to point to a set of other elements which are to be regarded as one conceptual unit for some reason. A hint to this reason could be provided using @type. More specific variations of this element could be used for specific purposes: A <damageGrp> would point to <damage> elements which may spread across all levels of hierarchy etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies on a linear encoding of a base text, which is just interrupted by additional, "strippable" markup. A similar solution seems not possible for MEI. > > Perry has often argued that <annot> does exactly this: It allows to group a set of other elements using @plist, and to provide additional information about this group using text inside the <annot>. This is definitely an option, and works out of the box with the current schema. However, I think this approach is too generic, especially since it encourages the use of <annot> for each and everything in MEI. Maybe I'm not convinced because <annot> has a very specific meaning for me (which might lead to a feature request for <annotStruct> in the future), but I would like to see a more specific solution for problems like this. Otherwise we would recommend the use of extremely powerful elements. In my eyes, doing so would significantly increase the risk of different encoding styles for the same problem, leading to incompatibility etc. > > However, I don't see all this for the upcoming release. The problem is definitely more fundamental than just a missing connection between related <app>s, and I would like to avoid rushing into a quick solution too hastily. I would suggest to not add anything to <app> right now, but instead to rely on the existing <annot> for the moment (yes, I still remember my arguments?). This is nothing we're able to cope with for the upcoming release, but it's definitely something we should discuss for the next release (scheduled for 2013). Until then, I'd prefer to live with the existing compromises instead of adding new ones (which we'd have to clean up later?). > > Just my two cents, > Johannes > > > > > > Am 23.07.2012 um 13:14 schrieb TW: > >> 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>: >>> Hi evbdy! >>> Discussing the lacking possibility to aggregate multiple app elements by >>> means of an attribute, which could be very handy indeed, I'd like to put >>> into consideration that @prev and @next imply an order. This might exactly >>> be what One is looking for, especially when thinking of genetic editions, >>> but something like @corresp might be more applicable in other situations. >>> >> >> @corresp would be covered by my suggestion to allow att.common.anl on >> <app> and <choice>. However, @corresp always felt a bit vague to me. >> I guess it could legitimately be used to point to an independent <app> >> element, meaning something like "Look, this is the same *kind* of >> difference" rather than "This belongs to one virtual entity that has >> been split because we can't break the hierarchy". @prev and @next are >> a bit more definite, implying a "user-defined collection". >> >> @sameas (also in att.common.anl) "sounds" like the most precise way of >> saying everything belongs to the same logical <app>, but I see that >> this meaning would be inconsistent with other uses of @sameas. >> >> Other options I can think of: >> - Having @plist on a "master" <app>, pointing to the subordinate >> <app>s. This is very clear, but it's rather arbitrary what becomes >> the master <app>. At first sight, a subordinate <app> can not be >> distinguished from a standalone <app>. >> - Some kind of stand-off markup? >> >> In any case, I think having att.common.anl would already be a really >> useful improvement. >> >> Thomas >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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 Jul 26 09:00:13 2012 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 26 Jul 2012 09:00:13 +0200 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <CAEB1mAoheyMg2VxM=QLxeZP-wppsGHnuqnaTwisL_+ijnr=q5g@mail.gmail.com> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> <CAEB1mAoheyMg2VxM=QLxeZP-wppsGHnuqnaTwisL_+ijnr=q5g@mail.gmail.com> Message-ID: <5010EAFD.4040700@edirom.de> Hi Johannes, thanks for elaborating. I am with you for most of it, although I don't see why @corresp should not be used? It's supposed to be used to point to elements corresponding to the current one in a "generic fashion" (whatever that be). Although from the "analytical" domain, I did not understand att.common.anl to be exclusively for music analysis (correct me if I'm wrong). I think analysis starts with examination of the subject matter. If I understood Thomas' original intention right (@Thomas please correct me), the idea was that on an early stage of encoding one might just like to mark correlation of two <app>s, then use a script to generate an apparatus, that would already have the correct @plist on its <annot>s. And in this case (having no other variants in this percise spot), the result should not be two <annot>s but a single one having measures one and two from two sources in its @plist. Let's say the phenomenon one would like to point out was a displacement of a line of notes in one staff (more or less the first note being wron, the rest just consecutive faults) it is good to indicate the connection straight away when encoding like Thomas did in his second version. For a solution: Although it is not possible to mark the correspondence directly on the <app> (I think this is no problem) the attributes we were talking about (@pre, @next, @corresp, and many more) together with @source (@Andrew: thx for pointing to it in the first place) can be used on <lem> or <rdg>. Which is even more accurate than putting it on the <app> as it is the readings from on source that correspond, not the apparatus in whole, which might contain even more <rdg>s unconnected to that very phenomenon. In the end you should be able to do what you intendended in the first place, @Thomas. Anyway I'd be very curious how the script might figure out the kind of correspondence and details of the <annot> to generate. In the end, best option might be to straight away put an <annot> (Go @Perry, go!) into (one of?) the <rdg>s with it's @plist pointing to the corresponding <rdg>s. Your scipt could then check for preexisting <annot>s deciding what to do whith <app>s/<rdg>s containing one or not. I think solutions for encoding the problem in general might be there in the firsthand (@Johannes: with slight possibilities of improvement), when thinking of intelligently machine processable connections the problem seems to have another scope in means of quantificating and qualificating the intellectual aspects. Have fun! Benni Benjamin Wolff Bohl *********************************************************** Edirom - Projekt "Digitale Musikedition" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 http://www.edirom.de *********************************************************** Am 24.07.2012 22:35, schrieb TW: > Hi Johannes, > > thanks for your elaboration, this is all very well reasoned. Using > <annot> with a specific @type and @plist indeed seems like a good > intermediary solution that can later be migrated to a proper solution. > > If such a proper solution would be able to group <app>s in a way that > makes clear they are to be understood as a single logical <app> > containing a continuous strand of events (like @prev and @next would), > then we could close issue 88 as WontFix and supersede it by a new > issue. If nobody objects against this, I'll formulate such a new > issue. > > Thomas > > > 2012/7/24 Johannes Kepper <kepper at edirom.de>: >> Hi all, >> >> as others have argued before, I don't like @next / @prev on <app>. It seems like there is no order of differences between sources. There is only a list of differences, which might be ordered following some criteria, but there is no natural order of variants. Using @next to indicate that a separate <app> deals with the _same_ situation seems absolutely awkward. @sameas would require an inconsistent usage, as Thomas already pointed out. @corresp is a generic attribute that should be left open for analytical purposes. If we give it a specific meaning on <app>, we're adding another exception to MEI (the otherwise generic @label has a specific meaning on <staffDef> already?). >> >> For me, this situation is another argument to a feature request I've been talking about quite a while. In my opinion, MEI will need a generic <grp> (group) element to address issues like this. This new element would have a @plist to point to a set of other elements which are to be regarded as one conceptual unit for some reason. A hint to this reason could be provided using @type. More specific variations of this element could be used for specific purposes: A <damageGrp> would point to <damage> elements which may spread across all levels of hierarchy etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies on a linear encoding of a base text, which is just interrupted by additional, "strippable" markup. A similar solution seems not possible for MEI. >> >> Perry has often argued that <annot> does exactly this: It allows to group a set of other elements using @plist, and to provide additional information about this group using text inside the <annot>. This is definitely an option, and works out of the box with the current schema. However, I think this approach is too generic, especially since it encourages the use of <annot> for each and everything in MEI. Maybe I'm not convinced because <annot> has a very specific meaning for me (which might lead to a feature request for <annotStruct> in the future), but I would like to see a more specific solution for problems like this. Otherwise we would recommend the use of extremely powerful elements. In my eyes, doing so would significantly increase the risk of different encoding styles for the same problem, leading to incompatibility etc. >> >> However, I don't see all this for the upcoming release. The problem is definitely more fundamental than just a missing connection between related <app>s, and I would like to avoid rushing into a quick solution too hastily. I would suggest to not add anything to <app> right now, but instead to rely on the existing <annot> for the moment (yes, I still remember my arguments?). This is nothing we're able to cope with for the upcoming release, but it's definitely something we should discuss for the next release (scheduled for 2013). Until then, I'd prefer to live with the existing compromises instead of adding new ones (which we'd have to clean up later?). >> >> Just my two cents, >> Johannes >> >> >> >> >> >> Am 23.07.2012 um 13:14 schrieb TW: >> >>> 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>: >>>> Hi evbdy! >>>> Discussing the lacking possibility to aggregate multiple app elements by >>>> means of an attribute, which could be very handy indeed, I'd like to put >>>> into consideration that @prev and @next imply an order. This might exactly >>>> be what One is looking for, especially when thinking of genetic editions, >>>> but something like @corresp might be more applicable in other situations. >>>> >>> @corresp would be covered by my suggestion to allow att.common.anl on >>> <app> and <choice>. However, @corresp always felt a bit vague to me. >>> I guess it could legitimately be used to point to an independent <app> >>> element, meaning something like "Look, this is the same *kind* of >>> difference" rather than "This belongs to one virtual entity that has >>> been split because we can't break the hierarchy". @prev and @next are >>> a bit more definite, implying a "user-defined collection". >>> >>> @sameas (also in att.common.anl) "sounds" like the most precise way of >>> saying everything belongs to the same logical <app>, but I see that >>> this meaning would be inconsistent with other uses of @sameas. >>> >>> Other options I can think of: >>> - Having @plist on a "master" <app>, pointing to the subordinate >>> <app>s. This is very clear, but it's rather arbitrary what becomes >>> the master <app>. At first sight, a subordinate <app> can not be >>> distinguished from a standalone <app>. >>> - Some kind of stand-off markup? >>> >>> In any case, I think having att.common.anl would already be a really >>> useful improvement. >>> >>> Thomas >>> >>> _______________________________________________ >>> mei-l mailing list >>> mei-l at lists.uni-paderborn.de >>> https://lists.uni-paderborn.de/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 zupftom at googlemail.com Sun Jul 29 07:13:45 2012 From: zupftom at googlemail.com (TW) Date: Sun, 29 Jul 2012 07:13:45 +0200 Subject: [MEI-L] Antw.: More "precise" <app>s In-Reply-To: <5010EAFD.4040700@edirom.de> References: <0MVYxn-1TLPE120Ip-00YQpr@mrelayeu.kundenserver.de> <CAEB1mArk1E6Ut=JGgGNFZVHtdeu+ia7mhMK_-tnAxQ1Hdr-KbA@mail.gmail.com> <86CE134D-87C1-41F2-8DD4-F3F7445E3723@edirom.de> <CAEB1mAoheyMg2VxM=QLxeZP-wppsGHnuqnaTwisL_+ijnr=q5g@mail.gmail.com> <5010EAFD.4040700@edirom.de> Message-ID: <CAEB1mAqAnNzbMHX5-AFzai20idjkMcUGZsVu5Gz7ejbEqnZ3vw@mail.gmail.com> Hi Benjamin and all, sorry for the late reply, I'm sort of on vacation. 2012/7/26 Benjamin Wolff Bohl <bohl at edirom.de>: > Hi Johannes, > thanks for elaborating. I am with you for most of it, although I don't see > why @corresp should not be used? It's supposed to be used to point to > elements corresponding to the current one in a "generic fashion" (whatever > that be). Although from the "analytical" domain, I did not understand > att.common.anl to be exclusively for music analysis (correct me if I'm > wrong). I think analysis starts with examination of the subject matter. > If I understood Thomas' original intention right (@Thomas please correct > me), the idea was that on an early stage of encoding one might just like to > mark correlation of two <app>s, then use a script to generate an apparatus, > that would already have the correct @plist on its <annot>s. No, that's not exactly my original idea. I was thinking about how to create a more classical synoptic visualization of the apparatus that compares two or more segments. In such a visualization I wouldn't want to split a melodic line measure by measure, therefore the suggestion to indicate the relationship in a more specific way. Indeed an <annot> (maybe with @type="app") seems like a pretty good way of dealing with this, also for examples where there's for example only one note that differs and you want to put this note into a minimal musically sensible context when creating the synoptic comparison. Then you could indicate what elements outside the <app> should be included in the visualization. If we one day get something like an <appGroup>, then however it would be nicer and cleaner to split this into a @plist for pointing to all the <app> elements and maybe a @context attribute the indicates the smallest sensible musical context. Thomas From kepper at edirom.de Wed Aug 1 16:07:03 2012 From: kepper at edirom.de (Johannes Kepper) Date: Wed, 1 Aug 2012 16:07:03 +0200 Subject: [MEI-L] Fwd: pre-release announcement to the Council References: <BBCC497C40D85642B90E9F94FC30343D0EF74B82@reagan.eservices.virginia.edu> Message-ID: <D35D78B1-B3ED-4750-BD55-5F85051783B7@edirom.de> Dear colleagues, Just to let you know, a new version of MEI is ready and will be released soon. Because it is expressed in the "One Document Does-it-all" (ODD) format, this release provides the ability to generate various schemas (RNG and W3C) and accompanying documentation and best practice guidelines. ODD also allows for the creation of customized schemas and documentation for those with special requirements. In fact, we have already implemented an MEI customization service as part of this release. In addition, ODD brings us technically closer to TEI, and together with the TEI Music Special Interest Group we have already enriched TEI with capabilities to include MEI markup. Of course, along the way we've improved the markup capabilities and overall documentation of "out-of-the-box" MEI. The Technical Team has worked hard to bring this about. During this time, we faced an increasing interest in MEI from different communities, which led to attendance at several conferences and other dissemination efforts. If you check http://music-encoding.org/community/events, you'll see some of the other activities we've been involved in. Even though the release took more time than we expected, we hope that you will agree that this is a good thing for MEI. So, while this release is a few months past our original deadline, we believe that satisfying the professional interest in MEI that has sprung up over the last year is an enviable position in which to find ourselves. Writing the new Guidelines, we had some very intense discussions, and we believe that, while there is of course always room for improvements, MEI is ready to be released in its current state. In order to avoid further delay and allow more time for review and comment, we decided to release this version without prior review from the Council. We encourage everyone to have a close look at what we offer with this release and provide comments and suggestions that will help us improve MEI. Due to the improvements we incorporated, this version will break backwards compatibility with the earlier MEI 2010-05 release. This step had to be made at some point, and it seemed better to make this decision sooner than later. All effort has been made to minimize the effect of these changes and we are happy to assist with the relatively easy transition. For the Technical Team, Perry Roland and Johannes Kepper From bohl at edirom.de Thu Aug 2 14:55:21 2012 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Thu, 02 Aug 2012 14:55:21 +0200 Subject: [MEI-L] [ANN] Edirom-Summer-School 2012 Registration open Message-ID: <501A78B9.5020404@edirom.de> Dear colleagues, as already announced, the third Edirom-Summer-School on digital tools and technologies in the humanities is to take place ** September 24 to 28, 2012 at the Heinz-Nixdorf-Institute, University of Paderborn, Germany** Registration is open at: http://www.edirom.de/summerschool2012 With a total of 13 independet classes it is our biggest summer school to date - not least because of your great interest over the past years. Starting with basic introductions to TEI (Text Encoding Initiative), MEI (Music Encoding Initiative) and Edirom-Tools we continue with courses on Edirom-Customization, introduction to eXist-db, XPath and regular expressions, as well as XSLT. We are very excited to welcome external tutors for the first time this year. Daniel Kurzawe and Tibor K?lm?n (both GWDG, G?ttingen, Germany) from DARIAH-DE project will hold an "introduction to sustainable handling of research data", Axel Teich Geertinger (DCM, Copenhagen) teaches "MerMEId Metadata Editor and Repository for MEI Data", and Raffaele Viglianti (King's College, London) will teach "Encoding Text and Music" and "An introduction to ODD". This als has an impact on teaching language and we are happy to anounce three **classes in english, being:** - Encoding Text and Music (Sept 27) - Manuscript Encoding and Digital Editions based on MEI (Sept 27 to 28) - An introduction to ODD (Sept 28) Attendance is open to everyone and will be charged with a mere ? 5.00 contribution towards expenses for each half day of attendance. Registration deadline is due August 31, 2012. On low registration numbers we reserve the right to merge or cancel classes. The Edirom-Summer-School team is looking forward to your attendance at Paderborn. For further information visit http://www.edirom.de/summerschool2012. Wit best wishes from your organisation team, Peter Stadler and Benjamin W. Bohl ===GERMAN========================================== Sehr geehrte Kolleginnen und Kollegen, wie bereits angek?ndigt, wird die dritte Paderborner Edirom-Summer-School zum Arbeiten mit digitalen Werkzeugen und Technologien in den Geisteswissenschaften **vom 24. bis 28. September 2012** am Heinz-Nixdorf-Institut der Universit?t Paderborn stattfinden. Die Anmeldung ist ab sofort m?glich unter: http://www.edirom.de/summerschool2012 Mit insgesamt 13 verschiedenen Veranstaltungen handelt es sich um unsere bisher gr??te Summer School - ein Erfolg, den wir nicht zuletzt Ihrem gro?en Interesse in den letzten Jahren zu verdanken haben. Besonders freuen wir uns, dass wir in diesem Jahr die ersten externen Referenten begr??en d?rfen. So werden Daniel Kurzawe und Tibor K?lm?n (beide GWDG, G?ttingen) aus dem DARIAH-DE Projekt unser Programm um einen Kurs zu "Grundlagen zum nachhaltigen Umgang mit Forschungsdaten"erweitern. Axel Teich Geertinger (DCM, Kopenhagen) erl?utert im Kurs "MerMEId - Arbeiten mit MEI Metadaten" nicht nur das Format MEI sondern auch den vom DCM entwickelten "Metadata Editor and Repository for MEI Data". Weiterhin freuen wir uns, Raffaele Viglianti (King's College, London) begr??en zu k?nnen, der uns durch seine nachhaltigen Erfahrungen im Umgang mit den Codierungsstandards TEI und MEI je einen Kurs "Encoding Text and Music" sowie "An introduction to ODD" anbieten wird. Damit geht auch eine Internationalisierung hinsichtlich der Kurssprachen einher, und somit werden in diesem Jahr insgesamt drei Kurse in englischer Sprache unterrichtet. Im Folgenden eine Auflistung aller angebotenen Kurse: - Einf?hrung in die Codierung von Notentexten mit MEI (24. - 25.09.) - Einf?hrung in die Codierung von Texten mit TEI (24. - 25.09.) - Edirom-Tools - Erstellen einer Edirom-Online (24.09.) - Edirom-Customization - Projektspezifische Anpassungen der Edirom-Online (25.09.) - MerMEId - Arbeiten mit MEI Metadaten (26.09.) - Einf?hrung in die native XML-Datenbank eXist (26.09.) - Edirom User Forum (26.09.) - Encoding Text and Music [Englisch] (27.09.) - Manuscript Encoding and Digital Editions based on MEI [Englisch] (27. - 28.09.) - XPath und Regul?re Ausdr?cke - Fortgeschrittenes Suchen in XML Dokumenten (27.09.) - Grundlagen zum nachhaltigen Umgang mit Forschungsdaten (27.09.) - XSL(T) f?r Einsteiger (28.09.) - An introduction to ODD [Englisch] (28.09.) F?r die Teilnahme an den Kursen wird lediglich ein Unkostenbeitrag in der H?he von ? 5,00 pro halbem Tag erhoben. Anmeldeschluss ist der 31.08.2012. Bei zu geringen Teilnehmerzahlen behalten wir uns vor, einzelne Kurse zusammenzulegen bzw. abzusagen. Wir m?chten ausdr?cklich darauf hinweisen, dass die Workshops "Einf?hrungen in MEI", "Einf?hrungen in TEI", "Edirom-Tools", sowie "Grundlagen zum nachhaltigen Umgang mit Forschungsdaten" auch ohne Vorkenntnisse auf den genannten Gebieten besucht werden k?nnen, allerdings setzen die weiteren Kurse XML-Kenntnisse voraus (die ggf. in den Einf?hrungskursen erworben werden k?nnen). Das Edirom-Summer-School Team freut sich darauf, Sie in Paderborn begr??en zu k?nnen! Weitere Informationen und die M?glichkeit zur Registrierung finden Sie unter: http://www.edirom.de/summerschool2012 Mit besten Gr??en von Ihrem Organisationsteam, Peter Stadler und Benjamin W. Bohl -- *********************************************************** Edirom - Projekt "Digitale Musikedition" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-665 Fax: +49 (0) 5231 / 975-668 http://www.edirom.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120802/608559bc/attachment.html> From kepper at edirom.de Fri Aug 24 22:34:53 2012 From: kepper at edirom.de (Johannes Kepper) Date: Fri, 24 Aug 2012 16:34:53 -0400 Subject: [MEI-L] Release of MEI 2012 v2.0.0 Message-ID: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> Dear MEIers, finally, we have made our way through the Guidelines, which means that we're happy to announce the release of MEI 2012. This release is available from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before adding more details about this, we would like to thank everyone involved in this release in one way or the other for the continuous support. Without a whole lot of dedication by all of you, this wouldn't have been possible. LABELLING SCHEME MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" is the label for it, the "v2.0.0" is the technical identification for it. We will use this numbering scheme for all subsequent releases of MEI. Let me explain the numbers a little bit. The first digit indicates the technical foundation to be used. We have built this release from scratch using a different technology (something I'm coming back to later), so this is the second iteration of MEI, following the original 2010-05 release. The second digit indicates changes in the schema, the third digit changes to the documentation. That means the number v2.0.1 would be used for a revised documentation for the current release, the number v2.1.3 would indicate a change in the schema itself, that already had three revisions to the documentation. TECHNICAL BACKGROUND ? ODD Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which stands for One Document Does-it-all. This is a meta schema language that allows one to generate schemas and documentation from the same source. It also facilitates customizing MEI in a self-documenting way. We already have a preliminary customization service for those of you familiar with ODD at http://custom.music-encoding.org. GUIDELINES Compared to MEI 2010-05, we completely rewrote the documentation for MEI. We had a tag library for that, which was helpful, but which required a certain amount of familiarity with the schema to work with it. Now we have a nearly 700 page document which still includes a tag library, but also around 250 pages explaining how to use MEI to encode different features of music notation of various kinds. It follows the module structure of MEI and significantly increases accessibility of the schema. Make sure to have a look at this PDF, which is contained in the release zip mentioned above, but is also separately available from http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. TODO Even though we have finished this release, there are still things to improve. First, we plan to reshape our website at music-encoding.org to match this new release. We plan to include the Guidelines, a revised tag library section, and a collection of MEI sample encodings. We will address these issues successively, starting in the next couple of weeks. What should happen simultaneously is that we gather feedback on the release, specifically on the Guidelines. If you have the opportunity to work a little bit with the Guidelines in the next few weeks or months, please do that. We hope to improve the Guidelines in a number of several small steps until the end of the current DFG/NEH funded grant, which will be summer next year. If you have any further questions, feel free to ask us personally or here on MEI-L. With best regards, Perry and Johannes From veit at weber-gesamtausgabe.de Fri Aug 24 22:49:19 2012 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Fri, 24 Aug 2012 22:49:19 +0200 Subject: [MEI-L] Release of MEI 2012 v2.0.0 In-Reply-To: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> References: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> Message-ID: <5037E8CF.7050100@weber-gesamtausgabe.de> Dear Perry and Johannes, congratulations!!!!! This was an enormous task and all MEI'ers will raise their glass of beer or wine this evening with singing the praise of the two editors but also singing thanking-hymns to all those in the still small MEI-world who have contributed with their hard work to this success!!! With this step the MEI-world will be growing still more rapidly - certainly! Please take a rest and raise your glasses and only later think that the work for version 3.0 begins tomorrow... Best greetings, and many, many - and still much more thanks to you and all! Joachim Am 24.08.12 22:34, schrieb Johannes Kepper: > Dear MEIers, > > finally, we have made our way through the Guidelines, which means that we're happy to announce the release of MEI 2012. This release is available from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before adding more details about this, we would like to thank everyone involved in this release in one way or the other for the continuous support. Without a whole lot of dedication by all of you, this wouldn't have been possible. > > > LABELLING SCHEME > MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" is the label for it, the "v2.0.0" is the technical identification for it. We will use this numbering scheme for all subsequent releases of MEI. Let me explain the numbers a little bit. The first digit indicates the technical foundation to be used. We have built this release from scratch using a different technology (something I'm coming back to later), so this is the second iteration of MEI, following the original 2010-05 release. The second digit indicates changes in the schema, the third digit changes to the documentation. That means the number v2.0.1 would be used for a revised documentation for the current release, the number v2.1.3 would indicate a change in the schema itself, that already had three revisions to the documentation. > > > TECHNICAL BACKGROUND ? ODD > Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which stands for One Document Does-it-all. This is a meta schema language that allows one to generate schemas and documentation from the same source. It also facilitates customizing MEI in a self-documenting way. We already have a preliminary customization service for those of you familiar with ODD at http://custom.music-encoding.org. > > > GUIDELINES > Compared to MEI 2010-05, we completely rewrote the documentation for MEI. We had a tag library for that, which was helpful, but which required a certain amount of familiarity with the schema to work with it. Now we have a nearly 700 page document which still includes a tag library, but also around 250 pages explaining how to use MEI to encode different features of music notation of various kinds. It follows the module structure of MEI and significantly increases accessibility of the schema. Make sure to have a look at this PDF, which is contained in the release zip mentioned above, but is also separately available from http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. > > > TODO > Even though we have finished this release, there are still things to improve. First, we plan to reshape our website at music-encoding.org to match this new release. We plan to include the Guidelines, a revised tag library section, and a collection of MEI sample encodings. We will address these issues successively, starting in the next couple of weeks. What should happen simultaneously is that we gather feedback on the release, specifically on the Guidelines. If you have the opportunity to work a little bit with the Guidelines in the next few weeks or months, please do that. We hope to improve the Guidelines in a number of several small steps until the end of the current DFG/NEH funded grant, which will be summer next year. > > > If you have any further questions, feel free to ask us personally or here on MEI-L. > > With best regards, > > Perry and Johannes > > > > > > > _______________________________________________ > 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 : veit.vcf Dateityp : text/x-vcard Dateigr??e : 364 bytes Beschreibung: nicht verf?gbar URL : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120824/e9a21579/attachment.vcf> From pdr4h at eservices.virginia.edu Mon Aug 27 17:16:11 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 27 Aug 2012 15:16:11 +0000 Subject: [MEI-L] AMS "Introduction to MEI" Workshop Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu> Dear MEIers, This is a gentle reminder about the pre-conference workshop in conjunction with the American Musicological Society and Society for Music Theory joint meeting in New Orleans. Please forgive any cross-posting, but we want to get the word out to a broad range of potential participants. This announcement has already been (or will soon be) posted to TEI-L and DH lists. However, please distribute this to other lists, such as national and local discussion lists concerned with music and digital humanities, and other interested individuals. Thanks for getting the word out, -- p. __________________________ Perry Roland Music Library University of Virginia P. O. Box 400175 Charlottesville, VA 22904 434-982-2702 (w) pdr4h (at) virginia (dot) edu AMS "Introduction to MEI" Workshop The University of Virginia Library, the University of Paderborn, and the Music Encoding Initiative Council are pleased to offer an opportunity to learn about the Music Encoding Initiative (MEI), an increasingly important tool for digital humanities music research, in conjunction with the joint meeting of the American Musicological Society, the Society for Ethnomusicology and the Society for Music Theory in New Orleans, scheduled for 1-4 November. "Introduction to MEI," an intensive, hands-on workshop, will be offered Wednesday, 31 October from 9:00 a.m. to 5:30 p.m. Experts from the Music Encoding Initiative Council will teach the workshop, during which participants will learn about MEI history and design principles, tools for creating, editing, and rendering MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and opportunities to address participant-specific issues. There are no fees associated with this workshop and no previous experience with MEI or XML is required; however, an understanding of music notation and other markup schemes, such as HTML and TEI, will be helpful. Participants are encouraged to bring laptop computers for hands-on exercises. The number of participants is limited to 25. To register, visit the AMS special events page at http://www.ams-net.org/neworleans/special_events.php. Please address questions to info at music-encoding.org. Workshop Schedule Session 1 (9:00-10:00): What is music encoding? This session introduces the basic need for and techniques of music encoding using XML. ? What is markup? What is its function? Why is it important? ? Basic concepts of XML: elements, attributes, document structure, and schemas ? What is the role of standards such as MEI? Why do we need markup languages? Session 2 (10:15-12:00): What is MEI? The following issues will be addressed during this session: ? MEI's situation within the landscape of digital humanities scholarship: What are its intellectual affiliations and commitments? ? How does MEI support the creation of digital musical texts? What is its role in defining how music documents should be represented? ? How is MEI currently used, and how is it evolving? ? What are the alternatives to MEI? What are the advantages and risks of using a detailed encoding system like MEI? Session 3 (1:30-3:00): Basics of Encoding with MEI This session will describe basic MEI elements and describe their use, using detailed musical examples. Session 4 (3:15-4:30): MEI Application Tutorials This session introduces MEI-specific encoding tools, such as, MerMEId, MEISE, and the Edirom Editor. Participants will learn how these tools can be used to design workflows for entering, editing, and rendering MEI. Session 5 (4:45-5:30): Wrap-up Discussion Participants will reflect on MEI markup and tools and how they can be employed in the participants? current and future projects. In addition, opportunities for participation in the MEI community will be covered. From andrew.hankinson at gmail.com Mon Aug 27 17:26:41 2012 From: andrew.hankinson at gmail.com (Andrew Hankinson) Date: Mon, 27 Aug 2012 11:26:41 -0400 Subject: [MEI-L] AMS "Introduction to MEI" Workshop In-Reply-To: <25353_1346080589_503B8F4C_25353_392_1_BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu> References: <25353_1346080589_503B8F4C_25353_392_1_BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu> Message-ID: <BD2498EC-784F-4248-96B7-4051C8DF23FA@gmail.com> I just sent it to the Canadian Music Libraries list. How did the Summer Workshop go? -Andrew On 2012-08-27, at 11:16 AM, "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> wrote: > Dear MEIers, > > This is a gentle reminder about the pre-conference workshop in conjunction with the American Musicological Society and Society for Music Theory joint meeting in New Orleans. Please forgive any cross-posting, but we want to get the word out to a broad range of potential participants. > > This announcement has already been (or will soon be) posted to TEI-L and DH lists. However, please distribute this to other lists, such as national and local discussion lists concerned with music and digital humanities, and other interested individuals. > > Thanks for getting the word out, > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > > > AMS "Introduction to MEI" Workshop > > The University of Virginia Library, the University of Paderborn, and the Music Encoding Initiative Council > are pleased to offer an opportunity to learn about the Music Encoding Initiative (MEI), an increasingly > important tool for digital humanities music research, in conjunction with the joint meeting of the American > Musicological Society, the Society for Ethnomusicology and the Society for Music Theory in New Orleans, > scheduled for 1-4 November. > > "Introduction to MEI," an intensive, hands-on workshop, will be offered Wednesday, 31 October from 9:00 > a.m. to 5:30 p.m. Experts from the Music Encoding Initiative Council will teach the workshop, during which > participants will learn about MEI history and design principles, tools for creating, editing, and rendering > MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and > opportunities to address participant-specific issues. > > There are no fees associated with this workshop and no previous experience with MEI or XML is required; > however, an understanding of music notation and other markup schemes, such as HTML and TEI, will be > helpful. Participants are encouraged to bring laptop computers for hands-on exercises. The number of > participants is limited to 25. > > To register, visit the AMS special events page at http://www.ams-net.org/neworleans/special_events.php. > > Please address questions to info at music-encoding.org. > > Workshop Schedule > > Session 1 (9:00-10:00): What is music encoding? > This session introduces the basic need for and techniques of music encoding using XML. > ? What is markup? What is its function? Why is it important? > ? Basic concepts of XML: elements, attributes, document structure, and schemas > ? What is the role of standards such as MEI? Why do we need markup languages? > > Session 2 (10:15-12:00): What is MEI? > The following issues will be addressed during this session: > ? MEI's situation within the landscape of digital humanities scholarship: What are its intellectual affiliations and commitments? > ? How does MEI support the creation of digital musical texts? What is its role in defining how music documents should be represented? > ? How is MEI currently used, and how is it evolving? > ? What are the alternatives to MEI? What are the advantages and risks of using a detailed encoding system like MEI? > > Session 3 (1:30-3:00): Basics of Encoding with MEI > This session will describe basic MEI elements and describe their use, using detailed musical examples. > > Session 4 (3:15-4:30): MEI Application Tutorials > This session introduces MEI-specific encoding tools, such as, MerMEId, MEISE, and the Edirom Editor. Participants will learn how these tools can be used to design workflows for entering, editing, and rendering MEI. > > Session 5 (4:45-5:30): Wrap-up Discussion > Participants will reflect on MEI markup and tools and how they can be employed in the participants? current and future projects. In addition, opportunities for participation in the MEI community will be covered. > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 1034 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120827/0327a574/attachment.bin> From pdr4h at eservices.virginia.edu Mon Aug 27 17:28:56 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 27 Aug 2012 15:28:56 +0000 Subject: [MEI-L] AMS "Introduction to MEI" Workshop In-Reply-To: <BD2498EC-784F-4248-96B7-4051C8DF23FA@gmail.com> References: <25353_1346080589_503B8F4C_25353_392_1_BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu>, <BD2498EC-784F-4248-96B7-4051C8DF23FA@gmail.com> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF88334@GRANT.eservices.virginia.edu> I think it went very well judging by the comments we got. -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at gmail.com] Sent: Monday, August 27, 2012 11:26 AM To: Music Encoding Initiative Subject: Re: [MEI-L] AMS "Introduction to MEI" Workshop I just sent it to the Canadian Music Libraries list. How did the Summer Workshop go? -Andrew On 2012-08-27, at 11:16 AM, "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> wrote: > Dear MEIers, > > This is a gentle reminder about the pre-conference workshop in conjunction with the American Musicological Society and Society for Music Theory joint meeting in New Orleans. Please forgive any cross-posting, but we want to get the word out to a broad range of potential participants. > > This announcement has already been (or will soon be) posted to TEI-L and DH lists. However, please distribute this to other lists, such as national and local discussion lists concerned with music and digital humanities, and other interested individuals. > > Thanks for getting the word out, > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > > > AMS "Introduction to MEI" Workshop > > The University of Virginia Library, the University of Paderborn, and the Music Encoding Initiative Council > are pleased to offer an opportunity to learn about the Music Encoding Initiative (MEI), an increasingly > important tool for digital humanities music research, in conjunction with the joint meeting of the American > Musicological Society, the Society for Ethnomusicology and the Society for Music Theory in New Orleans, > scheduled for 1-4 November. > > "Introduction to MEI," an intensive, hands-on workshop, will be offered Wednesday, 31 October from 9:00 > a.m. to 5:30 p.m. Experts from the Music Encoding Initiative Council will teach the workshop, during which > participants will learn about MEI history and design principles, tools for creating, editing, and rendering > MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and > opportunities to address participant-specific issues. > > There are no fees associated with this workshop and no previous experience with MEI or XML is required; > however, an understanding of music notation and other markup schemes, such as HTML and TEI, will be > helpful. Participants are encouraged to bring laptop computers for hands-on exercises. The number of > participants is limited to 25. > > To register, visit the AMS special events page at http://www.ams-net.org/neworleans/special_events.php. > > Please address questions to info at music-encoding.org. > > Workshop Schedule > > Session 1 (9:00-10:00): What is music encoding? > This session introduces the basic need for and techniques of music encoding using XML. > ? What is markup? What is its function? Why is it important? > ? Basic concepts of XML: elements, attributes, document structure, and schemas > ? What is the role of standards such as MEI? Why do we need markup languages? > > Session 2 (10:15-12:00): What is MEI? > The following issues will be addressed during this session: > ? MEI's situation within the landscape of digital humanities scholarship: What are its intellectual affiliations and commitments? > ? How does MEI support the creation of digital musical texts? What is its role in defining how music documents should be represented? > ? How is MEI currently used, and how is it evolving? > ? What are the alternatives to MEI? What are the advantages and risks of using a detailed encoding system like MEI? > > Session 3 (1:30-3:00): Basics of Encoding with MEI > This session will describe basic MEI elements and describe their use, using detailed musical examples. > > Session 4 (3:15-4:30): MEI Application Tutorials > This session introduces MEI-specific encoding tools, such as, MerMEId, MEISE, and the Edirom Editor. Participants will learn how these tools can be used to design workflows for entering, editing, and rendering MEI. > > Session 5 (4:45-5:30): Wrap-up Discussion > Participants will reflect on MEI markup and tools and how they can be employed in the participants? current and future projects. In addition, opportunities for participation in the MEI community will be covered. > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From mcbrider at email.unc.edu Mon Aug 27 19:35:05 2012 From: mcbrider at email.unc.edu (McBride, Renee) Date: Mon, 27 Aug 2012 17:35:05 +0000 Subject: [MEI-L] AMS "Introduction to MEI" Workshop In-Reply-To: <BBCC497C40D85642B90E9F94FC30343D0EF88334@GRANT.eservices.virginia.edu> References: <25353_1346080589_503B8F4C_25353_392_1_BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu>, <BD2498EC-784F-4248-96B7-4051C8DF23FA@gmail.com> <BBCC497C40D85642B90E9F94FC30343D0EF88334@GRANT.eservices.virginia.edu> Message-ID: <F825D8D96FE25F46A486AE605C00A09849F0E96E@ITS-MSXMBS4M.ad.unc.edu> I certainly enjoyed and learned from the summer workshop, though unfortunately I had to miss the end of it. Thanks, Perry, Johannes and Maya! Also, I have shared this announcement with MLA-L. Renee ~~~~~~~~~~~~~~~~~~~~~~~~~ Renee McBride Head, Special Formats & Metadata Section Resource Description & Management Dept. Davis Library, CB 3914 UNC-Chapel Hill Chapel Hill, NC 27514-8890 mcbrider at email.unc.edu (919) 962-9709 (phone) (919) 962-4450 (fax) -----Original Message----- From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, August 27, 2012 11:29 AM To: Music Encoding Initiative Subject: Re: [MEI-L] AMS "Introduction to MEI" Workshop I think it went very well judging by the comments we got. -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at gmail.com] Sent: Monday, August 27, 2012 11:26 AM To: Music Encoding Initiative Subject: Re: [MEI-L] AMS "Introduction to MEI" Workshop I just sent it to the Canadian Music Libraries list. How did the Summer Workshop go? -Andrew On 2012-08-27, at 11:16 AM, "Roland, Perry (pdr4h)" <pdr4h at eservices.virginia.edu> wrote: > Dear MEIers, > > This is a gentle reminder about the pre-conference workshop in conjunction with the American Musicological Society and Society for Music Theory joint meeting in New Orleans. Please forgive any cross-posting, but we want to get the word out to a broad range of potential participants. > > This announcement has already been (or will soon be) posted to TEI-L and DH lists. However, please distribute this to other lists, such as national and local discussion lists concerned with music and digital humanities, and other interested individuals. > > Thanks for getting the word out, > > -- > p. > > > __________________________ > Perry Roland > Music Library > University of Virginia > P. O. Box 400175 > Charlottesville, VA 22904 > 434-982-2702 (w) > pdr4h (at) virginia (dot) edu > > > > AMS "Introduction to MEI" Workshop > > The University of Virginia Library, the University of Paderborn, and > the Music Encoding Initiative Council are pleased to offer an > opportunity to learn about the Music Encoding Initiative (MEI), an > increasingly important tool for digital humanities music research, in > conjunction with the joint meeting of the American Musicological Society, the Society for Ethnomusicology and the Society for Music Theory in New Orleans, scheduled for 1-4 November. > > "Introduction to MEI," an intensive, hands-on workshop, will be > offered Wednesday, 31 October from 9:00 a.m. to 5:30 p.m. Experts from > the Music Encoding Initiative Council will teach the workshop, during > which participants will learn about MEI history and design principles, > tools for creating, editing, and rendering MEI, and techniques for customizing the MEI schema. The day will include lectures, hands-on practice, and opportunities to address participant-specific issues. > > There are no fees associated with this workshop and no previous > experience with MEI or XML is required; however, an understanding of > music notation and other markup schemes, such as HTML and TEI, will be > helpful. Participants are encouraged to bring laptop computers for hands-on exercises. The number of participants is limited to 25. > > To register, visit the AMS special events page at http://www.ams-net.org/neworleans/special_events.php. > > Please address questions to info at music-encoding.org. > > Workshop Schedule > > Session 1 (9:00-10:00): What is music encoding? > This session introduces the basic need for and techniques of music encoding using XML. > * What is markup? What is its function? Why is it important? > * Basic concepts of XML: elements, attributes, document structure, and > schemas * What is the role of standards such as MEI? Why do we need markup languages? > > Session 2 (10:15-12:00): What is MEI? > The following issues will be addressed during this session: > * MEI's situation within the landscape of digital humanities scholarship: What are its intellectual affiliations and commitments? > * How does MEI support the creation of digital musical texts? What is its role in defining how music documents should be represented? > * How is MEI currently used, and how is it evolving? > * What are the alternatives to MEI? What are the advantages and risks of using a detailed encoding system like MEI? > > Session 3 (1:30-3:00): Basics of Encoding with MEI This session will > describe basic MEI elements and describe their use, using detailed musical examples. > > Session 4 (3:15-4:30): MEI Application Tutorials This session > introduces MEI-specific encoding tools, such as, MerMEId, MEISE, and the Edirom Editor. Participants will learn how these tools can be used to design workflows for entering, editing, and rendering MEI. > > Session 5 (4:45-5:30): Wrap-up Discussion Participants will reflect on > MEI markup and tools and how they can be employed in the participants' current and future projects. In addition, opportunities for participation in the MEI community will be covered. > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Mon Aug 27 19:47:27 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 27 Aug 2012 17:47:27 +0000 Subject: [MEI-L] AMS "Introduction to MEI" Workshop In-Reply-To: <F825D8D96FE25F46A486AE605C00A09849F0E96E@ITS-MSXMBS4M.ad.unc.edu> References: <25353_1346080589_503B8F4C_25353_392_1_BBCC497C40D85642B90E9F94FC30343D0EF882F3@GRANT.eservices.virginia.edu>, <BD2498EC-784F-4248-96B7-4051C8DF23FA@gmail.com> <BBCC497C40D85642B90E9F94FC30343D0EF88334@GRANT.eservices.virginia.edu>, <F825D8D96FE25F46A486AE605C00A09849F0E96E@ITS-MSXMBS4M.ad.unc.edu> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EF88396@GRANT.eservices.virginia.edu> Hi, Renee, Thanks for the kind words and for letting our librarian friends know about New Orleans. -- 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 atge at kb.dk Mon Aug 27 21:04:27 2012 From: atge at kb.dk (Axel Teich Geertinger) Date: Mon, 27 Aug 2012 19:04:27 +0000 Subject: [MEI-L] Release of MEI 2012 v2.0.0 In-Reply-To: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> References: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> Message-ID: <0B6F63F59F405E4C902DFE2C2329D0D1514BE048@EXCHANGE-02.kb.dk> Hi Johannes, Perry, the tech team & all other contributors This is great news! Thanks a lot to all of you for your enormous effort to make this new release. I am sure it will further help MEI to gain the attention it really deserves. Best wishes from Copenhagen, Axel -----Oprindelig meddelelse----- Fra: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] P? vegne af Johannes Kepper Sendt: 24. august 2012 22:35 Til: Music Encoding Initiative Emne: [MEI-L] Release of MEI 2012 v2.0.0 Dear MEIers, finally, we have made our way through the Guidelines, which means that we're happy to announce the release of MEI 2012. This release is available from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before adding more details about this, we would like to thank everyone involved in this release in one way or the other for the continuous support. Without a whole lot of dedication by all of you, this wouldn't have been possible. LABELLING SCHEME MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" is the label for it, the "v2.0.0" is the technical identification for it. We will use this numbering scheme for all subsequent releases of MEI. Let me explain the numbers a little bit. The first digit indicates the technical foundation to be used. We have built this release from scratch using a different technology (something I'm coming back to later), so this is the second iteration of MEI, following the original 2010-05 release. The second digit indicates changes in the schema, the third digit changes to the documentation. That means the number v2.0.1 would be used for a revised documentation for the current release, the number v2.1.3 would indicate a change in the schema itself, that already had three revisions to the documentation. TECHNICAL BACKGROUND - ODD Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which stands for One Document Does-it-all. This is a meta schema language that allows one to generate schemas and documentation from the same source. It also facilitates customizing MEI in a self-documenting way. We already have a preliminary customization service for those of you familiar with ODD at http://custom.music-encoding.org. GUIDELINES Compared to MEI 2010-05, we completely rewrote the documentation for MEI. We had a tag library for that, which was helpful, but which required a certain amount of familiarity with the schema to work with it. Now we have a nearly 700 page document which still includes a tag library, but also around 250 pages explaining how to use MEI to encode different features of music notation of various kinds. It follows the module structure of MEI and significantly increases accessibility of the schema. Make sure to have a look at this PDF, which is contained in the release zip mentioned above, but is also separately available from http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. TODO Even though we have finished this release, there are still things to improve. First, we plan to reshape our website at music-encoding.org to match this new release. We plan to include the Guidelines, a revised tag library section, and a collection of MEI sample encodings. We will address these issues successively, starting in the next couple of weeks. What should happen simultaneously is that we gather feedback on the release, specifically on the Guidelines. If you have the opportunity to work a little bit with the Guidelines in the next few weeks or months, please do that. We hope to improve the Guidelines in a number of several small steps until the end of the current DFG/NEH funded grant, which will be summer next year. If you have any further questions, feel free to ask us personally or here on MEI-L. With best regards, Perry and Johannes _______________________________________________ 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 Fri Aug 31 03:05:41 2012 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Thu, 30 Aug 2012 18:05:41 -0700 (PDT) Subject: [MEI-L] Release of MEI 2012 v2.0.0 In-Reply-To: <5037E8CF.7050100@weber-gesamtausgabe.de> References: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> <5037E8CF.7050100@weber-gesamtausgabe.de> Message-ID: <94c460c0.00001db0.0000003c@CCARH-ADM-2.su.win.stanford.edu> Hi, Joachim, I know you sent a note recently, but I cannot find it. I travel this weekend, and I was in an auto accident a few days ago, so life is slightly crazy. Please write again. I'm sure we can find a time to meet on Thursday 6th, but I'm not yet sure when it will be. I will be at the Hotel Central from 3 to 8 Sept. Alles gut' Eleanor -----Original Message----- From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Joachim Veit Sent: Friday, August 24, 2012 1:49 PM To: mei-l at lists.uni-paderborn.de Subject: Re: [MEI-L] Release of MEI 2012 v2.0.0 Dear Perry and Johannes, congratulations!!!!! This was an enormous task and all MEI'ers will raise their glass of beer or wine this evening with singing the praise of the two editors but also singing thanking-hymns to all those in the still small MEI-world who have contributed with their hard work to this success!!! With this step the MEI-world will be growing still more rapidly - certainly! Please take a rest and raise your glasses and only later think that the work for version 3.0 begins tomorrow... Best greetings, and many, many - and still much more thanks to you and all! Joachim Am 24.08.12 22:34, schrieb Johannes Kepper: > Dear MEIers, > > finally, we have made our way through the Guidelines, which means that we're happy to announce the release of MEI 2012. This release is available from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before adding more details about this, we would like to thank everyone involved in this release in one way or the other for the continuous support. Without a whole lot of dedication by all of you, this wouldn't have been possible. > > > LABELLING SCHEME > MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" is the label for it, the "v2.0.0" is the technical identification for it. We will use this numbering scheme for all subsequent releases of MEI. Let me explain the numbers a little bit. The first digit indicates the technical foundation to be used. We have built this release from scratch using a different technology (something I'm coming back to later), so this is the second iteration of MEI, following the original 2010-05 release. The second digit indicates changes in the schema, the third digit changes to the documentation. That means the number v2.0.1 would be used for a revised documentation for the current release, the number v2.1.3 would indicate a change in the schema itself, that already had three revisions to the documentation. > > > TECHNICAL BACKGROUND - ODD > Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which stands for One Document Does-it-all. This is a meta schema language that allows one to generate schemas and documentation from the same source. It also facilitates customizing MEI in a self-documenting way. We already have a preliminary customization service for those of you familiar with ODD at http://custom.music-encoding.org. > > > GUIDELINES > Compared to MEI 2010-05, we completely rewrote the documentation for MEI. We had a tag library for that, which was helpful, but which required a certain amount of familiarity with the schema to work with it. Now we have a nearly 700 page document which still includes a tag library, but also around 250 pages explaining how to use MEI to encode different features of music notation of various kinds. It follows the module structure of MEI and significantly increases accessibility of the schema. Make sure to have a look at this PDF, which is contained in the release zip mentioned above, but is also separately available from http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. > > > TODO > Even though we have finished this release, there are still things to improve. First, we plan to reshape our website at music-encoding.org to match this new release. We plan to include the Guidelines, a revised tag library section, and a collection of MEI sample encodings. We will address these issues successively, starting in the next couple of weeks. What should happen simultaneously is that we gather feedback on the release, specifically on the Guidelines. If you have the opportunity to work a little bit with the Guidelines in the next few weeks or months, please do that. We hope to improve the Guidelines in a number of several small steps until the end of the current DFG/NEH funded grant, which will be summer next year. > > > If you have any further questions, feel free to ask us personally or here on MEI-L. > > With best regards, > > Perry and Johannes > > > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From veit at weber-gesamtausgabe.de Fri Aug 31 10:22:42 2012 From: veit at weber-gesamtausgabe.de (Joachim Veit) Date: Fri, 31 Aug 2012 10:22:42 +0200 Subject: [MEI-L] Release of MEI 2012 v2.0.0 In-Reply-To: <94c460c0.00001db0.0000003c@CCARH-ADM-2.su.win.stanford.edu> References: <BB077ABC-0448-4C4E-B80D-FEBFB4D4AE86@edirom.de> <5037E8CF.7050100@weber-gesamtausgabe.de> <94c460c0.00001db0.0000003c@CCARH-ADM-2.su.win.stanford.edu> Message-ID: <50407452.4040606@weber-gesamtausgabe.de> Dear Eleanor, thanks for your mail - I hope that you arose from the auto accident without any as only any harm!! Yes, we can meet on Thursday - the Edirom presentation has now been fixed from 13:30 to 14:30, so perhaps it would be the best to meet around noon or earlier. May I propose to meet either at 11:00 or 12:00. Would you prefere to meet at the Conference directly or should I come to your Hotel (in this case, I think 11:00 would be the better time) Best greetings, Joachim P.S. Would you mind when Johannes takes part in our meeting? Am 31.08.12 03:05, schrieb Eleanor Selfridge-Field: > Hi, Joachim, > > I know you sent a note recently, but I cannot find it. I travel this > weekend, and I was in an auto accident a few days ago, so life is slightly > crazy. > > Please write again. I'm sure we can find a time to meet on Thursday 6th, > but I'm not yet sure when it will be. > > I will be at the Hotel Central from 3 to 8 Sept. > > Alles gut' > > Eleanor > > > -----Original Message----- > From: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Joachim Veit > Sent: Friday, August 24, 2012 1:49 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Release of MEI 2012 v2.0.0 > > Dear Perry and Johannes, > congratulations!!!!! > This was an enormous task and all MEI'ers will raise their glass of beer > or wine this evening with singing the praise of the two editors but also > singing thanking-hymns to all those in the still small MEI-world who have > contributed with their hard work to this success!!! > With this step the MEI-world will be growing still more rapidly - > certainly! > Please take a rest and raise your glasses and only later think that the > work for version 3.0 begins tomorrow... > Best greetings, and many, many - and still much more thanks to you and > all! > Joachim > > > > Am 24.08.12 22:34, schrieb Johannes Kepper: >> Dear MEIers, >> >> finally, we have made our way through the Guidelines, which means that > we're happy to announce the release of MEI 2012. This release is available > from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before > adding more details about this, we would like to thank everyone involved > in this release in one way or the other for the continuous support. > Without a whole lot of dedication by all of you, this wouldn't have been > possible. >> >> LABELLING SCHEME >> MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" > is the label for it, the "v2.0.0" is the technical identification for it. > We will use this numbering scheme for all subsequent releases of MEI. Let > me explain the numbers a little bit. The first digit indicates the > technical foundation to be used. We have built this release from scratch > using a different technology (something I'm coming back to later), so this > is the second iteration of MEI, following the original 2010-05 release. > The second digit indicates changes in the schema, the third digit changes > to the documentation. That means the number v2.0.1 would be used for a > revised documentation for the current release, the number v2.1.3 would > indicate a change in the schema itself, that already had three revisions > to the documentation. >> >> TECHNICAL BACKGROUND - ODD >> Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which > stands for One Document Does-it-all. This is a meta schema language that > allows one to generate schemas and documentation from the same source. It > also facilitates customizing MEI in a self-documenting way. We already > have a preliminary customization service for those of you familiar with > ODD at http://custom.music-encoding.org. >> >> GUIDELINES >> Compared to MEI 2010-05, we completely rewrote the documentation for > MEI. We had a tag library for that, which was helpful, but which required > a certain amount of familiarity with the schema to work with it. Now we > have a nearly 700 page document which still includes a tag library, but > also around 250 pages explaining how to use MEI to encode different > features of music notation of various kinds. It follows the module > structure of MEI and significantly increases accessibility of the schema. > Make sure to have a look at this PDF, which is contained in the release > zip mentioned above, but is also separately available from > http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. >> >> TODO >> Even though we have finished this release, there are still things to > improve. First, we plan to reshape our website at music-encoding.org to > match this new release. We plan to include the Guidelines, a revised tag > library section, and a collection of MEI sample encodings. We will address > these issues successively, starting in the next couple of weeks. What > should happen simultaneously is that we gather feedback on the release, > specifically on the Guidelines. If you have the opportunity to work a > little bit with the Guidelines in the next few weeks or months, please do > that. We hope to improve the Guidelines in a number of several small steps > until the end of the current DFG/NEH funded grant, which will be summer > next year. >> >> If you have any further questions, feel free to ask us personally or > here on MEI-L. >> With best regards, >> >> Perry and 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 -------------- 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 : <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120831/946b5feb/attachment.vcf> From esfield at stanford.edu Sat Sep 1 01:49:33 2012 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Fri, 31 Aug 2012 16:49:33 -0700 (PDT) Subject: [MEI-L] Release of MEI 2012 v2.0.0 In-Reply-To: <50407452.4040606@weber-gesamtausgabe.de> Message-ID: <1049666688.17828189.1346456973216.JavaMail.root@zm07.stanford.edu> Dear Joachim, If you do not hear otherwise, I think that 11-12 at the hotel would be good. We could probably have lunch while passing to the conference site. I wanted to talk you about administrative matters affecting CCARH and try to understand from you the general climate of various issues that can affect critical editions. In the US there is unusual turbulence in the notation software market, and I am wondering what is happening in Germany, particularly among the big publishers--B?renreiter and Schott. (MEI is not my agenda, but I am hoping to come to your session. I have two other meetings to schedule on Thursday, so nothing is completely certain. Also I've just been notified of the Lufthansa strike....) Best regards, Eleanor ----- Original Message ----- From: "Joachim Veit" <veit at weber-gesamtausgabe.de> To: "Music Encoding Initiative" <mei-l at lists.uni-paderborn.de> Sent: Friday, 31 August, 2012 1:22:42 AM Subject: Re: [MEI-L] Release of MEI 2012 v2.0.0 Dear Eleanor, thanks for your mail - I hope that you arose from the auto accident without any as only any harm!! Yes, we can meet on Thursday - the Edirom presentation has now been fixed from 13:30 to 14:30, so perhaps it would be the best to meet around noon or earlier. May I propose to meet either at 11:00 or 12:00. Would you prefere to meet at the Conference directly or should I come to your Hotel (in this case, I think 11:00 would be the better time) Best greetings, Joachim P.S. Would you mind when Johannes takes part in our meeting? Am 31.08.12 03:05, schrieb Eleanor Selfridge-Field: > Hi, Joachim, > > I know you sent a note recently, but I cannot find it. I travel this > weekend, and I was in an auto accident a few days ago, so life is slightly > crazy. > > Please write again. I'm sure we can find a time to meet on Thursday 6th, > but I'm not yet sure when it will be. > > I will be at the Hotel Central from 3 to 8 Sept. > > Alles gut' > > Eleanor > > > -----Original Message----- > From: mei-l-bounces at lists.uni-paderborn.de > [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Joachim Veit > Sent: Friday, August 24, 2012 1:49 PM > To: mei-l at lists.uni-paderborn.de > Subject: Re: [MEI-L] Release of MEI 2012 v2.0.0 > > Dear Perry and Johannes, > congratulations!!!!! > This was an enormous task and all MEI'ers will raise their glass of beer > or wine this evening with singing the praise of the two editors but also > singing thanking-hymns to all those in the still small MEI-world who have > contributed with their hard work to this success!!! > With this step the MEI-world will be growing still more rapidly - > certainly! > Please take a rest and raise your glasses and only later think that the > work for version 3.0 begins tomorrow... > Best greetings, and many, many - and still much more thanks to you and > all! > Joachim > > > > Am 24.08.12 22:34, schrieb Johannes Kepper: >> Dear MEIers, >> >> finally, we have made our way through the Guidelines, which means that > we're happy to announce the release of MEI 2012. This release is available > from http://music-encoding.googlecode.com/files/MEI2012_v2.0.0.zip. Before > adding more details about this, we would like to thank everyone involved > in this release in one way or the other for the continuous support. > Without a whole lot of dedication by all of you, this wouldn't have been > possible. >> >> LABELLING SCHEME >> MEI 2012 v2.0.0 is the complete name for this release. While "MEI 2012" > is the label for it, the "v2.0.0" is the technical identification for it. > We will use this numbering scheme for all subsequent releases of MEI. Let > me explain the numbers a little bit. The first digit indicates the > technical foundation to be used. We have built this release from scratch > using a different technology (something I'm coming back to later), so this > is the second iteration of MEI, following the original 2010-05 release. > The second digit indicates changes in the schema, the third digit changes > to the documentation. That means the number v2.0.1 would be used for a > revised documentation for the current release, the number v2.1.3 would > indicate a change in the schema itself, that already had three revisions > to the documentation. >> >> TECHNICAL BACKGROUND - ODD >> Starting with MEI 2012 v2.0.0, MEI is described using TEI's ODD, which > stands for One Document Does-it-all. This is a meta schema language that > allows one to generate schemas and documentation from the same source. It > also facilitates customizing MEI in a self-documenting way. We already > have a preliminary customization service for those of you familiar with > ODD at http://custom.music-encoding.org. >> >> GUIDELINES >> Compared to MEI 2010-05, we completely rewrote the documentation for > MEI. We had a tag library for that, which was helpful, but which required > a certain amount of familiarity with the schema to work with it. Now we > have a nearly 700 page document which still includes a tag library, but > also around 250 pages explaining how to use MEI to encode different > features of music notation of various kinds. It follows the module > structure of MEI and significantly increases accessibility of the schema. > Make sure to have a look at this PDF, which is contained in the release > zip mentioned above, but is also separately available from > http://music-encoding.googlecode.com/files/MEI_Guidelines_2012_v2.0.0.pdf. >> >> TODO >> Even though we have finished this release, there are still things to > improve. First, we plan to reshape our website at music-encoding.org to > match this new release. We plan to include the Guidelines, a revised tag > library section, and a collection of MEI sample encodings. We will address > these issues successively, starting in the next couple of weeks. What > should happen simultaneously is that we gather feedback on the release, > specifically on the Guidelines. If you have the opportunity to work a > little bit with the Guidelines in the next few weeks or months, please do > that. We hope to improve the Guidelines in a number of several small steps > until the end of the current DFG/NEH funded grant, which will be summer > next year. >> >> If you have any further questions, feel free to ask us personally or > here on MEI-L. >> With best regards, >> >> Perry and 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 _______________________________________________ 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 Sep 3 12:32:36 2012 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Mon, 3 Sep 2012 12:32:36 +0200 Subject: [MEI-L] [ANN][ESS2012] registration deadline extension until end of this week for Edirom-Summer-School 2012 Message-ID: <200C1B20-C9A3-4F18-A980-CB6A51E0F938@edirom.de> Dear colleagues, to the date there are still places available at the courses of Edirom-Summer-School 2012. Hence we decided to extend registration deadline to the end of this week. *final deadline now is Sunday September 9, 0:00 CEST* If so far you have been undecided, use your chance. For further information and registration visit: http://www.edirom.de/summerschool2012. Edirom-Summer-School tries to communicate basic technologies and concepts for the "Digital Humanities". The focus lies on the XML-based encoding guidelines TEI and MEI as well as generic tools for analysis, manipulation and presentation of XML data. Alongside the "hands on" courses there will be opportunity for personal exchange or own presentations in order to make Edirom-Summer-School a general forum for users of different experience levels. Overview of english courses: - Encoding Text and Music (Sept 27) - Manuscript Encoding and Digital Editions based on MEI (Sept 27 to 28) - An introduction to ODD (Sept 28) Wit best wishes from your organizing committee, Peter Stadler and Benjamin W. Bohl -- *********************************************************** Edirom - Projekt "Digitale Musikedition" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D ? 32756 Detmold Tel. +49 (0) 5231 / 975-665 Fax: +49 (0) 5231 / 975-668 http://www.edirom.de *********************************************************** === GERMAN =============================== Sehr geehrte Kolleginnen und Kollegen, noch sind einige Pl?tze in den Kursen der Edirom-Summer-School 2012 frei. Wir haben uns daher entschieden, die Anmeldefrist um eine Woche zu verl?ngern: *endg?ltiger Anmeldeschluss ist nun Sonntag, der 09.09.2012, 0:00 Uhr MEZ.* Sollten Sie bis jetzt noch unentschlossen gewesen sein, nutzen Sie die Gelegenheit. Weitere Informationen und die M?glichkeit zur Registrierung finden Sie unter: http://www.edirom.de/summerschool2012 Die Edirom-Summer-School versucht grundlegende Technologien und Konzepte f?r die ?Digital Humanities? zu vermitteln. Den Schwerpunkt bilden die auf XML basierenden Auszeichnungsrichtlinien TEI und MEI sowie generische Werkzeuge zur Analyse, Manipulation und Pr?sentation der XML-Daten. Neben den jeweiligen Kursen, die alle ?hands on? abgehalten werden, soll auch Raum f?r pers?nlichen Austausch sowie eigene Pr?sentationen gegeben werden, sodass die Edirom-Summer-School auch ein allgemeines Forum f?r Anwender unterschiedlichen Erfahrungsstandes werden kann. Kurs?bersicht: - Einf?hrung in die Codierung von Notentexten mit MEI (24. - 25.09.) - Einf?hrung in die Codierung von Texten mit TEI (24. - 25.09.) - Edirom-Tools - Erstellen einer Edirom-Online (24.09.) - Edirom-Customization - Projektspezifische Anpassungen der Edirom-Online (25.09.) - MerMEId - Arbeiten mit MEI Metadaten (26.09.) - Einf?hrung in die native XML-Datenbank eXist (26.09.) - Edirom User Forum (26.09.) - Encoding Text and Music [Englisch] (27.09.) - Manuscript Encoding and Digital Editions based on MEI [Englisch] (27. - 28.09.) - XPath und Regul?re Ausdr?cke - Fortgeschrittenes Suchen in XML Dokumenten (27.09.) - Grundlagen zum nachhaltigen Umgang mit Forschungsdaten (27.09.) - XSL(T) f?r Einsteiger (28.09.) - An introduction to ODD [Englisch] (28.09.) Mit besten Gr??en von Ihrem Organisationsteam, Peter Stadler und Benjamin W. Bohl From rfreedma at haverford.edu Thu Oct 11 14:43:34 2012 From: rfreedma at haverford.edu (Richard Freedman) Date: Thu, 11 Oct 2012 08:43:34 -0400 Subject: [MEI-L] News on Du Chemin Project, MEI, and VexFlow Message-ID: <CA+zvZGfUZhgs3YiZe9owebhAXr+BBh9jnu6Fm+QJonK+QJ4pMw@mail.gmail.com> Friends, Just a short note to bring you up to date on the Du Chemin Project, and in particular some excellent progress we have made with MEI. You can read the details in the links below. I am printing the documents, too, and can easily send along copies of the report to you. Just let me know if you would like a copy. Meanwhile the most important developments (for the MEI group, in any case): thanks to Raffaele Viglianti and Andrew Hankinson, we have a nice system that allows us to move smoothly from our original Sibelius and Finale transcriptions to MEI and then to on-screen rendering of musical examples. The aim, as you might recall, is to build a large analytic "thesaurus" of musical types and procedures from our repertory, then coordinate these with proposed reconstructions of missing voice parts in still other pieces. Follow the links below to see various explanations and demonstrations. The attached set of images shows you just a small bit of what we can do--in this case searching for a particular type of cadence, then displaying the result. Meanwhile, best wishes for a productive year, Richard Links to various reports and demonstrations: A report on Year One of the Lost Voices Project http://duchemin.haverford.edu/editorsforum/lost-voices-2012/ The latest version of the Thesaurus (now 3.2), available in segments or in one file. http://duchemin.haverford.edu/editorsforum/thesaurus-3-2/ A Dossier documenting our methods, standards, and results so far. http://duchemin.haverford.edu/editorsforum/lost-voices-2012/ Materials for the Ecole III at Tours, with pieces to analyze and reconstruct (also some reconstructions for discussion). http://duchemin.haverford.edu/editorsforum/ecole-thematique-iii-2012/ Demonstration of the new interface and the VexFlow system. (Not complete, so don't be frustrated!). http://duchemin.haverford.edu/editorsforum/search-the-thesaurus-3-2/ -- Richard Freedman John C. Whitehead Professor of Music Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/faculty/rfreedma -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121011/7193409c/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: DuChemin_Search_Demo copy.pdf Type: application/pdf Size: 718764 bytes Desc: not available URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121011/7193409c/attachment.pdf> From raffaeleviglianti at gmail.com Thu Oct 11 15:52:34 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 11 Oct 2012 14:52:34 +0100 Subject: [MEI-L] News on Du Chemin Project, MEI, and VexFlow In-Reply-To: <CA+zvZGfUZhgs3YiZe9owebhAXr+BBh9jnu6Fm+QJonK+QJ4pMw@mail.gmail.com> References: <CA+zvZGfUZhgs3YiZe9owebhAXr+BBh9jnu6Fm+QJonK+QJ4pMw@mail.gmail.com> Message-ID: <CAMyHAnMy1s1-m9A3oCUyTKr3bKg-JTt7ESpfMK1QOooBNX2XxA@mail.gmail.com> Dear all, I would just like to add that the interfacing between MEI and VexFlow is achieved through a JavaScript library originally written by Richard Lewis at Goldsmith's, University of London ( https://github.com/ironchicken/MEItoVexFlow), which has been extended for the project. Best wishes, Raffaele On Thu, Oct 11, 2012 at 1:43 PM, Richard Freedman <rfreedma at haverford.edu>wrote: > Friends, > > Just a short note to bring you up to date on the Du Chemin Project, and in > particular some excellent progress we have made with MEI. You can read the > details in the links below. I am printing the documents, too, and can > easily send along copies of the report to you. Just let me know if you > would like a copy. > > Meanwhile the most important developments (for the MEI group, in any > case): thanks to Raffaele Viglianti and Andrew Hankinson, we have a nice > system that allows us to move smoothly from our original Sibelius and > Finale transcriptions to MEI and then to on-screen rendering of musical > examples. The aim, as you might recall, is to build a large analytic > "thesaurus" of musical types and procedures from our repertory, then > coordinate these with proposed reconstructions of missing voice parts in > still other pieces. > > Follow the links below to see various explanations and demonstrations. > The attached set of images shows you just a small bit of what we can > do--in this case searching for a particular type of cadence, then > displaying the result. > > Meanwhile, best wishes for a productive year, > > > Richard > > > > Links to various reports and demonstrations: > > > A report on Year One of the Lost Voices Project > http://duchemin.haverford.edu/editorsforum/lost-voices-2012/ > > The latest version of the Thesaurus (now 3.2), available in segments or in > one file. http://duchemin.haverford.edu/editorsforum/thesaurus-3-2/ > > A Dossier documenting our methods, standards, and results so far. > http://duchemin.haverford.edu/editorsforum/lost-voices-2012/ > > Materials for the Ecole III at Tours, with pieces to analyze and > reconstruct (also some reconstructions for discussion). > http://duchemin.haverford.edu/editorsforum/ecole-thematique-iii-2012/ > > Demonstration of the new interface and the VexFlow system. (Not complete, > so don't be frustrated!). > http://duchemin.haverford.edu/editorsforum/search-the-thesaurus-3-2/ > > > > > > > -- > Richard Freedman > John C. Whitehead Professor of Music > Haverford College > Haverford, PA 19041 > > 610-896-1007 > 610-896-4902 (fax) > > http://www.haverford.edu/faculty/rfreedma > > > _______________________________________________ > 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/20121011/4e5ef2fd/attachment.html> From pdr4h at eservices.virginia.edu Mon Oct 15 20:50:14 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 15 Oct 2012 18:50:14 +0000 Subject: [MEI-L] revision of <bibl> Message-ID: <BBCC497C40D85642B90E9F94FC30343D0EFA9489@GRANT.eservices.virginia.edu> Hello, Those of you subscribed to the developers list may have already seen a version of this message. My apologies for cross-posting, but I think this is important enough to warrant soliciting a wide range of opinions, since some of the changes proposed will break backwards compatibility. In order to better support bibliographic applications, such as MerMEId, the content model of <bibl> needs to be revised/expanded. The example below contains several new elements -- creator, editor, contributor, biblScope, genre, imprint, pubPlace, and publisher. These might also be useful at other points in addition to within <bibl>, say in the header, but that is not under consideration at the moment. A new <recipient> element may also be added for correspondence. <distributor> will also be allowed in <imprint>. In addition, some existing elements, such as <creation>, should also be permitted within <bibl>. This will allow the capture of non-bibliographic details of creation, such as the location where an item was created. Also, some existing elements, such as <physLoc> and <relatedItem>, should be allowed after re-definition; that is, <physLoc> will no longer function as the call number/shelf location. It will function as the wrapper for <repository> and <identifier>. In this context, <identifier> will hold the shelf number. With the FRBR changes, <relatedItem> will be replaced by <relation>, allowing <relatedItem> to be used as illustrated here. The new element <biblList> will be a member of model.listLike, allowing it to be used wherever <list> is currently allowed. Other places where it might occur include <work>, <source> (will be called <item> after FRBR implementation, <event>, <eventList>, etc. <biblList> <bibl>  <genre authority="marcgt" authURI="http://www.loc.gov/standards/valuelist/marcgt.html">article</genre> <creator>Daniel Grimley</creator> <title level="a">Modernism and Closure: Nielsen's Fifth Symphony

From pdr4h at eservices.virginia.edu Tue Jan 3 15:20:07 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 3 Jan 2012 14:20:07 +0000 Subject: [MEI-L] and external references In-Reply-To: References: Message-ID: Hi, Alastair, In order to allow multiple end-points and to make MEI more conformant with TEI, the target attribute replaced xlink:href. In addition, @targettype was added to att.pointing so that *the targets* could be classified -- as opposed to the global type attribute which provides a way to classify the element *to which it's attached.* Happy New Year! -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Alastair Porter [alastair at porter.net.nz] Sent: Saturday, December 31, 2011 4:05 PM To: mei-l at lists.uni-paderborn.de Subject: [MEI-L] and external references Hi, I've been working on revalidating some old files against the latest version of the MEI schema (I've generated an RNG file from branches/MEI_dev) and have a question about the attributes to the element. The att.pointing attribute list contains definitions for attributes pointing to external sources. @actuate, @role, @show, and @title are defined in the xlink schema, however @target and @targettype are not. Old versions of the schema (e.g the tag library at http://music-encoding.org/documentation/tagLibrary/graphic) appear to use xlink:href for external sources instead. Is there a reason that these target attributes are not the xlink ones (e.g. xlink:href)? Thanks, Alastair From zupftom at googlemail.com Wed Jan 4 17:41:05 2012 From: zupftom at googlemail.com (TW) Date: Wed, 4 Jan 2012 17:41:05 +0100 Subject: [MEI-L] @dur on and Message-ID: Does anything speak against having @dur on and , like on ? If no, I'd add a feature request to the issue tracker. Thomas From andrew.hankinson at mail.mcgill.ca Wed Jan 4 18:38:46 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Wed, 4 Jan 2012 17:38:46 +0000 Subject: [MEI-L] @dur on and In-Reply-To: <3647_1325695279_4F04812F_3647_66_1_CAEB1mAq0AhWd5uGbCzc5evrDYK-OeusBazMfdBB7J-BXTQ6XTA@mail.gmail.com> References: <3647_1325695279_4F04812F_3647_66_1_CAEB1mAq0AhWd5uGbCzc5evrDYK-OeusBazMfdBB7J-BXTQ6XTA@mail.gmail.com> Message-ID: Hi Thomas, It sounds OK to me (I'll leave the logistics up to other people to chime in on), but we will need to make sure we tag it for the release *after* 2012 since the schema is now frozen. I've added a new tag called "Milestone-Release2013" (If someone can think of something better, I'll change it). Please use that to tag your feature request. Cheers, -Andrew On 2012-01-04, at 11:41 AM, TW wrote: > Does anything speak against having @dur on and , like > on ? If no, I'd add a feature request to the issue tracker. > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Wed Jan 4 18:47:03 2012 From: zupftom at googlemail.com (TW) Date: Wed, 4 Jan 2012 18:47:03 +0100 Subject: [MEI-L] @dur on and In-Reply-To: References: <3647_1325695279_4F04812F_3647_66_1_CAEB1mAq0AhWd5uGbCzc5evrDYK-OeusBazMfdBB7J-BXTQ6XTA@mail.gmail.com> Message-ID: I would have tagged it "Priority-Low", which is already described as "might slip to later milestone". 2012/1/4 Andrew Hankinson, Mr : > Hi Thomas, > > It sounds OK to me (I'll leave the logistics up to other people to chime in on), but we will need to make sure we tag it for the release *after* 2012 since the schema is now frozen. > > I've added a new tag called "Milestone-Release2013" (If someone can think of something better, I'll change it). Please use that to tag your feature request. > > Cheers, > -Andrew > > On 2012-01-04, at 11:41 AM, TW wrote: > >> Does anything speak against having @dur on and , like >> on ? ?If no, I'd add a feature request to the issue tracker. >> >> Thomas >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Wed Jan 4 20:09:34 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Wed, 4 Jan 2012 19:09:34 +0000 Subject: [MEI-L] @dur on and In-Reply-To: References: Message-ID: Adding @dur on and , or more precisely, making them members of the att.duration.musical and att.augmentdots classes, is ok with me. Doing so would make these elements consistent with the element; that is, as an encoding shortcut, @dur can be placed on the or parent element instead of on the child or elements. But, because these attributes can't be disallowed on the child elements (they're needed when and occur outside of and of course), it will be valid for @dur and @dots to occur in either or both places. Perhaps schematron rules could be created that disallow @dur and @dots on the child elements when they exist on the parent. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] Sent: Wednesday, January 04, 2012 11:41 AM To: Music Encoding Initiative Subject: [MEI-L] @dur on and Does anything speak against having @dur on and , like on ? If no, I'd add a feature request to the issue tracker. Thomas _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Wed Jan 4 20:32:03 2012 From: zupftom at googlemail.com (TW) Date: Wed, 4 Jan 2012 20:32:03 +0100 Subject: [MEI-L] @dur on and In-Reply-To: References: Message-ID: I submitted the issue for the 2013 milestone. 2012/1/4 Roland, Perry (pdr4h) : > Adding @dur on and , or more precisely, making them members of the att.duration.musical and att.augmentdots classes, is ok with me. > > Doing so would make these elements consistent with the element; that is, as an encoding shortcut, @dur can be placed on the or parent element instead of on the child or elements. > > But, because these attributes can't be disallowed on the child elements (they're needed when and occur outside of and of course), it will be valid for @dur and @dots to occur in either or both places. ?Perhaps schematron rules could be created that disallow @dur and @dots on the child elements when they exist on the parent. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] > Sent: Wednesday, January 04, 2012 11:41 AM > To: Music Encoding Initiative > Subject: [MEI-L] @dur on and > > Does anything speak against having @dur on and , like > on ? ?If no, I'd add a feature request to the issue tracker. > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 kepper at edirom.de Sat Jan 7 08:23:59 2012 From: kepper at edirom.de (Johannes Kepper) Date: Sat, 7 Jan 2012 08:23:59 +0100 Subject: [MEI-L] @dur on and In-Reply-To: References: Message-ID: <53DE0E79-F27A-4F59-AF88-C2D26D42CCDA@edirom.de> Am 04.01.2012 um 20:09 schrieb Roland, Perry (pdr4h): > Adding @dur on and , or more precisely, making them members of the att.duration.musical and att.augmentdots classes, is ok with me. > > Doing so would make these elements consistent with the element; that is, as an encoding shortcut, @dur can be placed on the or parent element instead of on the child or elements. > > But, because these attributes can't be disallowed on the child elements (they're needed when and occur outside of and of course), it will be valid for @dur and @dots to occur in either or both places. Perhaps schematron rules could be created that disallow @dur and @dots on the child elements when they exist on the parent. I wonder if we really want to disallow these attributes on the child elements. I have no access to Read etc. currently, but if I remember correctly, at least one of them allows chords to contain notes with differing length. I'm not sure if I would like to follow this argumentation, but I don't think that MEI should disallow such a situation. I'm perfectly happy to address this in the Guidelines and make sure that this would be a rather uncommon and unexpected situation, but although Schematron certainly can suppress @dur within chords and trems, I wouldn't recommend it. Just my two drachma? Johannes > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] > Sent: Wednesday, January 04, 2012 11:41 AM > To: Music Encoding Initiative > Subject: [MEI-L] @dur on and > > Does anything speak against having @dur on and , like > on ? If no, I'd add a feature request to the issue tracker. > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From pdr4h at eservices.virginia.edu Mon Jan 9 02:59:27 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 9 Jan 2012 01:59:27 +0000 Subject: [MEI-L] @dur on and In-Reply-To: <53DE0E79-F27A-4F59-AF88-C2D26D42CCDA@edirom.de> References: , <53DE0E79-F27A-4F59-AF88-C2D26D42CCDA@edirom.de> Message-ID: Noted, and anticipated. Hence, the word "perhaps". :) I probably should have said that schematron rules can be written to control this situation *when it is not desirable to allow 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Johannes Kepper [kepper at edirom.de] Sent: Saturday, January 07, 2012 2:23 AM To: Music Encoding Initiative Subject: Re: [MEI-L] @dur on and Am 04.01.2012 um 20:09 schrieb Roland, Perry (pdr4h): > Adding @dur on and , or more precisely, making them members of the att.duration.musical and att.augmentdots classes, is ok with me. > > Doing so would make these elements consistent with the element; that is, as an encoding shortcut, @dur can be placed on the or parent element instead of on the child or elements. > > But, because these attributes can't be disallowed on the child elements (they're needed when and occur outside of and of course), it will be valid for @dur and @dots to occur in either or both places. Perhaps schematron rules could be created that disallow @dur and @dots on the child elements when they exist on the parent. I wonder if we really want to disallow these attributes on the child elements. I have no access to Read etc. currently, but if I remember correctly, at least one of them allows chords to contain notes with differing length. I'm not sure if I would like to follow this argumentation, but I don't think that MEI should disallow such a situation. I'm perfectly happy to address this in the Guidelines and make sure that this would be a rather uncommon and unexpected situation, but although Schematron certainly can suppress @dur within chords and trems, I wouldn't recommend it. Just my two drachma? Johannes > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of TW [zupftom at googlemail.com] > Sent: Wednesday, January 04, 2012 11:41 AM > To: Music Encoding Initiative > Subject: [MEI-L] @dur on and > > Does anything speak against having @dur on and , like > on ? If no, I'd add a feature request to the issue tracker. > > Thomas > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 raffaeleviglianti at gmail.com Thu Jan 19 17:54:47 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 19 Jan 2012 16:54:47 +0000 Subject: [MEI-L] Drum notation, or...? Message-ID: Dear list, Please forgive me if this is a silly question with a simple answer, but I've been asked to produce an encoding of this: http://www.warmuseum.ca/cwm/exhibitions/guerre/photo-e.aspx?PageId=4.B.3&photo=3.D.8.c&f=%2Fcwm%2Fexhibitions%2Fguerre%2Fa-soldiers-life-e.aspx What is the text above the staff? I suspect it is another staff for some sort of drum, probably a military drum. However, I've never come across anything like this and I can't really make sense of it, except maybe for a few things like "r" for roll. Does anyone know that that is and how to read it? And also: how would one go about encoding that in MEI? Best wishes, Raffaele -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.hankinson at mail.mcgill.ca Thu Jan 19 18:17:54 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Thu, 19 Jan 2012 17:17:54 +0000 Subject: [MEI-L] Drum notation, or...? In-Reply-To: <28671_1326992122_4F184AF9_28671_243_1_CAMyHAnPNO1JSrVOaqP+YdFr2TXrTb0vHxeTk=_cHnPY9wUNX5Q@mail.gmail.com> References: <28671_1326992122_4F184AF9_28671_243_1_CAMyHAnPNO1JSrVOaqP+YdFr2TXrTb0vHxeTk=_cHnPY9wUNX5Q@mail.gmail.com> Message-ID: <66EF65EF-ABE2-4BB8-BE6B-FC95CCC470EC@mail.mcgill.ca> Hi Raffaele, That's good ol' solfege notation! d = do r = re m = mi etc... -Andrew On 2012-01-19, at 11:54 AM, Raffaele Viglianti wrote: Dear list, Please forgive me if this is a silly question with a simple answer, but I've been asked to produce an encoding of this: http://www.warmuseum.ca/cwm/exhibitions/guerre/photo-e.aspx?PageId=4.B.3&photo=3.D.8.c&f=%2Fcwm%2Fexhibitions%2Fguerre%2Fa-soldiers-life-e.aspx What is the text above the staff? I suspect it is another staff for some sort of drum, probably a military drum. However, I've never come across anything like this and I can't really make sense of it, except maybe for a few things like "r" for roll. Does anyone know that that is and how to read it? And also: how would one go about encoding that in MEI? Best wishes, Raffaele _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/mailman/listinfo/mei-l From craigsapp at gmail.com Thu Jan 19 18:26:29 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 19 Jan 2012 09:26:29 -0800 Subject: [MEI-L] Drum notation, or...? In-Reply-To: References: Message-ID: Hi Raffelle, That is Tonic Sol-Fa. I have it in in a list of music representations: http://www.ccarh.org/courses/253/link/index.html#TonicSolFa ?"Text-based notation system which can be written on a standard typewriter developed by John Curwen in the middle of the 19th century in England. Similar in functionality to Shape-note notation but without staff lines. " en.wikipedia.org/wiki/Tonic_sol-fa www.mcsr.olemiss.edu/~mudws/notes/solfa.html (example) -=+Craig From raffaeleviglianti at gmail.com Thu Jan 19 18:36:01 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 19 Jan 2012 17:36:01 +0000 Subject: [MEI-L] Drum notation, or...? In-Reply-To: References:

Message-ID: Ah! Thanks Andrew and Craig. I've never come across it before. Ok, it makes sense, but is it just me or is that all a semitone up compared to the notation below? Any suggestions for encoding this in MEI? I'd think the only way at the moment is by adding directions on top of notes, but it doesn't sounds great. Best, Raffaele On Thu, Jan 19, 2012 at 5:26 PM, Craig Sapp wrote: > Hi Raffelle, > > That is Tonic Sol-Fa. > > I have it in in a list of music representations: > http://www.ccarh.org/courses/253/link/index.html#TonicSolFa > > "Text-based notation system which can be written on a standard > typewriter developed by John Curwen in the middle of the 19th century > in England. Similar in functionality to Shape-note notation but > without staff lines. " > > en.wikipedia.org/wiki/Tonic_sol-fa > > www.mcsr.olemiss.edu/~mudws/notes/solfa.html (example) > > -=+Craig > > _______________________________________________ > 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 Thu Jan 19 18:55:12 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Thu, 19 Jan 2012 09:55:12 -0800 Subject: [MEI-L] Drum notation, or...? In-Reply-To: References:

Message-ID: Hi Raffaele, > I've never come across it before. Ok, it makes sense, but is it just me or > is that all a semitone up compared to the notation below? Only because you are thinking (like a southern European) in a fixed-do system. The Tonic Sol-Fa method placed "do" on the tonic note, which in this case is B-flat (or B for Germans :-). Technically this is a parallel equivalent representation of the graphical music notation, so it should not necessarily be represented inside MEI (unless you want to duplicate encoding work), but rather be generated from the musical data in MEI. The only piece of non-graphical information needed should be the tonic note, then the notation can be derived from the MEI data which also generates the graphical notation. -=+Craig From pdr4h at eservices.virginia.edu Thu Jan 19 20:04:51 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 19 Jan 2012 19:04:51 +0000 Subject: [MEI-L] Drum notation, or...? In-Reply-To: References:

, Message-ID: Craig is correct -- the ideal way to get the solfa is to generate it. BUT, is a member of att.solfa, which provides @psolfa for capturing solfa along with (or instead of) pitch name. -- 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com] Sent: Thursday, January 19, 2012 12:55 PM To: Music Encoding Initiative Subject: Re: [MEI-L] Drum notation, or...? Hi Raffaele, > I've never come across it before. Ok, it makes sense, but is it just me or > is that all a semitone up compared to the notation below? Only because you are thinking (like a southern European) in a fixed-do system. The Tonic Sol-Fa method placed "do" on the tonic note, which in this case is B-flat (or B for Germans :-). Technically this is a parallel equivalent representation of the graphical music notation, so it should not necessarily be represented inside MEI (unless you want to duplicate encoding work), but rather be generated from the musical data in MEI. The only piece of non-graphical information needed should be the tonic note, then the notation can be derived from the MEI data which also generates the graphical notation. -=+Craig _______________________________________________ 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 Thu Jan 19 21:07:20 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Thu, 19 Jan 2012 20:07:20 +0000 Subject: [MEI-L] Drum notation, or...? In-Reply-To: References:

Message-ID: Ok, this all makes sense now. Many thanks! Raffaele On Jan 19, 2012 7:04 PM, "Roland, Perry (pdr4h)" < pdr4h at eservices.virginia.edu> wrote: > Craig is correct -- the ideal way to get the solfa is to generate it. > BUT, is a member of att.solfa, which provides @psolfa for capturing > solfa along with (or instead of) pitch name. > > -- > 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-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de[mei-l-bounces+pdr4h= > virginia.edu at lists.uni-paderborn.de] on behalf of Craig Sapp [ > craigsapp at gmail.com] > Sent: Thursday, January 19, 2012 12:55 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] Drum notation, or...? > > Hi Raffaele, > > > I've never come across it before. Ok, it makes sense, but is it just me > or > > is that all a semitone up compared to the notation below? > > Only because you are thinking (like a southern European) in a fixed-do > system. The Tonic Sol-Fa method placed "do" on the tonic note, which > in this case is B-flat (or B for Germans :-). > > Technically this is a parallel equivalent representation of the > graphical music notation, so it should not necessarily be represented > inside MEI (unless you want to duplicate encoding work), but rather be > generated from the musical data in MEI. The only piece of > non-graphical information needed should be the tonic note, then the > notation can be derived from the MEI data which also generates the > graphical notation. > > > -=+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 pdr4h at eservices.virginia.edu Thu Feb 9 16:07:46 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 9 Feb 2012 15:07:46 +0000 Subject: [MEI-L] @trans.diat and @trans.semi Message-ID: Looking at the documentation for these 2 attributes, it isn't exactly clear what values are expected. The documentation for trans.diat says, "records the amount of diatonic pitch shift, e.g. C to C? = 0, C to D? = 1. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from C to C? and one from C to D?." while for trans.semi, it says, "contains the amount of pitch shift in semitones, C to C? = 1, C to D? = 1. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from C to C? and one from C to D?." So, for the clarinet in B?should the values be trans.diat="1" and trans.semi="2", or should they read trans.diat="-1" and trans.semi="-2" ? It seems to me that the first set of values is somewhat redundant since the written pitches for the clarinet are already recorded as one step "too high" with respect to concert pitch. This redundancy, however, could be used to mean that the written pitches are not errors; that is, that an F# on the clarinet staff is correct in the concert key of C. Another way to approach these attributes (which is, by the way, used in the musicxml2mei XSL transform) is to use them to indicate the amount of "correction" necessary to achieve the concert pitch from the written one. In this case, the second set of values would be more helpful; that is, given a pitch of D4, to get a performable concert pitch, subtract the value of trans.semi. (Or perhaps more technically correct, add -2 semitones.) So, having made the decision once before (when writing the XSL transform), it would be convenient to make the documentation agree with the already-made decision. However, if anyone has a good argument, other than tradition, why this decision (and the documentation) should be reversed, please speak up. -- 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 craigsapp at gmail.com Sat Feb 11 03:23:03 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Fri, 10 Feb 2012 18:23:03 -0800 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: Message-ID: Hi Perry, The specification seems to come from Humdrum trans tool (which in turn comes from some 2D algorithm of transposition): http://musicog.ohio-state.edu/Humdrum/commands/trans.html And I have a transposing program for Humdrum which implements the base-40 method of transposing: http://extra.humdrum.org/man/transpose Example: Here is the score for a B-flat clarinet in Humdrum format: **kern *ITrd1c2 *Iclars *k[] *C: 4c 4d 4e 4f 4g 4a 4b 4cc *- The pitches are listed in concert pitch (the convention for Humdrum scores), and there is an interpretation "*ITrd1c2" which gives instructions on how to transpose to written pitch: *I = instrument code Tr = transpose d1 = go up one diatonic step c2 = while going up two chromatic steps So C->D, C#->D# and so on. > So, for the clarinet in B?should the values be trans.diat="1" and trans.semi="2", or should they read trans.diat="-1" and trans.semi="-2" ? I would say that using trans.diat="1" and trans.semi="2" would be better (particularly if the pitches in the file are listed in concert pitch). And these numbers then represent the transposition amount/direction which is necessary to transpose from concert pitch to written pitch of the transposing instrument. Since B-flat clarinets "sound down" they need to "transpose up" to get to the written pitch, so the intervals should be positive. In the documentation you should say something like "the transposition values indicate the size and direction of the transposition interval used to transpose concert pitches into written pitches for the transposing instrument." If you want the transposition to mean the size/direction to go from written to concert (which is the same size but reverse direction), then you switch the wording (although I would prefer convert->written transposition to be encoded in the score). In Humdrum files, the pitches are always expected to be in concert pitch. I use my transpose program mentioned above to transpose written parts into sounding parts when going from OMR encoded data into a final score. In that case I have a "-I" option which stores the reverse of the written->sounding transposition in the final score (I transpose down the B-flat part to concert pitch, but I store the upward direction indicating how to go from concert pitch to written). Are transposing parts always encoded in concert pitch in MEI? If so, then the sounding->written direction for transposition is very much preferred. If the MEI files can have either concert or written pitch, then what to do is not as clear. I would have the transposition value always from concert->written, and then some indication of what state the score/part is in, either "written" or "sounding". If the score is in Written mode, then the transpose interval would be negated to convert to concert pitch, and if the score is in Concert mode, then the transpose interval would be used as-is to transpose to Written mode. <> You or I are confused about this sentence. Given the pitch of D4 written for a B-flat clarinet, you need to apply both trans.semi and trans.diat to calculate the concert pitch (not just trans.semi; both are needed to get the correct transposed diatonic pitch name). In terms of calculating a base-12 MIDI pitch, you can just use trans.semi, but for correct diatonic spelling you will need both: go down one diatonic step while doing down two chromatic steps which is D4 to C4 (down a major second): D->C:d->c#->c. -=+Craig 2012/2/9 Roland, Perry (pdr4h) > Looking at the documentation for these 2 attributes, it isn't exactly > clear what values are expected. The documentation for trans.diat says, > > "records the amount of diatonic pitch shift, e.g. C to C? = 0, C to D? = > 1. > Transposition requires both trans.diat and trans.semi attributes in > order to distinguish > the difference, for example, between a transposition from C to C? and > one from C to D?." > > while for trans.semi, it says, > > "contains the amount of pitch shift in semitones, C to C? = 1, C to D? = > 1. > Transposition requires both trans.diat and trans.semi attributes in order > to distinguish > the difference, for example, between a transposition from C to C? and one > from C to D?." > > So, for the clarinet in B?should the values be trans.diat="1" and > trans.semi="2", or should they read trans.diat="-1" and trans.semi="-2" ? > > It seems to me that the first set of values is somewhat redundant since > the written pitches for the clarinet are already recorded as one step "too > high" with respect to concert pitch. This redundancy, however, could be > used to mean that the written pitches are not errors; that is, that an F# > on the clarinet staff is correct in the concert key of C. > > Another way to approach these attributes (which is, by the way, used in > the musicxml2mei XSL transform) is to use them to indicate the amount of > "correction" necessary to achieve the concert pitch from the written one. > In this case, the second set of values would be more helpful; that is, > given a pitch of D4, to get a performable concert pitch, subtract the value > of trans.semi. (Or perhaps more technically correct, add -2 semitones.) > > So, having made the decision once before (when writing the XSL transform), > it would be convenient to make the documentation agree with the > already-made decision. However, if anyone has a good argument, other than > tradition, why this decision (and the documentation) should be reversed, > please speak up. > > -- > 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 cuthbert at MIT.EDU Sat Feb 11 20:10:51 2012 From: cuthbert at MIT.EDU (Michael Scott Cuthbert) Date: Sat, 11 Feb 2012 14:10:51 -0500 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: Message-ID: <005b01cce8f0$df985800$9ec90800$@mit.edu> The processes Craig and Perry suggest work well for simple cases, but break on more difficult instruments, keys, and transpositions. A Db piccolo (very common in band music) might technically be -1 diatonic, -1 chromatic, but it?s quite often 0 diatonic, -1 chromatic when the scores go even a bit towards the sharp side. Even the B-flat clarinet often will choose to be an A# clarinet when the orchestra is in 5, 6, or 7 sharps. And in pieces for band, learning ensembles, etc., individual notes will be written enharmonically. So that a concert-pitch passage, C, D, D#, E#, F# might be written as D, E, F, G, Ab so as to avoid needing using double sharps or augmented intervals. Notating the score in written pitch is the better way to avoid this problem. Best, Myke From: mei-l-bounces at lists.uni-paderborn.de [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp Sent: Friday, February 10, 2012 21:23 To: Music Encoding Initiative Subject: Re: [MEI-L] @trans.diat and @trans.semi Hi Perry, The specification seems to come from Humdrum trans tool (which in turn comes from some 2D algorithm of transposition): http://musicog.ohio-state.edu/Humdrum/commands/trans.html And I have a transposing program for Humdrum which implements the base-40 method of transposing: http://extra.humdrum.org/man/transpose Example: Here is the score for a B-flat clarinet in Humdrum format: **kern *ITrd1c2 *Iclars *k[] *C: 4c 4d 4e 4f 4g 4a 4b 4cc *- The pitches are listed in concert pitch (the convention for Humdrum scores), and there is an interpretation "*ITrd1c2" which gives instructions on how to transpose to written pitch: *I = instrument code Tr = transpose d1 = go up one diatonic step c2 = while going up two chromatic steps So C->D, C#->D# and so on. > So, for the clarinet in B?should the values be trans.diat="1" and trans.semi="2", or should they read trans.diat="-1" and trans.semi="-2" ? I would say that using trans.diat="1" and trans.semi="2" would be better (particularly if the pitches in the file are listed in concert pitch). And these numbers then represent the transposition amount/direction which is necessary to transpose from concert pitch to written pitch of the transposing instrument. Since B-flat clarinets "sound down" they need to "transpose up" to get to the written pitch, so the intervals should be positive. In the documentation you should say something like "the transposition values indicate the size and direction of the transposition interval used to transpose concert pitches into written pitches for the transposing instrument." If you want the transposition to mean the size/direction to go from written to concert (which is the same size but reverse direction), then you switch the wording (although I would prefer convert->written transposition to be encoded in the score). In Humdrum files, the pitches are always expected to be in concert pitch. I use my transpose program mentioned above to transpose written parts into sounding parts when going from OMR encoded data into a final score. In that case I have a "-I" option which stores the reverse of the written->sounding transposition in the final score (I transpose down the B-flat part to concert pitch, but I store the upward direction indicating how to go from concert pitch to written). Are transposing parts always encoded in concert pitch in MEI? If so, then the sounding->written direction for transposition is very much preferred. If the MEI files can have either concert or written pitch, then what to do is not as clear. I would have the transposition value always from concert->written, and then some indication of what state the score/part is in, either "written" or "sounding". If the score is in Written mode, then the transpose interval would be negated to convert to concert pitch, and if the score is in Concert mode, then the transpose interval would be used as-is to transpose to Written mode. <> You or I are confused about this sentence. Given the pitch of D4 written for a B-flat clarinet, you need to apply both trans.semi and trans.diat to calculate the concert pitch (not just trans.semi; both are needed to get the correct transposed diatonic pitch name). In terms of calculating a base-12 MIDI pitch, you can just use trans.semi, but for correct diatonic spelling you will need both: go down one diatonic step while doing down two chromatic steps which is D4 to C4 (down a major second): D->C:d->c#->c. -=+Craig 2012/2/9 Roland, Perry (pdr4h) Looking at the documentation for these 2 attributes, it isn't exactly clear what values are expected. The documentation for trans.diat says, "records the amount of diatonic pitch shift, e.g. C to C? = 0, C to D? = 1. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from C to C? and one from C to D?." while for trans.semi, it says, "contains the amount of pitch shift in semitones, C to C? = 1, C to D? = 1. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from C to C? and one from C to D?." So, for the clarinet in B?should the values be trans.diat="1" and trans.semi="2", or should they read trans.diat="-1" and trans.semi="-2" ? It seems to me that the first set of values is somewhat redundant since the written pitches for the clarinet are already recorded as one step "too high" with respect to concert pitch. This redundancy, however, could be used to mean that the written pitches are not errors; that is, that an F# on the clarinet staff is correct in the concert key of C. Another way to approach these attributes (which is, by the way, used in the musicxml2mei XSL transform) is to use them to indicate the amount of "correction" necessary to achieve the concert pitch from the written one. In this case, the second set of values would be more helpful; that is, given a pitch of D4, to get a performable concert pitch, subtract the value of trans.semi. (Or perhaps more technically correct, add -2 semitones.) So, having made the decision once before (when writing the XSL transform), it would be convenient to make the documentation agree with the already-made decision. However, if anyone has a good argument, other than tradition, why this decision (and the documentation) should be reversed, please speak up. -- 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 craigsapp at gmail.com Sat Feb 11 20:41:46 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Sat, 11 Feb 2012 11:41:46 -0800 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: <005b01cce8f0$df985800$9ec90800$@mit.edu> References: <005b01cce8f0$df985800$9ec90800$@mit.edu> Message-ID: Hi Myke, On Sat, Feb 11, 2012 at 11:10 AM, Michael Scott Cuthbert wrote: > Even the B-flat clarinet often will choose to be an A# clarinet when the > orchestra is in 5, 6, or 7 sharps. This wouldn't be a problem, since the transposition is related to how you want to see it on the page, not to the name of the instrument. B-flat transposition would be 1 diatonic 2 chromatic (C->B; c->b->b-flat), A-sharp transposition would be 2 diatonic 2 chromatic (C->B->A; c->b->a#). Similarly for D-flat/C# piccolo. > And in pieces for band, learning ensembles, etc., individual notes will be > written enharmonically. So that a concert-pitch passage, C, D, D#, E#, F# > might be written as D, E, F, G, Ab so as to avoid needing using double > sharps or augmented intervals. Notating the score in written pitch is the > better way to avoid this problem. This is a good point, but can also be handled by a constant transposition system. The enharmonic spelling would be stored in the sounding-pitch spellings, rather than changed afterwards once the written notes are calculated. In other words the written pitches D E F G Ab are represented in concert pitch as: C D Eb F Gb and not as C D D# E# F# -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From cuthbert at MIT.EDU Sat Feb 11 21:04:31 2012 From: cuthbert at MIT.EDU (Michael Scott Cuthbert) Date: Sat, 11 Feb 2012 15:04:31 -0500 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: <005b01cce8f0$df985800$9ec90800$@mit.edu> Message-ID: <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> > > From: Craig Sapp > On Sat, Feb 11, 2012 at 11:10 AM, Michael Scott Cuthbert wrote: > Even the B-flat clarinet often will choose to be an A# clarinet when the orchestra is in 5, 6, or 7 sharps. > This wouldn't be a problem, since the transposition is related to how you want to see it on the page, not to the name of the instrument. B-flat transposition would be 1 diatonic 2 chromatic (C->B; c->b->b-flat), A-sharp transposition would be 2 diatonic 2 chromatic (C->B->A; c->b->a#). Similarly for D-flat/C# piccolo. The issue is that you want to be able to change the transposition for different passages, and I don't think that changing the Instrument tag is the best approach. > And in pieces for band, learning ensembles, etc., individual notes will be written enharmonically. So that a concert-pitch passage, C, D, D#, E#, F# might be written as D, E, F, G, Ab so as to avoid needing using double sharps or augmented intervals. Notating the score in written pitch is the better way to avoid this problem. > This is a good point, but can also be handled by a constant transposition system. The enharmonic spelling would be stored in the sounding-pitch spellings, rather than changed afterwards once the written notes are calculated. In other words the written pitches D E F G Ab are represented in concert pitch as: C D Eb F Gb and not as C D D# E# F# What you would like to have is the clarinet's notes displaying as "C D D# E# F#" when the score is viewed in concert pitch (so it matches the rest of the ensemble) and "D E F G Ab" when viewed transposed; the alternate representation ("C D Eb F Gb") represents a passage that doesn't appear in either a concert-pitch score or on the performers' parts. It may be too difficult to encode such things but they're frequently done instinctively by skilled copyists. Best, Myke -=+Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craigsapp at gmail.com Sat Feb 11 22:33:17 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Sat, 11 Feb 2012 13:33:17 -0800 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> Message-ID: Hi Myke, On Sat, Feb 11, 2012 at 12:04 PM, Michael Scott Cuthbert wrote: > The issue is that you want to be able to change the transposition for > different passages, and I don?t think that changing the Instrument tag is > the best approach. > Yes, there will be cases where the transposition for a transposing instrument may alternate between enharmonic equivalents within the same movement. A good example is Tchaikovsky's Romeo and Juliet overture-fantasy: http://imslp.org/wiki/Romeo_and_Juliet_%28overture-fantasia%29_%28Tchaikovsky,_Pyotr%29 In this piece the first two keys are A major and A-flat major. The Clarinet in A is notated with C major and B major, rather than C major and C-flat major. I just encoded this work via OMR with SharpEye from the parts. I prepared MuseData files for Walter in written pitch, and then he transposes to concert pitch and adds a transpotion-to-written-pitch code in the MuseData files (similar to Humdrum), since MuseData files for printing are stored in concert pitch with transposition instructions given for generating written pitch spellings. In measure 1 of the A clarinets, there will be an instruction to transpose up a minor third, while in measure 21 there will be an instruction to transpose up a diminished second (enharmonically equivalent to a minor third). Written parts for timpani are complicated--parts are displayed transposed, and there is no key signature notated (invisible key signature :-). > ** > > > And in pieces for band, learning ensembles, etc., individual notes will > be written enharmonically. So that a concert-pitch passage, C, D, D#, E#, > F# might be written as D, E, F, G, Ab so as to avoid needing using double > sharps or augmented intervals. Notating the score in written pitch is the > better way to avoid this problem. **** > > This is a good point, but can also be handled by a constant transposition > system. The enharmonic spelling would be stored in the sounding-pitch > spellings, rather than changed afterwards once the written notes are > calculated. In other words the written pitches > D E F G Ab > are represented in concert pitch as: > C D Eb F Gb > and not as > C D D# E# F# > > What you would like to have is the clarinet?s notes displaying as ?C D D# > E# F#? when the score is viewed in concert pitch (so it matches the rest of > the ensemble) and ?D E F G Ab? when viewed transposed; the alternate > representation (?C D Eb F Gb?) represents a passage that doesn?t appear in > either a concert-pitch score or on the performers? parts. It may be too > difficult to encode such things but they?re frequently done instinctively > by skilled copyists. The key phrase is "skilled copyist" which computers cannot be (not to mention "instictively" :-). In other words, to use the same data for generating a transposed part and a concert-pitch score, you would probably use variants in MEI. One variant specifies how to display it in the transposed part, and the other variant for the concert-pitch score. Transposition without enharmonic alteration is deterministic, so the written variant could equally be stored in concert pitch or written pitch. If you are going to be utilizing enharmonic equivalents, then neither system is better (if you are going to want to display in both written-pitch and concert-pitch). Humdrum and MuseData encode parts in concert pitch. I just checked, and MusicXML does it the other way. Here is a C-sounding pitch in a B-flat clarinet part which includes a transpose-to-concert-pitch instruction: 1 2 major 4

G 2 -1 -2 D 4 4 1 whole

light-heavy

G 2 -1 -2 D 4 4 1 whole

light-heavy

The tag is vague, as Perry was pointing out for MEI's equivalent. It should more verbosely be in contrast to . But it seems that the MusicXML convention is to encode the part already transposed, and then indicate the transpostion from written -> concert pitch. It would be useful specify the state of the data (written or concert) and also an explicit direction that the transposition represents (such as written->concert or concert->written). When going in the opposite direction the transposition interval could be reversed without confusion, such as concert data with a written->concert transposition could generate the written data by negating the written->concert transposition. -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Sun Feb 12 23:22:18 2012 From: kepper at edirom.de (Johannes Kepper) Date: Sun, 12 Feb 2012 23:22:18 +0100 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu>, Message-ID: <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> Hi all, I would like to add some more points to this discussion. In my opinion, allowing both directions of transposition in MEI is the worst decision we could ever make. This would require absolutely every application dealing with MEI files to be capable of calculating the pitches as it needs them. If we pick one, we can spare at least some tools from this additional effort. If MEI stores concert pitch, this would be more natural to sound-focused apps (-> MIDI exporters) and for music analysis. If it keeps written pitch, it would be much easier for renderers, OMR and hand encoders not sure what they're facing. It might be my personal focus to understand MEI as being somewhat document-centric, but there is another argument to choose written pitch: MIR tools are normally operating on simplifications of the original data (n-grams etc.), but not on data as complex as pure MEI. If they're abstracting anyway, adding the step of transposition to their calculations seems less demanding to me than to require a renderer to "misplace" every single note. After all, I could back a decision for concert pitch, but I think it would be a very bad choice to allow both directions at the same time. We only add unnecessary complexity, processing efforts and a potential source for trouble without a need. Best regards, Johannes Am 11.02.2012 um 23:26 schrieb Roland, Perry (pdr4h): > Hi, Craig, Mike, everyone, > > Thanks for jumping in. > > It's a good idea to use written pitch in MEI because 1) it's the only thing naive encoders (human and mechanical) know about the notation and 2) MusicXML is often the source of MEI data. BTW, if I remember correctly, the MusicXML documentation says that pitch should be encoded at sounding pitch, but in practice most implementations use written pitch. > > However, MEI doesn't have to limited to encoding written pitch -- there must to be a way of stating whether the document captures written pitch (with transposition to concert pitch) or vice versa. So, I propose adding another attribute (trans.method, trans.dir, or similar name) that takes the values "toConcert" or "toWritten" in order to capture the "state of the data" as Craig called it, as well as the target. The assumption is that "toConcert" means that the data is captured "asWritten" and vice versa. Even though I agree with Mike that encoding written pitch is a better starting point, the extra attribute permits MuseData-style, concert pitch encodings too. > > With the addition of this new attribute, in the case of the Bb clarinet, trans.diat and trans.semi can accommodate the values "1" and "2" or "-1" and "-2", depending on the pitch-encoding style. > > The presence of any of the @trans* attributes is contextual. Of course, a non-transposing staff won't use them at all. If a diatonic transposition is desired, as Craig pointed out, @trans.diat and @trans.semi must both be given. However, if a base-12 MIDI pitch is enough, only @trans.semi is necessary. However, if @trans.diat or @trans.semi is present, @trans.dir must be present. The bottom line is that all these attributes must be optional and the context of their use controlled by schematron. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Craig Sapp [craigsapp at gmail.com] > Sent: Saturday, February 11, 2012 4:33 PM > To: Music Encoding Initiative > Subject: Re: [MEI-L] @trans.diat and @trans.semi > > Hi Myke, > > On Sat, Feb 11, 2012 at 12:04 PM, Michael Scott Cuthbert wrote: > The issue is that you want to be able to change the transposition for different passages, and I don?t think that changing the Instrument tag is the best approach. > > Yes, there will be cases where the transposition for a transposing instrument may alternate between enharmonic equivalents within the same movement. A good example is Tchaikovsky's Romeo and Juliet overture-fantasy: > http://imslp.org/wiki/Romeo_and_Juliet_%28overture-fantasia%29_%28Tchaikovsky,_Pyotr%29 > In this piece the first two keys are A major and A-flat major. The Clarinet in A is notated with C major and B major, rather than C major and C-flat major. > > I just encoded this work via OMR with SharpEye from the parts. I prepared MuseData files for Walter in written pitch, and then he transposes to concert pitch and adds a transpotion-to-written-pitch code in the MuseData files (similar to Humdrum), since MuseData files for printing are stored in concert pitch with transposition instructions given for generating written pitch spellings. In measure 1 of the A clarinets, there will be an instruction to transpose up a minor third, while in measure 21 there will be an instruction to transpose up a diminished second (enharmonically equivalent to a minor third). > > Written parts for timpani are complicated--parts are displayed transposed, and there is no key signature notated (invisible key signature :-). > > > And in pieces for band, learning ensembles, etc., individual notes will be written enharmonically. So that a concert-pitch passage, C, D, D#, E#, F# might be written as D, E, F, G, Ab so as to avoid needing using double sharps or augmented intervals. Notating the score in written pitch is the better way to avoid this problem. > This is a good point, but can also be handled by a constant transposition system. The enharmonic spelling would be stored in the sounding-pitch spellings, rather than changed afterwards once the written notes are calculated. In other words the written pitches > D E F G Ab > are represented in concert pitch as: > C D Eb F Gb > and not as > C D D# E# F# > > What you would like to have is the clarinet?s notes displaying as ?C D D# E# F#? when the score is viewed in concert pitch (so it matches the rest of the ensemble) and ?D E F G Ab? when viewed transposed; the alternate representation (?C D Eb F Gb?) represents a passage that doesn?t appear in either a concert-pitch score or on the performers? parts. It may be too difficult to encode such things but they?re frequently done instinctively by skilled copyists. > > The key phrase is "skilled copyist" which computers cannot be (not to mention "instictively" :-). In other words, to use the same data for generating a transposed part and a concert-pitch score, you would probably use variants in MEI. One variant specifies how to display it in the transposed part, and the other variant for the concert-pitch score. > > Transposition without enharmonic alteration is deterministic, so the written variant could equally be stored in concert pitch or written pitch. If you are going to be utilizing enharmonic equivalents, then neither system is better (if you are going to want to display in both written-pitch and concert-pitch). > > Humdrum and MuseData encode parts in concert pitch. I just checked, and MusicXML does it the other way. Here is a C-sounding pitch in a B-flat clarinet part which includes a transpose-to-concert-pitch instruction: > > > > > 1 > > 2 > major > > > 4 > 4 > > > G > 2 > > > -1 > -2 > > > > > > D > 4 > > 4 > 1 > whole > > > light-heavy > > > > > > The tag is vague, as Perry was pointing out for MEI's equivalent. It should more verbosely be in contrast to . But it seems that the MusicXML convention is to encode the part already transposed, and then indicate the transpostion from written -> concert pitch. > > It would be useful specify the state of the data (written or concert) and also an explicit direction that the transposition represents (such as written->concert or concert->written). When going in the opposite direction the transposition interval could be reversed without confusion, such as concert data with a written->concert transposition could generate the written data by negating the written->concert transposition. > > -=+Craig > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From craigsapp at gmail.com Mon Feb 13 04:03:18 2012 From: craigsapp at gmail.com (Craig Sapp) Date: Sun, 12 Feb 2012 19:03:18 -0800 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> Message-ID: Hi MEIers, On Sun, Feb 12, 2012 at 2:22 PM, Johannes Kepper wrote: > > I would like to add some more points to this discussion. In my opinion, > allowing both directions of transposition in MEI is the worst decision we > could ever make. This would require absolutely every application dealing > with MEI files to be capable of calculating the pitches as it needs them. > It will be less confusing if the transposed parts were stored in the transposed state. And I have looked more closely at a MuseData part and now see that they are stored in the written (transposed) form. Here is the start of the 1st clarinet (in A) which has an F5 of the transposed form (see the score: http://www.musedata.org/cgi-bin/mddata?work=beet/bh/sym/no2&file=distrib/pdf/score-hand/work.pdf) Breitkopf & H\a3rtel, Leipzig, Series 1 No. 2 Beethoven Symphony No. 2 in D Major, Op. 36 Mvt. 1 Clarinetto 1 in A 0 0 Group memberships: sound sound: part 5 of 18 $ K:-1 Q:24 T:3/4 C:4 X:-11 D:Adagio molto F5 3 t d ff measure 1 F5 36 q. d F rest 12 e rest 24 q measure 2 rest 72 measure 3 rest 72 measure 4 rest 24 q rest 12 e G5 9 s. d [[ p. The "$.. X:-11" information indicates how to get from the written form to the concert pitch form (-11 means transpose down a minor third). So I think that the original form of the MEI transposition attributes are intended to mean the same thing (likewise MusicXML). B-flat clarinets parts would be encoded in the transposed state, with @trans.diat="-1" and @trans.semit="-2" given to indicate how to get to concert pitch from the written state of the data. So since both MuseData and MusicXML store transposed parts in transposed form, it is a wise idea to do the same in MEI. (This also explains why I have to fix some transpositions in Haydn symphony data converted from MuseData to Humdrum which does not have the transposition information necessary to get to concert pitch). > If MEI stores concert pitch, this would be more natural to sound-focused > apps (-> MIDI exporters) and for music analysis. If it keeps written pitch, > it would be much easier for renderers, OMR and hand encoders not sure what > they're facing. > So you can guess what Perry will say :-) It might be my personal focus to understand MEI as being somewhat > document-centric, but there is another argument to choose written pitch: > MIR tools are normally operating on simplifications of the original data > (n-grams etc.), but not on data as complex as pure MEI. If they're > abstracting anyway, adding the step of transposition to their calculations > seems less demanding to me than to require a renderer to "misplace" every > single note. > Transposition is fairly trivial and deterministic, so a renderer which has problems with transposition will most likely have lots of other bugs in it... MEI Iron is the ideal place to simplify the data to a standardized form. The user/application could specify to MEI Iron that they want transposed data to end up in the written state or the concert-pitch state, then no matter what the original state of the data, the output from MEI Iron is what is desired. When a part-generating program wants the data in transpose form, it asks MEI Iron for the transposed state of the data, when a MIDI-generating program want the data in concert pitch, it asks MEI Iron for data in the untransposed state. When a renderer needs to display the score in concert-pitch, it could alternately ask MEI Iron for data in the concert-pitch state. -=+Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From kepper at edirom.de Mon Feb 13 09:45:45 2012 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 13 Feb 2012 09:45:45 +0100 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> Message-ID: <4D829BDA-852E-4563-9B16-85B726C75DAA@edirom.de> Hi Craig, Am 13.02.2012 um 04:03 schrieb Craig Sapp: > Hi MEIers, > > On Sun, Feb 12, 2012 at 2:22 PM, Johannes Kepper wrote: > >> I would like to add some more points to this discussion. In my opinion, allowing both directions of transposition in MEI is the worst decision we could ever make. This would require absolutely every application dealing with MEI files to be capable of calculating the pitches as it needs them. >> > It will be less confusing if the transposed parts were stored in the transposed state. And I have looked more closely at a MuseData part and now see that they are stored in the written (transposed) form. Here is the start of the 1st clarinet (in A) which has an F5 of the transposed form (see the score: http://www.musedata.org/cgi-bin/mddata?work=beet/bh/sym/no2&file=distrib/pdf/score-hand/work.pdf ) > > Breitkopf & H\a3rtel, Leipzig, Series 1 No. 2 > Beethoven Symphony No. 2 in D Major, Op. 36 > Mvt. 1 > Clarinetto 1 in A > 0 0 > Group memberships: sound > sound: part 5 of 18 > $ K:-1 Q:24 T:3/4 C:4 X:-11 D:Adagio molto > F5 3 t d ff > measure 1 > F5 36 q. d F > rest 12 e > rest 24 q > measure 2 > rest 72 > measure 3 > rest 72 > measure 4 > rest 24 q > rest 12 e > G5 9 s. d [[ p. > > The "$.. X:-11" information indicates how to get from the written form to the concert pitch form (-11 means transpose down a minor third). So I think that the original form of the MEI transposition attributes are intended to mean the same thing (likewise MusicXML). B-flat clarinets parts would be encoded in the transposed state, with @trans.diat="-1" and @trans.semit="-2" given to indicate how to get to concert pitch from the written state of the data. > > So since both MuseData and MusicXML store transposed parts in transposed form, it is a wise idea to do the same in MEI. (This also explains why I have to fix some transpositions in Haydn symphony data converted from MuseData to Humdrum which does not have the transposition information necessary to get to concert pitch). > >> If MEI stores concert pitch, this would be more natural to sound-focused apps (-> MIDI exporters) and for music analysis. If it keeps written pitch, it would be much easier for renderers, OMR and hand encoders not sure what they're facing. > > So you can guess what Perry will say :-) > >> It might be my personal focus to understand MEI as being somewhat document-centric, but there is another argument to choose written pitch: MIR tools are normally operating on simplifications of the original data (n-grams etc.), but not on data as complex as pure MEI. If they're abstracting anyway, adding the step of transposition to their calculations seems less demanding to me than to require a renderer to "misplace" every single note. > > Transposition is fairly trivial and deterministic, so a renderer which has problems with transposition will most likely have lots of other bugs in it? I didn't say that it's rocket science to calculate pitch, I said it's an additional step that could be spared for _some_ applications. > > MEI Iron is the ideal place to simplify the data to a standardized form. The user/application could specify to MEI Iron that they want transposed data to end up in the written state or the concert-pitch state, then no matter what the original state of the data, the output from MEI Iron is what is desired. When a part-generating program wants the data in transpose form, it asks MEI Iron for the transposed state of the data, when a MIDI-generating program want the data in concert pitch, it asks MEI Iron for data in the untransposed state. When a renderer needs to display the score in concert-pitch, it could alternately ask MEI Iron for data in the concert-pitch state. Brilliant idea! I haven't spent a thought on the iron for this purpose, but you're absolutely right, that's the ideal place to resolve it. We will put it on the MEIron Todo? But, I would still argue that deciding for one direction is crucial to avoid any confusion about this. The MEIron would then only provide a one-way translation, as this would only be a first step in processing the data and turning them into something else. It would not be an officially supported state of an MEI file that one would save as interchangeable file*. Did I hear correctly that you would prefer written pitch as well? So, any other opinions out there? Johannes * Maybe we should offer the other direction in MEIron as well, but I'm afraid that this would require Perry's additional attribute to indicate the current state. And if we add this to the current model, I suppose it's hard to suppress 'misuse' of this feature? Am I wrong? > > -=+Craig > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From zupftom at googlemail.com Mon Feb 13 12:08:55 2012 From: zupftom at googlemail.com (TW) Date: Mon, 13 Feb 2012 12:08:55 +0100 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: <4D829BDA-852E-4563-9B16-85B726C75DAA@edirom.de> References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> <4D829BDA-852E-4563-9B16-85B726C75DAA@edirom.de> Message-ID: 2012/2/13 Johannes Kepper : > Am 13.02.2012 um 04:03 schrieb Craig Sapp: > > >> >> MEI Iron is the ideal place to simplify the data to a standardized form. The user/application could specify to MEI Iron that they want transposed data to end up in the written state or the concert-pitch state, then no matter what the original state of the data, the output from MEI Iron is what is desired. ?When a part-generating program wants the data in transpose form, it asks MEI Iron for the transposed state of the data, when a MIDI-generating program want the data in concert pitch, it asks MEI Iron for data in the untransposed state. ?When a renderer needs to display the score in concert-pitch, it could alternately ask MEI Iron for data in the concert-pitch state. > > Brilliant idea! I haven't spent a thought on the iron for this purpose, but you're absolutely right, that's the ideal place to resolve it. We will put it on the MEIron Todo? But, I would still argue that deciding for one direction is crucial to avoid any confusion about this. The MEIron would then only provide a one-way translation, as this would only be a first step in processing the data and turning them into something else. It would not be an officially supported state of an MEI file that one would save as interchangeable file*. Did I hear correctly that you would prefer written pitch as well? So, any other opinions out there? > >From my perspective, written pitch is the way to go. Transposing has a lot of impact on the appearance (stem direction, accidental arrangement, placement of beams/slurs, placement of articulation marks etc.). MEI can provide information about all this, but is this sensible if sounding pitch rather than visual pitch is recorded? I'm not sure whether it would be a good idea to transform all visual stuff to a separate layout tree. Thomas From raffaeleviglianti at gmail.com Mon Feb 13 12:16:11 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 13 Feb 2012 11:16:11 +0000 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> <4D829BDA-852E-4563-9B16-85B726C75DAA@edirom.de> Message-ID: Hello, I'm also a supporter of MEI as firstly being a document-oriented format, so the written pitch should be preferred in my opinion. We need to make sure, though, that enough information is provided to compute the transposition for analytical purposes and for exporting to other formats, and it seems that the attributes in question are the place where to express this information. If I understand correctly, this does not fully solved what Michael pointed out: "The issue is that you want to be able to change the transposition for different passages, and I don?t think that changing the Instrument tag is the best approach." Do we perhaps need a way to specify when and how the transposition rules are supposed to change within a piece? Is re-defining staffDef the best way? Best, Raffaele On Mon, Feb 13, 2012 at 11:08 AM, TW wrote: > 2012/2/13 Johannes Kepper : > > Am 13.02.2012 um 04:03 schrieb Craig Sapp: > > > > > >> > >> MEI Iron is the ideal place to simplify the data to a standardized > form. The user/application could specify to MEI Iron that they want > transposed data to end up in the written state or the concert-pitch state, > then no matter what the original state of the data, the output from MEI > Iron is what is desired. When a part-generating program wants the data in > transpose form, it asks MEI Iron for the transposed state of the data, when > a MIDI-generating program want the data in concert pitch, it asks MEI Iron > for data in the untransposed state. When a renderer needs to display the > score in concert-pitch, it could alternately ask MEI Iron for data in the > concert-pitch state. > > > > Brilliant idea! I haven't spent a thought on the iron for this purpose, > but you're absolutely right, that's the ideal place to resolve it. We will > put it on the MEIron Todo? But, I would still argue that deciding for one > direction is crucial to avoid any confusion about this. The MEIron would > then only provide a one-way translation, as this would only be a first step > in processing the data and turning them into something else. It would not > be an officially supported state of an MEI file that one would save as > interchangeable file*. Did I hear correctly that you would prefer written > pitch as well? So, any other opinions out there? > > > > From my perspective, written pitch is the way to go. Transposing has > a lot of impact on the appearance (stem direction, accidental > arrangement, placement of beams/slurs, placement of articulation marks > etc.). MEI can provide information about all this, but is this > sensible if sounding pitch rather than visual pitch is recorded? I'm > not sure whether it would be a good idea to transform all visual stuff > to a separate layout tree. > > Thomas > > _______________________________________________ > 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 Feb 20 23:29:06 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 20 Feb 2012 22:29:06 +0000 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: References: <005b01cce8f0$df985800$9ec90800$@mit.edu> <007d01cce8f8$5e972940$1bc57bc0$@mit.edu> <04AF4EC0-4B6C-4A72-9D29-EC10CAE6B799@edirom.de> <4D829BDA-852E-4563-9B16-85B726C75DAA@edirom.de> , Message-ID: Hello, all, Sorry I dropped out of the conversation. I was attending the MLA meeting in Dallas. So, it seems my proposal to allow MEI to store either written or sounded pitch fell flat. That's fine, it was just a straw man anyway. We're agreed then that @trans.diat and @trans.semi indicate the amount of "correction" necessary to achieve the concert pitch from the written one. I'll change the documentation to reflect this, something like: trans.diat -- "records the amount of diatonic pitch shift, e.g., C to C? = 0, C to D? = 1, necessary to achieve the sounded pitch from the written one. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from the key of C to C? and one from the key of C to D?." trans.semi -- "records the amount of pitch shift in semitones, C to C? = 1, C to D? = 1, to achieve the sounded pitch from the written one. Transposition requires both trans.diat and trans.semi attributes in order to distinguish the difference, for example, between a transposition from C to C? and one from C to D?." A statement that MEI always records the written pitch in pname will also be added to the description of the pname attribute. And an example of transposition will be added to the guidelines. To answer Raffaele's question, I can't say it's the "best way", but currently the way to record changes in transposition, say from B? to A clarinet, is by using . The label and instrument definition for the staff are independent of the @trans attributes. This makes it possible for the transposition to change while the label (say, "Player 1") and the MIDI instrument name (say, "Clarinet") remain unchanged. Or vice versa. :-) -- 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 bohl at edirom.de Sat Feb 25 12:20:09 2012 From: bohl at edirom.de (Benjamin Wolff Bohl) Date: Sat, 25 Feb 2012 12:20:09 +0100 Subject: [MEI-L] Report from the MEI Technical Team Meeting 2012-02-21 Message-ID: <4F48C3E9.9000101@edirom.de> On 21 February 2012 the MEI Technical Team held it's quarterly meeting . Topics discussed were repository strategies, referencing MEI tools from the http://www.music-encoding.org website and of course the MEI 2012 release including the previously unreleased MEI Guidelines. The official release of MEI 2012 and corresponding guidelines is to be expected by August. During the next few days a pre-release of the schema will be made available through the newly established schema customization web service based on ROMA and capable of handling customizations files in the ODD format (http://customization.music-encoding.org). This web service will gradually offer more customizations preconfigured for specific use cases. At the same time projects and developers are encouraged to submit their own customizations to the mei-incubator project (http://code.google.com/p/mei-incubator/), which is designated as platform to share application specific schema customizations, experimental status modules or modifications to the MEI core development. Good examples for this are the MEI-FRBR-customization or the new solesmes module currently under development. Everybody is very welcome to share and test the pre-release of the schema or any of the customizations on the mei-incubator. If you need assistance in getting a working schema out of these files, the Technical Team is happy to answer any such questions on this list. At the same time, there are ways to support the Technical Team on its work for the coming release. Several module descriptions are still unattended for. If you would like to support the MEI community, fleshing out some chapters for the guidelines is a good way. Your participation may range from providing a couple of paragraphs as a word processor document to a fully TEI encoded chapter including musical examples in MEI. Currently the following modules are vacant: analysis, corpus, figtable, harmony, linkalign, namesdates, ptrref, tablature, text. If you would like to know what these chapters actually have to cover, or you would like to participate on one of the other chapters, please contact Perry Roland (pdr4h at virginia.edu ) or Johannes Kepper (kepper at edirom.de ). On behalf of the MEI Technical Team, Benjamin W. Bohl -- *********************************************************** Edirom - Projekt "Digitale Musikedition" Musikwissenschaftliches Seminar Detmold/Paderborn Gartenstra?e 20 D -- 32756 Detmold Tel. +49 (0) 5231 / 975-669 Fax: +49 (0) 5231 / 975-668 http://www.edirom.de *********************************************************** -------------- n?chster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: From donbyrd at indiana.edu Sat Feb 25 21:38:03 2012 From: donbyrd at indiana.edu (Byrd, Donald A.) Date: Sat, 25 Feb 2012 15:38:03 -0500 Subject: [MEI-L] @trans.diat and @trans.semi Message-ID: <20120225153803.ckpjfqc5i8kw8c8s@webmail.iu.edu> Hi, everyone. To make a very long story very short, my change of careers is at least temporarily on hold, and I again have time to think about MEI etc.; beyond that, I can't say, though I've talked to Perry a bit about how I might contribute to the MEI effort (by writing a full notation editor?)... Anyway, I have a belated comment or two on this issue. Please forgive me if I'm repeating what others said while I wasn't paying attention, or if I'm just off track and this is irrelevant! My article "Written vs. Sounding Pitch", which is (or was!) in Workshop Resources has a lot of examples of the problems here. In general, the relationship between written and sounding pitch is so messy that even using the word "transposition" to describe it makes me nervous. With scordatura, you have to think of different transpositions being in effect at the same time, even within a chord, and you have to interpret the key signature very carefully (Fig. 6 of my article). Even timpani notation of the late 18th and early 19th century, with just two notes, is like that: consider the first movement of the Beethoven 4th, in B-flat major, where the timpani B-flat's and F's are on a staff with no key signature and no accidentals (Fig. 4). I think Thomas is exactly right in that written pitch must be encoded for a lot of information about the appearance of the score to be meaningful. However, there are also many cases where you can't reliably infer the sounding pitch without giving the "transposition" on a note-by-note basis. But in that situation, why think about "transposition" at all? It makes more sense to just encode the sounding as well as the written pitch. --Don On Mon, 13 Feb 2012 12:08:55 +0100, TW wrote: > 2012/2/13 Johannes Kepper : >> Am 13.02.2012 um 04:03 schrieb Craig Sapp: >> >> >>> >>> MEI Iron is the ideal place to simplify the data to a standardized >>> form. The user/application could specify to MEI Iron that they want >>> transposed data to end up in the written state or the concert-pitch >>> state, then no matter what the original state of the data, the >>> output from MEI Iron is what is desired. ?When a part-generating >>> program wants the data in transpose form, it asks MEI Iron for the >>> transposed state of the data, when a MIDI-generating program want >>> the data in concert pitch, it asks MEI Iron for data in the >>> untransposed state. ?When a renderer needs to display the score in >>> concert-pitch, it could alternately ask MEI Iron for data in the >>> concert-pitch state. >> >> Brilliant idea! I haven't spent a thought on the iron for this >> purpose, but you're absolutely right, that's the ideal place to >> resolve it. We will put it on the MEIron Todo? But, I would still >> argue that deciding for one direction is crucial to avoid any >> confusion about this. The MEIron would then only provide a one-way >> translation, as this would only be a first step in processing the >> data and turning them into something else. It would not be an >> officially supported state of an MEI file that one would save as >> interchangeable file*. Did I hear correctly that you would prefer >> written pitch as well? So, any other opinions out there? >> > > From my perspective, written pitch is the way to go. Transposing has > a lot of impact on the appearance (stem direction, accidental > arrangement, placement of beams/slurs, placement of articulation marks > etc.). MEI can provide information about all this, but is this > sensible if sounding pitch rather than visual pitch is recorded? I'm > not sure whether it would be a good idea to transform all visual stuff > to a separate layout tree. > > Thomas > > _______________________________________________ > 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 & Music Indiana University, Bloomington From pdr4h at eservices.virginia.edu Sat Feb 25 23:40:40 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Sat, 25 Feb 2012 22:40:40 +0000 Subject: [MEI-L] @trans.diat and @trans.semi In-Reply-To: <20120225153803.ckpjfqc5i8kw8c8s@webmail.iu.edu> References: <20120225153803.ckpjfqc5i8kw8c8s@webmail.iu.edu> Message-ID: > It makes more sense to just encode the sounding as well as the written pitch. Which MEI accommodates by allowing to have @pname (for written pitch) and @pname.ges (for sounded pitch). -- 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 pdr4h at eservices.virginia.edu Thu Mar 1 23:16:31 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Thu, 1 Mar 2012 22:16:31 +0000 Subject: [MEI-L] eventLike in bend, gliss, mordent, etc. Message-ID: Hello all, Please pardon the duplication if you get this message more than once. Elements in the model.eventLike class -- barLine, beam, beatRpt, bend, bTrem, chord, clef, clefGrp, custos, fTrem, gliss, halfmRpt, ineume, keySig, ligature, mensur, mRest, mRpt, mRpt2, mSpace, multiRest, multiRpt, note, pad, proport, rest, space, tuplet, uneume were allowed to occur in selected eventLike elements -- bend, gliss, mordent, trill, turn, note in earlier versions of MEI that didn't yet have the ability to encode multiple readings. Now that MEI does have for dealing with multiple readings, having this "event within event" structure is redundant and confusing. I think we need to kill off this dinosaur. Since the next release of MEI has already been frozen with regard to the addition / deletion of features, I propose to add documentation that deprecates this feature even though it will technically be allowed. Of course, in the next-next release this feature will be disabled. Any objections? Is anyone using this? Going, going, ... Best wishes, -- 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 kristina.richts at gmx.de Mon Mar 5 10:26:32 2012 From: kristina.richts at gmx.de (Kristina Richts) Date: Mon, 5 Mar 2012 10:26:32 +0100 Subject: [MEI-L] trills within beams Message-ID: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> Hi all, while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: ? Did I miss anything? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Bildschirmfoto 2012-03-05 um 08.07.00.png Type: image/png Size: 20470 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Mon Mar 5 14:49:42 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Mon, 5 Mar 2012 13:49:42 +0000 Subject: [MEI-L] trills within beams In-Reply-To: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> Message-ID: Hi, Kristina, MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. >From snowy (yes, snowy!) Charlottesville, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] Sent: Monday, March 05, 2012 4:26 AM To: Music Encoding Initiative Subject: [MEI-L] trills within beams Hi all, while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. [cid:2B8787F5-91C3-4F4D-A92F-10B5B83D2F4B at bib.hfm-detmold.de] Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: ? Did I miss anything? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Bildschirmfoto 2012-03-05 um 08.07.00.png Type: image/png Size: 20470 bytes Desc: Bildschirmfoto 2012-03-05 um 08.07.00.png URL: From raffaeleviglianti at gmail.com Mon Mar 5 15:16:13 2012 From: raffaeleviglianti at gmail.com (Raffaele Viglianti) Date: Mon, 5 Mar 2012 14:16:13 +0000 Subject: [MEI-L] trills within beams In-Reply-To: References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> Message-ID: Hi Kristina, I agree with Perry. I very much prefer to deal with any element that spans multiple events and measures at the bottom of the measure where they start. It avoids all sorts of overlapping hierarchies. I mainly mean and , but also , , , etc. is perhaps my only exception to this rule. I typically use time stamp and/or ids (in this order or preference) to anchor them to the relevant events or position in time. I believe this is really efficient, especially when you're dealing with manuscript notation and editorial intervention, as it leaves room for those elements. Best wishes, Raffaele On Mon, Mar 5, 2012 at 1:49 PM, Roland, Perry (pdr4h) < pdr4h at eservices.virginia.edu> wrote: > Hi, Kristina, > > > > MEI is not designed to be encoded in one pass -- some things, such as > trills, pedal markings, text directives, etc., must be captured after the > notes. > > > > It might be possible to do what you suggest in some cases but it won't > work all the time because it potentially leads to overlapping hierarchies. > It also means that your proposed element would have to allow every > other possible element, leading to opportunities for encoders to do > unsupported things. > > > > From snowy (yes, snowy!) Charlottesville, > > > > -- > > 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-bounces at lists.uni-paderborn.de [ > mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [ > kristina.richts at gmx.de] > *Sent:* Monday, March 05, 2012 4:26 AM > *To:* Music Encoding Initiative > *Subject:* [MEI-L] trills within beams > > Hi all, > > while encoding the following passage, I just mentioned, that there seems > to be no way to encode the trill right here, as I don't want to extract > this information and place it at the end of the measure. > > > > Why isn't it possible to provide notes within a beam with a > element, as could be done with single notes, like this: > "down"/>? > > Did I miss anything? > > Best, > Kristina > > > > > > _______________________________________________ > 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: Bildschirmfoto 2012-03-05 um 08.07.00.png Type: image/png Size: 20470 bytes Desc: not available URL: From kepper at edirom.de Mon Mar 5 15:18:57 2012 From: kepper at edirom.de (Johannes Kepper) Date: Mon, 5 Mar 2012 15:18:57 +0100 Subject: [MEI-L] trills within beams In-Reply-To: References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> Message-ID: <321241D0-D59E-4C72-B7B5-4D9A9F560EEF@edirom.de> I think the question was mostly targeting at trills that do not span over a number of notes, but instead just read a "tr" on top of a note. One could argue this to be a value for @artic or some such? Johannes Am 05.03.2012 um 15:16 schrieb Raffaele Viglianti: > Hi Kristina, > > I agree with Perry. I very much prefer to deal with any element that spans multiple events and measures at the bottom of the measure where they start. It avoids all sorts of overlapping hierarchies. I mainly mean and , but also , , , etc. is perhaps my only exception to this rule. > > I typically use time stamp and/or ids (in this order or preference) to anchor them to the relevant events or position in time. I believe this is really efficient, especially when you're dealing with manuscript notation and editorial intervention, as it leaves room for those elements. > > Best wishes, > Raffaele > > On Mon, Mar 5, 2012 at 1:49 PM, Roland, Perry (pdr4h) wrote: > Hi, Kristina, > > > MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. > > > It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. > > > From snowy (yes, snowy!) Charlottesville, > > > -- > > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] > Sent: Monday, March 05, 2012 4:26 AM > To: Music Encoding Initiative > Subject: [MEI-L] trills within beams > > Hi all, > > while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. > > > > Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: > ? > > Did I miss anything? > > Best, > Kristina > > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/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 esfield at stanford.edu Tue Mar 6 00:03:29 2012 From: esfield at stanford.edu (Eleanor Selfridge-Field) Date: Mon, 5 Mar 2012 15:03:29 -0800 (PST) Subject: [MEI-L] trills within beams In-Reply-To: References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> Message-ID: <00f601ccfb24$2d7bbc20$88733460$@stanford.edu> Hi, Kristina, Perry, et al. >From my perspective Kristina is prompting a really important question, and one response ("more than one pass....") seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: We used it in our "desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1] How would MEI handle it? Eleanor Eleanor Selfridge-Field Consulting Professor, Music Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ http://www.ccarh.org From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, March 05, 2012 5:50 AM To: Music Encoding Initiative Subject: Re: [MEI-L] trills within beams Hi, Kristina, MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. >From snowy (yes, snowy!) Charlottesville, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] Sent: Monday, March 05, 2012 4:26 AM To: Music Encoding Initiative Subject: [MEI-L] trills within beams Hi all, while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: ? Did I miss anything? Best, Kristina -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 20470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 15918 bytes Desc: not available URL: From andrew.hankinson at mail.mcgill.ca Tue Mar 6 01:57:06 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Tue, 6 Mar 2012 00:57:06 +0000 Subject: [MEI-L] trills within beams In-Reply-To: <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> Message-ID: <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> Hi Eleanor, The way I understand the problem is a choice between the following options: or: or: In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note. If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things. MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy. In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached): This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned). I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events. The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another. -Andrew On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote: Hi, Kristina, Perry, et al. >From my perspective Kristina is prompting a really important question, and one response (?more than one pass....?) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: We used it in our ?desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1] How would MEI handle it? Eleanor Eleanor Selfridge-Field Consulting Professor, Music Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ http://www.ccarh.org From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, March 05, 2012 5:50 AM To: Music Encoding Initiative Subject: Re: [MEI-L] trills within beams Hi, Kristina, MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. >From snowy (yes, snowy!) Charlottesville, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] Sent: Monday, March 05, 2012 4:26 AM To: Music Encoding Initiative Subject: [MEI-L] trills within beams Hi all, while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: ? Did I miss anything? Best, Kristina _______________________________________________ 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 Mar 6 13:11:16 2012 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 6 Mar 2012 13:11:16 +0100 Subject: [MEI-L] trills within beams In-Reply-To: <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> Message-ID: Hi Andrew, I absolutely agree with what you say about hierarchy issues etc. I think this discussion is very helpful for identifying what MEI is and what it is not, and, even more beneficial, how people understand it. But still, I think it misses Kristina's initial question. Sometimes, a trill stretches no longer than the note it's written above. In these cases, it seems to be no spanning element on its own, but rather a playing instruction for this particular note. The question then is not whether we want to redefine the model of to allow it within a note or as a container of notes, but instead if "tr" should be an allowed value of @artic (or any other attribute on ). By no means this would argue against the existence of the current standoff , it would just be a shortcut for describing trill that do not stretch beyond their initial note. Currently, the would have to duplicate the @tstamp and @dur of this note (@tstamp on notes is normally omitted, I know). It is fine to decide that we don't want to offer this limited-power shortcut for a certain kind of trills, but we have several such constructs for other things in MEI already. I don't see that anyone asked for remodelling the trill element (but please correct me!!!!). Best, Johannes Am 06.03.2012 um 01:57 schrieb Andrew Hankinson, Mr: > Hi Eleanor, > > The way I understand the problem is a choice between the following options: > > > > > > or: > > > > > > or: > > > > > In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note. > > If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things. > > MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy. > > In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached): > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned). > > I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events. > > The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces > > I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another. > > -Andrew > > On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote: > > Hi, Kristina, Perry, et al. > > From my perspective Kristina is prompting a really important question, and one response (?more than one pass....?) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. > > What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. > When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. > > Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: > > > We used it in our ?desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1] > > How would MEI handle it? > > Eleanor > > > Eleanor Selfridge-Field > Consulting Professor, Music > Braun Music Center #129 > Stanford University > Stanford, CA 94305-3076, USA > http://www.stanford.edu/~esfield/ > http://www.ccarh.org > > > > From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) > Sent: Monday, March 05, 2012 5:50 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] trills within beams > > Hi, Kristina, > > MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. > > It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. > > From snowy (yes, snowy!) Charlottesville, > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] > Sent: Monday, March 05, 2012 4:26 AM > To: Music Encoding Initiative > Subject: [MEI-L] trills within beams > Hi all, > > while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. > > > > Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: > ? > > Did I miss anything? > > Best, > Kristina > > > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l > > > _______________________________________________ > mei-l mailing list > mei-l at lists.uni-paderborn.de > https://lists.uni-paderborn.de/mailman/listinfo/mei-l From andrew.hankinson at mail.mcgill.ca Tue Mar 6 16:05:28 2012 From: andrew.hankinson at mail.mcgill.ca (Andrew Hankinson, Mr) Date: Tue, 6 Mar 2012 15:05:28 +0000 Subject: [MEI-L] trills within beams In-Reply-To: <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de> References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de> Message-ID: Thanks Johannes! I gave a couple examples to show how trill *could* be done in XML (and is done in some other XML-based music encoding schemes), since I was responding to Eleanor's question. But I don't think that it *should* be done that way, since, like I said, it creates a situation where you're forced into creating these artificial and non-musical hierarchies. I didn't mean to suggest that I felt any changes to should be made, I just wanted to address Eleanor's question directly by showing how MEI does it differently. But to address Kristina's question: I did some asking around our lab yesterday. We came to the agreement that a trill is an ornament, not an articulation. If doesn't have @ornament or something along those lines, I think this is a great argument for it. One of the musicologists in our lab found a couple helpful pages for this discussion: http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html Couperin's Ornaments: http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false -Andrew On 2012-03-06, at 7:11 AM, Johannes Kepper wrote: > Hi Andrew, > > I absolutely agree with what you say about hierarchy issues etc. I think this discussion is very helpful for identifying what MEI is and what it is not, and, even more beneficial, how people understand it. But still, I think it misses Kristina's initial question. Sometimes, a trill stretches no longer than the note it's written above. In these cases, it seems to be no spanning element on its own, but rather a playing instruction for this particular note. The question then is not whether we want to redefine the model of to allow it within a note or as a container of notes, but instead if "tr" should be an allowed value of @artic (or any other attribute on ). By no means this would argue against the existence of the current standoff , it would just be a shortcut for describing trill that do not stretch beyond their initial note. Currently, the would have to duplicate the @tstamp and @dur of this note (@tstamp on notes is normally omitted, I know). > > It is fine to decide that we don't want to offer this limited-power shortcut for a certain kind of trills, but we have several such constructs for other things in MEI already. I don't see that anyone asked for remodelling the trill element (but please correct me!!!!). > > Best, > Johannes > > > > > Am 06.03.2012 um 01:57 schrieb Andrew Hankinson, Mr: > >> Hi Eleanor, >> >> The way I understand the problem is a choice between the following options: >> >> >> >> >> >> or: >> >> >> >> >> > >> or: >> >> >> >> >> In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note. >> >> If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things. >> >> MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy. >> >> In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached): >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned). >> >> I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events. >> >> The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces >> >> I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another. >> >> -Andrew >> >> On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote: >> >> Hi, Kristina, Perry, et al. >> >> From my perspective Kristina is prompting a really important question, and one response (?more than one pass....?) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. >> >> What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. >> When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. >> >> Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: >> >> >> We used it in our ?desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1] >> >> How would MEI handle it? >> >> Eleanor >> >> >> Eleanor Selfridge-Field >> Consulting Professor, Music >> Braun Music Center #129 >> Stanford University >> Stanford, CA 94305-3076, USA >> http://www.stanford.edu/~esfield/ >> http://www.ccarh.org >> >> >> >> From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) >> Sent: Monday, March 05, 2012 5:50 AM >> To: Music Encoding Initiative >> Subject: Re: [MEI-L] trills within beams >> >> Hi, Kristina, >> >> MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. >> >> It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. >> >> From snowy (yes, snowy!) Charlottesville, >> >> -- >> 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] >> Sent: Monday, March 05, 2012 4:26 AM >> To: Music Encoding Initiative >> Subject: [MEI-L] trills within beams >> Hi all, >> >> while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. >> >> >> >> Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: >> ? >> >> Did I miss anything? >> >> Best, >> Kristina >> >> >> >> >> _______________________________________________ >> mei-l mailing list >> mei-l at lists.uni-paderborn.de >> https://lists.uni-paderborn.de/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: smime.p7s Type: application/pkcs7-signature Size: 1054 bytes Desc: not available URL: From pdr4h at eservices.virginia.edu Tue Mar 6 16:57:55 2012 From: pdr4h at eservices.virginia.edu (Roland, Perry (pdr4h)) Date: Tue, 6 Mar 2012 15:57:55 +0000 Subject: [MEI-L] trills within beams In-Reply-To: References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de>, Message-ID: If single-note trills are treated differently, then why not any other single-note / instantaneous "control event", such as arpeg, breath, pedal, reh, dynam, etc.? Once you start down that road, Pandora's box is opened. A proliferation of attributes wouldn't be helpful. If attributes were added, @ornam for example, they would only be useful part of the time; that is, in the case of @ornam/ @trill, for a single-note trill and when complete control of the rendering of the trill is to be handled by the rendering engine. There's no opportunity to add visual information to that trill without resorting to attributes about attributes (and that way certainly lies madness!) If an child of were added or allowed to be a child of in order to accommodate visual info., then we're back into the hierarchy problems Andrew so eloquently described yesterday. In addition, if we allow both possibilities (attribute and child), then user confusion is increased and interchange / interoperability diminished. When these other things are considered, I believe recording trills and such after the notes they're attached to is still the best of the alternatives. -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca] Sent: Tuesday, March 06, 2012 10:05 AM To: Music Encoding Initiative Subject: Re: [MEI-L] trills within beams Thanks Johannes! I gave a couple examples to show how trill *could* be done in XML (and is done in some other XML-based music encoding schemes), since I was responding to Eleanor's question. But I don't think that it *should* be done that way, since, like I said, it creates a situation where you're forced into creating these artificial and non-musical hierarchies. I didn't mean to suggest that I felt any changes to should be made, I just wanted to address Eleanor's question directly by showing how MEI does it differently. But to address Kristina's question: I did some asking around our lab yesterday. We came to the agreement that a trill is an ornament, not an articulation. If doesn't have @ornament or something along those lines, I think this is a great argument for it. One of the musicologists in our lab found a couple helpful pages for this discussion: http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html Couperin's Ornaments: http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false -Andrew On 2012-03-06, at 7:11 AM, Johannes Kepper wrote: Hi Andrew, I absolutely agree with what you say about hierarchy issues etc. I think this discussion is very helpful for identifying what MEI is and what it is not, and, even more beneficial, how people understand it. But still, I think it misses Kristina's initial question. Sometimes, a trill stretches no longer than the note it's written above. In these cases, it seems to be no spanning element on its own, but rather a playing instruction for this particular note. The question then is not whether we want to redefine the model of to allow it within a note or as a container of notes, but instead if "tr" should be an allowed value of @artic (or any other attribute on ). By no means this would argue against the existence of the current standoff , it would just be a shortcut for describing trill that do not stretch beyond their initial note. Currently, the would have to duplicate the @tstamp and @dur of this note (@tstamp on notes is normally omitted, I know). It is fine to decide that we don't want to offer this limited-power shortcut for a certain kind of trills, but we have several such constructs for other things in MEI already. I don't see that anyone asked for remodelling the trill element (but please correct me!!!!). Best, Johannes Am 06.03.2012 um 01:57 schrieb Andrew Hankinson, Mr: Hi Eleanor, The way I understand the problem is a choice between the following options: or: or: In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note. If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things. MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy. In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached): This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned). I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events. The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another. -Andrew On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote: Hi, Kristina, Perry, et al. >From my perspective Kristina is prompting a really important question, and one response (?more than one pass....?) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: We used it in our ?desk-top publishing IEEE tutorial of 1994. [For all the examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category 2, Type 1] How would MEI handle it? Eleanor Eleanor Selfridge-Field Consulting Professor, Music Braun Music Center #129 Stanford University Stanford, CA 94305-3076, USA http://www.stanford.edu/~esfield/ http://www.ccarh.org From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de [mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On Behalf Of Roland, Perry (pdr4h) Sent: Monday, March 05, 2012 5:50 AM To: Music Encoding Initiative Subject: Re: [MEI-L] trills within beams Hi, Kristina, MEI is not designed to be encoded in one pass -- some things, such as trills, pedal markings, text directives, etc., must be captured after the notes. It might be possible to do what you suggest in some cases but it won't work all the time because it potentially leads to overlapping hierarchies. It also means that your proposed element would have to allow every other possible element, leading to opportunities for encoders to do unsupported things. >From snowy (yes, snowy!) Charlottesville, -- 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts [kristina.richts at gmx.de] Sent: Monday, March 05, 2012 4:26 AM To: Music Encoding Initiative Subject: [MEI-L] trills within beams Hi all, while encoding the following passage, I just mentioned, that there seems to be no way to encode the trill right here, as I don't want to extract this information and place it at the end of the measure. Why isn't it possible to provide notes within a beam with a element, as could be done with single notes, like this: ? Did I miss anything? Best, Kristina _______________________________________________ mei-l mailing list mei-l at lists.uni-paderborn.de https://lists.uni-paderborn.de/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 kepper at edirom.de Tue Mar 6 17:06:11 2012 From: kepper at edirom.de (Johannes Kepper) Date: Tue, 6 Mar 2012 17:06:11 +0100 Subject: [MEI-L] trills within beams In-Reply-To: References: <5DE906DC-281C-4DB4-BC46-B3A8A0800E72@gmx.de> <24846_1330988626_4F554651_24846_2_1_00f601ccfb24$2d7bbc20$88733460$@stanford.edu> <114F68D8-A9A2-422B-9C85-716CAE715DD6@mail.mcgill.ca> <21712_1331035890_4F55FEF2_21712_135_1_ED80AB9F-6C17-4270-BAE9-E2CE42AE2D24@edirom.de>, Message-ID: I see the point, but in this case, shouldn't we consider to deprecate @tie, @slur and similar constructs? The arguments you provide below apply to them as well? devil's advocate Johannes Am 06.03.2012 um 16:57 schrieb Roland, Perry (pdr4h): > If single-note trills are treated differently, then why not any other single-note / instantaneous "control event", such as arpeg, breath, pedal, reh, dynam, etc.? Once you start down that road, Pandora's box is opened. A proliferation of attributes wouldn't be helpful. > > If attributes were added, @ornam for example, they would only be useful part of the time; that is, in the case of @ornam/ @trill, for a single-note trill and when complete control of the rendering of the trill is to be handled by the rendering engine. There's no opportunity to add visual information to that trill without resorting to attributes about attributes (and that way certainly lies madness!) > > If an child of were added or allowed to be a child of in order to accommodate visual info., then we're back into the hierarchy problems Andrew so eloquently described yesterday. In addition, if we allow both possibilities (attribute and child), then user confusion is increased and interchange / interoperability diminished. > > When these other things are considered, I believe recording trills and such after the notes they're attached to is still the best of the alternatives. > > -- > 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-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson, Mr [andrew.hankinson at mail.mcgill.ca] > Sent: Tuesday, March 06, 2012 10:05 AM > To: Music Encoding Initiative > Subject: Re: [MEI-L] trills within beams > > > Thanks Johannes! > > > I gave a couple examples to show how trill *could* be done in XML (and is done in some other XML-based music encoding schemes), since I was responding to Eleanor's question. But I don't think that it *should* be done that way, since, like I said, it creates a situation where you're forced into creating these artificial and non-musical hierarchies. I didn't mean to suggest that I felt any changes to should be made, I just wanted to address Eleanor's question directly by showing how MEI does it differently. > > > But to address Kristina's question: I did some asking around our lab yesterday. We came to the agreement that a trill is an ornament, not an articulation. If doesn't have @ornament or something along those lines, I think this is a great argument for it. > > > One of the musicologists in our lab found a couple helpful pages for this discussion: > > > http://www.music.vt.edu/musicdictionary/appendix/ornaments/ornaments.html > > > Couperin's Ornaments: > http://books.google.ca/books?id=CecBsvk7Oz0C&lpg=PA34&ots=VQ2uwRSt_n&dq=ornaments%20couperin&pg=PA34#v=onepage&q=ornaments%20couperin&f=false > > > -Andrew > > > On 2012-03-06, at 7:11 AM, Johannes Kepper wrote: > > > Hi Andrew, > > I absolutely agree with what you say about hierarchy issues etc. I think this discussion is very helpful for identifying what MEI is and what it is not, and, even more beneficial, how people understand it. But still, I think it misses Kristina's initial question. Sometimes, a trill stretches no longer than the note it's written above. In these cases, it seems to be no spanning element on its own, but rather a playing instruction for this particular note. The question then is not whether we want to redefine the model of to allow it within a note or as a container of notes, but instead if "tr" should be an allowed value of @artic (or any other attribute on ). By no means this would argue against the existence of the current standoff , it would just be a shortcut for describing trill that do not stretch beyond their initial note. Currently, the would have to duplicate the @tstamp and @dur of this note (@tstamp on notes is normally omitted, I know). > > It is fine to decide that we don't want to offer this limited-power shortcut for a certain kind of trills, but we have several such constructs for other things in MEI already. I don't see that anyone asked for remodelling the trill element (but please correct me!!!!). > > Best, > Johannes > > > > > Am 06.03.2012 um 01:57 schrieb Andrew Hankinson, Mr: > > > Hi Eleanor, > > > > The way I understand the problem is a choice between the following options: > > > > > > > > > > > > or: > > > > > > > > > > > > > > or: > > > > > > > > > > In the first example, note becomes a "child" element of trill; the second example inverts that so that trill becomes a child of note. If we were to wish to express this in "pure" XML, it would need to be a choice between either of these, since XML imposes a very hierarchical structure if used naively. Sometimes this hierarchy makes sense (note as a child of chord), but in this case it doesn't really make musical sense for trill to be a parent or a child of note. > > > > If we were to want to expand trill so that it covers more than one note, we would have to choose option 1 OR we would have to try and figure out some other way of grouping notes. Perry's concern was that if we allow all things that can be trilled, or that can hold children that can also be trilled, then we pretty much have to allow most things as children of trills. This makes the encoding task much more difficult, since it can be very easy to get into trouble and do nonsensical things. > > > > MEI and TEI have a fairly elegant solution to this which is still valid XML but allows us to break out of this rigid hierarchy. > > > > In the third example, we remove the hierarchy and assign the trill to the note by reference; that is, the element is not hierarchically related to note, but the @startid attribute points to the element where the trill starts. This is much easier to handle, since you can put many other elements between them. For example, you could do this (a highly simplified version of the first measure of the example you attached): > > > > > > > > This allows much more flexibility in the encoding, since it means you do not have to decide whether the trill is hierarchically higher or lower than the note; you can simply list all the "spanning" elements at the end of the measure, and then give @startid/@endid or @tstamp references (as Raffaele mentioned). > > > > I can't speak directly for Perry, but I think that's what he meant by "one pass" vs. "two pass". It's not that you can't do all the encoding in the same sitting, it's just that sometimes you'll want to identify and encode elements that don't strictly fall into the hierarchy later in the measure. So you would, in effect, do two passes through the measure: one to encode the notes, and the other to encode the other events. > > > > The complexity of keeping all this straight when encoding is certainly not trivial, but I don't think that's an MEI issue. My own feeling is that it should be the job of the notation encoding software to help you manage all of the bits and pieces > > > > I think this addresses your concern directly. You don't have to put all elements in an arbitrary hierarchy since things can be referenced after they have "happened" in the score, without needing to decide if it makes musical sense to have it as a hierarchical relationship. This, in my opinion, is more musical than other attempts at encoding music notation in XML since you don't have to make seemingly arbitrary decisions over which musical structure is a child of another. > > > > -Andrew > > > > On 2012-03-05, at 6:03 PM, Eleanor Selfridge-Field wrote: > > > > Hi, Kristina, Perry, et al. > > > > From my perspective Kristina is prompting a really important question, and one response (?more than one pass....?) seems to be the inevitable place where all encoders end up when confronted with real music. It may be unavoidable, but it is not ideal. > > > > What is unsettling in the responses is that we are putting hierarchy above music and the needs of encoders. > > When working with MSS, there are dozens of potential distractions, and making a second pass to capture left-over details requires finding the exact spot on the folio, checking to see which features were encoded on the first pass, and, over time, a lot of secondary bookkeeping about what is finished and what has yet to be done. (I know; I did that kind of housework for my Marcello catalogue in the 1980s---3000 bitty music files, each one in need of its own particular notes.) The risks of eventual inaccuracy, incomplete information, and duplication are very real. > > > > Granted we want MEI to work, but if it is optimized for programming efficiency at the cost of usability, we may need to step back and look for other solutions. The low level of generalizability of music features across repertories is widely acknowledged, and we are simply encountering one instance here. For another example from the same category, consider this CPE Bach incipit: > >