Re: GSoC 2020 update, July 18

[Benkő Pál]

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
https://www.last.fm/music/Philippus+de+Caserta/+images/f82a66af9573ba3cf431b0b1986f07e8
(staff three, the black block between two red block in the first half
of the staff); or see the youtube video
https://www.youtube.com/watch?v=wd3ouxA9p-o

Owen Lamb <owendlamb@gmail.com> ezt írta (időpont: 2020. júl. 20., H, 22:27):
>
> 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