[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC 2020 update, July 18
Re: GSoC 2020 update, July 18
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 <firstname.lastname@example.org> ezt írta (időpont: 2020. júl. 20., H, 22:27):
> On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys <email@example.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.
Re: GSoC 2020 update, July 18, Werner LEMBERG, 2020/07/20
- GSoC 2020 update, July 18, Owen Lamb, 2020/07/18
- Re: GSoC 2020 update, July 18, Karlin High, 2020/07/18
- Re: GSoC 2020 update, July 18, Han-Wen Nienhuys, 2020/07/19
- Re: GSoC 2020 update, July 18, Owen Lamb, 2020/07/20
- Re: GSoC 2020 update, July 18,
Benkő Pál <=
- Re: GSoC 2020 update, July 18, Werner LEMBERG, 2020/07/21
- Re: GSoC 2020 update, July 18, Lukas-Fabian Moser, 2020/07/21
- Re: GSoC 2020 update, July 18, Benkő Pál, 2020/07/21
- Re: GSoC 2020 update, July 18, Owen Lamb, 2020/07/21
- Re: GSoC 2020 update, July 18, Benkő Pál, 2020/07/22
- Re: GSoC 2020 update, July 18, Owen Lamb, 2020/07/22