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

Raffaele Viglianti raffaeleviglianti at gmail.com
Fri Jul 6 22:14:50 CEST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120706/ede55dd7/attachment.html>


More information about the mei-l mailing list