[MEI-L] Events inside events

[Roland, Perry (pdr4h)]

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