[MEI-L] Events inside events
Laurent Pugin
laurent at music.mcgill.ca
Thu Mar 15 12:10:18 CET 2012
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>
> <!-- 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
>>
>>
>
> _______________________________________________
> 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>
More information about the mei-l
mailing list