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

Sat Jul 7 00:23:58 CEST 2012

Dear all, 

thanks for the answers so far, they are really helpful. Just to clarify: We don't want to touch [imt], that's a completely different datatype which is used not only for @wordpos, but also for @tie. As these can't overlap, there is no risk for confusion. We also regard this datatype as undoubtedly handy, so it won't go away, no matter what we will do with [imt][1-6]. 

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, but it seems like the current solution for single-pass is at least misleading and should therefore go away before causing more trouble. We might want to think about introducing a different one-pass method later, though. 

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>:
>> 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
>> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l