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

[Raffaele Viglianti]

Hello,

On Fri, Jul 6, 2012 at 11:23 PM, Johannes Kepper <kepper at edirom.de> wrote:
>
>
> 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


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) .

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.

Best,
Raffaele


> .
>
> 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
>
>
> _______________________________________________
> 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/20120707/d88ff22a/attachment.html>