lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC 2020 update, July 18


From: Owen Lamb
Subject: Re: GSoC 2020 update, July 18
Date: Mon, 20 Jul 2020 13:26:54 -0700

On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys <hanwenn@gmail.com> wrote:

> I don't understand why we need 2 properties here. What benefit do we
> get relative to a single property?
>

Well, you got me there! Originally, I was under the impression that a
notehead grob may at some point have two stems attached to it, i.e. when it
is merged from two noteheads in opposite directions. A closer look has
revealed that this is not the case: when this happens, there are still two
noteheads present, and one of them is merely made transparent.

That leaves only one small reason to keep the new properties: I figured it
would make things easier for the user. SMuFL provides two variants of a
stem attachment point from the start, so the stem-attachment property would
have to do one of two things:

   - Return either the upwards variant for up-stems, or the downwards
   variant translated around the center into a pseudo-upwards position for
   down-stems. This would ensure you always get an up-stem-flavored
   coordinate, so that moving it to the right always means moving it away from
   the stem, and vice versa, just the way things have worked in the past.
   However, this isn't terribly intuitive and requires a double transformation
   to get from the original down-stem metadata to a final stem position, which
   could introduce rounding errors.
   - Return the up-or-down variant from metadata unchanged. This is easier
   to implement and understand and removes the need to transform
   unnecessarily, but it comes at the cost of having to check a grob's
   direction every time you want to make sense of the property.

With the two new properties, the user would be able to specifically
redefine -up and -down anchors from the get-go. This, I figured, would make
Scheme scripts cleaner and easier to read and write. However, given the
fact that a notehead grob will only ever have one stem attachment point,
this argument doesn't have a lot of weight anymore.

In short, thank you for pointing this out! If no one objects, I'll remove
the extra properties.

--Owen


reply via email to

[Prev in Thread] Current Thread [Next in Thread]