[MEI-L] datatype [imt][1-6]

Sat Jul 7 12:38:42 CEST 2012

Raffaele,

In this context "one pass encoding" means capturing all information available at any given point in the encoding at one time. For example, while you're on a given note, it means capturing info about any ties, slurs, beams, etc. that start on that note.  MEI accomplishes this primarily with attributes; that is, @beam, @slur, @tie.

"Two pass encoding" means capturing the note information first and the beam, tie, and slur data later, relating the second pass to the first, of course.  This method results in note, chord, etc. elements  followed later by tie, slur, etc. elements with @tstamp or @startid attributes.

The beam element is slightly anomalous in that it encloses notes, but it's really part of the one-pass method.  It's difficult to treat other things, like slur, tie, etc. that might overlap each other the same way as beams. And even for beams, when overlapping occurs one must switch to beamSpan.

I still believe one-pass encoding has a place in MEI, at least until any hand encoding (meaning editing of the MEI file in a non-graphical environment) is no longer necessary.  However, these attributes should certainly be better documented and perhaps moved to a separate module instead of being eliminated altogether. We could even go so far as to define them as unacceptable in "canonical" MEI as long as we provide conversion from the attribute method to the element method.  In addition to their usefulness in hand-coding, these attributes are helpful when transforming data already in a one-pass-oriented form, such as MuseData and to some extent MusicXML, to MEI.

I agree that keeping @tie while eliminating the other "one-pass attributes" is inconsistent.  This is another reason for not getting rid of @slur, etc. entirely.

When hand-coding is no longer necessary, then @slur, etc. including @tie can go away, but I don't think we're completely there yet.

Just my two cents,

--

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 Raffaele Viglianti [raffaeleviglianti at gmail.com]
Sent: Saturday, July 07, 2012 6:07 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] datatype [imt][1-6]

Hello,

On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>> wrote:

Basically, this change would mean that we drop the possibility for a one-pass encoding here and require a second pass. That's certainly a drawback

A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) .

I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me.

Best,
Raffaele

.

Thanks again, and still listening to other opinions,
Johannes

Am 06.07.2012 um 23:17 schrieb TW:

> I agree with this, as well.  I never felt comfortable with this kind
> of beam/slur indication as it scatters information about a single
> object over several others, and the object itself doesn't even exist
> as an entity of its own.  @beam/@slur attributes would make sense to
> me if they were plists/idrefs pointing to the beam/beamSpan/slur
> element they belong to.
>
> For lyrics however, i|m|t totally convinces me as it indicates the
> relationship between different entities.
>
> Thomas
>
>
> 2012/7/6 Raffaele Viglianti <raffaeleviglianti at gmail.com<mailto:raffaeleviglianti at gmail.com>>:
>> Dear all,
>>
>> In general, I would agree with both of Andrew's points:
>> - get rid of the datatype for beam and other "spanners" like slurs and
>> tuplets (and the related attributes);
>> - keep i/m/t for wordpos (can't think of any other places where this could
>> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might
>> be worth keeping.
>>
>> Best,
>> Raffaele
>>
>>
>>
>> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <Maja.Hartwig at gmx.de<mailto:Maja.Hartwig at gmx.de>> wrote:
>>>
>>> Dear Johannes and Perry!
>>>
>>> Actually I used this datatype, but never for encoding beams, rather for
>>> slurs, though my understanding was a different one.
>>> I used the "i1" for the first slur in a measure, "i2" for the second one
>>> also when the first beam ended before.
>>> So I didn´t use the "i1" twice in one measure, because I think that would
>>> be confusing to get the appropriate "i´s" and "t´s" together.
>>> I was always wondering about the limit of 1-6, because in my way of using
>>> that datatype, I couldn´t encode more than 6 slurs in a measure.
>>> Now I switched over to encode slurs with @tstamp and duration or @startid
>>> and @endid.
>>> To encode beams, I always use the <beam>/<beamSpan>, and I think I
>>> wouldn´t miss the i/m/t 1-6!
>>> Best,
>>>
>>> Maja
>>>
>>>
>>> -------- Original-Nachricht --------
>>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200
>>>> Von: Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>>
>>>> An: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>>
>>>> Betreff: [MEI-L] datatype [imt][1-6]
>>>
>>>> Dear MEI-L,
>>>>
>>>> this is a somewhat technical question that I still would like to ask all
>>>> of you, although it's particularly interesting to hear developer's
>>>> opinions.
>>>>
>>>> MEI offers several attributes with a datatype of [imt][1-6], that is one
>>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to
>>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature
>>>> which may
>>>> overlap. The number distinguishes between those overlapping occurences.
>>>> For
>>>> instance a
>>>>
>>>> <note beam="i1">
>>>>
>>>> indicates the beginning of a beam. If a second, independent beam would
>>>> start before the first ends, it would be start with a value of "i2". If
>>>> it
>>>> would start after the end of the first one, it would reuse the "i1"
>>>> value.
>>>> Trying to clarify such details in the Guidelines, Perry and me are
>>>> wondering
>>>> if this behaviour is particularly comprehensible, or if we should take
>>>> this
>>>> feature away completely. You may encode beams using either the <beam> or
>>>> <beamSpan> element, the first one being extremely comfortable, the
>>>> second
>>>> extremely flexible. Besides beams, the same datatype is available for
>>>> tuplets
>>>> and slurs, which also offer other encoding possibilities. Is anyone
>>>> actually using the functionality of this datatype, or do you have strong
>>>> opinions
>>>> for other reasons?
>>>>
>>>> It would be great if we could get some feedback in the next couple of
>>>> days
>>>> in order to make a decision about this soon.
>>>>
>>>> Thanks very much,
>>>> Perry and 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
>>
>>
>>
>> _______________________________________________
>> 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

_______________________________________________
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/20120707/6d0606dd/attachment.html>