[MEI-L] Interpreting @tstamp2

[Johannes Kepper]

I agree that "target measure" is probably clearer than "current measure" in this context. One thing I wanted to add: It is possibly to omit the "[1-9]m" part, but I would strongly recommend to write this always as "0m+2" etc. To me, the regex that defines this data type (available from http://www.music-encoding.org/documentation/guidelines2013/data.MEASUREBEAT) is defined too loosely. I would also advise against the whitespaces in there, even though they may increase readability (I guess that's their justification in the first place). What do others think – should we provide stricter rules for data.MEASUREBEAT, or should we leave it as open as it is now?

Johannes



Am 08.07.2013 um 12:07 schrieb Kőmíves Zoltán <zolaemil at gmail.com>:

> Thinking about it, it's about considering *target* measure, rather than *current* measure.
> 
> Current measure sometimes equals to target measure, but more generally timestamp values relate to the time signature of the measure where they are pointing to. @tstamp can only point to the current measure, so in that case the distinction is irrelevant, but in case of @tstamp2 maybe it would make a sense to say that beats in @tstamp2 values are calculated in relation to the target measure, and if no measure part "[1-9]m" is specified then target measure = current measure.
> 
> What do you think?
> Zoltan
> 
> 
> 2013/7/8 Kőmíves Zoltán <zolaemil at gmail.com>
> Hi Johannes, 
> 
> Thanks for your answer! 
> 
> Sure will file the issue, is this the link to do so: https://code.google.com/p/music-encoding/ ?
> 
> Thanks
> Zoltan
> 
> 
> 2013/7/8 Johannes Kepper <kepper at edirom.de>
> Hi Zoltán,
> 
> congrats, you've spotted another underspecification. You're absolutely right – it makes no sense to calculate the distance and timestamp of the range all by the first meter if that is changed later on. The "2m" part is clearly independent from the meter, and for the "+3" part, the "ending measure" should be regarded as current (so that in case of a meter change from 4/4 to 6/8, it would denote the third eighth in this case).
> 
> Can you file a bug report on Google Code?
> 
> Best,
> Johannes
> 
> Am 08.07.2013 um 10:56 schrieb Kőmíves Zoltán <zolaemil at gmail.com>:
> 
> > Hi All,
> >
> > I'm looking for confirmation that my thinking is right about interpreting @tstamp2 values (e.g. 2m+2) when the time signature changes between the location of the element indicating @tstamp and the 2nd next measure.
> >
> > According to the guidelines 'the timestamp (@tstamp) of a musical event is calculated in relation to the meter of the *current* measure and resembles the so-called ‘beat’.' About @tstamp: '[@tstamp2] is expressed using the same logic as described above'. (see http://music-encoding.org/documentation/guidelines2013/cmn#cmnTstamp )
> >
> > I haven't found any explicit statement how to understand *current* measure in case of @tstamp2. Strictly speaking, *current* measure is the measure where the element with the @tstamp2 is located. However intuitively, all encountered measures should be considered with their effective time signature, therefore if there are three measures, the first in 2/4, the second in 5/8 and the third is 2/4, then 2m+1 should indicate the first quarter note in the last measure (as opposed to the 5th eights note in the second measure).
> >
> > Thank you
> > Zoltan Komives
> > _______________________________________________
> > 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