[Top][All Lists]

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

Re: GSoC 2020 update, July 18

From: Benkő Pál
Subject: Re: GSoC 2020 update, July 18
Date: Tue, 21 Jul 2020 08:31:40 +0200

in ancient (ars subtilior) notation there actually are noteheads with
two stems (which may also be flagged differently), called "dragma".
a picture search for "dragma ars subtilior" returned poor images; one
not entirely useless is
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video

Owen Lamb <> ezt írta (időpont: 2020. júl. 20., H, 22:27):
> On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys <> 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]