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.<div>
<br></div><div>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?</div>
<div><br></div><div><note></div><div> <turn><br><div> <!-- interpretation of how to perform the turn --><br> <note/><br> <note/><br> <note/><br></div> <note/><br> </turn></div>
<div><note></div><div><br></div><div>I am sure you already answered it before, sorry about it. Or is this what you mean by abomination?</div><div><br></div><div>Laurent<div><div><br><div class="gmail_quote">On Mon, Mar 12, 2012 at 2:37 PM, Roland, Perry (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Laurent,<br>
<br>
My example wasn't very clear, was it? Sorry about that.<br>
<br>
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:<br>
<br>
<measure n="1"><br>
<staff n="1"><br>
<layer><br>
<note pname="c" oct="4" dur="4"/><br>
<note pname="d"/><br>
<note pname="e"/><br>
<note pname="f"/><br>
</layer><br>
</staff><br>
<!-- control events, such as turns, here --><br>
<choice><br>
<orig><br>
<turn tstamp="2"/><!-- capture of the turn symbol --><br>
<div> </orig><br>
<reg><br>
<note/><!-- interpretation of how to perform the turn --><br>
<note/><br>
<note/><br>
<note/><br>
</reg><br>
</choice><br>
</div></measure><br>
<br>
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.<br>
<br>
The following still feels more intuitively correct:<br>
<br>
<measure n="1"><br>
<staff n="1"><br>
<layer><br>
<note pname="c" oct="4" dur="4"/><br>
<note pname="d"/><br>
<note pname="e"/><br>
<note pname="f"/><br>
</layer><br>
</staff><br>
<turn tstamp="2"><br>
<div> <!-- interpretation of how to perform the turn --><br>
<note/><br>
<note/><br>
<note/><br>
</div> <note/><br>
</turn><br>
</measure><br>
<br>
because the turn and its interpretation are more closely linked together.<br>
<br>
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>*:<br>
<br>
<turn tstamp="2"><br>
<!-- interpretations of how to perform the turn --><br>
<choice><br>
<reg><br>
<note/><br>
<note/><br>
<note/><br>
<note/><br>
</reg><br>
<reg><br>
<note/><br>
<note/><br>
<note/><br>
<note/><br>
<note/><br>
<note/><br>
</reg><br>
</turn><br>
<br>
However, I still think the following is an abomination:<br>
<br>
<note><br>
<note/><br>
<note/><br>
</note><br>
<br>
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. :-)<br>
<div><br>
--<br>
p.<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
<br>
<br>
<br>
</div>From: <a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Laurent Pugin [<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>]<br>
Sent: Monday, March 12, 2012 4:21 AM<br>
To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] Events inside events<br>
<div><div><br>
<br>
Hi Perry,<br>
<br>
<br>
I am confused. In the following example:<br>
<br>
<br>
<choice><br>
<orig><br>
<turn></turn><!-- capture of the turn symbol --><br>
</orig><br>
<reg><br>
<note/><!-- interpretation of how to perform the turn --><br>
<note/><br>
<note/><br>
<note/><br>
</reg><br>
</choice><br>
<br>
<br>
Where is given for the original the note to which the turn applies. Am I overlooking something? Sorry about it.<br>
<br>
<br>
Laurent<br>
<br>
<br>
On Wed, Mar 7, 2012 at 2:25 PM, Johannes Kepper <<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>> wrote:<br>
<br>
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).<br>
<br>
-------<br>
<br>
<br>
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.,<br>
<br>
<turn><br>
<note/><br>
<note/><br>
<note/><br>
</turn><br>
<br>
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<br>
<br>
<choice><br>
<orig><br>
<turn></turn><!-- capture of the turn symbol --><br>
</orig><br>
<reg><br>
<note/><!-- interpretation of how to perform the turn --><br>
<note/><br>
<note/><br>
<note/><br>
</reg><br>
</choice><br>
<br>
when marking up a single source, or if the turn and its "resolution" exist in different sources<br>
<br>
<app><br>
<rdg source="A"><br>
<turn/><br>
</rdg><br>
<rdg souce="B"><br>
<note/><br>
<note/><br>
<note/><br>
<note/><br>
</rdg><br>
</app><br>
<br>
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.<br>
<br>
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>.<br>
<br>
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.<br>
<br>
Comments?<br>
<br>
--<br>
p.<br>
<br>
<br>
--------------<br>
<br>
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.<br>
<br>
Johannes<br>
<br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
</div></div></blockquote></div><br>
</div></div></div>