[MEI-L] Music Addressability API draft

[Raffaele Viglianti]

Hello,

Point 1 is clear to me too and it's good to see that we seem to agree all
around :) The Music Addressability API adopts the same understanding (it
will be made clear that it is derived by the MEI specification), minus the
measure component (Xm+). The latter is not needed because the measure
parameter already sets the context.

Point 2 I have less of a passion for, but I see Craig's point. It shouldn't
be too taxing for the datatype to support fractions too. I guess we can
continue discussion of this point in the other thread.

Laurent wrote:
> do you think it would be possible to support un-measured music? I saw
that measure is required, and I am not sure how this would work with MEI
where we have /staff directly under /section. Any idea?

Mostly, what's stopping me from making measure optional is that having a
middle parameter being optional complicates the parsing of the URL. I am
tempted to consider un-measured music as one-measured music for the sake of
the addressing act. This would also require adopting an absolute beat that
counts from 0 to the end of the piece. So you may have expressions like
/1/1-4/1-22 to indicated a selection of fours staves, from the beginning to
the end of a piece spanning across 22 beats (taking into account time
signature changes). Does that make sense? If it seems too complex, it may
be worth considering a dedicated route for un-measured music that may take
into account barlines for a neater beat-based selection. Other ideas?

Thanks!
Raff

On Wed, Nov 12, 2014 at 6:23 AM, Laurent Pugin <laurent at music.mcgill.ca>
wrote:

> Point 1 seems clear to me.
>
> Point 2: I think we should be concerned about round-off errors. It
> probably does not matter for elements such as harpins, but as Craig
> explained, they do create well-known problems for data processing.
>
> Laurent
>
> On Wed, Nov 12, 2014 at 4:49 AM, Roland, Perry D. (pdr4h)
> <pdr4h at eservices.virginia.edu> wrote:
> >
> > It seems to me that there are at least 2 intertwined issues here.  One
> is how to specify the logical and visual endpoints of a control event; that
> is, a feature that uses @tstamp2.  Another is what values @tstamp2 ought to
> allow.  Yet another is the question of "addressability".
> >
> > On issue 1 Laurent wrote:
> >
> >> With @tstamp2, we could recommend to have
> >>
> >> <hairpin tstamp="1" tstamp2="0m+3"/>
> >>
> >> if the hairpin stops before the barline and
> >>
> >> <hairpin tstamp="1" tstamp2="1m+1"/>
> >>
> >> if it stops after right before the first note of the next measure as
> >> in the attachement. Then further adjustments can be done with @ho.
> >
> > This is the precisely how I think tstamp2 should be used.  Assuming the
> first example is in 2/4, "0m+3" would be at the barline.  The second
> hairpin would end on beat 1 of the following measure.  Visually, however,
> both hairpins should terminate just before their "logical" endpoints.  This
> is consistent with the way most musicians understand hairpins (as other
> things with the tstamp2 attribute) -- a hairpin is in effect until the next
> beat or fraction of a beat following its visual end.  This accommodates any
> marking (such as a forte dynamic marking) that might occur directly on the
> logical beat (on beat 1 in the 2nd example).  I believe this is what
> Raffaele was referring to by saying he would allow the rendering engine to
> make decisions about the visual placement of the endpoint of the hairpin.
> This spacing between the logical end of the hairpin and its visual end
> should be specified in the configuration of the renderer.
> >
> > @ho is relative to this ending value.  So,
> >
> > tstamp="0m+3" ho="-1.2"
> >
> > indicates termination at the barline, but visually moved "backward" 1.2
> virtual units (remember a virtual unit is 1/2 the distance between staff
> lines).  The only question for me is whether the "default" behavior of
> allowing some space between the visual ending of the feature and its
> logical ending is or is not accounted for in this case.  I think it is not;
> that is, the @ho value "overrides" the amount of space the rendering engine
> would normally leave between the end of the hairpin and the terminal beat.
> Note that the value of @ho can be positive or negative, allowing one to
> move the endpoint forward or backward.
> >
> > Point 2:
> > I'm not opposed to somehow allowing fractions within data.BEAT, but if
> we make our position on Point 1 clear, then I don't see the need for it,
> since "1.3" is just another way of writing "1+1/3".  I don't think we
> should be concerned with round-off error since the decimal part of "1.3" is
> intended to indicate a fractional part of the beat; that is, one can write
> "1.333" or "1.3" or "1+1/3", but all three mean the location of the 2nd
> note of a triplet beginning on beat 1, in other words, a musical value, not
> a visual one.  @tstamp2 *should only* refer to the "logical" endpoint. @ho
> should be used to move the visual endpoint.  This contradicts my own
> earlier thinking and Johannes' suggestion to use "4.999" to encode a
> hairpin stopping just before the beat.  I believe this erroneously
> conflates the logical and visual endpoints.
> >
> > Does this help clarify things?  Am I missing something?
> >
> > I will delay comment on addressability until later.  It's dinner time in
> Kunming.  :-)
> >
> > --
> > p.
> >
> >
> > __________________________
> > 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent
> Pugin [laurent at music.mcgill.ca]
> > Sent: Tuesday, November 11, 2014 1:54 PM
> > To: Music Encoding Initiative
> > Subject: Re: [MEI-L] Music Addressability API draft
> >
> >>>
> >>> Another way of representing this could be to have something like a
> >>> @timespan to encode the extend of the event.
> >>
> >>
> >> 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.
> >>
> >
> > Changing to a @tispan could still mean that the time signature of the
> > measure where it ends has to be taken into account. But I agree it
> > does not necessary change much. What is probably bugging me is the use
> > of the sign "+" together with the fact that is is 1-based. It seems
> > confusing to says 1m+1 where actually +1 adds nothing. Another sign
> > (e.g., /) would be clearer, I think: "1m/1", or making it 0-based.
> > This might look like a detail, but I think it creates a lot of
> > confusion and it might very well be one reason for the discussion
> > here. If this cannot be changed it certainly requires some
> > clarification.
> >
> >> 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?
> >
> > I am not sure how to encode this with @ho. The problem is an offset to
> > what? We can have many things at the beginning for the measure before
> > the first note (clef, key signature, etc.), so it seems difficult to
> > use offsets for this, but maybe I am overlooking something. This is
> > why I thought that having two ways of encoding an event with the same
> > duration could be of some help (not necessary for rendering, but also
> > for encoding how this is in a source). With @tstamp2, we could
> > recommend to have
> >
> > <hairpin tstamp="1" tstamp2="0m+3"/>
> >
> > if the hairpin stops before the barline and
> >
> > <hairpin tstamp="1" tstamp2="1m+1"/>
> >
> > if it stops after right before the first note of the next measure as
> > in the attachement. Then further adjustments can be done with @ho. Is
> > this what you are saying? Or would you use only the second approach
> > even we it stops before the barline?
> >
> >>
> >> (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)
> >
> > Thanks!
> >
> >>
> >> On the other hand, I wouldn't be opposed to allowing fractions in the
> >> datatype. It could be useful.
> >
> > Good.
> >>
> >>>
> >>> I haven't had the time to look at the EMA repository yet, but this
> >>> looks quite useful!
> >>
> >>
> >> Thanks! I look forward to your comments if you have any :)
> >
> > Yes: do you think it would be possible to support un-measured music? I
> > saw that measure is required, and I am not sure how this would work
> > with MEI where we have /staff directly under /section. Any idea?
> >
> > Best,
> > Laurent
> >
> >>
> >> Raff
> >>
> >>>
> >>>
> >>> Laurent
> >>>
> >>> On Tue, Nov 4, 2014 at 2:09 PM, Kőmíves Zoltán <zolaemil at gmail.com>
> wrote:
> >>> > Hi Raff,
> >>> >
> >>> > My comment was more about the ambiguity that is created by the
> implicit
> >>> > nature of the actual cut-off mode (and this is vaguely related to the
> >>> > MEI
> >>> > tstamp2 problem).
> >>> >
> >>> > If the definition of the "cut" mode is that the end value is the
> >>> > absolute
> >>> > end, that is nothing can extend longer than the end value, you can
> still
> >>> > chose to discard or actually cut the events that would extend longer,
> >>> > but
> >>> > the point is that this position is defined by then end value
> explicitly,
> >>> > rather than implicitly (by applying ceil or +1).
> >>> >
> >>> > So in 4/4 the if the URL ended something like "../1-3/cut" and
> there's a
> >>> > half-note starting on the second beat, it will be qualified as a
> non-fit
> >>> > (while according the original system, it would be qualified as a
> fit.)
> >>> > This
> >>> > would also allow you to specify an interval shorter than a beat (e.g.
> >>> > 1-1.5/cut).
> >>> >
> >>> > I wasn't trying to suggest anything about what to do with the
> >>> > non-fitters
> >>> > though. I guess it is very much application dependent; perhaps would
> be
> >>> > a
> >>> > good idea to allow three options here: drop, keep, cut?
> >>> >
> >>> > Z
> >>> >
> >>> >
> >>> > 2014-11-04 14:46 GMT+00:00 Raffaele Viglianti
> >>> > <raffaeleviglianti at gmail.com>:
> >>> >>
> >>> >> Hi Zoltan,
> >>> >>
> >>> >> Thanks for your email!
> >>> >>
> >>> >> I think we agree entirely on the tstamp2 issue. Your more
> sophisticated
> >>> >> example matches my expectations. I would definitely keep the same
> >>> >> behavior
> >>> >> also for percussive/plucked instruments and other borderline
> scenarios
> >>> >> like
> >>> >> an eight for double bass that is to be played both pizzicato and
> >>> >> crescendo
> >>> >> (I guess in this case the bass becomes a plucked instrument).
> >>> >>
> >>> >> I also struggle to think of a reasonable example for slurs, but
> >>> >> notation
> >>> >> doesn't always match a physical gesture or real sound effect. So I
> >>> >> would
> >>> >> keep the same tstamp2 behavior for phrase marks too.
> >>> >>
> >>> >> About EMA, I see your point. I think ceil(end) is what I mean now
> for
> >>> >> "cut" mode. If you have an end beat of 1, you consider the whole of
> >>> >> beat 1.
> >>> >> If you have 1.2 you consider the whole of beat 1 and .2 of the
> >>> >> following.
> >>> >> This forces a processor to alter the notation to fit the beat limit.
> >>> >> Are you
> >>> >> suggesting that event that do not end within the range should be
> >>> >> dropped
> >>> >> entirely in "cut" mode? That may be easier to implement, but then a
> >>> >> selection of beat 1 to 1 where only a whole note is encoded, would
> >>> >> return an
> >>> >> empty set.
> >>> >>
> >>> >> Raff
> >>> >>
> >>> >>
> >>> >> On Tue, Nov 4, 2014 at 4:14 AM, Kőmíves Zoltán <zolaemil at gmail.com>
> >>> >> wrote:
> >>> >>>
> >>> >>> Hi Raff,
> >>> >>>
> >>> >>> I'm glad to see you're making great progress with the EMA project!
> Let
> >>> >>> me
> >>> >>> chip in to the discussion with some casual comments.
> >>> >>>
> >>> >>> I like your description of the thought-process of transcribing a
> >>> >>> hairpin
> >>> >>> from a source document. I think there may be room for some more
> >>> >>> sophistication here: for example if a performer sees a hairpin
> ending
> >>> >>> roughly on the last beat of the measure, or perhaps slightly after
> it,
> >>> >>> they
> >>> >>> could argue that the crescendo needs to continue right to the end
> of
> >>> >>> the
> >>> >>> measure, (they would especially inclined to do so, if in the next
> >>> >>> measure a
> >>> >>> diminuendo starts at beat one). I think it is necessary to
> distinguish
> >>> >>> between this and the case, when the crescendo would actually stop
> at
> >>> >>> the
> >>> >>> beginning of the last beat, and the performer would keep the volume
> >>> >>> for the
> >>> >>> duration of the last beat. Based on the logic you describe, I would
> >>> >>> transcribe the full-length crescendo with tstamp2="5" or "4.999",
> as
> >>> >>> Jo
> >>> >>> suggests. Then it could be up to there renderer to decide whether
> to
> >>> >>> draw
> >>> >>> the hairpin right up to the barline or somewhere between the last
> note
> >>> >>> and
> >>> >>> the barline.
> >>> >>>
> >>> >>> In short, my penny is on tstamp2 meaning the absolute end.
> >>> >>>
> >>> >>> N.B. the above problem only arises in situations when an event can
> >>> >>> feasibly start/end between other time positions than beginning of
> >>> >>> notes;
> >>> >>> such a situation is a crescendo performed on a non-percussive(e.g.
> >>> >>> piano)
> >>> >>> and non-plucked instrument. Well, even on these instruments, the
> >>> >>> full-length
> >>> >>> crescendo may be the "artistic intention" and should be kept
> intact,
> >>> >>> even
> >>> >>> though it is never going to be executed. However, I cannot think of
> >>> >>> any
> >>> >>> problematic case for slurs, for example (off the top of my head I
> >>> >>> cannot
> >>> >>> think of any example when the a slur starting or ending in between
> >>> >>> notes is
> >>> >>> particularly meaningful...)
> >>> >>>
> >>> >>> As far as I can see, when it comes to EMA, it all boils down to the
> >>> >>> definition of the end of the range. By default, the range is
> flexible
> >>> >>> on the
> >>> >>> right hand side: it includes everything that start within the base
> >>> >>> range,
> >>> >>> defined by start and end positions. But it's not clear what the
> >>> >>> cut-off
> >>> >>> point is when you apply "cut"? Is it end+1 or ceil(end)? If it is
> >>> >>> ceil(end),
> >>> >>> is it not too restrictive that you cannot cut off at other
> positions
> >>> >>> than
> >>> >>> integer beat positions? If it is end+1 it may not be very
> intuitive to
> >>> >>> use
> >>> >>> when end isn't an integer value.
> >>> >>>
> >>> >>> It seems to me that a more explicit definition of the end of the
> range
> >>> >>> could be more easy to deal with: by default the range as defined
> now,
> >>> >>> but in
> >>> >>> "cut" mode nothing should extend longer than the end position. Then
> >>> >>> the user
> >>> >>> could have more control over the actual cut-off point.
> >>> >>>
> >>> >>> Best
> >>> >>> Zoltan
> >>> >>>
> >>> >>> 2014-11-03 22:15 GMT+00:00 Raffaele Viglianti
> >>> >>> <raffaeleviglianti at gmail.com>:
> >>> >>>>
> >>> >>>> 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
> >>> >>>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> _______________________________________________
> >>> >>>> 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
> >>> >>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > 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
> >>
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20141112/59105985/attachment.html>