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

[Roland, Perry D. (pdr4h)]

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] 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>
> 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>
>  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>:
> >
> >> 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-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
> > 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
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l