Re: feature requests: scalable \shape values; (stem) for \shapeII

2020-10-11 Thread Thomas Morley
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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Andrew Bernard
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

2020-10-11 Thread Andrew Bernard
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

2020-10-11 Thread Philippe Auclair

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

2020-10-11 Thread Jean Abou Samra

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

2020-10-11 Thread Ralph Palmer
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

2020-10-11 Thread Freeman Gilmore
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

2020-10-11 Thread James.Correa
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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Kieren MacMillan
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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Kieren MacMillan
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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Kieren MacMillan
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

2020-10-11 Thread Jean Abou Samra
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

2020-10-11 Thread Marc Shepherd
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

2020-10-11 Thread Martin Neubauer




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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Martín Rincón Botero
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

2020-10-11 Thread Andrew Bernard
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