<div dir="ltr">Hello Eleanor,<div><br></div><div>You make an important point about cadenzas and other events that cannot be addressed by beat (such as grace notes). Back to the drawing board for this.</div><div><br></div><div>For un-measured music, it is possible to adopt the drafted addressing system without much change, as long as a beat-based system is still sufficiently expressive. Will give this more thought as well.</div><div><br></div><div>Thanks everyone for the very useful feedback!</div><div><br></div><div>Raff</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 5:08 PM, Eleanor Selfridge-Field <span dir="ltr"><<a href="mailto:esfield@stanford.edu" target="_blank">esfield@stanford.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
RE "unmeasured", a written cadenza (unmeasured) within a measured context would not work in an "until the end of time" scenario.<br>
<br>
Requiring "measured" only will also leave aside a lot of 17th and 20th century music. Finale introduced this concept in 1987 to work with MIDI interchange, but our goals are not the same as Finale's. Could there be a branch for unmeasured, polyrhythms, non- Western, and other "special needs" repertories?<br>
<br>
Eleanor<br>
<br>
<br>
<br>
<br>
<br>
<br>
<!--<br>
/* Font Definitions */<br>
@font-face<br>
{font-family:"Cambria Math";<br>
panose-1:2 4 5 3 5 4 6 3 2 4;<br>
mso-font-charset:0;<br>
mso-generic-font-family:roman;<br>
mso-font-pitch:variable;<br>
mso-font-signature:-536870145 1107305727 0 0 415 0;}<br>
@font-face<br>
{font-family:Calibri;<br>
panose-1:2 15 5 2 2 2 4 3 2 4;<br>
mso-font-charset:0;<br>
mso-generic-font-family:swiss;<br>
mso-font-pitch:variable;<br>
mso-font-signature:-536870145 1073786111 1 0 415 0;}<br>
/* Style Definitions */<br>
p.MsoNormal, li.MsoNormal, div.MsoNormal<br>
{mso-style-unhide:no;<br>
mso-style-qformat:yes;<br>
mso-style-parent:"";<br>
margin:0in;<br>
margin-bottom:.0001pt;<br>
mso-pagination:widow-orphan;<br>
font-size:11.0pt;<br>
font-family:"Calibri","sans-serif";<br>
mso-ascii-font-family:Calibri;<br>
mso-ascii-theme-font:minor-latin;<br>
mso-fareast-font-family:"Times New Roman";<br>
mso-fareast-theme-font:minor-fareast;<br>
mso-hansi-font-family:Calibri;<br>
mso-hansi-theme-font:minor-latin;<br>
mso-bidi-font-family:"Times New Roman";<br>
mso-bidi-theme-font:minor-bidi;}<br>
a:link, span.MsoHyperlink<br>
{mso-style-priority:99;<br>
color:blue;<br>
text-decoration:underline;<br>
text-underline:single;}<br>
a:visited, span.MsoHyperlinkFollowed<br>
{mso-style-noshow:yes;<br>
mso-style-priority:99;<br>
color:#954F72;<br>
mso-themecolor:followedhyperlink;<br>
text-decoration:underline;<br>
text-underline:single;}<br>
.MsoChpDefault<br>
{mso-style-type:export-only;<br>
mso-default-props:yes;<br>
font-size:11.0pt;<br>
mso-ansi-font-size:11.0pt;<br>
mso-bidi-font-size:11.0pt;<br>
mso-ascii-font-family:Calibri;<br>
mso-ascii-theme-font:minor-latin;<br>
mso-fareast-font-family:"Times New Roman";<br>
mso-fareast-theme-font:minor-fareast;<br>
mso-hansi-font-family:Calibri;<br>
mso-hansi-theme-font:minor-latin;<br>
mso-bidi-font-family:"Times New Roman";<br>
mso-bidi-theme-font:minor-bidi;}<br>
@page WordSection1<br>
{size:8.5in 11.0in;<br>
margin:1.0in 1.0in 1.0in 1.0in;<br>
mso-header-margin:.5in;<br>
mso-footer-margin:.5in;<br>
mso-paper-source:0;}<br>
div.WordSection1<br>
{page:WordSection1;}<br>
--><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Eleanor<br>
Selfridge-Field<br>
<br>
Consulting Professor, Music (and, by courtesy, Symbolic Systems)<br>
<br>
Braun Music Center #129<br>
<br>
Stanford University<br>
<br>
Stanford, CA 94305-3076, USA<br>
<br>
<a href="http://web.stanford.edu/~esfield/" target="_blank">http://web.stanford.edu/~esfield/</a><br>
<a href="tel:%2B1%2F%20650%20725-9242" value="+16507259242">+1/ 650 725-9242</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
From: Raffaele Viglianti <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>><br>
To: Music Encoding Initiative <<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>><br>
Sent: Wed, 12 Nov 2014 07:54:34 -0800 (PST)<br>
Subject: Re: [MEI-L] Music Addressability API draft<br>
<br>
Hello,<br>
<br>
Point 1 is clear to me too and it's good to see that we seem to agree all<br>
around :) The Music Addressability API adopts the same understanding (it<br>
will be made clear that it is derived by the MEI specification), minus the<br>
measure component (Xm+). The latter is not needed because the measure<br>
parameter already sets the context.<br>
<br>
Point 2 I have less of a passion for, but I see Craig's point. It shouldn't<br>
be too taxing for the datatype to support fractions too. I guess we can<br>
continue discussion of this point in the other thread.<br>
<br>
Laurent wrote:<br>
> do you think it would be possible to support un-measured music? I saw<br>
that measure is required, and I am not sure how this would work with MEI<br>
where we have /staff directly under /section. Any idea?<br>
<br>
Mostly, what's stopping me from making measure optional is that having a<br>
middle parameter being optional complicates the parsing of the URL. I am<br>
tempted to consider un-measured music as one-measured music for the sake of<br>
the addressing act. This would also require adopting an absolute beat that<br>
counts from 0 to the end of the piece. So you may have expressions like<br>
/1/1-4/1-22 to indicated a selection of fours staves, from the beginning to<br>
the end of a piece spanning across 22 beats (taking into account time<br>
signature changes). Does that make sense? If it seems too complex, it may<br>
be worth considering a dedicated route for un-measured music that may take<br>
into account barlines for a neater beat-based selection. Other ideas?<br>
<br>
Thanks!<br>
Raff<br>
<br>
On Wed, Nov 12, 2014 at 6:23 AM, Laurent Pugin <<a href="mailto:laurent@music.mcgill.ca">laurent@music.mcgill.ca</a>><br>
wrote:<br>
<br>
> Point 1 seems clear to me.<br>
><br>
> Point 2: I think we should be concerned about round-off errors. It<br>
> probably does not matter for elements such as harpins, but as Craig<br>
> explained, they do create well-known problems for data processing.<br>
><br>
> Laurent<br>
><br>
> On Wed, Nov 12, 2014 at 4:49 AM, Roland, Perry D. (pdr4h)<br>
> <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>> wrote:<br>
> ><br>
> > It seems to me that there are at least 2 intertwined issues here. One<br>
> is how to specify the logical and visual endpoints of a control event; that<br>
> is, a feature that uses @tstamp2. Another is what values @tstamp2 ought to<br>
> allow. Yet another is the question of "addressability".<br>
> ><br>
> > On issue 1 Laurent wrote:<br>
> ><br>
> >> With @tstamp2, we could recommend to have<br>
> >><br>
> >> <hairpin tstamp="1" tstamp2="0m+3"/><br>
> >><br>
> >> if the hairpin stops before the barline and<br>
> >><br>
> >> <hairpin tstamp="1" tstamp2="1m+1"/><br>
> >><br>
> >> if it stops after right before the first note of the next measure as<br>
> >> in the attachement. Then further adjustments can be done with @ho.<br>
> ><br>
> > This is the precisely how I think tstamp2 should be used. Assuming the<br>
> first example is in 2/4, "0m+3" would be at the barline. The second<br>
> hairpin would end on beat 1 of the following measure. Visually, however,<br>
> both hairpins should terminate just before their "logical" endpoints. This<br>
> is consistent with the way most musicians understand hairpins (as other<br>
> things with the tstamp2 attribute) -- a hairpin is in effect until the next<br>
> beat or fraction of a beat following its visual end. This accommodates any<br>
> marking (such as a forte dynamic marking) that might occur directly on the<br>
> logical beat (on beat 1 in the 2nd example). I believe this is what<br>
> Raffaele was referring to by saying he would allow the rendering engine to<br>
> make decisions about the visual placement of the endpoint of the hairpin.<br>
> This spacing between the logical end of the hairpin and its visual end<br>
> should be specified in the configuration of the renderer.<br>
> ><br>
> > @ho is relative to this ending value. So,<br>
> ><br>
> > tstamp="0m+3" ho="-1.2"<br>
> ><br>
> > indicates termination at the barline, but visually moved "backward" 1.2<br>
> virtual units (remember a virtual unit is 1/2 the distance between staff<br>
> lines). The only question for me is whether the "default" behavior of<br>
> allowing some space between the visual ending of the feature and its<br>
> logical ending is or is not accounted for in this case. I think it is not;<br>
> that is, the @ho value "overrides" the amount of space the rendering engine<br>
> would normally leave between the end of the hairpin and the terminal beat.<br>
> Note that the value of @ho can be positive or negative, allowing one to<br>
> move the endpoint forward or backward.<br>
> ><br>
> > Point 2:<br>
> > I'm not opposed to somehow allowing fractions within data.BEAT, but if<br>
> we make our position on Point 1 clear, then I don't see the need for it,<br>
> since "1.3" is just another way of writing "1+1/3". I don't think we<br>
> should be concerned with round-off error since the decimal part of "1.3" is<br>
> intended to indicate a fractional part of the beat; that is, one can write<br>
> "1.333" or "1.3" or "1+1/3", but all three mean the location of the 2nd<br>
> note of a triplet beginning on beat 1, in other words, a musical value, not<br>
> a visual one. @tstamp2 *should only* refer to the "logical" endpoint. @ho<br>
> should be used to move the visual endpoint. This contradicts my own<br>
> earlier thinking and Johannes' suggestion to use "4.999" to encode a<br>
> hairpin stopping just before the beat. I believe this erroneously<br>
> conflates the logical and visual endpoints.<br>
> ><br>
> > Does this help clarify things? Am I missing something?<br>
> ><br>
> > I will delay comment on addressability until later. It's dinner time in<br>
> Kunming. :-)<br>
> ><br>
> > --<br>
> > p.<br>
> ><br>
> ><br>
> > __________________________<br>
> > Perry Roland<br>
> > Music Library<br>
> > University of Virginia<br>
> > P. O. Box 400175<br>
> > Charlottesville, VA 22904<br>
> > 434-982-2702 (w)<br>
> > pdr4h (at) virginia (dot) edu<br>
> > ________________________________________<br>
> > From: mei-l [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Laurent<br>
> Pugin [<a href="mailto:laurent@music.mcgill.ca">laurent@music.mcgill.ca</a>]<br>
> > Sent: Tuesday, November 11, 2014 1:54 PM<br>
> > To: Music Encoding Initiative<br>
> > Subject: Re: [MEI-L] Music Addressability API draft<br>
> ><br>
> >>><br>
> >>> Another way of representing this could be to have something like a<br>
> >>> @timespan to encode the extend of the event.<br>
> >><br>
> >><br>
> >> I wonder if this would really be more expressive than tstamp2... There<br>
> is<br>
> >> some advantage in switching the context to the "landing" measure; it<br>
> seems<br>
> >> more intuitive to me to determine the beat relatively to the time<br>
> signature<br>
> >> at the measure where the event stops.<br>
> >><br>
> ><br>
> > Changing to a @tispan could still mean that the time signature of the<br>
> > measure where it ends has to be taken into account. But I agree it<br>
> > does not necessary change much. What is probably bugging me is the use<br>
> > of the sign "+" together with the fact that is is 1-based. It seems<br>
> > confusing to says 1m+1 where actually +1 adds nothing. Another sign<br>
> > (e.g., /) would be clearer, I think: "1m/1", or making it 0-based.<br>
> > This might look like a detail, but I think it creates a lot of<br>
> > confusion and it might very well be one reason for the discussion<br>
> > here. If this cannot be changed it certainly requires some<br>
> > clarification.<br>
> ><br>
> >> Re: Behind Bars p. 105, I'm conflicted on whether that should be<br>
> something<br>
> >> left to a rendering system (or @ho). I would be tempted to encode that<br>
> as<br>
> >> extending to the forte on beat 1 with @tstamp2="1m+1" and leave it to a<br>
> >> rendering system to figure out whether it needs to stop before the<br>
> barline<br>
> >> or not. That would be my interpretation of the semantics there and my<br>
> >> encoding would reflect that. I would use @ho to specify relative<br>
> positions<br>
> >> if I want to be specific with the intended output. What do you think?<br>
> ><br>
> > I am not sure how to encode this with @ho. The problem is an offset to<br>
> > what? We can have many things at the beginning for the measure before<br>
> > the first note (clef, key signature, etc.), so it seems difficult to<br>
> > use offsets for this, but maybe I am overlooking something. This is<br>
> > why I thought that having two ways of encoding an event with the same<br>
> > duration could be of some help (not necessary for rendering, but also<br>
> > for encoding how this is in a source). With @tstamp2, we could<br>
> > recommend to have<br>
> ><br>
> > <hairpin tstamp="1" tstamp2="0m+3"/><br>
> ><br>
> > if the hairpin stops before the barline and<br>
> ><br>
> > <hairpin tstamp="1" tstamp2="1m+1"/><br>
> ><br>
> > if it stops after right before the first note of the next measure as<br>
> > in the attachement. Then further adjustments can be done with @ho. Is<br>
> > this what you are saying? Or would you use only the second approach<br>
> > even we it stops before the barline?<br>
> ><br>
> >><br>
> >> (For those who don't have Behind Bars or don't want to go grab the book<br>
> from<br>
> >> the high shelf, I'm attaching a version of the Behind Bars example<br>
> >> re-typeset in MuseScore - I hope it makes it because I don't remember<br>
> if the<br>
> >> list allows attachments)<br>
> ><br>
> > Thanks!<br>
> ><br>
> >><br>
> >> On the other hand, I wouldn't be opposed to allowing fractions in the<br>
> >> datatype. It could be useful.<br>
> ><br>
> > Good.<br>
> >><br>
> >>><br>
> >>> I haven't had the time to look at the EMA repository yet, but this<br>
> >>> looks quite useful!<br>
> >><br>
> >><br>
> >> Thanks! I look forward to your comments if you have any :)<br>
> ><br>
> > Yes: do you think it would be possible to support un-measured music? I<br>
> > saw that measure is required, and I am not sure how this would work<br>
> > with MEI where we have /staff directly under /section. Any idea?<br>
> ><br>
> > Best,<br>
> > Laurent<br>
> ><br>
> >><br>
> >> Raff<br>
> >><br>
> >>><br>
> >>><br>
> >>> Laurent<br>
> >>><br>
> >>> On Tue, Nov 4, 2014 at 2:09 PM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com">zolaemil@gmail.com</a>><br>
> wrote:<br>
> >>> > Hi Raff,<br>
> >>> ><br>
> >>> > My comment was more about the ambiguity that is created by the<br>
> implicit<br>
> >>> > nature of the actual cut-off mode (and this is vaguely related to the<br>
> >>> > MEI<br>
> >>> > tstamp2 problem).<br>
> >>> ><br>
> >>> > If the definition of the "cut" mode is that the end value is the<br>
> >>> > absolute<br>
> >>> > end, that is nothing can extend longer than the end value, you can<br>
> still<br>
> >>> > chose to discard or actually cut the events that would extend longer,<br>
> >>> > but<br>
> >>> > the point is that this position is defined by then end value<br>
> explicitly,<br>
> >>> > rather than implicitly (by applying ceil or +1).<br>
> >>> ><br>
> >>> > So in 4/4 the if the URL ended something like "../1-3/cut" and<br>
> there's a<br>
> >>> > half-note starting on the second beat, it will be qualified as a<br>
> non-fit<br>
> >>> > (while according the original system, it would be qualified as a<br>
> fit.)<br>
> >>> > This<br>
> >>> > would also allow you to specify an interval shorter than a beat (e.g.<br>
> >>> > 1-1.5/cut).<br>
> >>> ><br>
> >>> > I wasn't trying to suggest anything about what to do with the<br>
> >>> > non-fitters<br>
> >>> > though. I guess it is very much application dependent; perhaps would<br>
> be<br>
> >>> > a<br>
> >>> > good idea to allow three options here: drop, keep, cut?<br>
> >>> ><br>
> >>> > Z<br>
> >>> ><br>
> >>> ><br>
> >>> > 2014-11-04 14:46 GMT+00:00 Raffaele Viglianti<br>
> >>> > <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>>:<br>
> >>> >><br>
> >>> >> Hi Zoltan,<br>
> >>> >><br>
> >>> >> Thanks for your email!<br>
> >>> >><br>
> >>> >> I think we agree entirely on the tstamp2 issue. Your more<br>
> sophisticated<br>
> >>> >> example matches my expectations. I would definitely keep the same<br>
> >>> >> behavior<br>
> >>> >> also for percussive/plucked instruments and other borderline<br>
> scenarios<br>
> >>> >> like<br>
> >>> >> an eight for double bass that is to be played both pizzicato and<br>
> >>> >> crescendo<br>
> >>> >> (I guess in this case the bass becomes a plucked instrument).<br>
> >>> >><br>
> >>> >> I also struggle to think of a reasonable example for slurs, but<br>
> >>> >> notation<br>
> >>> >> doesn't always match a physical gesture or real sound effect. So I<br>
> >>> >> would<br>
> >>> >> keep the same tstamp2 behavior for phrase marks too.<br>
> >>> >><br>
> >>> >> About EMA, I see your point. I think ceil(end) is what I mean now<br>
> for<br>
> >>> >> "cut" mode. If you have an end beat of 1, you consider the whole of<br>
> >>> >> beat 1.<br>
> >>> >> If you have 1.2 you consider the whole of beat 1 and .2 of the<br>
> >>> >> following.<br>
> >>> >> This forces a processor to alter the notation to fit the beat limit.<br>
> >>> >> Are you<br>
> >>> >> suggesting that event that do not end within the range should be<br>
> >>> >> dropped<br>
> >>> >> entirely in "cut" mode? That may be easier to implement, but then a<br>
> >>> >> selection of beat 1 to 1 where only a whole note is encoded, would<br>
> >>> >> return an<br>
> >>> >> empty set.<br>
> >>> >><br>
> >>> >> Raff<br>
> >>> >><br>
> >>> >><br>
> >>> >> On Tue, Nov 4, 2014 at 4:14 AM, Kőmíves Zoltán <<a href="mailto:zolaemil@gmail.com">zolaemil@gmail.com</a>><br>
> >>> >> wrote:<br>
> >>> >>><br>
> >>> >>> Hi Raff,<br>
> >>> >>><br>
> >>> >>> I'm glad to see you're making great progress with the EMA project!<br>
> Let<br>
> >>> >>> me<br>
> >>> >>> chip in to the discussion with some casual comments.<br>
> >>> >>><br>
> >>> >>> I like your description of the thought-process of transcribing a<br>
> >>> >>> hairpin<br>
> >>> >>> from a source document. I think there may be room for some more<br>
> >>> >>> sophistication here: for example if a performer sees a hairpin<br>
> ending<br>
> >>> >>> roughly on the last beat of the measure, or perhaps slightly after<br>
> it,<br>
> >>> >>> they<br>
> >>> >>> could argue that the crescendo needs to continue right to the end<br>
> of<br>
> >>> >>> the<br>
> >>> >>> measure, (they would especially inclined to do so, if in the next<br>
> >>> >>> measure a<br>
> >>> >>> diminuendo starts at beat one). I think it is necessary to<br>
> distinguish<br>
> >>> >>> between this and the case, when the crescendo would actually stop<br>
> at<br>
> >>> >>> the<br>
> >>> >>> beginning of the last beat, and the performer would keep the volume<br>
> >>> >>> for the<br>
> >>> >>> duration of the last beat. Based on the logic you describe, I would<br>
> >>> >>> transcribe the full-length crescendo with tstamp2="5" or "4.999",<br>
> as<br>
> >>> >>> Jo<br>
> >>> >>> suggests. Then it could be up to there renderer to decide whether<br>
> to<br>
> >>> >>> draw<br>
> >>> >>> the hairpin right up to the barline or somewhere between the last<br>
> note<br>
> >>> >>> and<br>
> >>> >>> the barline.<br>
> >>> >>><br>
> >>> >>> In short, my penny is on tstamp2 meaning the absolute end.<br>
> >>> >>><br>
> >>> >>> N.B. the above problem only arises in situations when an event can<br>
> >>> >>> feasibly start/end between other time positions than beginning of<br>
> >>> >>> notes;<br>
> >>> >>> such a situation is a crescendo performed on a non-percussive(e.g.<br>
> >>> >>> piano)<br>
> >>> >>> and non-plucked instrument. Well, even on these instruments, the<br>
> >>> >>> full-length<br>
> >>> >>> crescendo may be the "artistic intention" and should be kept<br>
> intact,<br>
> >>> >>> even<br>
> >>> >>> though it is never going to be executed. However, I cannot think of<br>
> >>> >>> any<br>
> >>> >>> problematic case for slurs, for example (off the top of my head I<br>
> >>> >>> cannot<br>
> >>> >>> think of any example when the a slur starting or ending in between<br>
> >>> >>> notes is<br>
> >>> >>> particularly meaningful...)<br>
> >>> >>><br>
> >>> >>> As far as I can see, when it comes to EMA, it all boils down to the<br>
> >>> >>> definition of the end of the range. By default, the range is<br>
> flexible<br>
> >>> >>> on the<br>
> >>> >>> right hand side: it includes everything that start within the base<br>
> >>> >>> range,<br>
> >>> >>> defined by start and end positions. But it's not clear what the<br>
> >>> >>> cut-off<br>
> >>> >>> point is when you apply "cut"? Is it end+1 or ceil(end)? If it is<br>
> >>> >>> ceil(end),<br>
> >>> >>> is it not too restrictive that you cannot cut off at other<br>
> positions<br>
> >>> >>> than<br>
> >>> >>> integer beat positions? If it is end+1 it may not be very<br>
> intuitive to<br>
> >>> >>> use<br>
> >>> >>> when end isn't an integer value.<br>
> >>> >>><br>
> >>> >>> It seems to me that a more explicit definition of the end of the<br>
> range<br>
> >>> >>> could be more easy to deal with: by default the range as defined<br>
> now,<br>
> >>> >>> but in<br>
> >>> >>> "cut" mode nothing should extend longer than the end position. Then<br>
> >>> >>> the user<br>
> >>> >>> could have more control over the actual cut-off point.<br>
> >>> >>><br>
> >>> >>> Best<br>
> >>> >>> Zoltan<br>
> >>> >>><br>
> >>> >>> 2014-11-03 22:15 GMT+00:00 Raffaele Viglianti<br>
> >>> >>> <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>>:<br>
> >>> >>>><br>
> >>> >>>> Hi Jo,<br>
> >>> >>>><br>
> >>> >>>> Thank you for your reply! Very interesting question.<br>
> >>> >>>><br>
> >>> >>>> To help me explain my view on the problem you pose, let's consider<br>
> >>> >>>> your<br>
> >>> >>>> example 3 and 4 as if they were on two different staves of the<br>
> same<br>
> >>> >>>> piece.<br>
> >>> >>>> Time is 4/4.<br>
> >>> >>>><br>
> >>> >>>> On staff 1 we'd have a whole note with a crescendo, and we're<br>
> >>> >>>> debating<br>
> >>> >>>> whether tstamp2 should be 1 or 4:<br>
> >>> >>>> <hairpin tstamp="1" tstamp2="0m+1" form="cres" /> or<br>
> >>> >>>> <hairpin tstamp="1" tstamp2="0m+4" form="cres" /><br>
> >>> >>>><br>
> >>> >>>> On staff 2 we'd have three quarters and two eights, with an<br>
> hairpin<br>
> >>> >>>> going to the last note<br>
> >>> >>>> <hairpin tstamp="1" tstamp2="0m+4.5" form="cres" /><br>
> >>> >>>><br>
> >>> >>>> If I were encoding a source document, I would use tstamp2 to<br>
> specify<br>
> >>> >>>> were I think the crescendo ends in relationship to the beat. I<br>
> >>> >>>> justify this<br>
> >>> >>>> by imagining a performer performing the MEI (heh): I would prefer<br>
> a<br>
> >>> >>>> tstamp2=4 to indicate that the performer is expected to hold the<br>
> >>> >>>> volume<br>
> >>> >>>> around beat 4. I would do this because if the hairpin were<br>
> shorter,<br>
> >>> >>>> that<br>
> >>> >>>> would be meaningful musically. For example, if it were stopping<br>
> >>> >>>> around what<br>
> >>> >>>> would seem, as a performer, closer to beat 3 than 4.<br>
> >>> >>>><br>
> >>> >>>> What is less evident to me, instead, is how I would encode this<br>
> when<br>
> >>> >>>> the<br>
> >>> >>>> staff below has the hairpin stretching to 4.5 because of the<br>
> eights.<br>
> >>> >>>> Is it<br>
> >>> >>>> ok to have the hairpins on each staff ending at different tstamps<br>
> (4<br>
> >>> >>>> and<br>
> >>> >>>> 4.5)? If the source document aligns them, should the tstamp2s be<br>
> >>> >>>> aligned<br>
> >>> >>>> too? Or should the alignment be left to a rendering system. I may<br>
> >>> >>>> lean<br>
> >>> >>>> towards adjusting both tstamp2s to match, but I can also see why<br>
> the<br>
> >>> >>>> opposite could be argued.<br>
> >>> >>>><br>
> >>> >>>> EMA is relative unaffected by this problem. The API, as it is now,<br>
> >>> >>>> specifies that any notational element occurring *on* the final<br>
> beat<br>
> >>> >>>> is<br>
> >>> >>>> considered in its entirety, regardless of how its dur or tstamp2<br>
> are<br>
> >>> >>>> expressed. So a selection on the example above of staff 1, beat 1,<br>
> >>> >>>> would<br>
> >>> >>>> return the whole note *and* the hairpin with its tstamp2<br>
> unaltered.<br>
> >>> >>>><br>
> >>> >>>> This default behavior can be overridden by raising the "cut" flag,<br>
> >>> >>>> which<br>
> >>> >>>> will force the returned notation to be altered to stay within the<br>
> >>> >>>> range<br>
> >>> >>>> specified. So a selection on the example above of staff 1, beat 1,<br>
> >>> >>>> would<br>
> >>> >>>> return *a quarter* note and the hairpin with its tstamp2 changed<br>
> to<br>
> >>> >>>> 1.<br>
> >>> >>>><br>
> >>> >>>> I'm more than happy to discuss whether this is a good idea, etc.<br>
> >>> >>>><br>
> >>> >>>> Thanks again! Best,<br>
> >>> >>>> Raff<br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>><br>
> >>> >>>> On Mon, Nov 3, 2014 at 4:33 PM, Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a><br>
> ><br>
> >>> >>>> wrote:<br>
> >>> >>>>><br>
> >>> >>>>> Hi Raff,<br>
> >>> >>>>><br>
> >>> >>>>> it's great to hear about EMA again, and it seems like you've<br>
> made a<br>
> >>> >>>>> lot<br>
> >>> >>>>> of progress (congrats!). There is one question I stumbled upon<br>
> >>> >>>>> recently in<br>
> >>> >>>>> the Freischütz context, which clearly falls into the scope of<br>
> EMA as<br>
> >>> >>>>> well,<br>
> >>> >>>>> and I would like to hear your opinion about it. Since it (in my<br>
> >>> >>>>> opinion) is<br>
> >>> >>>>> an MEI question, I prefer to discuss it over here, instead of<br>
> >>> >>>>> Github. Let's<br>
> >>> >>>>> see where it leads us…<br>
> >>> >>>>><br>
> >>> >>>>> Let's assume we're in a simple 4/4 meter, and we want to encode a<br>
> >>> >>>>> slur<br>
> >>> >>>>> that ranges from the first to the last note in that measure. Now<br>
> >>> >>>>> let's look<br>
> >>> >>>>> at different examples in this setup.<br>
> >>> >>>>><br>
> >>> >>>>> 1)<br>
> >>> >>>>> We have four quarter notes. Our slur is<br>
> >>> >>>>> <slur tstamp="1" tstamp2="0m+4"/><br>
> >>> >>>>><br>
> >>> >>>>> 2)<br>
> >>> >>>>> Let's consider we have a hairpin instead, which ranges from the<br>
> >>> >>>>> first<br>
> >>> >>>>> to the last quarter:<br>
> >>> >>>>> <hairpin tstamp="1" tstamp2="0m+4"/><br>
> >>> >>>>><br>
> >>> >>>>> 3)<br>
> >>> >>>>> Let's consider our hairpin stretches across the full measure,<br>
> which<br>
> >>> >>>>> contains just a whole note:<br>
> >>> >>>>> <hairpin tstamp="1" tstamp2="0m+4"/><br>
> >>> >>>>><br>
> >>> >>>>> 4)<br>
> >>> >>>>> Let's go back to a slur which stretches to the second of two<br>
> eighth<br>
> >>> >>>>> notes on the last beat. Our slur is<br>
> >>> >>>>> <slur tstamp="1" tstamp2="0m+4.5"/><br>
> >>> >>>>><br>
> >>> >>>>> 5)<br>
> >>> >>>>> What does this mean to 3)? Should it be<br>
> >>> >>>>> <hairpin tstamp="1" tstamp2="0m+4.5"/><br>
> >>> >>>>> instead, to indicate that the hairpin really goes to the end of<br>
> the<br>
> >>> >>>>> measure? By definition, in MEI a tstamp="5" (in 4/4) denotes the<br>
> >>> >>>>> right<br>
> >>> >>>>> barline, so should we use something like "5", or perhaps "4.999"<br>
> in<br>
> >>> >>>>> this<br>
> >>> >>>>> situation?<br>
> >>> >>>>><br>
> >>> >>>>> 6)<br>
> >>> >>>>> To my understanding, a musical range in MEI should include all<br>
> >>> >>>>> events<br>
> >>> >>>>> which have an onset (=tstamp) that is between the range's<br>
> starting<br>
> >>> >>>>> tstamp<br>
> >>> >>>>> and it's ending tstamp2.<br>
> >>> >>>>><br>
> >>> >>>>> 7)<br>
> >>> >>>>> If 6) is true, a valid encoding for 3) would be<br>
> >>> >>>>> <hairpin tstamp="1" tstamp2="0m+1"/><br>
> >>> >>>>> This hairpin would cover all notes that start at tstamp="1",<br>
> which<br>
> >>> >>>>> is<br>
> >>> >>>>> obviously true for a whole note.<br>
> >>> >>>>><br>
> >>> >>>>> 8)<br>
> >>> >>>>> However, this encoding obviously does not address the (graphical)<br>
> >>> >>>>> aspect of the hairpin stretching the whole measure. I'm not sure<br>
> if<br>
> >>> >>>>> this is<br>
> >>> >>>>> a problem – it could be addressed with other (more graphical)<br>
> >>> >>>>> attributes<br>
> >>> >>>>> instead.<br>
> >>> >>>>><br>
> >>> >>>>> ----<br>
> >>> >>>>><br>
> >>> >>>>> It all comes down to the question if 6) is correct, or if a<br>
> tstamp2<br>
> >>> >>>>> denotes the absolute end of a range. In other words: Does the<br>
> >>> >>>>> crescendo stop<br>
> >>> >>>>> at the onset of the note at which hairpin/@tstamp2 is pointing,<br>
> or<br>
> >>> >>>>> does it<br>
> >>> >>>>> also include the duration of that note (which would make it<br>
> context<br>
> >>> >>>>> dependent…)? In terms of EMA: Would you include the notes that<br>
> start<br>
> >>> >>>>> at the<br>
> >>> >>>>> specified ending beat, or would you drop them, since they don't<br>
> >>> >>>>> completely<br>
> >>> >>>>> fit into the specified range?<br>
> >>> >>>>><br>
> >>> >>>>> I think MEI isn't clear enough on this, on EMA seems to be a<br>
> perfect<br>
> >>> >>>>> opportunity to discuss how people would interpret it, and if we<br>
> >>> >>>>> should try<br>
> >>> >>>>> to be more explicit on this.<br>
> >>> >>>>><br>
> >>> >>>>> Best,<br>
> >>> >>>>> jo<br>
> >>> >>>>><br>
> >>> >>>>><br>
> >>> >>>>><br>
> >>> >>>>><br>
> >>> >>>>> Am 03.11.2014 um 17:11 schrieb Raffaele Viglianti<br>
> >>> >>>>> <<a href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>>:<br>
> >>> >>>>><br>
> >>> >>>>> > Dear List,<br>
> >>> >>>>> ><br>
> >>> >>>>> > The idea behind the Enhancing Music Notation Addressability<br>
> (EMA)<br>
> >>> >>>>> > project is to investigate ways to make it possible to link to<br>
> >>> >>>>> > specific parts<br>
> >>> >>>>> > of a music document available online. Being able to do so<br>
> could be<br>
> >>> >>>>> > useful to<br>
> >>> >>>>> > quote passages, express analytical statements and annotations,<br>
> or<br>
> >>> >>>>> > passing a<br>
> >>> >>>>> > selection of music notation on to another process for<br>
> rendering,<br>
> >>> >>>>> > computational analysis, etc.<br>
> >>> >>>>> ><br>
> >>> >>>>> > As part of the project, I've been working on a URL<br>
> specification<br>
> >>> >>>>> > to<br>
> >>> >>>>> > express a selection of music notation based on measure, staves,<br>
> >>> >>>>> > and beats. I<br>
> >>> >>>>> > am also writing an API that describes how to process the URL<br>
> and<br>
> >>> >>>>> > the music<br>
> >>> >>>>> > notation.<br>
> >>> >>>>> ><br>
> >>> >>>>> > You can find the URL specification and the API documentation<br>
> here:<br>
> >>> >>>>> > <a href="https://github.com/umd-mith/ema/blob/master/docs/api.md" target="_blank">https://github.com/umd-mith/ema/blob/master/docs/api.md</a><br>
> >>> >>>>> ><br>
> >>> >>>>> > I am now working on an implementation of the API that works<br>
> with<br>
> >>> >>>>> > MEI<br>
> >>> >>>>> > files. If you have used an image server before, you can imagine<br>
> >>> >>>>> > how this<br>
> >>> >>>>> > will work: given a URL specifying a zoom level and a region of<br>
> an<br>
> >>> >>>>> > image, the<br>
> >>> >>>>> > server returns an image of the selected region. Likewise, this<br>
> >>> >>>>> > MEI-based<br>
> >>> >>>>> > implementation would return the region of an MEI file,<br>
> according<br>
> >>> >>>>> > to the<br>
> >>> >>>>> > selection specified by the URL.<br>
> >>> >>>>> ><br>
> >>> >>>>> > I would be very interested in hearing any comments and<br>
> suggestions<br>
> >>> >>>>> > that you might have at this stage. Can you imagine that this<br>
> >>> >>>>> > system may be<br>
> >>> >>>>> > useful for your projects? Is the URL specification expressive<br>
> >>> >>>>> > enough? Are<br>
> >>> >>>>> > there other parameters that you would want the API to include?<br>
> >>> >>>>> ><br>
> >>> >>>>> > If you are interested, I would encourage you to fork the GitHub<br>
> >>> >>>>> > repository and contributing!<br>
> >>> >>>>> ><br>
> >>> >>>>> > Many thanks and all the best,<br>
> >>> >>>>> > Raff<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>
> >>> >>>> _______________________________________________<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>
> >>> >> _______________________________________________<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>
> >> _______________________________________________<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>
> > 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>
<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></div>