[MEI-L] Music Addressability API draft

[Raffaele Viglianti]

Hi Jo,

Thank you for your reply! Very interesting question.

To help me explain my view on the problem you pose, let's consider your
example 3 and 4 as if they were on two different staves of the same piece.
Time is 4/4.

On staff 1 we'd have a whole note with a crescendo, and we're debating
whether tstamp2 should be 1 or 4:
<hairpin tstamp="1" tstamp2="0m+1" form="cres" /> or
<hairpin tstamp="1" tstamp2="0m+4" form="cres" />

On staff 2 we'd have three quarters and two eights, with an hairpin going
to the last note
<hairpin tstamp="1" tstamp2="0m+4.5" form="cres" />

If I were encoding a source document, I would use tstamp2 to specify were I
think the crescendo ends in relationship to the beat. I justify this by
imagining a performer performing the MEI (heh): I would prefer a tstamp2=4
to indicate that the performer is expected to hold the volume around beat
4. I would do this because if the hairpin were shorter, that would be
meaningful musically. For example, if it were stopping around what would
seem, as a performer, closer to beat 3 than 4.

What is less evident to me, instead, is how I would encode this when the
staff below has the hairpin stretching to 4.5 because of the eights. Is it
ok to have the hairpins on each staff ending at different tstamps (4 and
4.5)? If the source document aligns them, should the tstamp2s be aligned
too? Or should the alignment be left to a rendering system. I may lean
towards adjusting both tstamp2s to match, but I can also see why the
opposite could be argued.

EMA is relative unaffected by this problem. The API, as it is now,
specifies that any notational element occurring *on* the final beat is
considered in its entirety, regardless of how its dur or tstamp2 are
expressed. So a selection on the example above of staff 1, beat 1, would
return the whole note *and* the hairpin with its tstamp2 unaltered.

This default behavior can be overridden by raising the "cut" flag, which
will force the returned notation to be altered to stay within the range
specified. So a selection on the example above of staff 1, beat 1, would
return *a quarter* note and the hairpin with its tstamp2 changed to 1.

I'm more than happy to discuss whether this is a good idea, etc.

Thanks again! Best,
Raff



On Mon, Nov 3, 2014 at 4:33 PM, Johannes Kepper <kepper at edirom.de> wrote:

> Hi Raff,
>
> it's great to hear about EMA again, and it seems like you've made a lot of
> progress (congrats!). There is one question I stumbled upon recently in the
> Freischütz context, which clearly falls into the scope of EMA as well, and
> I would like to hear your opinion about it. Since it (in my opinion) is an
> MEI question, I prefer to discuss it over here, instead of Github. Let's
> see where it leads us…
>
> Let's assume we're in a simple 4/4 meter, and we want to encode a slur
> that ranges from the first to the last note in that measure. Now let's look
> at different examples in this setup.
>
> 1)
> We have four quarter notes. Our slur is
> <slur tstamp="1" tstamp2="0m+4"/>
>
> 2)
> Let's consider we have a hairpin instead, which ranges from the first to
> the last quarter:
> <hairpin tstamp="1" tstamp2="0m+4"/>
>
> 3)
> Let's consider our hairpin stretches across the full measure, which
> contains just a whole note:
> <hairpin tstamp="1" tstamp2="0m+4"/>
>
> 4)
> Let's go back to a slur which stretches to the second of two eighth notes
> on the last beat. Our slur is
> <slur tstamp="1" tstamp2="0m+4.5"/>
>
> 5)
> What does this mean to 3)? Should it be
> <hairpin tstamp="1" tstamp2="0m+4.5"/>
> instead, to indicate that the hairpin really goes to the end of the
> measure? By definition, in MEI a tstamp="5" (in 4/4) denotes the right
> barline, so should we use something like "5", or perhaps "4.999" in this
> situation?
>
> 6)
> To my understanding, a musical range in MEI should include all events
> which have an onset (=tstamp) that is between the range's starting tstamp
> and it's ending tstamp2.
>
> 7)
> If 6) is true, a valid encoding for 3) would be
> <hairpin tstamp="1" tstamp2="0m+1"/>
> This hairpin would cover all notes that start at tstamp="1", which is
> obviously true for a whole note.
>
> 8)
> However, this encoding obviously does not address the (graphical) aspect
> of the hairpin stretching the whole measure. I'm not sure if this is a
> problem – it could be addressed with other (more graphical) attributes
> instead.
>
> ----
>
> It all comes down to the question if 6) is correct, or if a tstamp2
> denotes the absolute end of a range. In other words: Does the crescendo
> stop at the onset of the note at which hairpin/@tstamp2 is pointing, or
> does it also include the duration of that note (which would make it context
> dependent…)? In terms of EMA: Would you include the notes that start at the
> specified ending beat, or would you drop them, since they don't completely
> fit into the specified range?
>
> I think MEI isn't clear enough on this, on EMA seems to be a perfect
> opportunity to discuss how people would interpret it, and if we should try
> to be more explicit on this.
>
> Best,
> jo
>
>
>
>
> Am 03.11.2014 um 17:11 schrieb Raffaele Viglianti <
> raffaeleviglianti at gmail.com>:
>
> > Dear List,
> >
> > The idea behind the Enhancing Music Notation Addressability (EMA)
> project is to investigate ways to make it possible to link to specific
> parts of a music document available online. Being able to do so could be
> useful to quote passages, express analytical statements and annotations, or
> passing a selection of music notation on to another process for rendering,
> computational analysis, etc.
> >
> > As part of the project, I've been working on a URL specification to
> express a selection of music notation based on measure, staves, and beats.
> I am also writing an API that describes how to process the URL and the
> music notation.
> >
> > You can find the URL specification and the API documentation here:
> > https://github.com/umd-mith/ema/blob/master/docs/api.md
> >
> > I am now working on an implementation of the API that works with MEI
> files. If you have used an image server before, you can imagine how this
> will work: given a URL specifying a zoom level and a region of an image,
> the server returns an image of the selected region. Likewise, this
> MEI-based implementation would return the region of an MEI file, according
> to the selection specified by the URL.
> >
> > I would be very interested in hearing any comments and suggestions that
> you might have at this stage. Can you imagine that this system may be
> useful for your projects? Is the URL specification expressive enough? Are
> there other parameters that you would want the API to include?
> >
> > If you are interested, I would encourage you to fork the GitHub
> repository and contributing!
> >
> > Many thanks and all the best,
> > Raff
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20141103/19901c10/attachment.html>