[MEI-L] Events inside events

[Laurent Pugin]

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> 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 (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><!-- 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> 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
> https://lists.uni-paderborn.de/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>