[MEI-L] trills within beams

[Laurent Pugin]

>I agree.  An "inputting environment" might want to offer the
> >convenience notation and extend them "automatically".  I don't know
> >whether this is a sensible suggestion, but what about moving
> >convenience features to a module of their own so they can easily be
> >enabled/disabled?  (Am I opening another can of worms?)
>

This seems to be over the top for me. I think we should take a decision and
I would vote for deprecating them. It does not have to be within 5 minutes,
but the earlier the better (10 minutes?). Once we will have tools relying
on them, we will have votes against deprecation, which does not seem to be
the case now - actually, I already use them but would not mind shutting up
if it can allow some simplification.

Now for the trill, I my understanding correct that we would expect this
encoding

<trill>
 <note />
 <note />
 <note />
</trill>

to be used for encoding the realization of the trill, and that

<note id="123" />
<trill startid="123" />

to be used for encoding the note (as written) with its ornament?

I guess one would rather (or also) use .ges attributes for encoding its
realization, but using the first one with only the written note seems
awkward to me because logically, I see a note with a trill and really not a
trill with a note. It is significantly different from a chord and from a
beam. Do we care about this?

Laurent


> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
> ________________________________________
> From: mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de[mei-l-bounces+pdr4h=
> virginia.edu at lists.uni-paderborn.de] on behalf of TW [
> zupftom at googlemail.com]
> Sent: Tuesday, March 06, 2012 12:46 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] trills within beams
>
> 2012/3/6 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
> > Slow down, take it easy, remain calm.  I said I could imagine a future
> without them, but I didn't mean in the next 5 minutes.  :)
> >
> > These features are very convenient for hand-encoders.  They have been
> frequently requested in the past and, in fact, this thread started with a
> request for just such a feature.
> >
> > These features also make it somewhat easier to more-directly capture
> data from other systems that allow/encourage this kind of thing.
> >
> > So, I would urge caution at this point.  Anyone who doesn't want to use
> these "conveniences" shouldn't feel compelled to do so.
>
> The problem for people like me and Julian is that we don't have a
> choice because we have to eat what people are throwing at us.  If we
> want to handle MEI as completely as possible, we currently would have
> to take into account four different ways for specifying beams
> (@beam.group/@beam.rest, <beam>, <beamspan> and @beam).  <beamspan>
> again has two ways of being used, @startid+ at endid and @tstamp+ at dur,
> (In theory and mathematicaly, the specs allow for twelve different
> combinations, but I believe that the @*.ges and @*.real attributes
> don't make a lot of sense and mixing IDs and time based start/end
> attributes can be neglected).
>
> > But I don't think that I want to rush to remove them.  I think we should
> be thinking about canonicalization instead.
>
> I agree.  An "inputting environment" might want to offer the
> convenience notation and extend them "automatically".  I don't know
> whether this is a sensible suggestion, but what about moving
> convenience features to a module of their own so they can easily be
> enabled/disabled?  (Am I opening another can of worms?)
>
> Thomas
>
> _______________________________________________
> 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
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120307/311f6eb8/attachment.html>