Hello,<br><br><div class="gmail_quote">On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <span dir="ltr"><<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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</blockquote><div><br></div><div>A second pass towards what? Do you have a specific transformation in mind? Once the XML tree is parsed, knowing that a note is beamed (and whether its i/m/t) by its attribute value or by its ancestor::beam + position should be equivalent (beamspan is more complex, but that's already the case) .</div>
<div><br></div><div>I'm also slightly concerned about keeping @tie if we get rid of @slur and @beam. Even though @tie is less ambiguous and so has a different datatype, they all just seem to be part of the same category to me.</div>
<div><br></div><div>Best,</div><div>Raffaele</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">.<br>
<br>
Thanks again, and still listening to other opinions,<br>
Johannes<br>
<br>
<br>
<br>
Am 06.07.2012 um 23:17 schrieb TW:<br>
<div class="HOEnZb"><div class="h5"><br>
> I agree with this, as well. I never felt comfortable with this kind<br>
> of beam/slur indication as it scatters information about a single<br>
> object over several others, and the object itself doesn't even exist<br>
> as an entity of its own. @beam/@slur attributes would make sense to<br>
> me if they were plists/idrefs pointing to the beam/beamSpan/slur<br>
> element they belong to.<br>
><br>
> For lyrics however, i|m|t totally convinces me as it indicates the<br>
> relationship between different entities.<br>
><br>
> Thomas<br>
><br>
><br>
> 2012/7/6 Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>>:<br>
>> Dear all,<br>
>><br>
>> In general, I would agree with both of Andrew's points:<br>
>> - get rid of the datatype for beam and other "spanners" like slurs and<br>
>> tuplets (and the related attributes);<br>
>> - keep i/m/t for wordpos (can't think of any other places where this could<br>
>> be needed, though as a rule of thumb, if 1-6 is not needed then i/m/t might<br>
>> be worth keeping.<br>
>><br>
>> Best,<br>
>> Raffaele<br>
>><br>
>><br>
>><br>
>> On Fri, Jul 6, 2012 at 5:48 PM, Maja Hartwig <<a href="mailto:Maja.Hartwig@gmx.de">Maja.Hartwig@gmx.de</a>> wrote:<br>
>>><br>
>>> Dear Johannes and Perry!<br>
>>><br>
>>> Actually I used this datatype, but never for encoding beams, rather for<br>
>>> slurs, though my understanding was a different one.<br>
>>> I used the "i1" for the first slur in a measure, "i2" for the second one<br>
>>> also when the first beam ended before.<br>
>>> So I didn´t use the "i1" twice in one measure, because I think that would<br>
>>> be confusing to get the appropriate "i´s" and "t´s" together.<br>
>>> I was always wondering about the limit of 1-6, because in my way of using<br>
>>> that datatype, I couldn´t encode more than 6 slurs in a measure.<br>
>>> Now I switched over to encode slurs with @tstamp and duration or @startid<br>
>>> and @endid.<br>
>>> To encode beams, I always use the <beam>/<beamSpan>, and I think I<br>
>>> wouldn´t miss the i/m/t 1-6!<br>
>>> Best,<br>
>>><br>
>>> Maja<br>
>>><br>
>>><br>
>>> -------- Original-Nachricht --------<br>
>>>> Datum: Fri, 6 Jul 2012 18:16:41 +0200<br>
>>>> Von: Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>><br>
>>>> An: Music Encoding Initiative <<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>><br>
>>>> Betreff: [MEI-L] datatype [imt][1-6]<br>
>>><br>
>>>> Dear MEI-L,<br>
>>>><br>
>>>> this is a somewhat technical question that I still would like to ask all<br>
>>>> of you, although it's particularly interesting to hear developer's<br>
>>>> opinions.<br>
>>>><br>
>>>> MEI offers several attributes with a datatype of [imt][1-6], that is one<br>
>>>> letter out of i, m or t, follwed by a digit from 1 to 6. It is used to<br>
>>>> indicate the beginning ("i"), middle ("m") or end ("t") of a feature<br>
>>>> which may<br>
>>>> overlap. The number distinguishes between those overlapping occurences.<br>
>>>> For<br>
>>>> instance a<br>
>>>><br>
>>>> <note beam="i1"><br>
>>>><br>
>>>> indicates the beginning of a beam. If a second, independent beam would<br>
>>>> start before the first ends, it would be start with a value of "i2". If<br>
>>>> it<br>
>>>> would start after the end of the first one, it would reuse the "i1"<br>
>>>> value.<br>
>>>> Trying to clarify such details in the Guidelines, Perry and me are<br>
>>>> wondering<br>
>>>> if this behaviour is particularly comprehensible, or if we should take<br>
>>>> this<br>
>>>> feature away completely. You may encode beams using either the <beam> or<br>
>>>> <beamSpan> element, the first one being extremely comfortable, the<br>
>>>> second<br>
>>>> extremely flexible. Besides beams, the same datatype is available for<br>
>>>> tuplets<br>
>>>> and slurs, which also offer other encoding possibilities. Is anyone<br>
>>>> actually using the functionality of this datatype, or do you have strong<br>
>>>> opinions<br>
>>>> for other reasons?<br>
>>>><br>
>>>> It would be great if we could get some feedback in the next couple of<br>
>>>> days<br>
>>>> in order to make a decision about this soon.<br>
>>>><br>
>>>> Thanks very much,<br>
>>>> Perry and Johannes<br>
>>>> _______________________________________________<br>
>>>> mei-l mailing list<br>
>>>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>>><br>
>>> _______________________________________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br>