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

[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>:
> 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> 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>
>> > An: Music Encoding Initiative <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
>> > 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
>