<div dir="ltr">Hi Laurent,<div><br></div><div>On Tue, Nov 11, 2014 at 3:15 AM, Laurent Pugin <span dir="ltr"><<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Another way of representing this could be to have something like a<br>
@timespan to encode the extend of the event. <br></blockquote><div><br></div><div>I wonder if this would really be more expressive than tstamp2... There is some advantage in switching the context to the "landing" measure; it seems more intuitive to me to determine the beat relatively to the time signature at the measure where the event stops.</div><div><br></div><div>Re: Behind Bars p. 105, I'm conflicted on whether that should be something left to a rendering system (or @ho). I would be tempted to encode that as extending to the forte on beat 1 with @tstamp2="1m+1" and leave it to a rendering system to figure out whether it needs to stop before the barline or not. That would be my interpretation of the semantics there and my encoding would reflect that. I would use @ho to specify relative positions if I want to be specific with the intended output. What do you think?</div><div><br></div><div>(For those who don't have Behind Bars or don't want to go grab the book from the high shelf, I'm attaching a version of the Behind Bars example re-typeset in MuseScore - I hope it makes it because I don't remember if the list allows attachments)</div><div><br></div><div>On the other hand, I wouldn't be opposed to allowing fractions in the datatype. It could be useful.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I haven't had the time to look at the EMA repository yet, but this<br>
looks quite useful!<br></blockquote><div><br></div><div>Thanks! I look forward to your comments if you have any :)</div><div><br></div><div>Raff</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Laurent<br>
</font></span><span class="im HOEnZb"><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>> wrote:<br>
> Hi Raff,<br>
><br>
</span><span class="im HOEnZb">> My comment was more about the ambiguity that is created by the implicit<br>
> nature of the actual cut-off mode (and this is vaguely related to the MEI<br>
> tstamp2 problem).<br>
><br>
> If the definition of the "cut" mode is that the end value is the absolute<br>
> end, that is nothing can extend longer than the end value, you can still<br>
> chose to discard or actually cut the events that would extend longer, but<br>
> the point is that this position is defined by then end value 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 there's a<br>
> half-note starting on the second beat, it will be qualified as a non-fit<br>
> (while according the original system, it would be qualified as a fit.) 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 non-fitters<br>
> though. I guess it is very much application dependent; perhaps would be a<br>
> good idea to allow three options here: drop, keep, cut?<br>
><br>
> Z<br>
><br>
><br>
</span><div class="HOEnZb"><div class="h5">> 2014-11-04 14:46 GMT+00:00 Raffaele Viglianti <<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 sophisticated<br>
>> example matches my expectations. I would definitely keep the same behavior<br>
>> also for percussive/plucked instruments and other borderline scenarios like<br>
>> an eight for double bass that is to be played both pizzicato and 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 notation<br>
>> doesn't always match a physical gesture or real sound effect. So I 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 for<br>
>> "cut" mode. If you have an end beat of 1, you consider the whole of beat 1.<br>
>> If you have 1.2 you consider the whole of beat 1 and .2 of the following.<br>
>> This forces a processor to alter the notation to fit the beat limit. Are you<br>
>> suggesting that event that do not end within the range should be 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 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>> wrote:<br>
>>><br>
>>> Hi Raff,<br>
>>><br>
>>> I'm glad to see you're making great progress with the EMA project! Let me<br>
>>> chip in to the discussion with some casual comments.<br>
>>><br>
>>> I like your description of the thought-process of transcribing a 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 ending<br>
>>> roughly on the last beat of the measure, or perhaps slightly after it, they<br>
>>> could argue that the crescendo needs to continue right to the end of the<br>
>>> measure, (they would especially inclined to do so, if in the next measure a<br>
>>> diminuendo starts at beat one). I think it is necessary to distinguish<br>
>>> between this and the case, when the crescendo would actually stop at the<br>
>>> beginning of the last beat, and the performer would keep the volume 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", as Jo<br>
>>> suggests. Then it could be up to there renderer to decide whether to draw<br>
>>> the hairpin right up to the barline or somewhere between the last note 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 notes;<br>
>>> such a situation is a crescendo performed on a non-percussive(e.g. piano)<br>
>>> and non-plucked instrument. Well, even on these instruments, the full-length<br>
>>> crescendo may be the "artistic intention" and should be kept intact, even<br>
>>> though it is never going to be executed. However, I cannot think of any<br>
>>> problematic case for slurs, for example (off the top of my head I cannot<br>
>>> think of any example when the a slur starting or ending in between 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 flexible on the<br>
>>> right hand side: it includes everything that start within the base range,<br>
>>> defined by start and end positions. But it's not clear what the cut-off<br>
>>> point is when you apply "cut"? Is it end+1 or ceil(end)? If it is ceil(end),<br>
>>> is it not too restrictive that you cannot cut off at other positions than<br>
>>> integer beat positions? If it is end+1 it may not be very intuitive to 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 range<br>
>>> could be more easy to deal with: by default the range as defined now, but in<br>
>>> "cut" mode nothing should extend longer than the end position. Then 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 your<br>
>>>> example 3 and 4 as if they were on two different staves of the same piece.<br>
>>>> Time is 4/4.<br>
>>>><br>
>>>> On staff 1 we'd have a whole note with a crescendo, and we're 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 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 specify<br>
>>>> were I think the crescendo ends in relationship to the beat. I justify this<br>
>>>> by imagining a performer performing the MEI (heh): I would prefer a<br>
>>>> tstamp2=4 to indicate that the performer is expected to hold the volume<br>
>>>> around beat 4. I would do this because if the hairpin were shorter, that<br>
>>>> would be meaningful musically. For example, if it were stopping 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 when the<br>
>>>> staff below has the hairpin stretching to 4.5 because of the eights. Is it<br>
>>>> ok to have the hairpins on each staff ending at different tstamps (4 and<br>
>>>> 4.5)? If the source document aligns them, should the tstamp2s be aligned<br>
>>>> too? Or should the alignment be left to a rendering system. I may lean<br>
>>>> towards adjusting both tstamp2s to match, but I can also see why 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 beat is<br>
>>>> considered in its entirety, regardless of how its dur or tstamp2 are<br>
>>>> expressed. So a selection on the example above of staff 1, beat 1, would<br>
>>>> return the whole note *and* the hairpin with its tstamp2 unaltered.<br>
>>>><br>
>>>> This default behavior can be overridden by raising the "cut" flag, which<br>
>>>> will force the returned notation to be altered to stay within the range<br>
>>>> specified. So a selection on the example above of staff 1, beat 1, would<br>
>>>> return *a quarter* note and the hairpin with its tstamp2 changed to 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>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi Raff,<br>
>>>>><br>
>>>>> it's great to hear about EMA again, and it seems like you've made a lot<br>
>>>>> of progress (congrats!). There is one question I stumbled upon recently in<br>
>>>>> the Freischütz context, which clearly falls into the scope of EMA as well,<br>
>>>>> and I would like to hear your opinion about it. Since it (in my opinion) is<br>
>>>>> an MEI question, I prefer to discuss it over here, instead of 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 slur<br>
>>>>> that ranges from the first to the last note in that measure. Now 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 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, 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 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 the<br>
>>>>> measure? By definition, in MEI a tstamp="5" (in 4/4) denotes the right<br>
>>>>> barline, so should we use something like "5", or perhaps "4.999" in this<br>
>>>>> situation?<br>
>>>>><br>
>>>>> 6)<br>
>>>>> To my understanding, a musical range in MEI should include all events<br>
>>>>> which have an onset (=tstamp) that is between the range's starting 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", which 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 if this is<br>
>>>>> a problem – it could be addressed with other (more graphical) attributes<br>
>>>>> instead.<br>
>>>>><br>
>>>>> ----<br>
>>>>><br>
>>>>> It all comes down to the question if 6) is correct, or if a tstamp2<br>
>>>>> denotes the absolute end of a range. In other words: Does the crescendo stop<br>
>>>>> at the onset of the note at which hairpin/@tstamp2 is pointing, or does it<br>
>>>>> also include the duration of that note (which would make it context<br>
>>>>> dependent…)? In terms of EMA: Would you include the notes that start at the<br>
>>>>> specified ending beat, or would you drop them, since they don't completely<br>
>>>>> fit into the specified range?<br>
>>>>><br>
>>>>> I think MEI isn't clear enough on this, on EMA seems to be a perfect<br>
>>>>> opportunity to discuss how people would interpret it, and if we 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 (EMA)<br>
>>>>> > project is to investigate ways to make it possible to link to specific parts<br>
>>>>> > of a music document available online. Being able to do so could be useful to<br>
>>>>> > quote passages, express analytical statements and annotations, or passing a<br>
>>>>> > selection of music notation on to another process for rendering,<br>
>>>>> > computational analysis, etc.<br>
>>>>> ><br>
>>>>> > As part of the project, I've been working on a URL specification to<br>
>>>>> > express a selection of music notation based on measure, staves, and beats. I<br>
>>>>> > am also writing an API that describes how to process the URL and the music<br>
>>>>> > notation.<br>
>>>>> ><br>
>>>>> > You can find the URL specification and the API documentation 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 with MEI<br>
>>>>> > files. If you have used an image server before, you can imagine how this<br>
>>>>> > will work: given a URL specifying a zoom level and a region of an image, the<br>
>>>>> > server returns an image of the selected region. Likewise, this MEI-based<br>
>>>>> > implementation would return the region of an MEI file, according to the<br>
>>>>> > selection specified by the URL.<br>
>>>>> ><br>
>>>>> > I would be very interested in hearing any comments and suggestions<br>
>>>>> > that you might have at this stage. Can you imagine that this system may be<br>
>>>>> > useful for your projects? Is the URL specification expressive 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>
</div></div></blockquote></div><br></div></div>