Re: feature requests: scalable \shape values; (stem) for \shapeII
Am Mi., 7. Okt. 2020 um 10:35 Uhr schrieb Martín Rincón Botero
:
>
> Now that we’ve been talking about \shape and \shapeII, I would like to ask if
> it’s possible that values put for \shape(II) could scale according to staff
> size. Whenever I have a smaller staff, whatever values work for a 20 points
> staff are too much for smaller staves (either with a smaller font size or
> with \magnify). It would be great, from a user perspective, that a (0 . 1)
> value would produce a similar/proportional result no matter the size of the
> staff, instead of being always in a different “scale” every time you have
> different staff sizes (so that you have to put smaller values for smaller
> staves). That would also be useful if you decide later to increase or
> decrease the font size used.
Hi Martín,
\shape adds your settings to the calculated control-points of the curve.
Though, those control-points are calculated differently depending on
staff-space.
Look at the example below, you will notice the default control-points
are always different.
In the attached image I let print the second and third control-point.
\layout {
\context {
\Voice
\override NoteHead.stencil = #point-stencil
}
}
mus = { b'1_~ b'1 }
\new Staff \with { \magnifyStaff #4 } \mus
\new Staff \with { \magnifyStaff #1 } \mus
\new Staff \with { \magnifyStaff #1/4 } \mus
This means \shape always gets different control-points to work with,
thus the result will never be consistent even for scaled
offset-values.
Nevertheless, it's not too hard to code a shape-version, which will
scale it's offset-values according to current staff-space:
\version "2.20.0"
shape-h =
#(define-music-function (offsets item)
(list? key-list-or-music?)
(_i "Offset control-points of @var{item} by @var{offsets}. The
argument is a list of number pairs or list of such lists. Each
element of a pair represents an offset to one of the coordinates of a
control-point. If @var{item} is a string, the result is
@code{\\once\\override} for the specified grob type. If @var{item} is
a music expression, the result is the same music expression with an
appropriate tweak applied.")
(define (shape-curve grob coords)
(let* ((orig (ly:grob-original grob))
(siblings (if (ly:spanner? grob)
(ly:spanner-broken-into orig) '()))
(total-found (length siblings))
(staff-space (ly:staff-symbol-staff-space grob))
(offsets
(map
(lambda (offset)
(if (number-pair? offset)
(cons (car offset) (* (cdr offset) staff-space))
offset))
offsets)))
(define (offset-control-points offsets)
(if (null? offsets)
coords
(map coord-translate coords offsets)))
(define (helper sibs offs)
(if (pair? offs)
(if (eq? (car sibs) grob)
(offset-control-points (car offs))
(helper (cdr sibs) (cdr offs)))
coords))
;; we work with lists of lists
(if (or (null? offsets)
(not (list? (car offsets
(set! offsets (list offsets)))
(if (>= total-found 2)
(helper siblings offsets)
(offset-control-points (car offsets)
(once (propertyTweak 'control-points
(grob-transformer 'control-points shape-curve)
item)))
\layout {
\context {
\Voice
\override NoteHead.stencil = #point-stencil
}
}
mus = { b'1 \shape-h #'((0 . 1) (0 . 0) (0 . 0) (0 . 0)) _~ b'1 }
\new Staff \with { \magnifyStaff #4 } \mus
\new Staff \with { \magnifyStaff #1 } \mus
\new Staff \with { \magnifyStaff #1/4 } \mus
See second image.
Cheers,
Harm
atest-105.cropped.pdf
Description: Adobe PDF document
atest-105-scaled-shape.cropped.pdf
Description: Adobe PDF document
Re: feature requests: scalable \shape values; (stem) for \shapeII
Dear Thomas,
sorry for not having provided examples myself of what doesn’t scale. I haven’t
had the time for that yet. However, your explanation seems to be right. I
definitely have to use smaller values for smaller font sizes. I was planning to
collect a few examples from the viola concerto I’m working on. But your example
shows what I meant! Curves can look substantially different with the same
values with different font sizes.
Thank you for that code!!! I can see now that values seem to scale with it.
I’ll have to try it myself. Perhaps that could be the fix for the recently
opened issue a couple of messages above in this thread?
Regards,
Martín.
www.martinrinconbotero.com
On 11. Oct 2020, 10:04 +0200, Thomas Morley , wrote:
> Am Mi., 7. Okt. 2020 um 10:35 Uhr schrieb Martín Rincón Botero
> :
> >
> > Now that we’ve been talking about \shape and \shapeII, I would like to ask
> > if it’s possible that values put for \shape(II) could scale according to
> > staff size. Whenever I have a smaller staff, whatever values work for a 20
> > points staff are too much for smaller staves (either with a smaller font
> > size or with \magnify). It would be great, from a user perspective, that a
> > (0 . 1) value would produce a similar/proportional result no matter the
> > size of the staff, instead of being always in a different “scale” every
> > time you have different staff sizes (so that you have to put smaller values
> > for smaller staves). That would also be useful if you decide later to
> > increase or decrease the font size used.
>
> Hi Martín,
>
> \shape adds your settings to the calculated control-points of the curve.
> Though, those control-points are calculated differently depending on
> staff-space.
> Look at the example below, you will notice the default control-points
> are always different.
> In the attached image I let print the second and third control-point.
>
> \layout {
> \context {
> \Voice
> \override NoteHead.stencil = #point-stencil
> }
> }
>
> mus = { b'1_~ b'1 }
>
> \new Staff \with { \magnifyStaff #4 } \mus
> \new Staff \with { \magnifyStaff #1 } \mus
> \new Staff \with { \magnifyStaff #1/4 } \mus
>
> This means \shape always gets different control-points to work with,
> thus the result will never be consistent even for scaled
> offset-values.
>
> Nevertheless, it's not too hard to code a shape-version, which will
> scale it's offset-values according to current staff-space:
>
> \version "2.20.0"
>
> shape-h =
> #(define-music-function (offsets item)
> (list? key-list-or-music?)
> (_i "Offset control-points of @var{item} by @var{offsets}. The
> argument is a list of number pairs or list of such lists. Each
> element of a pair represents an offset to one of the coordinates of a
> control-point. If @var{item} is a string, the result is
> @code{\\once\\override} for the specified grob type. If @var{item} is
> a music expression, the result is the same music expression with an
> appropriate tweak applied.")
> (define (shape-curve grob coords)
> (let* ((orig (ly:grob-original grob))
> (siblings (if (ly:spanner? grob)
> (ly:spanner-broken-into orig) '()))
> (total-found (length siblings))
> (staff-space (ly:staff-symbol-staff-space grob))
> (offsets
> (map
> (lambda (offset)
> (if (number-pair? offset)
> (cons (car offset) (* (cdr offset) staff-space))
> offset))
> offsets)))
> (define (offset-control-points offsets)
> (if (null? offsets)
> coords
> (map coord-translate coords offsets)))
>
> (define (helper sibs offs)
> (if (pair? offs)
> (if (eq? (car sibs) grob)
> (offset-control-points (car offs))
> (helper (cdr sibs) (cdr offs)))
> coords))
>
> ;; we work with lists of lists
> (if (or (null? offsets)
> (not (list? (car offsets
> (set! offsets (list offsets)))
>
> (if (>= total-found 2)
> (helper siblings offsets)
> (offset-control-points (car offsets)
>
> (once (propertyTweak 'control-points
> (grob-transformer 'control-points shape-curve)
> item)))
>
> \layout {
> \context {
> \Voice
> \override NoteHead.stencil = #point-stencil
> }
> }
>
> mus = { b'1 \shape-h #'((0 . 1) (0 . 0) (0 . 0) (0 . 0)) _~ b'1 }
>
> \new Staff \with { \magnifyStaff #4 } \mus
> \new Staff \with { \magnifyStaff #1 } \mus
> \new Staff \with { \magnifyStaff #1/4 } \mus
>
> See second image.
>
> Cheers,
> Harm
Re: lilypond-user Digest, Vol 215, Issue 44
Hi Klaus, Always problematical replying to people who reply to digest subject lines - the topic subject gets lost, and it confuses people and the context becomes lost. [I ban this on all the mailing lists I run - but I am horrible! :-)] Therefore I will start a new thread to reply. Andrew On Sun, 11 Oct 2020 at 02:48, Klaus Blum wrote: > May I ask if there is a special reason to move to Gitlab? Wouldn't it be > easier just to keep the existing repo at Github?
OLL and git
To all interested in OLL. as I am starting this anew, in effect, I am at the moment considering moving to Gitlab instead of Github. There is precedent for this - lilypond is there! (not that that is directly related to OLL). The current github organisation has been orphaned as far as I can see, and for me to do the work and make the improvements I see I prefer to move to Gitlab, so I can have complete management control. Likewise, openlilylib.org has been removed, and I have registered openlilylib.space and I am building a new website today, which will have documentation, a blog, and support material and so on, and anything else people may want. My career has been in UNIX software development and IT Enterprise Architecture. I am critically aware of the impact that changes can have on people and existing code. However, I have been unhappy, as an end user, with OLL git being fragmented into a number of repos. This makes it harder than need be for beginners and people, and part of the whole reason I am taking this on is to enhance the uptake and utility for lilypond users, so I want to unify the work into one repo. There's no criticism of what is there, but I think it 'just grew'. Now, making a change like this would mean people will have to re-org their code a bit, but on reflection I don't think this is a big deal or a big job, and to move forward sometimes breaking changes need to be made. I will of course keep all the very valuable existing code modules - nothing will change there, except I will complete the move to make all the snippets package compliant modules. Changes like this often cause an uproar, but the existing github will still be around, and people can move as and when they see fit, and all new development and contributions should occur on the new Gitlab repo. [It's not ready yet - I only started in on this with definite intent today.] Andrew
Re: Tremolo slope
StemTremolo is for tremolos on a single note, which are
printed over the stem. Yours is just a special case of
Beam, so here you go:
\version "2.20.0"
\score {
\new Staff {
\override Beam.positions = #'(-1 . 1)
\repeat tremolo 16 { c'32 c'' }
}
}
Thanks Jean. This is indeed a beginning.
However, you have to change the positions each time the notes change.
And and if you want to shorten the beams, it becomes really very tedious
(see below)!
Could it be possible to specify vertical AND horizontal positions
relative to notes rather than staff?
Philippe Auclair
\version "2.20.0"
\score {
<<
% first staff just to have reasonable measure width
\new Staff {
c' d' e' f'
c' d' e' f'
c' d' e' f'
c' d' e' f'
}
\new Staff {
\repeat tremolo 16 { c'32 c'' }
% horizontal beams : is this really the rule?
\override Beam.positions = #'(-1 . 0)
\repeat tremolo 16 { c'32 c'' }
% this seems better
% and if you want to shorten the beams
\once \override Beam.X-positions = #'(2 . -2)
\repeat tremolo 16 { c'32 c'' }
% this doesn't work; what does X-positions do?
\override Beam.positions = #'(0 . 1)
\repeat tremolo 16 {
\once \override Stem.X-offset = 2.5 e'32
\once \override Stem.X-offset = -0.5 e'' }
}
>>
}
tremolo.pdf
Description: Adobe PDF document
Re: Tremolo slope
Thanks Jean. This is indeed a beginning. However, you have to change the positions each time the notes change. And and if you want to shorten the beams, it becomes really very tedious (see below)! Could it be possible to specify vertical AND horizontal positions relative to notes rather than staff? Philippe Auclair Well, this time you'll need help from other people as this exceeds my capabilities. Just for reference, the weird tremolo placement is a known issue: https://gitlab.com/lilypond/lilypond/-/issues/318 Best, Jean
Re: OLL and git
Kudos to you, Andrew! And my thanks! I have very limited experience in 1) Github; 2) Oll; and 3) programming, but I'm willing to help in any way I can. All the best, Ralph On Sun, Oct 11, 2020 at 5:19 AM Andrew Bernard wrote: > To all interested in OLL. as I am starting this anew, in effect, I am > at the moment considering moving to Gitlab instead of Github. There is > precedent for this - lilypond is there! > > Changes like this often cause an uproar, but the existing github will > still be around, and people can move as and when they see fit, and all > new development and contributions should occur on the new Gitlab repo. > [It's not ready yet - I only started in on this with definite intent > today.] > -- Ralph Palmer Brattleboro, VT USA (he, him, his) palmer.r.vio...@gmail.com
Re: OLL and git
Thank you. ƒg On Sun, Oct 11, 2020 at 5:19 AM Andrew Bernard wrote: > To all interested in OLL. as I am starting this anew, in effect, I am > at the moment considering moving to Gitlab instead of Github. There is > precedent for this - lilypond is there! (not that that is directly > related to OLL). The current github organisation has been orphaned as > far as I can see, and for me to do the work and make the improvements > I see I prefer to move to Gitlab, so I can have complete management > control. Likewise, openlilylib.org has been removed, and I have > registered openlilylib.space and I am building a new website today, > which will have documentation, a blog, and support material and so on, > and anything else people may want. > > My career has been in UNIX software development and IT Enterprise > Architecture. I am critically aware of the impact that changes can > have on people and existing code. However, I have been unhappy, as an > end user, with OLL git being fragmented into a number of repos. This > makes it harder than need be for beginners and people, and part of the > whole reason I am taking this on is to enhance the uptake and utility > for lilypond users, so I want to unify the work into one repo. There's > no criticism of what is there, but I think it 'just grew'. Now, making > a change like this would mean people will have to re-org their code a > bit, but on reflection I don't think this is a big deal or a big job, > and to move forward sometimes breaking changes need to be made. > > I will of course keep all the very valuable existing code modules - > nothing will change there, except I will complete the move to make all > the snippets package compliant modules. > > Changes like this often cause an uproar, but the existing github will > still be around, and people can move as and when they see fit, and all > new development and contributions should occur on the new Gitlab repo. > [It's not ready yet - I only started in on this with definite intent > today.] > > Andrew > >
Re: OLL and git
Thank you Andrew for keeping OLL alive! I'm not a programmer, but as a OLL user (mainly \shapeII, notation-snippets and custom-music-fonts),I am kin to help. All the best, James --- James Correa Composer - guitarist - sound designer http://www.jamescorrea.net http://wp.ufpel.edu.br/labcomp/ Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, October 11th, 2020 at 6:19 AM, Andrew Bernard wrote: > To all interested in OLL. as I am starting this anew, in effect, I am > > at the moment considering moving to Gitlab instead of Github. There is > > precedent for this - lilypond is there! (not that that is directly > > related to OLL). The current github organisation has been orphaned as > > far as I can see, and for me to do the work and make the improvements > > I see I prefer to move to Gitlab, so I can have complete management > > control. Likewise, openlilylib.org has been removed, and I have > > registered openlilylib.space and I am building a new website today, > > which will have documentation, a blog, and support material and so on, > > and anything else people may want. > > My career has been in UNIX software development and IT Enterprise > > Architecture. I am critically aware of the impact that changes can > > have on people and existing code. However, I have been unhappy, as an > > end user, with OLL git being fragmented into a number of repos. This > > makes it harder than need be for beginners and people, and part of the > > whole reason I am taking this on is to enhance the uptake and utility > > for lilypond users, so I want to unify the work into one repo. There's > > no criticism of what is there, but I think it 'just grew'. Now, making > > a change like this would mean people will have to re-org their code a > > bit, but on reflection I don't think this is a big deal or a big job, > > and to move forward sometimes breaking changes need to be made. > > I will of course keep all the very valuable existing code modules - > > nothing will change there, except I will complete the move to make all > > the snippets package compliant modules. > > Changes like this often cause an uproar, but the existing github will > > still be around, and people can move as and when they see fit, and all > > new development and contributions should occur on the new Gitlab repo. > > [It's not ready yet - I only started in on this with definite intent > > today.] > > Andrew
grace notes spacing
Hello all, I wanted to ask how do you deal with grace notes (not immediately after the bar line) incorrectly taking too much horizontal space from normal notes. Using \override Score.SpacingSpanner.strict-grace-spacing = ##t seems only useful when no grace notes are used immediately after the bar line and no accidentals are used, which seems like a function for a very limited use case. Browsing the archive I couldn't find any satisfactory solution either. Cheers, Martín. -- www.martinrinconbotero.com
Re: grace notes spacing
Hi Martín, > I wanted to ask how do you deal with grace notes (not immediately after the > bar line) incorrectly taking too much horizontal space from normal notes. Tweaks (X-extent, extra-spacing-width, etc.). Specifically: using the edition-engraver. Hope that helps! Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: grace notes spacing
Thank you for your quick answer! I’ll try that! I didn’t know the edition-engraver manages the issue. www.martinrinconbotero.com On 11. Oct 2020, 19:07 +0200, Kieren MacMillan , wrote: > Hi Martín, > > > I wanted to ask how do you deal with grace notes (not immediately after the > > bar line) incorrectly taking too much horizontal space from normal notes. > > Tweaks (X-extent, extra-spacing-width, etc.). > Specifically: using the edition-engraver. > > Hope that helps! > Kieren. > > > Kieren MacMillan, composer (he/him/his) > ‣ website: www.kierenmacmillan.info > ‣ email: kie...@kierenmacmillan.info >
Re: grace notes spacing
Hi Martín, > I didn’t know the edition-engraver manages the issue. That’s not exactly what I meant… =) You can adjust the spacing "inline" [p.s. Next time, send an MWE, and I’d actually show you how!], but I find it useful and helpful to put all my tweaks in an edition — then, when newer versions of Lilypond improve the automagic handling of issues, I simply delete unnecessary tweaks. Cheers, Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info
Re: grace notes spacing
That’s not exactly what I meant… =)
Yes, lol, I noticed that after reading about the edition-engraver.
Interestingly, the edition-engraver reminds me of Abjad's modus operandi,
which I'm learning at the moment.
Anyways, I couldn't make use of any of your suggestions. I couldn't figure
out how to apply the mentioned tweaks. Here is a MWE:
\version "2.20.0"
{
<< \relative c''' { r4 \appoggiatura {cis32 b ais } b4 gis' e }
\relative c'' { \repeat unfold 2 { gis8 b gis b } }
>>
}
[image: image.png]
How can I make the appoggiaturas move to the left?
Am So., 11. Okt. 2020 um 19:55 Uhr schrieb Kieren MacMillan <
kieren_macmil...@sympatico.ca>:
> Hi Martín,
>
> > I didn’t know the edition-engraver manages the issue.
>
> That’s not exactly what I meant… =)
>
> You can adjust the spacing "inline" [p.s. Next time, send an MWE, and I’d
> actually show you how!], but I find it useful and helpful to put all my
> tweaks in an edition — then, when newer versions of Lilypond improve the
> automagic handling of issues, I simply delete unnecessary tweaks.
>
> Cheers,
> Kieren.
>
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info
>
>
--
www.martinrinconbotero.com
Re: grace notes spacing
Hi Martín,
> Anyways, I couldn't make use of any of your suggestions. I couldn't figure
> out how to apply the mentioned tweaks.
Here’s one possibility:
\version "2.20.0"
fixa = \tweak NoteColumn.X-offset #-3 \etc
fixb = \tweak NoteColumn.X-offset #-2 \etc
fixc = \tweak Accidental.X-extent #'(1 . -0.5) \tweak
NoteHead.extra-spacing-width #'(-1 . -1) \etc
fixd = \tweak NoteColumn.X-offset #0.875 \etc
{
<<
\relative c''' { r4 \appoggiatura { \fixa cis32 \fixb b \fixc ais } b4 gis'
e }
\relative c'' { gis8 \fixd b gis b gis b gis b }
>>
}
Note that I had to unfold the \repeat in the lower staff, in order to easily
apply the tweak to the correct moment. This is one of the [many!] reasons I use
the edition-engraver: you can inject the tweak at an exact moment, regardless
of how the musical elements in that moment were generated.
Hope this helps!
Kieren.
Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info
grace notes spacing
Using \override Score.SpacingSpanner.strict-grace-spacing = ##t seems only useful when no grace notes are used immediately after the bar line and no accidentals are used, which seems like a function for a very limited use case This is a known issue: https://gitlab.com/lilypond/lilypond/-/issues/2630 Best, Jean
Markup Between Systems
Is there a way to print markup that occupies the full width of the page, and resides between two systems? I know that if there are multiple scores within the same book, a markup block can reside between two scores (or above or below any of them). I want markup that is within a score (above a system), but not attached to a staff or note. -- Marc Shepherd
Re: grace notes spacing
On 11/10/2020 21:26, Kieren MacMillan wrote:
Note that I had to unfold the \repeat in the lower staff, in order to easily
apply the tweak to the correct moment. This is one of the [many!] reasons I use
the edition-engraver: you can inject the tweak at an exact moment, regardless
of how the musical elements in that moment were generated.
What I found really nice is the possibility to program the input to the
edition engraver to handle tweaks to the same moment within numerous
bars. Here's a particularly silly (in so many ways...) example
illustrating the idea using just some very basic scheme:
>
\version "2.21.6"
\include "oll-core/package.ily"
\loadPackage edition-engraver
\consistToContexts #edition-engraver Score.Staff.Voice
\addEdition beams
\editionModList beams notes.Voice [ #(map (lambda (n) (cons n '(3/8)))
(iota 30 1))
\editionModList beams notes.Voice ] #(map (lambda (n) (cons n '(5/8)))
(iota 30 1))
\new Staff \with {
\editionID ##f notes
} {
\repeat unfold 40 {
\repeat unfold 8 {
c'8
}
}
}
<
OpenPGP_0x57FC077AF9176739.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: feature requests: scalable \shape values; (stem) for \shapeII
Dear Harm,
I have to run more tests, but your \shape-h function is simply excellent. Thank
you! I wish this could be the default behavior of a new \reshape function.
Perhaps the open issue shouldn’t be fixed for \shape: that way the folks who
carefully used small values for small staves to fix their slurs don’t see their
work destroyed by a fixed \shape function in a next update.
Cheers,
Martín.
www.martinrinconbotero.com
On 11. Oct 2020, 10:04 +0200, Thomas Morley , wrote:
> Am Mi., 7. Okt. 2020 um 10:35 Uhr schrieb Martín Rincón Botero
> :
> >
> > Now that we’ve been talking about \shape and \shapeII, I would like to ask
> > if it’s possible that values put for \shape(II) could scale according to
> > staff size. Whenever I have a smaller staff, whatever values work for a 20
> > points staff are too much for smaller staves (either with a smaller font
> > size or with \magnify). It would be great, from a user perspective, that a
> > (0 . 1) value would produce a similar/proportional result no matter the
> > size of the staff, instead of being always in a different “scale” every
> > time you have different staff sizes (so that you have to put smaller values
> > for smaller staves). That would also be useful if you decide later to
> > increase or decrease the font size used.
>
> Hi Martín,
>
> \shape adds your settings to the calculated control-points of the curve.
> Though, those control-points are calculated differently depending on
> staff-space.
> Look at the example below, you will notice the default control-points
> are always different.
> In the attached image I let print the second and third control-point.
>
> \layout {
> \context {
> \Voice
> \override NoteHead.stencil = #point-stencil
> }
> }
>
> mus = { b'1_~ b'1 }
>
> \new Staff \with { \magnifyStaff #4 } \mus
> \new Staff \with { \magnifyStaff #1 } \mus
> \new Staff \with { \magnifyStaff #1/4 } \mus
>
> This means \shape always gets different control-points to work with,
> thus the result will never be consistent even for scaled
> offset-values.
>
> Nevertheless, it's not too hard to code a shape-version, which will
> scale it's offset-values according to current staff-space:
>
> \version "2.20.0"
>
> shape-h =
> #(define-music-function (offsets item)
> (list? key-list-or-music?)
> (_i "Offset control-points of @var{item} by @var{offsets}. The
> argument is a list of number pairs or list of such lists. Each
> element of a pair represents an offset to one of the coordinates of a
> control-point. If @var{item} is a string, the result is
> @code{\\once\\override} for the specified grob type. If @var{item} is
> a music expression, the result is the same music expression with an
> appropriate tweak applied.")
> (define (shape-curve grob coords)
> (let* ((orig (ly:grob-original grob))
> (siblings (if (ly:spanner? grob)
> (ly:spanner-broken-into orig) '()))
> (total-found (length siblings))
> (staff-space (ly:staff-symbol-staff-space grob))
> (offsets
> (map
> (lambda (offset)
> (if (number-pair? offset)
> (cons (car offset) (* (cdr offset) staff-space))
> offset))
> offsets)))
> (define (offset-control-points offsets)
> (if (null? offsets)
> coords
> (map coord-translate coords offsets)))
>
> (define (helper sibs offs)
> (if (pair? offs)
> (if (eq? (car sibs) grob)
> (offset-control-points (car offs))
> (helper (cdr sibs) (cdr offs)))
> coords))
>
> ;; we work with lists of lists
> (if (or (null? offsets)
> (not (list? (car offsets
> (set! offsets (list offsets)))
>
> (if (>= total-found 2)
> (helper siblings offsets)
> (offset-control-points (car offsets)
>
> (once (propertyTweak 'control-points
> (grob-transformer 'control-points shape-curve)
> item)))
>
> \layout {
> \context {
> \Voice
> \override NoteHead.stencil = #point-stencil
> }
> }
>
> mus = { b'1 \shape-h #'((0 . 1) (0 . 0) (0 . 0) (0 . 0)) _~ b'1 }
>
> \new Staff \with { \magnifyStaff #4 } \mus
> \new Staff \with { \magnifyStaff #1 } \mus
> \new Staff \with { \magnifyStaff #1/4 } \mus
>
> See second image.
>
> Cheers,
> Harm
Re: grace notes spacing
Thanks for the link Jean. 8 years old issue? Ouch! www.martinrinconbotero.com On 11. Oct 2020, 21:59 +0200, Jean Abou Samra , wrote: > > Using \override Score.SpacingSpanner.strict-grace-spacing = ##t seems > > only useful when no grace notes are used immediately after the bar > > line and no accidentals are used, which seems like a function for a > > very limited use case > This is a known issue: > > https://gitlab.com/lilypond/lilypond/-/issues/2630 > > Best, > Jean >
OLL redux
Hello All, Having made the decision that OLL is worth preserving (thank you all for your feedback), I have thrown my efforts in to setting it all up anew, with a principal aim of making it easier to use and better well known. OLL has languished somewhat in obscurity for a while, only really utilized by those in the know. I know both Urs and myself want to see it more widely appreciated and further developed. As mentioned in an earlier post I will be starting afresh with a new git project at Gitlab. I will do that over the next few days. I have created a website for OLL with Wordpress running on my own virtual Linux Server in Singapore (or is it New York? !) This I envision as a central hub for OLL activities and information, especially documentation and tutorial material. Here's the site, in initial release, with much to do. https://openlilylib.space/ Please observe the TLD is .space and not .org. As a further comment., I do a lot of work making websites and mailing lists as well as engraving 300 page string quartets in lilypond, so I am contemplating setting up a Discouse server as a forum for OLL discussion. Discourse supports 95% of what traditional email lists do in parallel to being a very widely used web forum platform now. I myself am the one very wary of balkanisation of lilypond development effort, and I am not entirely happy with setting up a separate world for OLL, but presently with no sign of OLL becoming integrated into Lilypond core, I think having an OLL ecosystem independent of the lilypond-user mailing list is worthwhile. I may be wrong! In any case, we need it for the documentation. I am providing the resources at my own expense, but there are costs such as domain name registration, server hosting. Wordpress bits and bobs and so on. Not right now, but I may make a polite request on the OLL website for donations in the future to run the system. Very small beer amounts.This I only mention as I have complex health issues (a very rare incurable blood cancer) that forced me out the workforce some time ago and I no longer have a salary, else I would happily pay for all this myself. To that extent also, although I don't need technical help presently with the OLL move, and I do appreciate people having made kind offers, I will be looking in the medium term to hand over to other people. Speaking as an IT Enterprise Architect (my former work) this I term Succession Planning - and it's just as important as coding and debugging. Andrew
