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 <owendl...@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 <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