On Sun, Jul 19, 2020 at 2:17 AM Han-Wen Nienhuys <hanw...@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