[MEI-L] Coordinate system confusion [and terminology]

Fri Jul 7 22:41:35 CEST 2017

Yes, 1 vu = 1 diatonic step.  However, the phrase “diatonic step” doesn’t actually appear in the definition –

“A single vu is half the distance between the vertical center point of a staff line and that of an adjacent staff line.”

Even this definition occurs within the description of @vu.height.  This is definitely a place where the Guidelines could use some work.

--
p.

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Craig Sapp
Sent: Friday, July 07, 2017 2:58 PM
To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de>
Subject: Re: [MEI-L] Coordinate system confusion [and terminology]

> We can/should define a "vu" in relation to diatonic steps though.

Is that not already the case? Otherwise, I am confused...  In other words 1vu = 1 diatonic step (such as E to F, or G-flat to A-sharp since the chromatic alteration does not matter).

On 7 July 2017 at 20:45, Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>> wrote:

I have trouble, as I think most folks would, with values like "2-1/2 half-spaces". I can live with "2-1/2 steps", but still prefer "2-1/2 vu".  We can/should define a "vu" in relation to diatonic steps though.

--
p.

> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Byrd, Donald A.
> Sent: Friday, July 07, 2017 11:23 AM
> To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>>
> Subject: Re: [MEI-L] Coordinate system confusion [and terminology]
>
> Sure. As I said, both Gould and Ross talk about "half spaces".  --DAB
>
> On Jul 7, 2017, at 11:03 AM, "Roland, Perry D. (pdr4h)" <pdr4h at eservices.virginia.edu<mailto:pdr4h at eservices.virginia.edu>>
>  wrote:
>
> >
> > Hi Don,
> >
> > You make a good argument for the term "staff-space" or "space".  However, MEI doesn't
> use this distance as its unit of measurement. Instead, MEI uses *half the distance* between
> adjacent staff lines, hence the need for a different term.  Perhaps "interline distance" and
> "virtual unit" aren't intuitive, but they accurately describe the situation, which "staff-space"
> or "space" do not.  Of course, we could start using the entire distance between staff lines
> as the unit, but that would mean changing all existing MEI markup and software.
> >
> > --
> > p.
> >
> >
> >> -----Original Message-----
> >> From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] On Behalf Of Byrd, Donald
> A.
> >> Sent: Tuesday, July 04, 2017 11:26 AM
> >> To: Music Encoding Initiative <mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>>
> >> Subject: Re: [MEI-L] Coordinate system confusion [and terminology]
> >>
> >> This reminds me of another source of coordinate system confusion,
> >> namely the term for the distance between staff lines. Verovio source
> >> code calls it a "double unit", and half that distance a "virtual unit" or "VU" or just
> "unit"; none of those terms is at all intuitive.
> >> Johannes calls it the "interline distance", which is much better, but
> >> rather long, and "half interline distance" is way too long (and
> >> clumsy). Well, look at Chapter 1 of _Behind Bars_. Her term is
> >> "stave-space", or just "space" for short; half that distance, of
> >> course, is a "half space". Ross' _Art of Music Engraving and
> >> Processing_, the only other book I know of that says much on the subject, just uses the
> term "space'. So, for example, both might describe a certain stem length as "2-1/2 spaces".
> >>
> >> I submit "stave-space" (or "staff-space" on my side of the Puddle) as
> >> the full term and "space" for short are both the most standard and the best terms.
> >>
> >> --Don
> >>
> >>
> >> On Jul 4, 2017, at 11:16 AM, Daniel Alles
> >> <DanielAlles at stud.uni-frankfurt.de<mailto:DanielAlles at stud.uni-frankfurt.de>>
> >> wrote:
> >>
> >>> Thank you, Johannes, that really helped and made that clear. So I
> >>> can continue using the
> >> Edirom-coordinates for ulx etc.
> >>>
> >>>
> >>>
> >>> Zitat von Johannes Kepper <kepper at edirom.de<mailto:kepper at edirom.de>>:
> >>>
> >>>> Dear Daniel,
> >>>>
> >>>> that's a real confusion, and we need to make it clearer in the
> >>>> guidelines. *Pixel* coordinates are always with the origin in the
> >>>> top left corner. *Music* coordinates, however, are always bottom
> >>>> up. @ulx and so on are always in pixel units, but @vo (vertical
> >>>> offset) is specified in interline distances (half the distance
> >>>> between two staff lines, or, in other words, the vertical distance
> >>>> between a C4 and a D4, or any other two adjacent notes). If you
> >>>> want to specify that a dynamic is written above its default
> >>>> position, it seems more natural that values go up (i.e., @vo="3").
> >>>> This means that for musical units the origin has to be bottom left.
> >>>> I know it's confusing in the guidelines, and we will address this
> >>>> at some point. If you don't mind, you're invited to prepare
> >>>> something on Git and submit a pull request ;-)
> >>>>
> >>>> Hope this helps,
> >>>> jo
> >>>>
> >>>>
> >>>>> Am 04.07.2017 um 14:48 schrieb Daniel Alles <DanielAlles at stud.uni-
<mailto:DanielAlles at stud.uni-%0b>> frankfurt.de<http://frankfurt.de>>:
> >>>>>
> >>>>> Dear all,
> >>>>>
> >>>>> at the moment, I am a little bit confused about how MEI defines its coordinate
> system:
> >> It is possible to add the attributes @ulx, @uly, @lrx and @lry to for
> >> example a surface, as written in part 12 of the Guidelines, which
> >> places the origin of the coordinate system in the upper left corner. All the examples in
> that part show that behavior, ulx/uly is always 0/0.
> >> This would correspond to the coordinate systems used in SVG and DOM
> >> and (which is what I use for my work) Edirom Editor. On the other
> >> hand it is written in part 22.3, that MEI uses a coordinate system in
> >> which "the y-axis points from bottom up". That would mean, that ulx/uly could never
> be 0/0.
> >>>>>
> >>>>> So now my questions: Is it sufficient to use the coordinates like
> >>>>> in the examples, with
> >> the origin in the upper left corner? Would that "override" MEIs original coordinate
> system?
> >> If not: Isn't the possibility to encode areas from top-left to
> >> bottom-right corners a semantic error in MEI, if the coordinate system is pointing from
> bottom-left to top-right?
> >>>>>
> >>>>> Best,
> >>>>> Daniel
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> mei-l mailing list
> >>> mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
> >>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> >>
> >> ---
> >> Donald Byrd
> >> Woodrow Wilson Indiana Teaching Fellow Adjunct Associate Professor of
> >> Informatics Visiting Scientist, Research Technologies Indiana
> >> University Bloomington
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> mei-l mailing list
> >> mei-l at lists.uni-paderborn.de<mailto: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<mailto:mei-l at lists.uni-paderborn.de>
> > https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
> ---
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies
> Indiana University Bloomington
>
>
>
>
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto: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<mailto: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/20170707/330bcda5/attachment.html>