[MEI-L] Events inside events

Tue Mar 13 15:02:52 CET 2012

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>
   <!-- interpretation of how to perform the 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>
 <!-- control events, such as turns, here -->
 <choice>
   <orig>
     <turn tstamp="2"/><!-- capture of the turn symbol -->
   </orig>
   <reg>
     <note/><!-- interpretation of how to perform the turn -->
     <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">
   <!-- interpretation of how to perform the turn -->
   <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">
   <!-- interpretations of how to perform the turn -->
   <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><!-- capture of the turn symbol -->
 </orig>
 <reg>
 <note/><!-- interpretation of how to perform the turn -->
 <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><!-- capture of the turn symbol -->
 </orig>
 <reg>
 <note/><!-- interpretation of how to perform the turn -->
 <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>