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

Andrew Hankinson, Mr andrew.hankinson at mail.mcgill.ca
Fri Jul 6 18:30:32 CEST 2012


I didn't know what those were for, but now that I do I think the numerical indication is quite confusing for overlapping elements. It would be clearer and easier to use the @staff and @layer attributes on the spanning elements to indicate which particular staff and layer (or "voice") they apply to, and then the @tstamp, @dur, @startid & @endid for start and end points.

I wouldn't do away with the 'i', 'm', and 't' completely, though. That would be particularly useful for things like @wordpos in lyric syllables. You wouldn't need the numbers, though.

-Andrew

On 2012-07-06, at 12:16 PM, Johannes Kepper wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1054 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120706/c2e2a6cc/attachment.bin>


More information about the mei-l mailing list