[MEI-L] Music Addressability API draft
Raffaele Viglianti
raffaeleviglianti at gmail.com
Thu Nov 13 16:53:28 CET 2014
Hello Eleanor,
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.
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.
Thanks everyone for the very useful feedback!
Raff
On Wed, Nov 12, 2014 at 5:08 PM, Eleanor Selfridge-Field <
esfield at stanford.edu> wrote:
>
> RE "unmeasured", a written cadenza (unmeasured) within a measured context
> would not work in an "until the end of time" scenario.
>
> 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?
>
> Eleanor
>
>
>
>
>
>
> <!--
> /* Font Definitions */
> @font-face
> {font-family:"Cambria Math";
> panose-1:2 4 5 3 5 4 6 3 2 4;
> mso-font-charset:0;
> mso-generic-font-family:roman;
> mso-font-pitch:variable;
> mso-font-signature:-536870145 1107305727 0 0 415 0;}
> @font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;
> mso-font-charset:0;
> mso-generic-font-family:swiss;
> mso-font-pitch:variable;
> mso-font-signature:-536870145 1073786111 1 0 415 0;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {mso-style-unhide:no;
> mso-style-qformat:yes;
> mso-style-parent:"";
> margin:0in;
> margin-bottom:.0001pt;
> mso-pagination:widow-orphan;
> font-size:11.0pt;
> font-family:"Calibri","sans-serif";
> mso-ascii-font-family:Calibri;
> mso-ascii-theme-font:minor-latin;
> mso-fareast-font-family:"Times New Roman";
> mso-fareast-theme-font:minor-fareast;
> mso-hansi-font-family:Calibri;
> mso-hansi-theme-font:minor-latin;
> mso-bidi-font-family:"Times New Roman";
> mso-bidi-theme-font:minor-bidi;}
> a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;
> text-underline:single;}
> a:visited, span.MsoHyperlinkFollowed
> {mso-style-noshow:yes;
> mso-style-priority:99;
> color:#954F72;
> mso-themecolor:followedhyperlink;
> text-decoration:underline;
> text-underline:single;}
> .MsoChpDefault
> {mso-style-type:export-only;
> mso-default-props:yes;
> font-size:11.0pt;
> mso-ansi-font-size:11.0pt;
> mso-bidi-font-size:11.0pt;
> mso-ascii-font-family:Calibri;
> mso-ascii-theme-font:minor-latin;
> mso-fareast-font-family:"Times New Roman";
> mso-fareast-theme-font:minor-fareast;
> mso-hansi-font-family:Calibri;
> mso-hansi-theme-font:minor-latin;
> mso-bidi-font-family:"Times New Roman";
> mso-bidi-theme-font:minor-bidi;}
> @page WordSection1
> {size:8.5in 11.0in;
> margin:1.0in 1.0in 1.0in 1.0in;
> mso-header-margin:.5in;
> mso-footer-margin:.5in;
> mso-paper-source:0;}
> div.WordSection1
> {page:WordSection1;}
> -->
>
>
>
>
>
>
>
>
> Eleanor
> Selfridge-Field
>
> Consulting Professor, Music (and, by courtesy, Symbolic Systems)
>
> Braun Music Center #129
>
> Stanford University
>
> Stanford, CA 94305-3076, USA
>
> http://web.stanford.edu/~esfield/
> +1/ 650 725-9242
>
>
>
>
>
> ----- Original Message -----
> From: Raffaele Viglianti <raffaeleviglianti at gmail.com>
> To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
> Sent: Wed, 12 Nov 2014 07:54:34 -0800 (PST)
> Subject: Re: [MEI-L] Music Addressability API draft
>
> 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
> >
>
>
>
> _______________________________________________
> 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/20141113/fc961a15/attachment.html>
More information about the mei-l
mailing list