Re: GSoC 2020 update, July 18
Ah, I think I see what you mean. Yes, two properties may prove useful in
the future. But given the presence of a simple workaround for the cases
we're aware of at the moment, I don't see a need to change things until
such an evolution actually happens.
Thanks,
Owen
On Wed, Jul 22, 2020 at 2:35 AM Benkő Pál wrote:
> I just raised it to show that SMuFL may evolve so (if musicology's
> interpretation of dragmae change so) that separate properties of up
> and down stem attachment points may come handy. you may well have far
> stronger counterarguments, of course.
>
> Owen Lamb ezt írta (időpont: 2020. júl. 22., Sze,
> 1:57):
> >
> > Thanks for the tip, Benkő!
> >
> > At the moment, I think these sort of double stems are outside of my
> project's scope. A two-stemmed black dragma is present in SMuFL as a
> pre-composed note (mensuralBlackDragma), but Emmentaler does not have a
> glyph for it and LilyPond does not specifically support double-stemming
> single notehead grobs. All I am in charge of at the moment is taking how
> LilyPond currently handles glyphs and adapting it to the SMuFL
> specification, and that's keeping my hands full enough at the moment.
> >
> > If you need it, I think the basic version of such a glyph can currently
> be simulated by using two notehead grobs, something like this:
> >
> > dragma =
> > #(define-music-function (music)
> >(ly:music?)
> >#{
> > \override Staff.Stem.length = 4
> > <<
> >\override NoteColumn.direction = #UP
> >#music
> >\\
> >\override NoteColumn.direction = #DOWN
> >#music
> > >>
> > \revert Staff.Stem.length
> >#})
> >
> > \score {
> > \new Staff {
> > \override Staff.NoteHead.style = #'petrucci
> > \dragma { g'4 a'2 }
> > b'4 \dragma b' a' c''
> > }
> > }
> >
> > I can't vouch for the flags looking right, but it's something.
> >
> > If you want to use the precomposed glyph as it is found in another SMuFL
> font, you should be able to find it via something like OLL's \smuflglyph
> command once I'm done with GSoC. Otherwise, this would probably be a good
> idea for a separate feature request.
> >
> > Hope this helps,
> > Owen
> >
> > On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál wrote:
> >>
> >> Thanks. Lukas, that's what I looked for! On the next page there are
> >> dragmas with flags on both stem and ones with flags only on the down
> >> stem.
> >>
> >> Lukas-Fabian Moser ezt írta (időpont: 2020. júl. 21., K,
> 11:32):
> >> >
> >> > Hi 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
> >> >
> >> > See also the examples given in Apel, the first of which being
> >> >
> >> >
> https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
> >> >
> >> > Best
> >> > Lukas
> >> >
>
Re: GSoC 2020 update, July 18
I just raised it to show that SMuFL may evolve so (if musicology's
interpretation of dragmae change so) that separate properties of up
and down stem attachment points may come handy. you may well have far
stronger counterarguments, of course.
Owen Lamb ezt írta (időpont: 2020. júl. 22., Sze, 1:57):
>
> Thanks for the tip, Benkő!
>
> At the moment, I think these sort of double stems are outside of my project's
> scope. A two-stemmed black dragma is present in SMuFL as a pre-composed note
> (mensuralBlackDragma), but Emmentaler does not have a glyph for it and
> LilyPond does not specifically support double-stemming single notehead grobs.
> All I am in charge of at the moment is taking how LilyPond currently handles
> glyphs and adapting it to the SMuFL specification, and that's keeping my
> hands full enough at the moment.
>
> If you need it, I think the basic version of such a glyph can currently be
> simulated by using two notehead grobs, something like this:
>
> dragma =
> #(define-music-function (music)
>(ly:music?)
>#{
> \override Staff.Stem.length = 4
> <<
>\override NoteColumn.direction = #UP
>#music
>\\
>\override NoteColumn.direction = #DOWN
>#music
> >>
> \revert Staff.Stem.length
>#})
>
> \score {
> \new Staff {
> \override Staff.NoteHead.style = #'petrucci
> \dragma { g'4 a'2 }
> b'4 \dragma b' a' c''
> }
> }
>
> I can't vouch for the flags looking right, but it's something.
>
> If you want to use the precomposed glyph as it is found in another SMuFL
> font, you should be able to find it via something like OLL's \smuflglyph
> command once I'm done with GSoC. Otherwise, this would probably be a good
> idea for a separate feature request.
>
> Hope this helps,
> Owen
>
> On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál wrote:
>>
>> Thanks. Lukas, that's what I looked for! On the next page there are
>> dragmas with flags on both stem and ones with flags only on the down
>> stem.
>>
>> Lukas-Fabian Moser ezt írta (időpont: 2020. júl. 21., K,
>> 11:32):
>> >
>> > Hi 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
>> >
>> > See also the examples given in Apel, the first of which being
>> >
>> > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
>> >
>> > Best
>> > Lukas
>> >
Re: GSoC 2020 update, July 18
Thanks for the tip, Benkő!
At the moment, I think these sort of double stems are outside of my
project's scope. A two-stemmed black dragma is present in SMuFL as a
pre-composed note (mensuralBlackDragma), but Emmentaler does not have a
glyph for it and LilyPond does not specifically support double-stemming
single notehead grobs. All I am in charge of at the moment is taking how
LilyPond currently handles glyphs and adapting it to the SMuFL
specification, and that's keeping my hands full enough at the moment.
If you need it, I think the basic version of such a glyph can currently be
simulated by using two notehead grobs, something like this:
dragma =
#(define-music-function (music)
(ly:music?)
#{
\override Staff.Stem.length = 4
<<
\override NoteColumn.direction = #UP
#music
\\
\override NoteColumn.direction = #DOWN
#music
>>
\revert Staff.Stem.length
#})
\score {
\new Staff {
\override Staff.NoteHead.style = #'petrucci
\dragma { g'4 a'2 }
b'4 \dragma b' a' c''
}
}
I can't vouch for the flags looking right, but it's something.
If you want to use the precomposed glyph as it is found in another SMuFL
font, you should be able to find it via something like OLL's
\smuflglyph command once I'm done with GSoC. Otherwise, this would probably
be a good idea for a separate feature request.
Hope this helps,
Owen
On Tue, Jul 21, 2020 at 3:28 AM Benkő Pál wrote:
> Thanks. Lukas, that's what I looked for! On the next page there are
> dragmas with flags on both stem and ones with flags only on the down
> stem.
>
> Lukas-Fabian Moser ezt írta (időpont: 2020. júl. 21., K,
> 11:32):
> >
> > Hi 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
> >
> > See also the examples given in Apel, the first of which being
> >
> > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up
> >
> > Best
> > Lukas
> >
>
Re: GSoC 2020 update, July 18
Thanks. Lukas, that's what I looked for! On the next page there are dragmas with flags on both stem and ones with flags only on the down stem. Lukas-Fabian Moser ezt írta (időpont: 2020. júl. 21., K, 11:32): > > Hi 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 > > See also the examples given in Apel, the first of which being > > https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up > > Best > Lukas >
Re: GSoC 2020 update, July 18
Hi 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 See also the examples given in Apel, the first of which being https://archive.org/details/notationofpolyph1953apel/page/392/mode/2up Best Lukas
Re: GSoC 2020 update, July 18
> 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 Very interesting, thanks for the links! I think these double-stemmed noteheads count as stems in the normal, modern sense – in particular, the length of the stems never change. I rather think that we should consider them special glyphs, this is, note head + lower stem (or note head and lower hook, respectively) should form complete glyph entities. Are those glyphs already in SMuFL? Werner
Re: GSoC 2020 update, July 18
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 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
Re: GSoC 2020 update, July 18
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
Re: GSoC 2020 update, July 18
Owen, you progress looks really good. Congrats! Some general comments to the code style: Please avoid overlong lines (i.e., lines longer than 80 characters if possible). Especially if working with git repository viewers like `gitk` or inspecting merge requests on the gitlab web page this is very helpful. Werner
Re: GSoC 2020 update, July 18
On Sun, Jul 19, 2020 at 4:29 AM Owen Lamb wrote: > (I also made a couple new scheme properties for a notehead grob: > stem-attachment-up and stem-attachment-down. At the moment, the old, > generic stem-attachment property simply calls for the -up or -down variant > depending on the grob's direction, but it may be wise to always make it > return stem-attachment-up, to preserve backwards compatibility. > Perhaps--although this is beyond my Scheme expertise--"setting" > stem-attachment should set stem-attachment-up, while setting > stem-attachment-down to an appropriate reflection as well? What do you all > think?) I don't understand why we need 2 properties here. What benefit do we get relative to a single property? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: GSoC 2020 update, July 18
On Sat, Jul 18, 2020, 9:29 PM Owen Lamb wrote: > After that, I encoded those glyphs, filling out the rest of the Aikin > shape-note glyphs while I was at it. > Thanks for that! I'm in a community that uses Aikin noteheads to the exclusion of all else. -- Karlin High Missouri, USA >
