[MEI-L] trills within beams

[Johannes Kepper]

Slowly, calm down. I am on your side, I want to deprecate this. But we have agreed that the schema for the upcoming release is already frozen. There is a loose idea to have another release before the current DFG/NEH grant ends, which will be around late summer 2013. If we would deprecate (= technically allow, but discourage to use) it by then and kill it in the release following that, I think we would have a reasonable schedule. The only question is if we want to mention the future deprecation in the current guidelines or not ("@tie is likely to be deprecated in future releases of MEI" etc.). This seems like a doubled deprecation process to me, but would probably be more fair to everyone who's going to start encoding today. The remaining time could also help to have the applications we've been talking about in place. 





Am 07.03.2012 um 12:29 schrieb 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,

That's another issue that has been raised already internally (@Laurent, look for Perry's mail from 2011-07-07), but which was never responded. I think we will have to put that in a separate thread. I know that Perry is busy today, so I will try to sum it up to give us a good start in this discussion.



Best,
Johannes



> 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
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l