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

[Maja Hartwig]

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