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

Fri Jul 7 18:56:04 CEST 2017

Think of "virtual units" as "diatonic steps" and then there should be no
confusion.

On 7 July 2017 at 17:22, Byrd, Donald A. <donbyrd at indiana.edu> wrote:

> 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>
>  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] 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
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20170707/f2496d6a/attachment.html>