Re: How to detect SpanBar from inside a make-bar-line definition?

[Thomas Morley]

Am Sa., 16. März 2024 um 14:59 Uhr schrieb Thomas Morley
:
>
> Am Do., 14. März 2024 um 02:31 Uhr schrieb Dan Eble
> :
> >
> > On 2024-03-13 20:09, Thomas Morley wrote:
> > > I don't understand what you propose.
> >
> > My advice was general software-design advice based on a hasty
> > consideration of your post, so I'm not really surprised.
> >
> > > To give a different example, let's look at make-dotted-bar-line (afaik
> > > it's your code).
> > > There you have a `making-span-bar?'-condition, obviously you want a
> > > span bar a little different than bar line.
> >
> > Yes, I remember that there were cases where the dashes didn't meet well,
> > but I don't remember the details.
> >
> > > a) If I implement (pretty-print grob) there, I always get BarLine,
> > > never something else, regardless where I place that.
> >
> > In that case, I think you will need to pass more information into the
> > function from above or find a heuristic that works better.
> >
> > > c) the condition itself may fail, see
> > > /input/regression/non-centered-bar-lines.ly for an example, or try to
> > > set bar-extent to an interval not crossing zero.
> >
> > That's why the comments call it a heuristic.
> >
> > > Because of b) I tried to patch make-dotted-bar-line, alas I found no
> > > condition to apply the patched functionality to span bars only.
> > >
> > > Thus I ask if there is such a condition at all. Or how it could be coded.
> >
> > I'm not sure, and I have to be very motivated to read Scheme, which I am
> > not at the moment.  Sorry.
> > --
> > Dan
>
> I now tried for weeks to find a better heuristic or condition. To no avail.
>
> Then I introduced a new grob-property, 'is-span-bar and have set it in
> `span-bar::compound-bar-line'.
> Now regtests are always failing with ununderstandable messages:
> programming error: Grob `VoltaBracket' has no interface for property
> `is-span-bar'
> programming error: Grob `System' has no interface for property 
> `in-note-padding'
> I neither tackled VoltaBracket nor System...
>
> Nevertheless I uploaded the branch (maybe someone wants to have a look):
> https://gitlab.com/lilypond/lilypond/-/merge_requests/2274
> Not surprisingly the pipeline fails, with completely other messages, though.
>
> Currently I think I'll give up on improving dashed/dotted span bar.
> Uploading soon a patch only adjusting for other staff-spaces.
>
> Thanks,
>   Harm

I think (hope) I found the culprit.
Don't set the property in `span-bar::compound-bar-line', but in
`ly:span-bar::print' for `model-bar'

Cheers,
  Harm

Re: How to detect SpanBar from inside a make-bar-line definition?

[Thomas Morley]

Am Do., 14. März 2024 um 02:31 Uhr schrieb Dan Eble
:
>
> On 2024-03-13 20:09, Thomas Morley wrote:
> > I don't understand what you propose.
>
> My advice was general software-design advice based on a hasty
> consideration of your post, so I'm not really surprised.
>
> > To give a different example, let's look at make-dotted-bar-line (afaik
> > it's your code).
> > There you have a `making-span-bar?'-condition, obviously you want a
> > span bar a little different than bar line.
>
> Yes, I remember that there were cases where the dashes didn't meet well,
> but I don't remember the details.
>
> > a) If I implement (pretty-print grob) there, I always get BarLine,
> > never something else, regardless where I place that.
>
> In that case, I think you will need to pass more information into the
> function from above or find a heuristic that works better.
>
> > c) the condition itself may fail, see
> > /input/regression/non-centered-bar-lines.ly for an example, or try to
> > set bar-extent to an interval not crossing zero.
>
> That's why the comments call it a heuristic.
>
> > Because of b) I tried to patch make-dotted-bar-line, alas I found no
> > condition to apply the patched functionality to span bars only.
> >
> > Thus I ask if there is such a condition at all. Or how it could be coded.
>
> I'm not sure, and I have to be very motivated to read Scheme, which I am
> not at the moment.  Sorry.
> --
> Dan

I now tried for weeks to find a better heuristic or condition. To no avail.

Then I introduced a new grob-property, 'is-span-bar and have set it in
`span-bar::compound-bar-line'.
Now regtests are always failing with ununderstandable messages:
programming error: Grob `VoltaBracket' has no interface for property
`is-span-bar'
programming error: Grob `System' has no interface for property `in-note-padding'
I neither tackled VoltaBracket nor System...

Nevertheless I uploaded the branch (maybe someone wants to have a look):
https://gitlab.com/lilypond/lilypond/-/merge_requests/2274
Not surprisingly the pipeline fails, with completely other messages, though.

Currently I think I'll give up on improving dashed/dotted span bar.
Uploading soon a patch only adjusting for other staff-spaces.

Thanks,
  Harm

Re: How to detect SpanBar from inside a make-bar-line definition?

[Thomas Morley]

Am Mi., 13. März 2024 um 23:56 Uhr schrieb Dan Eble
:
>
> On 2024-03-13 17:35, Thomas Morley wrote:
>
> > currently I'm attempting to improve dashed/dotted bar lines wrt to
> > changed staff-space and span bars.
> > We use both definitions for BarLine _and_ SpanBar, but then SpanBar is
> > frequently a little off.
> > It would be nice to have a possibility to detect whether a definition
> > is used for span bars.
>
> What specifically do you want to know?  Do you expect to code something like
>
>  if the grob is a BarLine:
>adjust ... by ...
>  if the grob is a Divisio:
>adjust ... by ...
>  if the grob is a SpanBar:
>adjust ... by ...
>
> If so, it seems that you could add a grob property for that adjustment
> and get it from the grob.
>
> > #(define (make-test-bar-line grob extent)
> >(let ((grob::make-span-bar? #f))
>
> Another possibility is for the grob's print procedure to pass more
> information down to this function.  That might be more appropriate if
> the information you require is not associated with the grob only, but is
> derived from a number of sources, like the surrounding staves, and would
> be useful for many different glyph print procedures.  Of course,
> ly:bar-line::print would provide values appropriate for bar lines and
> ly:span-bar::print would provide values appropriate for span bars.
>
> These are the opinions off the top of my head and I reserve the right to
> change them.
> --
> Dan
>
Hi Dan,

I don't understand what you propose.

To give a different example, let's look at make-dotted-bar-line (afaik
it's your code).
There you have a `making-span-bar?'-condition, obviously you want a
span bar a little different than bar line.
Though, I noticed a few things:
a) If I implement (pretty-print grob) there, I always get BarLine,
never something else, regardless where I place that.
b) Dotted span bars are not optimal. Compile my example from my
initilal post to get an example.
c) the condition itself may fail, see
/input/regression/non-centered-bar-lines.ly for an example, or try to
set bar-extent to an interval not crossing zero.

Because of b) I tried to patch make-dotted-bar-line, alas I found no
condition to apply the patched functionality to span bars only.

Thus I ask if there is such a condition at all. Or how it could be coded.
Alternatively, I could code a special `make-dotted-span-bar'-procedure
and define the dotted bar line as
(define-bar-line ";" #t #f ";-span")
or the like...

Thanks,
  Harm

How to detect SpanBar from inside a make-bar-line definition?

[Thomas Morley]

Hi,

currently I'm attempting to improve dashed/dotted bar lines wrt to
changed staff-space and span bars.
We use both definitions for BarLine _and_ SpanBar, but then SpanBar is
frequently a little off.
It would be nice to have a possibility to detect whether a definition
is used for span bars.
But how to?

Her some code to play with, `grob::make-span-bar?' should become
something else ofcourse...

#(define (make-test-bar-line grob extent)
  (let ((grob::make-span-bar? #f))
(if grob::make-span-bar?
((@@ (lily) make-simple-bar-line) grob extent)
((@@ (lily) make-dotted-bar-line) grob extent

#(add-bar-glyph-print-procedure "t" make-test-bar-line)
#(define-bar-line "t" "t" "t" "t")

tst = { s1 \bar "t" s }

\new StaffGroup
<<
  \new Staff \tst
  \new Staff \tst
>>

Thanks,
  Harm

Re: toc, \with-link and `bookpart-level-page-numbering'

[Thomas Morley]

Am Sa., 17. Feb. 2024 um 18:47 Uhr schrieb Thomas Morley
:
>
> Hi,
>
> please consider the following code:
>
> \version "2.25.13"
>
> \paper {
>   print-first-page-number = ##t
>   bookpart-level-page-numbering = ##t
> }
>
> \book {
>   \bookpart { \markuplist \table-of-contents }
>   \bookpart {
> \paper { page-number-type = #'roman-upper }
> \tocItem \markup "Text"
> \markup { Lorem ipsum dolor sit amet. }
>   }
>   \bookpart {
> \tocItem \markup "Music"
> { b }
>   }
> }
>
> Imho, there are two issues here
> a) the intern links of the toc are all not working correctly, more
> precisely, they all point to page 1 of the resulting pdf.
> b) I'd prefer if the toc would print the page-number as formated in
> the bookparts, i.e. for "Text" as roman capital.
>
> `bookpart-level-page-numbering' was implemented with
>
> commit 4e2ebc31eb79319c6914fe5e5c1836d5e873d3ee
> Author: Jean Abou Samra 
> Date:   Tue Aug 9 10:23:37 2022 +0200
>
> Add bookpart-level-page-numbering paper variable
>
> If bookpart-level-page-numbering is set to #t, bookparts have
> independent sequences of page numbers.  This can be useful if
> publishing a set of instrumental parts that are joint in a single
> book, perhaps with a common introduction, but intended to be used
> separately. Furthermore, setting this variable only for the first
> bookpart in conjunction with page-number-type can be used to number
> pages in the introductory material with separate numbering and in
> roman numbers, which is common practice.
>
> Fixes #6396
>
> If I understand correctly (and my cc-knowledge is more or less zero)
> the change in paper-book.cc overrides the real page-number, meaning
> \with-link only sees the new value.
> I found no workaround...
>
> How about implementing some logic like current-page-number vs
> internal-page-number like we have with currentBarNumber and
> internalBarNumber?
> The page-number in toc could then be printed as current-page-number
> but point to internal-page-number.
>
> Thanks,
>   Harm
>
> P.S. I didn't write about formating the toc (the second point above),
> worth another thread...

I've created two issues:
https://gitlab.com/lilypond/lilypond/-/issues/6696
https://gitlab.com/lilypond/lilypond/-/issues/6697

Cheers,
  Harm

toc, \with-link and `bookpart-level-page-numbering'

[Thomas Morley]

Hi,

please consider the following code:

\version "2.25.13"

\paper {
  print-first-page-number = ##t
  bookpart-level-page-numbering = ##t
}

\book {
  \bookpart { \markuplist \table-of-contents }
  \bookpart {
\paper { page-number-type = #'roman-upper }
\tocItem \markup "Text"
\markup { Lorem ipsum dolor sit amet. }
  }
  \bookpart {
\tocItem \markup "Music"
{ b }
  }
}

Imho, there are two issues here
a) the intern links of the toc are all not working correctly, more
precisely, they all point to page 1 of the resulting pdf.
b) I'd prefer if the toc would print the page-number as formated in
the bookparts, i.e. for "Text" as roman capital.

`bookpart-level-page-numbering' was implemented with

commit 4e2ebc31eb79319c6914fe5e5c1836d5e873d3ee
Author: Jean Abou Samra 
Date:   Tue Aug 9 10:23:37 2022 +0200

Add bookpart-level-page-numbering paper variable

If bookpart-level-page-numbering is set to #t, bookparts have
independent sequences of page numbers.  This can be useful if
publishing a set of instrumental parts that are joint in a single
book, perhaps with a common introduction, but intended to be used
separately. Furthermore, setting this variable only for the first
bookpart in conjunction with page-number-type can be used to number
pages in the introductory material with separate numbering and in
roman numbers, which is common practice.

Fixes #6396

If I understand correctly (and my cc-knowledge is more or less zero)
the change in paper-book.cc overrides the real page-number, meaning
\with-link only sees the new value.
I found no workaround...

How about implementing some logic like current-page-number vs
internal-page-number like we have with currentBarNumber and
internalBarNumber?
The page-number in toc could then be printed as current-page-number
but point to internal-page-number.

Thanks,
  Harm

P.S. I didn't write about formating the toc (the second point above),
worth another thread...

Re: RFC and help at MR 2256

[Thomas Morley]

Am Mo., 12. Feb. 2024 um 12:37 Uhr schrieb Jean Abou Samra :
>
>
> It prints
>
> backtrace:
>  0: AgogicLineSpanner.Y-offset (# ly:side-position-interface::y-aligned-side (_ #:optional _)>)
>  1: AgogicLineSpanner.vertical-skylines (# ly:grob::vertical-skylines-from-element-stencils (_)>)
>  2: VerticalAxisGroup.vertical-skylines (# ly:hara-kiri-group-spanner::calc-skylines (_)>)
>
>
> Might be the same as https://gitlab.com/lilypond/lilypond/-/issues/3409 ?

Actually, I feel not qualified to judge here.

> Maybe I have an idea (about 'side-support-elements).
> I'll try and report back.

Filling 'side-support-elements with NoteHeads and Stems made things even worse.

Currently I see only two alternatives:
- Abandon it. Which would be a pity. I first worked on #3176 3 years
ago and never got so far. But I'm completely stuck with no perspective
left.
- Polish the patch and add a warning in NR. Basically: only works in Score.

Opinions?

Thanks,
  Harm

Re: RFC and help at MR 2256

[Thomas Morley]

Am So., 11. Feb. 2024 um 13:51 Uhr schrieb Jean Abou Samra :
>
> > Alas, as soon as the relevant engravers are moved to another context,
> > which is a common use case, I get an error:
> >
> > programming error: cyclic dependency: calculation-in-progress
> > encountered for AgogicLineSpanner.vertical-skylines
> >
> > and the graphical output is wrong.
> > Again, this does not happen at score-level.
> > Example-code to trigger it at #2256
> >
> > I've no clue how to proceed. Every hint is very welcome.
>
> I don't really have the time to investigate, but have you tried
>
> #(ly:set-option 'debug-property-callbacks)
>
> ? It should print a stack of the callbacks showing the cyclic dependency.
>

It prints

backtrace:
  0: AgogicLineSpanner.Y-offset (#)
  1: AgogicLineSpanner.vertical-skylines (#)
  2: VerticalAxisGroup.vertical-skylines (#)

Not sure what exactly that means and how to solve the problem.
Maybe I have an idea (about 'side-support-elements).
I'll try and report back.

Thanks,
  Harm

RFC and help at MR 2256

[Thomas Morley]

Hi,

https://gitlab.com/lilypond/lilypond/-/merge_requests/2256 attempts to
solve https://gitlab.com/lilypond/lilypond/-/issues/3176 by
introducing AgogicMark, AgogicSpanner and AgogicLineSpanner at
score-level.
It all mimics how DynamicLineSpanner collects and aligns dynamic stuff.
So far all works fine.
Alas, as soon as the relevant engravers are moved to another context,
which is a common use case, I get an error:

programming error: cyclic dependency: calculation-in-progress
encountered for AgogicLineSpanner.vertical-skylines

and the graphical output is wrong.
Again, this does not happen at score-level.
Example-code to trigger it at #2256

I've no clue how to proceed. Every hint is very welcome.

Thanks,
  Harm

Re: FingerGlideSpanner disappears if listened

[Thomas Morley]

Am Mo., 25. Dez. 2023 um 20:55 Uhr schrieb David Kastrup :
>
> Jean Abou Samra  writes:
>
> > Probably related to the code and comment in lily/rhythmic-music-iterator.cc.
>
> Probably.  Articulation events with a listener are removed (and
> separately broadcast) from the articulations on a non-chord NoteEvent
> before it is passed to its own engravers.
>
> --
> David Kastrup

I'd never expected something could vansih, if listened to; and there
seems to be no hint in CG 10.11.3 Listening to music events.
Furthermore the following feels inconsistent:

mus = {
b2-\rightHandFinger #2 \5-\glide -1 -\accent
b-\rightHandFinger #2 \5-1 -\accent



}

<<
  \new Voice
\mus

  \new Voice
\with {
  \consists
#(lambda (ctx)
  (make-engraver
(listeners
  ((finger-glide-event this-engraver event) '())
  ((fingering-event this-engraver event) '())
  ((string-number-event this-engraver event) '())
  ((stroke-finger-event this-engraver event) '())
  ((articulation-event this-engraver event) '())
  )))
}
\mus
>>

Why does Fingering and accent survive? Isn't at least the accent an
articulation?
And yes, in-chord all's fine.

Thanks,
  Harm

FingerGlideSpanner disappears if listened

[Thomas Morley]

Hi,

please consider:

mus = { b-\glide -1 b-1 }

<<
  \new Voice
\mus

  \new Voice
\with {
  \consists
#(lambda (ctx)
  (make-engraver
(listeners ((finger-glide-event this-engraver event) '()
}
\mus
>>

With most recent master out of
c3f2dddaa2b16231bc2f786fba7421f03f7da7af I get the attached image.
The FingerGlideSpanner in the second Staff disappears.
With 2.24.0 both are printed.

I've no clue what happens. Insights?

Thanks,
  Harm

Re: Doc-problem with new markup-command

[Thomas Morley]

Am Do., 23. Nov. 2023 um 11:53 Uhr schrieb Jean Abou Samra :
>
>
> > Now m̀ake' fails.
> > Offending line in the doc-string is
> > The input-string @var{strg} may be composed by any string of \";|.:![]{}\".
> > Obviously the braces, { and }, need to be escaped.
> > How to?
>
>
> Like this I think:
>
> ... composed of the characters @samp{; | . : ! [ ] @{ @}}
>

Works now. Many thanks!

Re: Doc-problem with new markup-command

[Thomas Morley]

Am Do., 23. Nov. 2023 um 10:49 Uhr schrieb Thomas Morley
:
>
> Am Do., 23. Nov. 2023 um 10:40 Uhr schrieb Jean Abou Samra 
> :
> >
> > > Ok.
> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2179
> >
> > Oh, I see. You forgot to give it a #:category .
>
> Thanks for the hint. Would it make sense to warn if #:category is omitted?
> Corrected patch is up.
>
> Thanks,
>   Harm

Now m̀ake' fails.
Offending line in the doc-string is
The input-string @var{strg} may be composed by any string of \";|.:![]{}\".
Obviously the braces, { and }, need to be escaped.
How to?

Thanks,
  Harm

Re: Doc-problem with new markup-command

[Thomas Morley]

Am Do., 23. Nov. 2023 um 10:40 Uhr schrieb Jean Abou Samra :
>
> > Ok.
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/2179
>
> Oh, I see. You forgot to give it a #:category .

Thanks for the hint. Would it make sense to warn if #:category is omitted?
Corrected patch is up.

Thanks,
  Harm

Re: Doc-problem with new markup-command

[Thomas Morley]

Am Do., 23. Nov. 2023 um 10:23 Uhr schrieb Jean Abou Samra :
>
> Is this a doc build from scratch or an incremental rebuild?

>From scratch.

> I'd suggest opening the MR anyway.

Ok.
https://gitlab.com/lilypond/lilypond/-/merge_requests/2179

Doc-problem with new markup-command

[Thomas Morley]

Hi,

I'm working on #3164 "add a `\bar-line` markup function" and thought
the patch is ready to upload for review, i.e. the new
bar-line-markup-command works as I think it should,
`make check' (with a new regtest) returns as expected.
`make doc' succeds without errors.

Alas, the new markup-command is not listed in NR.
I was under the impression this would happen automatically.
Am I wrong?

How to proceed, upload the patch anyway?

Thanks,
  Harm

Re: Multiple clefs in one Staff

[Thomas Morley]

Am Fr., 27. Okt. 2023 um 11:29 Uhr schrieb Werner LEMBERG :
>
>
> > Inspired by
> > 
> >
> > Should we be offering something like that?
>
> What exactly do you mean with 'offering'?
>
> Having this functionality is certainly useful for Piano music.
> However, it's quite rare, and an LSR snippet should be sufficient
> (possibly integrated into LilyPond's documentation).
>
>
> Werner
>

We already have
https://lsr.di.unimi.it/LSR/Item?id=326
Although ot tested, David's code looks clearer and cleaner.

Cheers,
  Harm

Re: LSR #983 produces strange result

[Thomas Morley]

Am So., 23. Apr. 2023 um 09:33 Uhr schrieb Thomas Morley
:
>
> Am So., 23. Apr. 2023 um 07:45 Uhr schrieb Werner LEMBERG :
> >
> >
> > Please have a look at
> >
> >   https://lsr.di.unimi.it/LSR/Item?id=983
> >
> > This code has obviously worked some time before, but it no longer
> > doesn't.  Is this a problem with the code or a bug?
> >
> >
> > Werner
> >
>
> Fixed inside LSR by replacing
> \once\omit Staff.BarLine
> by
> \once\hide Staff.BarLine
>
> No clue though, why it works now.
>
> Cheers,
>   Harm

I think it may be a bug. Consider:
{
  \textLengthOn
  s1-"loong"
  \once \omit Staff.BarLine
  \clef F
  r1
}
with a starting spacer _and_ an omitted BarLine _and_ a clef change.

2.22. is ok, but output of 2.24. is bad.

Cheers,
  Harm

Re: LSR #983 produces strange result

[Thomas Morley]

Am So., 23. Apr. 2023 um 07:45 Uhr schrieb Werner LEMBERG :
>
>
> Please have a look at
>
>   https://lsr.di.unimi.it/LSR/Item?id=983
>
> This code has obviously worked some time before, but it no longer
> doesn't.  Is this a problem with the code or a bug?
>
>
> Werner
>

Fixed inside LSR by replacing
\once\omit Staff.BarLine
by
\once\hide Staff.BarLine

No clue though, why it works now.

Cheers,
  Harm

Re: LSR update?

[Thomas Morley]

Am Mi., 28. Dez. 2022 um 07:17 Uhr schrieb Werner LEMBERG :
>
>
> > Lateron, when LSR runs 2.24.0, we need to insert all snippets from
> > /Documentation/snippets/new.

Done.

> > As final step we need to delete the ones from
> > /Documentation/snippets/new and commit the new state, I would be
> > very thankful if someone else could do so.
>
> I can help with that.
>
>
> Werner

Did I understand correctly, you volunteered to do the final steps,
i.e.
(1) Delete all snippets from /Documentation/snippets/new with a
version prior to 2.24.0.
Actually, only breathing-signs.ly (for \version "2.25.0") should stay.
(2) Run makelsr.pl
(3) Commit the new state.
?

Thanks,
  Harm

Re: Missing items to make Cairo ready

[Thomas Morley]

Am Fr., 6. Jan. 2023 um 14:26 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> On Fri, 2023-01-06 at 14:21 +0100, Jean Abou Samra wrote:
> > Le 06/01/2023 à 10:19, Jonas Hahnfeld a écrit :

> > I don't see any markup commands other than \postscript
> > and \epsfile that we cannot fully support in Cairo.
>
> Any number bigger than zero represents a "breaking change" for me, and
> it's not the sort of change that can be fixed by convert-ly or even
> manually because there is no (general) equivalent.

Imho, a good point to look at what users do with \postscript is the LSR.

Currently 20 snippets mention 'postscript'. I'm pretty sure most of
them can be modified to use \path etc.
Apart from https://lsr.di.unimi.it/LSR/Item?id=1060
This one is nice, though.

Anyway, I'd offer to modify said snippets during the 2.25. circle.
Maybe it helps deprecating \postscript ?


Only one lsr-file uses \epsfile.

Cheers,
  Harm

Re: Unbreakable space in texinfo and html

[Thomas Morley]

Am Mo., 2. Jan. 2023 um 13:30 Uhr schrieb Werner LEMBERG :
>
>
> > Here the next one: What's html for @@code@{TupletBracket@}
> > ?
>
> Are you talking about
> `it/texidocs/controlling-tuplet-bracket-visibility.texidoc`?  There,
> `@@code@{TupletBracket@}` is wrong; it should be
> `@code{TupletBracket}` instead.
>
> The HTML equivalent to `@code{TupletBracket}` is
> `TupletBracket`.
>
>
> Werner

Ok, thanks.
  Harm

Re: Unbreakable space in texinfo and html

[Thomas Morley]

Am Mo., 2. Jan. 2023 um 13:23 Uhr schrieb Werner LEMBERG :
>
>
>
> > I could do (in the description)
> >
> > (1)  fa
> > (2)  fa
> > (3)  'fa'
> >
> > What do you recommend?
>
> Assuming that people are going to translate this I would do (1).
>
>
> Werner

Thanks, done.
  Harm

Re: LSR update?

[Thomas Morley]

Am Mo., 2. Jan. 2023 um 13:33 Uhr schrieb Werner LEMBERG :
>
>
> >> Ideally, there would be a git repository to which we can actually
> >> push the new files (to retain the editing history), and a script
> >> that regenerates the database automatically – and vice versa.
> >
> > Werner, actually it's less work than expected.
> > Currently /Documentations/snippets/new contains 53 ly-files [...]
>
> Oh, the files in `new` are not what I'm concerned about.  It's rather
> running `convert-ly` on all other snippets in the LSR...
>
>
> Werner

There might be some misunderstanding.
I've already downloaded, converted to 2.24.0 and fixed (where
neccessary) all the 921 ly-files currently in LSR.
Ofcourse locally on my computer.
This is done. (Apart from removing all headers and and version-statements see
CG 7.7 Updating the LSR to a new version

Once LSR runs 2.24.0 Sebastiano gets a tarball with them and inserts
the snippets.

In my previous post I was talking about /Documentation/snippets/new -
what I did, and what is on TODO

Cheers,
  Harm

Re: LSR update?

[Thomas Morley]

Am Mi., 28. Dez. 2022 um 07:17 Uhr schrieb Werner LEMBERG :
>
>
> > Lateron, when LSR runs 2.24.0, we need to insert all snippets from
> > /Documentation/snippets/new.  This is tedious, any help would be
> > great.
>
> Sebastiano, if we send you an archive with all updated snippets: Do
> you have a possibility to mass-import them into the database?
> Submitting them one by one via the LSR web interface is not feasible.
>
> Ideally, there would be a git repository to which we can actually push
> the new files (to retain the editing history), and a script that
> regenerates the database automatically – and vice versa.

Werner, actually it's less work than expected.
Currently /Documentations/snippets/new contains 53 ly-files and 1
README as of 2023/1/1

9 files are really new ones:

  adjusting-figured-bass-alteration-glyphs.ly
  aligning-the-ends-of-hairpins-to-notecolumn-directions.ly
  customizing-the-chord-grid-style.ly
  customizing-the-no-chord-symbol.ly
  direction-of-merged-fa-shape-note-heads.ly
  measure-centered-bar-numbers.ly
  overriding-articulations-by-type.ly
  positioning-opposing-fermatas-on-a-bar-line.ly
  printing-tuplet-brackets-on-the-note-head-side.ly

I've already put them into LSR (unapproved and the code is commented).

##

Locally I updated the following 43 lsr-files by replacing the code by
the code from the relevant /new-snippets

  accordion-register-symbols.ly
  adding-an-ottava-marking-to-a-single-voice.ly
  adding-parentheses-around-an-expressive-mark-or-chordal-note.ly
  ancient-fonts.ly
  ancient-headword.ly
  ancient-notation-templatemodern-transcription-of-gregorian-music.ly
  
automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly
  book-parts.ly
  centered-measure-numbers.ly
  changing-the-positions-of-figured-bass-alterations.ly
  changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly
  chant-or-psalms-notation.ly
  chord-names-alternative.ly
  controlling-tuplet-bracket-visibility.ly
  creating-a-delayed-turn.ly
  cross-staff-stems.ly
  customized-drum-notation-in-printed-and-midi-output.ly
  customizing-the-position-and-number-of-dots-in-repeat-sign-bar-lines.ly
  flute-slap-notation.ly
  generating-custom-flags.ly
  heavily-customized-polymetric-time-signatures.ly
  hymn-template.ly
  mensurstriche-layout-bar-lines-between-the-staves.ly
  modifying-default-values-for-articulation-shorthand-notation.ly
  modifying-the-ottava-spanner-slope.ly
  of-the-ubiquity-of-markup-objects.ly
  page-label.ly
  percussion-example.ly
  positioning-segno-and-coda-with-line-break.ly
  preventing-final-mark-from-removing-final-tuplet.ly
  printing-bar-numbers-at-regular-intervals.ly
  printing-bar-numbers-using-modulo-bar-number-visible.ly
  printing-marks-on-every-staff.ly
  printing-music-with-different-time-signatures.ly
  printing-the-bar-number-for-the-first-measure.ly
  repeats-headword.ly
  rhythmic-slashes.ly
  setting-the-minimum-length-of-hairpins.ly
  showing-the-same-articulation-above-and-below-a-note-or-chord.ly
  tam-tam-example.ly
  unfretted-headword.ly
  using-tags-to-produce-mensural-and-modern-music-from-the-same-source.ly
  vertical-aligned-staffgroups-without-connecting-systemstartbar.ly

These will be included in a tarball, which Sebastiano will need.

##

As soon as the LSR runs 2.24.0 and all above mentioned snippets are
in, for 9 of them the outdated description needs to be adjusted:

  adding-an-ottava-marking-to-a-single-voice.ly
  adding-parentheses-around-an-expressive-mark-or-chordal-note.ly
  
automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly
  centered-measure-numbers.ly
  changing-the-positions-of-figured-bass-alterations.ly
  controlling-tuplet-bracket-visibility.ly
  modifying-default-values-for-articulation-shorthand-notation.ly
  of-the-ubiquity-of-markup-objects.ly
  printing-the-bar-number-for-the-first-measure.ly

Afaict, this can't be done together with the code-upgrade.

> > As final step we need to delete the ones from
> > /Documentation/snippets/new and commit the new state, I would be
> > very thankful if someone else could do so.

In /Documentations/snippets/new only 1 snippet should stay

>
> I can help with that.

Many thanks!!
>
>
> Werner

Cheers,
  Harm

Re: Unbreakable space in texinfo and html

[Thomas Morley]

Am So., 1. Jan. 2023 um 22:24 Uhr schrieb Aaron Hill :
>
> On 2023-01-01 11:21 am, Thomas Morley wrote:
> > May I ask further:
> > What are the html equivalents of @qq{…} and @q{…}?
>
> If you are looking for HTML entities, there are several online resources
> (such as [1]) that list them.
>
> [1]: https://unicode-table.com/en/html-entities/
>
> Typographer's quotes would be  and  (for left/right single
> quote) as well as  and  (for left/right double quote).
>
>
> -- Aaron Hill

The problem is I need a command that makelsr.pl will understand and
transform correctly from html to texinfo.
Thus those manuals are only of limited usability.

Here the next one: What's html for @@code@{TupletBracket@}
?

Cheers,
  Harm

Re: Unbreakable space in texinfo and html

[Thomas Morley]

Am So., 1. Jan. 2023 um 23:58 Uhr schrieb Werner LEMBERG :
>
>
> > What are the html equivalents of @qq{…} and @q{…}?
>
> There is no stand-alone equivalent to `@q`.  If you write
>
> ```
> foo
> ```
>
> it gets converted by `pandoc` to
>
> ```
> ``foo''
> ```
>
> which `makelsr.pl` in turn converts to `@qq{foo}`.
>
> You get
>
> ```
> `foo'
> ```
>
> only for the inner quote environment if you use ` ...  ... 
> ... `.  This is not handled by `makelsr.pl` but it could be added.
>
>
> Werner

What to do with
/Documentation/snippets/new/direction-of-merged-fa-shape-note-heads.ly
then?
The title uses 'fa'. Its description contains @q{fa}.
In 
http://lilypond.org/doc/v2.24/Documentation/snippets/pitches#pitches-direction-of-merged-_0027fa_0027-shape-note-heads
it reads as:

Direction of merged ’fa’ shape note heads
[...]the direction of ‘fa’ shape note heads[...]

I could do (in the description)
(1)  fa
(2)  fa
(3)  'fa'

What do you recommend?

Thanks,
  Harm

Re: Unbreakable space in texinfo and html

[Thomas Morley]

Happy new year as well!!

Am So., 1. Jan. 2023 um 19:12 Uhr schrieb Werner LEMBERG :
>
>
> Hallo Harm,
>
>
> a Happy New Year to you and all other LilyPonders!
>
>
> > In our doc-strings we sometimes have @tie{} to get an unbreakable
> > space.  As lsr-editor I need similar for html.  Is  the
> > correct equivalent?
>
> Yes.  Note that U+00A0 would also work.
>
> > Will  correctly be transformed to @tie{} if lsr-snippets are
> > imported?
>
> Yes, `makelsr.pl` has special code to do exactly that.
>
>
> Werner

Thanks!
May I ask further:
What are the html equivalents of @qq{…} and @q{…}?

Thanks,
  Harm

Unbreakable space in texinfo and html

[Thomas Morley]

In our doc-strings we sometimes have @tie{} to get an unbreakable space.
As lsr-editor I need similar for html.
Is  the correct equivalent?
Will  correctly be transformed to @tie{} if lsr-snippets are imported?

Thanks,
  Harm

Re: LSR update?

[Thomas Morley]

Am So., 1. Jan. 2023 um 11:52 Uhr schrieb Jean Abou Samra :
>
> Le 31/12/2022 à 21:15, Thomas Morley a écrit :
> > Today I found some time :)
> >
> > lilypond *.ly on all lsr-snippets fails because of the following snippets:
> >custom-tuning-and-midi-rendering.ly
> >dodecaphonic-staff.ly
> >dodecaphonic-staff-with-accurate-ledger-lines.ly
> >microtonal-notation-and-theory-of-harmony.ly
> >retuning-to-a-regular-temperament.ly
> >
> > All of them are using ly:set-default-scale and/or
> > ly:parser-set-note-names on toplevel niveau.
> >
> > How to limit those settings to the current file?
>
>
> I would approach it differently: not "how to fix the snippets?", but
> "how to fix LilyPond so that these settings apply to the current file?".
>

Sure, out of my depth, though.
And any fix in lilypond would be too late for the 2.24. lsr-update.

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 16:55 Uhr schrieb Thomas Morley
:
>
> Am Di., 27. Dez. 2022 um 15:24 Uhr schrieb Jean Abou Samra 
> :
> >
> > Le 27/12/2022 à 15:06, Thomas Morley a écrit :

> > > (3)
> > > It's not possible to do
> > > lilypond *.ly
> > > on all snippets.
> > > Somewhere there's a bleed over, causing multiple
> > > warnings/errors/crashes on otherwise clean compilimg snippets, when
> > > compiled separately.
> > > Worth researching I'd say, too tired right now though.
> >
> >
> >
> > I think this is a lost cause. There is a lot of hacky Scheme code
> > in snippets and I think quite a few are not protected against
> > bleedover.
>
> Once I have much time, I may give it a try. Not that I'd know when
> "much time" will happen...
>

Today I found some time :)

lilypond *.ly on all lsr-snippets fails because of the following snippets:
  custom-tuning-and-midi-rendering.ly
  dodecaphonic-staff.ly
  dodecaphonic-staff-with-accurate-ledger-lines.ly
  microtonal-notation-and-theory-of-harmony.ly
  retuning-to-a-regular-temperament.ly

All of them are using ly:set-default-scale and/or
ly:parser-set-note-names on toplevel niveau.

How to limit those settings to the current file?

Otherwise all snippets are updated in one or the other way, even the 5
snippets above compile if compiled separately.

Still some work to do...

Cheers,
  Harm

Re: Strange behaviour with unknown alternativeNumberingStyle

[Thomas Morley]

Meanwhile I created https://gitlab.com/lilypond/lilypond/-/issues/6507

Am Sa., 31. Dez. 2022 um 19:01 Uhr schrieb Dan Eble :
>
> On Dec 30, 2022, at 12:10, Thomas Morley  wrote:
> >
> > Hi all,
> >
> > please have a look at:
> >
> > \version "2.25.0"
> >
> > {
> >  \override Score.BarNumber.break-visibility = ##(#f #t #t)
> > %  \set Score.alternativeNumberingStyle = #'whatever
> >  b1
> >  \repeat volta 2 { c' c' }
> >  \alternative { d' e' }
> >  f'
> > }
> >
> > As soon as the style-setting is uncommented it behaves like
> >  \set Score.alternativeNumberingStyle = #'number
> > shouldn't an unknown style behave like the default '()?
>
> I don't see documentation or regression tests for anything beyond 'number and 
> 'numbers-with-letters.
>
> Since 
> https://gitlab.com/lilypond/lilypond/-/merge_requests/594#note_477121479,
> Timing_translator chooses the numbers and Bar_number_engraver formats them.  
> Any value of "alternativeNumberingStyle" causes Timing_translator to use the 
> alternative numbering scheme common to both of those styles.

Ok, still a bug, imho.
We should provide a predictable fallback, getting 'number instead is unexpected.

>
> > tl;dr
> > This probably prevents me defining a knew style
> > with a custom engraver
> > as fix for lsr-snippet 1080 "Incrementing bar numbers in volta
> > repeats"
> > https://lsr.di.unimi.it/LSR/Item?id=1080
>
> From the description: "Here is a hack that increments the currentBarNumber 
> property whenever volta repeats occur.  It also offers basic (though limited) 
> support for alternatives."
>
> Do you need a new value for alternativeNumberingStyle?  If you want the 
> behavior arising from leaving alternativeNumberingStyle unset, why not leave 
> it unset and let your custom engraver do the rest?

Yep, that's what I've done. Alas, I feel creating a new style would
have been more elegant.

>
> Besides, the snippet's numbering scheme seems oriented toward the volte in 
> general rather than the alternatives.  It isn't clearly a new kind of 
> alternative numbering.

Well, 'numbers is not that far from the default either.

Cheers,
  Harm

> —
> Dan
>

Strange behaviour with unknown alternativeNumberingStyle

[Thomas Morley]

Hi all,

please have a look at:

\version "2.25.0"

{
  \override Score.BarNumber.break-visibility = ##(#f #t #t)
%  \set Score.alternativeNumberingStyle = #'whatever
  b1
  \repeat volta 2 { c' c' }
  \alternative { d' e' }
  f'
}

As soon as the style-setting is uncommented it behaves like
  \set Score.alternativeNumberingStyle = #'number
shouldn't an unknown style behave like the default '()?

tl;dr
This probably prevents me defining a knew style with a custom engraver
as fix for lsr-snippet 1080 "Incrementing bar numbers in volta
repeats"
https://lsr.di.unimi.it/LSR/Item?id=1080

Cheers,
  Harm

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 17:54 Uhr schrieb Jean Abou Samra :
>
> Le 27/12/2022 à 17:44, Thomas Morley a écrit :
> > Here string-delete has one argument, a procedure.
>
>
> No; check the parentheses again.
>

I did, several times - before I got it:
My editor takes the parentheses in
   ((#\%)
as a commented parentheses, so it is not counted for bracket-matching :((

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 17:08 Uhr schrieb Jean Abou Samra :
>
> Le 27/12/2022 à 16:55, Thomas Morley a écrit :
> >
> > Lateron, when LSR runs 2.24.0, we need to insert all snippets from
> > /Documentation/snippets/new.
> > This is tedious, any help would be great.
>
>
> I hope it will be done by feeding LSR with the updated snippets in
> batch and not by editing them one by one... ?
>

As far as I know it needs indeed to be done one by one through the web interface


> > As final step we need to delete the ones from
> > /Documentation/snippets/new and commit the new state,
> > I would be very thankful if someone else could do so.
>
>
> This should be a matter of running makelsr.pl and removing
> all snippets from new/ present in stable/2.24, right?
>

Yep, though I very often (always) struggle when I need to run makelsr.pl ...


>
> > Out of curiosity and not related to lsr-update, do you have an example
> > of 2.22.-code (where Mark_engraver is moved) which would not run in
> > 2.24.?
>
>
>
>
> \version "2.22.2"
>
> \layout {
>\context {
>  \Score
>  \remove Mark_engraver
>}
>\context {
>  \Staff
>  \consists Mark_engraver
>}
> }
>
> <<
>\new Staff { \mark \default c'1 }
>\new Staff { c'1 }
>  >>
>
>
>
> 2.22 doesn't print a mark in the second staff, 2.24
> does. You have to move Mark_tracking_translator as
> well if you don't want it.

True, though it's still valid code for 2.24...
But I'll end the discussion on that specific topic now :)

>
>
> >> The latter (\tweak direction #DOWN) is shown in the official docs, maybe
> >> we can add a snippet just for it.
> > I still think it is usefull.
> >
> > Btw, the "obsolet"-additions are from you?
>
>
> Yup.
>
>
> > Do you think all of the snippets labelled this way should be deleted?
>
>
> Yes.
>
>
> > If so, I suggest to upfate them as well and delete them after lsr-update is 
> > done
>
>
> Not sure I understand, why should we update them first if it's to delete
> them immediately?
>

It's more a matter of timing (as long as we have 2.22-lsr they can
stay) and "forgetfulness" (updated snippets don't disturb, but
forgetting to delete them correctly would be bad).

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 17:11 Uhr schrieb Jean Abou Samra :
>
> Le 27/12/2022 à 17:06, Thomas Morley a écrit :
> >>>TODO guile message about `string-delete'
> >>>
> >>> adding-fingerings-or-string-numbers-or-stroke-fingerings-outside-of-the-music-code.ly
> >>
> >> Can be fixed by just inverting the arguments to string-delete.
> > Surprisingly not.
>
>
> ?

Obviously I don't understand:

>
> I took the snippet code and replaced
>

Here string-delete has two arguments. A string and a procedure.

>(string-delete s
>(lambda (c)
>  (case c
>((#\%)
>  (if (not (char=? prev-char #\nul))
> (set! delete? #t)))
>((#\newline)(set! delete? #f)))
>  (set! prev-char c)
>  delete?
>
>
> with
>

Here string-delete has one argument, a procedure.

>(string-delete
>(lambda (c)
>  (case c
>((#\%)
>  (if (not (char=? prev-char #\nul))
> (set! delete? #t)))
>((#\newline)(set! delete? #f)))
>  (set! prev-char c)
>  delete?)
>s)))

Am I wrong?

> After this, it compiles without warning in 2.24 and gives the same
> output (minus small spacing differences) as 2.22.

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 15:24 Uhr schrieb Jean Abou Samra :
>
> Le 27/12/2022 à 15:06, Thomas Morley a écrit :
> > Well, I started to update the snippets to 2.24.0 locally.
>
> Thank you for doing this.
>
> Do you intend to do them all, or do you need help?
>
>
> > Some observations:
> >
> > (1)
> > I'm stuck with three snippets:
> > a) clip-systems.ly It's tagged "doc"
> > I've no clue how we get it into Snippets, though the image there is
> > wrong (compared with lsr).
> > For me it looks like the emitted .eps-files are replaced by .pdf-files
> > and then the snippet crashes.
> > How to fix?
> > b) incrementing-bar-numbers-in-volta-repeats.ly
> > Needs a complete rewrite!?
>
> > c) inserting-bar-lines-everywhere.ly
> > `barAlways' is gone, but the proposed replacement
> > `forbidBreakBetweenBarLines' does not what the snippet deserves.
>
>
> I propose to just delete this snippet, and maybe replace
> it with a snippet showing how to use forbidBreakBetweenBarLines.
>
> I don't see what the use case for barAlways and defaultBarType != ""
> could be (although it would still be possible with a Scheme engraver).
>
>
> > (2)
> > convert-ly emits a plethora of "not smart enough" messages for
> > \consists Mark_engraver
> > But why?
> > It's not outdated code!!
> > It's going on my nerves. I don't think we should use convert-ly to
> > educate our users to use the new possibilties, that's the duty of the
> > documentation.
> > And there are still cases where \remove/consists Mark_engraver is what
> > the user wants, but these messages will persists forever.
> > I vote for simply deleting that convert-rule.
>
>
>
> Disagreed. \consists Mark_engraver needs conversion in *some* cases.
> The convert-ly rule is not advertising new possibilities, it's warning
> about a potential needed update to get the same output as before.
>
> The messages will not "persist forever" since convert-ly will
> update the \version statement and the rule will not run afterwards.
> (OK, LSR snippets don't have a \version line, but you'd run
> convert-ly from the latest stable.)
>
>
> > (3)
> > It's not possible to do
> > lilypond *.ly
> > on all snippets.
> > Somewhere there's a bleed over, causing multiple
> > warnings/errors/crashes on otherwise clean compilimg snippets, when
> > compiled separately.
> > Worth researching I'd say, too tired right now though.
>
>
>
> I think this is a lost cause. There is a lot of hacky Scheme code
> in snippets and I think quite a few are not protected against
> bleedover.
>
>
>
> > (4)
> > Here a list what I did else:
> >
> >   [fixed manually]
> >   adding-articulation-marks-using-scheme-simple.ly
> >   adding-or-modifying-script-articulations.ly
> >   ancient-accidentals.ly
> >   
> > automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly
> >   
> > compare-and-adjust-parts-with-different-volta-settings-to-create-a-score.ly
> >   coloured-boxes-around---behind-notes.ly
> >   displaying-bar-numbers-on-a-separate-staff.ly
> >   extracting-text-from-markup.ly
> >   
> > how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2-[obsolete-in-2.23].ly
> >   REMARK: Above is *not* obsolet
>
>
> In the snippet file, you write:
>
> "I don't think the snippet is obsolet, because we don't have a snippet
> explaining
> how to print above *and* below"
>
> Isn't it obvious once you know how to add a text mark above
> and how to add a text mark below?
>
> The latter (\tweak direction #DOWN) is shown in the official docs, maybe
> we can add a snippet just for it.
>
>
>
> >   modifying-the-ottava-spanner-slope.ly
> >   REMARK: Above will be replaced by the one from
> > /Doceumentation/snippets/new anyway
> >   ottava-text-on-the-right.ly
> >   positioning-two-opposite--fermata-signs-over-the-last-bar-line.ly
> >   printing-marks-on-every-staff.ly
> >   squeeze-and-split-staff.ly
> >   using-a-percent-repeat-with-plainchant.ly
> >   using-marklines-in-a-frenched-score.ly
> >   using-tags-to-produce-mensural-and-modern-music-from-the-same-source.ly
> >   vertical-aligned-staffgroups-without-connecting-systemstartbar.ly
> >   REMARK: Above will be replaced by the one from
> > /Doceumentation/snippets/new anyway
> >
> >   [fixed manually inside LSR]
> >   coloring-staves.ly
> >   extended-position-fingering-for-string-instruments.ly
> >   TOD

Re: LSR update?

[Thomas Morley]

Am Di., 27. Dez. 2022 um 15:24 Uhr schrieb Jean Abou Samra :
>
> Le 27/12/2022 à 15:06, Thomas Morley a écrit :
> > Well, I started to update the snippets to 2.24.0 locally.
>
> Thank you for doing this.
>
> Do you intend to do them all, or do you need help?

I'd volunteer to update all lsr-snippets, though I surely need some help.
Especially for the snippets in (1) a) b) c)

Your comments below are already helpful.

Lateron, when LSR runs 2.24.0, we need to insert all snippets from
/Documentation/snippets/new.
This is tedious, any help would be great.

As final step we need to delete the ones from
/Documentation/snippets/new and commit the new state,
I would be very thankful if someone else could do so.

>
>
> > Some observations:
> >
> > (1)
> > I'm stuck with three snippets:
> > a) clip-systems.ly It's tagged "doc"
> > I've no clue how we get it into Snippets, though the image there is
> > wrong (compared with lsr).
> > For me it looks like the emitted .eps-files are replaced by .pdf-files
> > and then the snippet crashes.
> > How to fix?
> > b) incrementing-bar-numbers-in-volta-repeats.ly
> > Needs a complete rewrite!?
>
> > c) inserting-bar-lines-everywhere.ly
> > `barAlways' is gone, but the proposed replacement
> > `forbidBreakBetweenBarLines' does not what the snippet deserves.
>
>
> I propose to just delete this snippet, and maybe replace
> it with a snippet showing how to use forbidBreakBetweenBarLines.
>
> I don't see what the use case for barAlways and defaultBarType != ""
> could be (although it would still be possible with a Scheme engraver).

Ok, for now I let it in, though.
Hopefully we not forget to delete/replace it...

>
> > (2)
> > convert-ly emits a plethora of "not smart enough" messages for
> > \consists Mark_engraver
> > But why?
> > It's not outdated code!!
> > It's going on my nerves. I don't think we should use convert-ly to
> > educate our users to use the new possibilties, that's the duty of the
> > documentation.
> > And there are still cases where \remove/consists Mark_engraver is what
> > the user wants, but these messages will persists forever.
> > I vote for simply deleting that convert-rule.
>
>
>
> Disagreed. \consists Mark_engraver needs conversion in *some* cases.

Out of curiosity and not related to lsr-update, do you have an example
of 2.22.-code (where Mark_engraver is moved) which would not run in
2.24.?

> The convert-ly rule is not advertising new possibilities, it's warning
> about a potential needed update to get the same output as before.
>
> The messages will not "persist forever" since convert-ly will
> update the \version statement and the rule will not run afterwards.
> (OK, LSR snippets don't have a \version line, but you'd run
> convert-ly from the latest stable.)

Well, ok.

>
> > (3)
> > It's not possible to do
> > lilypond *.ly
> > on all snippets.
> > Somewhere there's a bleed over, causing multiple
> > warnings/errors/crashes on otherwise clean compilimg snippets, when
> > compiled separately.
> > Worth researching I'd say, too tired right now though.
>
>
>
> I think this is a lost cause. There is a lot of hacky Scheme code
> in snippets and I think quite a few are not protected against
> bleedover.

Once I have much time, I may give it a try. Not that I'd know when
"much time" will happen...

> > (4)
> > Here a list what I did else:
> >
> >   [fixed manually]
> >   adding-articulation-marks-using-scheme-simple.ly
> >   adding-or-modifying-script-articulations.ly
> >   ancient-accidentals.ly
> >   
> > automatically-changing-the-stem-direction-of-the-middle-note-based-on-the-melody.ly
> >   
> > compare-and-adjust-parts-with-different-volta-settings-to-create-a-score.ly
> >   coloured-boxes-around---behind-notes.ly
> >   displaying-bar-numbers-on-a-separate-staff.ly
> >   extracting-text-from-markup.ly
> >   
> > how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2-[obsolete-in-2.23].ly
> >   REMARK: Above is *not* obsolet
>
>
> In the snippet file, you write:
>
> "I don't think the snippet is obsolet, because we don't have a snippet
> explaining
> how to print above *and* below"
>
> Isn't it obvious once you know how to add a text mark above
> and how to add a text mark below?
>
> The latter (\tweak direction #DOWN) is shown in the official docs, maybe
> we can add a snippet just for it.

I still think it is usefull.

Btw, the "obsolet"-additions are from you?
Do you think all of the snippets labelled this way

Re: Issue with deep-copy/map-some-music a tuplet

[Thomas Morley]

Am So., 25. Dez. 2022 um 18:18 Uhr schrieb Jean Abou Samra :
>
>
>
> > Le 25 déc. 2022 à 18:08, Paolo Prete  a écrit :
> >
> > 
> > Hello Jean,
> >
> > I just verified that 2.25 doesn't accept a tuplet of skips ( i.e:  \tuplet 
> > 3/2 {  s s s }, while all the previous versions do.
> > Is this really intended?
>
>
> No, as I wrote on a comment in the issue. It was not an intended effect of my 
> change.

Hi Jean,

sounds like you know already what's the problem?
Otherwise I'd offer to bisect (probably tomorrow).

Cheers,
  Harm

Re: Issue with deep-copy/map-some-music a tuplet

[Thomas Morley]

Hi Paolo,

the culprit is a non-breakable space character.
Delete it.

Am Sa., 24. Dez. 2022 um 20:20 Uhr schrieb Paolo Prete :
>
> Hello,
>
> I just noticed an inconsistent behavior with 2.25.0. The snippet below
> doesn't compile; I don't know if there is a hidden problem inside it, but
> it worked for all the versions prior to 2.25:

Nope, on my machine it failed for all versions.

>
> %---
>
> test = #(define-music-function (parser location music) (ly:music?)
> (let
>   ((musiccpy '()))
>   (begin
>
> (set! musiccpy (ly:music-deep-copy music))
>
> (map-some-music (lambda (evt)
>   (let ((nameUp (ly:music-property evt 'name)))
> (cond
>   ((eq? nameUp 'NoteEvent)
>   (set! evt '())
> evt)
>   (else #f))
> ))
> musiccpy)
>
>  );; Here, right before the bracket
> #{ $musiccpy #}))
>
> {
>   \test { \tuplet 3/2 { e'8 s  s } }
> }
>
> %---
>
> Some observations:
>
> 1) the snippet compiles if the tuplet is removed
> 2) the snippet compiles if map-some-music is don on $music, instead of
> $musiccpy

Can't confirm, see above.

>
> I don't know if it's a bug, but in any case, is there a way/workaround to
> fix it while preserving both ly:music-deep-copy and the tuplet?
>
> Thanks and Merry Christmas!
>
> Paolo

Cheers,
  Harm

P.S.
I take the code as a stripped down version of something larger, thus I
don't comment on the coding itself

Re: markup->string

[Thomas Morley]

Am So., 13. Nov. 2022 um 16:30 Uhr schrieb Jean Abou Samra :
>
>
>
> > Le 13 nov. 2022 à 16:22, Thomas Morley  a écrit :
> >
> > Nevertheless, _if_ the old code is just (markup->string
> > ), would it be possible to leave it untouched while
> > running convert-ly? After all it continues to work with 2.23. in this
> > simple manor, only inserting a more complex expression, if the old
> > code already has an optional argument?
> > Can't check myself, my python is as non-existent as my C++ ...
>
>
> How do you know if the old code does not use the optional argument? It could 
> be any Scheme expression, or even a #{ … #} expression. Scheme has more 
> syntax than one might think: there could be ; or #! or #| comments and all 
> sorts of things.
>
> One could special-case (markup->string ), catching a subset of those 
> cases. I’m not bothered by the current replacement, but would that make you 
> happier? In any case, we can’t reliably detect all cases of markup->string 
> applies to one argument only.
>
> Jean

Well, I have to admit I can't follow.
In my understanding the old markup->string has one or more arguments,
the first must be of type markup.
Obviously my understanding is not entirely correct.

Nevertheless the insertion done by convert-ly is not nice, imho. As a
mere user I'd think some bug happened.

Would it be feasable to do a type-checking for `headers' in
`headers-property-alist-chain'?
At least one could eliminate the (if ...) in the convert-rule.

Something at the lines of:

(define-public (headers-property-alist-chain headers)
  "Take a list of @code{\\header} blocks (Guile modules).  Return an
alist chain containing all of their bindings where the names have been
prefixed with @code{header:}.  This alist chain is suitable for
interpreting a markup in the context of these headers."
  (map
   (lambda (module)
 (map
  (lambda (entry)
(cons
 (string->symbol
  (string-append "header:"
 (symbol->string (car entry
 (cdr entry)))
  (ly:module->alist module)))
   (or headers '(
^
Or if this to bold/optimistic:
(if (list? headers) headers '())

Cheers,
  Harm

Re: markup->string

[Thomas Morley]

Am So., 13. Nov. 2022 um 15:43 Uhr schrieb Jean Abou Samra :
>
> Le 13/11/2022 à 14:41, Thomas Morley a écrit :
> > Hi,
> >
> > please consider below (originally for 2.20. _not_ converted):
> >
> > \version "2.23.80"
> >
> > \header {
> >myTitle = "myTitle"
> >myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
> >title = $(markup->string myOtherTitle)
> > }
> >
> > \markup { "TEST" }
> >
> > A title is not printed.
> > Though, I'm at loss, am I doing something wrongly or is it a bug
> > (\fromproperty has an `as-string'-setting) or _should_ it not work?
>
>
>
>
> This is working as expected. \fromproperty is not different from
> other markup commands. If you try #(display myOtherTitle), you will
> see that myTitle has not been replaced with its value at the time of
> creation of the markup. It is only when the markup is interpreted
> that the definition of the \fromproperty command looks up
> the value of myTitle, and it does so in the props argument
> passed to interpret-markup in the call (interpret-markup layout props mkup).
> When the \header title is implicitly interpreted by LilyPond,
> this is done with a props argument reflecting the header fields,
> as you can see from
>
> \version "2.23.80"
>
> \header {
>foo = "foo value"
>bar = "bar value"
>title = \markup $(markup-lambda (layout props) ()
>   ((@ (ice-9 pretty-print) pretty-print) props)
>   empty-stencil)
> }
>
> \markup Test
>
>
> The way you are calling markup->string, it does not have this information
> at hand. You need to provide it with
>
>
> \version "2.23.80"
>
> \header {
>myTitle = "myTitle"
>myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
>title = $(markup->string myOtherTitle #:props
> (headers-property-alist-chain (list (current-module
> }
>
> \markup { "TEST" }
>
>
>
> > tl;dr
> > In a private mail the user wondered why running convert-ly over old
> > code containing `markup->string' results in such a complex insertion:
> > 2.20.0 code:
> > title = $(markup->string myOtherTitle)
> > becomes with 2.23.80:
> > title = $(
> > (lambda* (m #:optional headers)
> >(if headers
> >(markup->string m #:props (headers-property-alist-chain headers))
> >(markup->string m)))
> >   myOtherTitle)
> >
> > Alas, it doesn't work with the initial code above, still no title.
> >
> > Thus, if it does not work either way, do we need the complex result of
> > convert-ly at all?
>
>
>
>
> But your example code
>
> \header {
>myTitle = "myTitle"
>myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
>title = $(markup->string myOtherTitle)
> }
>
> \markup { "TEST" }
>
>
> did not work originally in 2.20, did it? I can't test that version on
> my machine (Pango throws an assertion error), but I confirm that in
> 2.22 it does not work. That is as expected, for exactly the same
> reason as above. It does work with
>
> \version "2.22.2"
>
> \header {
>myTitle = "myTitle"
>myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
>title = $(markup->string myOtherTitle (list (current-module)))
> }
>
> \markup { "TEST" }
>
>
>
> In 2.22, the second optional argument to markup->string was a list
> of header modules. In 2.23, there are two optional keyword arguments,
> #:layout and #:props, and the equivalent of the previous headers
> argument is achieved using headers-property-alist-chain for #:props.
> The convert-ly replacement is a way to cater for that change of
> signature. Admittedly, it is a bit complex, but the alternative would have
> been a NOT_SMART, and I'm not sure that would have been better...
>
> Jean
>
>

Thanks for your detailed explanations.

Nevertheless, _if_ the old code is just (markup->string
), would it be possible to leave it untouched while
running convert-ly? After all it continues to work with 2.23. in this
simple manor, only inserting a more complex expression, if the old
code already has an optional argument?
Can't check myself, my python is as non-existent as my C++ ...

Cheers,
  Harm

markup->string

[Thomas Morley]

Hi,

please consider below (originally for 2.20. _not_ converted):

\version "2.23.80"

\header {
  myTitle = "myTitle"
  myOtherTitle = \markup { \italic \fromproperty #'header:myTitle }
  title = $(markup->string myOtherTitle)
}

\markup { "TEST" }

A title is not printed.
Though, I'm at loss, am I doing something wrongly or is it a bug
(\fromproperty has an `as-string'-setting) or _should_ it not work?

tl;dr
In a private mail the user wondered why running convert-ly over old
code containing `markup->string' results in such a complex insertion:
2.20.0 code:
title = $(markup->string myOtherTitle)
becomes with 2.23.80:
title = $(
(lambda* (m #:optional headers)
  (if headers
  (markup->string m #:props (headers-property-alist-chain headers))
  (markup->string m)))
 myOtherTitle)

Alas, it doesn't work with the initial code above, still no title.

Thus, if it does not work either way, do we need the complex result of
convert-ly at all?


Thanks,
  Harm

Re: procedure to check equality of list-elements

[Thomas Morley]

Am So., 6. Nov. 2022 um 13:39 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 06/11/2022 à 13:27, Thomas Morley a écrit :
> > Ofcourse not, though you need to know that the chosen proc is suitable
> > for the task.
> > For me eqv? was always meant to work with exactly two values, like cons.
> > But (apply cons '(1 2 3)) fails ofcourse.
> >
> > In the past I searched the guile-manual and our own lilbrary to get a
> > procedure testing equality of list-elements. To no avail. So I ended
> > up defining some custom-recursion...
> > Having a named (and documented) procedure would probably have helped.
>
>
> To me that sounds more like you should submit a doc patch to Guile
> so that the Guile doc doesn't say eqv? et al. apply to two elements
> only.
>
>

For the record, patch at
https://lists.gnu.org/archive/html/guile-devel/2022-11/msg8.html
Jean's improvements in the follow up.

Thanks Jean again,
  Harm

Re: procedure to check equality of list-elements

[Thomas Morley]

Am So., 6. Nov. 2022 um 13:39 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 06/11/2022 à 13:27, Thomas Morley a écrit :
> > Ofcourse not, though you need to know that the chosen proc is suitable
> > for the task.
> > For me eqv? was always meant to work with exactly two values, like cons.
> > But (apply cons '(1 2 3)) fails ofcourse.
> >
> > In the past I searched the guile-manual and our own lilbrary to get a
> > procedure testing equality of list-elements. To no avail. So I ended
> > up defining some custom-recursion...
> > Having a named (and documented) procedure would probably have helped.
>
>
> To me that sounds more like you should submit a doc patch to Guile
> so that the Guile doc doesn't say eqv? et al. apply to two elements
> only.
>
>
Currently the only hint one can get is: doing in a guile-prompt:

scheme@(guile-user)> +
$1 = #
scheme@(guile-user)> eq?
$2 = #
scheme@(guile-user)>

Now one could imagine eq? could be used on more than two values, like +.
Though, I'd say one need to know it already, before one gets the idea
to enter it in a prompt...

Thanks,
  Harm

Re: procedure to check equality of list-elements

[Thomas Morley]

Am So., 6. Nov. 2022 um 13:07 Uhr schrieb Jean Abou Samra :
>
> Le 06/11/2022 à 13:03, Thomas Morley a écrit :
> > Hi,
> >
> > in !1701 `ly:beam::calc-knee' checks whether all list-elements are equal.
> > Basically doing (apply eqv? ).
> > Tbh, I don't understand why it works...
>
>
> eqv? has no problem working on more than two elements.
>
> scheme@(guile-user)> (eqv? 1 1)
> $1 = #t
> scheme@(guile-user)> (eqv? 1 2)
> $2 = #f
> scheme@(guile-user)> (eqv? 1 1 1)
> $3 = #t
> scheme@(guile-user)> (eqv? 1 1 2)
> $4 = #f
> scheme@(guile-user)> (eqv? 1 1 1 1)
> $5 = #t
> scheme@(guile-user)> (eqv? 1 2 3 4)
> $6 = #f
> scheme@(guile-user)> (eqv?)
> $7 = #t
>

Call me surprised.
The guile manual only gives code-examples comparing _two_ values with
eq? and friends.
I didn't know and didn't imagine it would work for more arguments as
you wrote above.

>
>
> This is similar to how in other languages you have to
> repeat the + operator (a+b+c+d) whereas in Scheme you
> can do (+ a b c d).
>
>
>
> > Though, the need to check a list for all list-elements are equal
> > happened to me not only once.
> > Thus, would it be acceptable to add something like:
> >
> > (define* (equal-list-elts? list #:optional (proc eq?))
> >(apply proc list))
> >
> > to lily-library.scm?
>
>
>
> What would be the point? Do you dislike (apply proc lst)?
>
Ofcourse not, though you need to know that the chosen proc is suitable
for the task.
For me eqv? was always meant to work with exactly two values, like cons.
But (apply cons '(1 2 3)) fails ofcourse.

In the past I searched the guile-manual and our own lilbrary to get a
procedure testing equality of list-elements. To no avail. So I ended
up defining some custom-recursion...
Having a named (and documented) procedure would probably have helped.

Cheers,
  Harm

procedure to check equality of list-elements

[Thomas Morley]

Hi,

in !1701 `ly:beam::calc-knee' checks whether all list-elements are equal.
Basically doing (apply eqv? ).
Tbh, I don't understand why it works...
Though, the need to check a list for all list-elements are equal
happened to me not only once.
Thus, would it be acceptable to add something like:

(define* (equal-list-elts? list #:optional (proc eq?))
  (apply proc list))

to lily-library.scm?

Cheers,
  Harm

Re: Potential LSR licensing violations

[Thomas Morley]

Am Do., 20. Okt. 2022 um 21:30 Uhr schrieb Han-Wen Nienhuys :
>
> On Thu, Oct 20, 2022 at 2:34 AM Jean Abou Samra  wrote:
> > So far, so good. However, take this snippet:
> >
> > https://lsr.di.unimi.it/LSR/Item?id=102
> >
> > It begins with 300 lines of code that used to be in the LilyPond
> > repository, released under the GPL, before they were considered
> > legacy and moved to a snippet. I am pretty sure this violates
> > the GPL. 300 lines looks too much for fair use law to apply,
> > doesn't it?
>
> Why not ask Jan who wrote the chords snippet if is he OK to relicense
> the snippet as public domain? (or, maybe he already did this when the
> snippet was submitted)
>
> --
> Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
>

Yep, though pretty often the author of a snippet is not known to the
LSR editor...

Cheers,
  Harm

Re: Potential LSR licensing violations

[Thomas Morley]

Am Do., 20. Okt. 2022 um 02:34 Uhr schrieb Jean Abou Samra :

> I figured that now I am an LSR editor, I had to learn about what
> legal responsibility I have when accepting contributions.

Well, I think the work of an LSR editor is roughly described in CG 7. LSR work.
Afaict, license issues are not mentioned.

Apart from obvious cases [*] I don't think it's my duty as an LSR
editor to think about the problem at all.
More: discussions about license issues inevitably causes headache to me.
If we extend the duties of LSR editors in that way, i'll immediately
step down from that role.

Sorry,
  Harm

[*] I hope copyright with https://lsr.di.unimi.it/LSR/Item?id=1005 is
sufficently solved. See discussions:
https://lists.gnu.org/archive/html/bug-lilypond/2016-04/msg4.html
and finally:
https://lists.gnu.org/archive/html/bug-lilypond/2020-03/msg00060.html

Re: Potential LSR licensing violations

[Thomas Morley]

Am Do., 20. Okt. 2022 um 07:23 Uhr schrieb Werner LEMBERG :

> > So far, so good. However, take this snippet:
> >
> > https://lsr.di.unimi.it/LSR/Item?id=102
> >
> > It begins with 300 lines of code that used to be in the LilyPond
> > repository, released under the GPL, before they were considered
> > legacy and moved to a snippet.  I am pretty sure this violates the
> > GPL.  300 lines looks too much for fair use law to apply, doesn't
> > it?
>
> Assuming that it is ok with , we can put his
> outdated, GPLed code into the public domain.  Harm, do you remember
> the history of this snippet?

Sorry, I don't remember,

Cheers,
  Harm

Re: weird error engraving two files with 2.23.14

[Thomas Morley]

Am Do., 13. Okt. 2022 um 14:08 Uhr schrieb Thomas Morley
:
>
> Am Do., 13. Okt. 2022 um 01:09 Uhr schrieb Federico Bruni 
> :

> > These two files are copyrighted and I can't share them here, but I will
> > send privately to anyone interested in debugging this issue.
>
> Hi  Federico,
>
> I'd offer to have a look.
>
> Cheers,
>   Harm

Thanks for the files.
The culprit seems to be:

tuningOpenBb =
\markup {
  \with-dimensions #'(0 . 0.8) #'(0 . 1.0)
  \postscript "/Arial-Bold findfont
1.3 scalefont
setfont -0.5 3.6 moveto
(D) show -0.5 2.0 moveto
(C) show -0.5 0.6 moveto
(F) show -0.5 -0.8 moveto
(D) show -0.5 -2.2 moveto
(Bb) show -0.5 -3.6 moveto
(F) show
stroke"
}

It is no longer possible to specify fonts like above.
https://lists.gnu.org/archive/html/lilypond-devel/2022-04/msg00018.html

I suggest to do instead:

tuningOpenBb =
\markup {
  \fontsize #-4
  \override #'(baseline-skip . 1.5)
  \column \override #'(font-name . "Arial Bold") {
  D C F D Bb F
  }
}

HTH,
  Harm

Re: weird error engraving two files with 2.23.14

[Thomas Morley]

Am Do., 13. Okt. 2022 um 01:09 Uhr schrieb Federico Bruni :
>
> Hi folks
>
> I've recently used convert-ly to update my private music sheet library
> and test version 2.23.14 (official binaries).
> Two files are failing with the same error message:
>
> Drawing systems...
> Converting to `foo.pdf'...
> warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH
> -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-9384021)'
> failed (256)
>
> /var/home/fede/.local/lilypond/lilypond-2.23.14/share/lilypond/2.23.14/ly/init.ly:65:2:
> error: Guile signaled an error for the expression beginning here
> #
>  (let ((book-handler (if (defined? 'default-toplevel-book-handler)
> Throw to key `ly-file-failed' with args `()'.
>
>
> Any idea about the cause? I'm using a different font for tablature
> numbers, but commenting that line still triggers this error.
> These two files are copyrighted and I can't share them here, but I will
> send privately to anyone interested in debugging this issue.

Hi  Federico,

I'd offer to have a look.

Cheers,
  Harm

>
> Thanks
> Federico
>
> PS
> Here's the --verbose log:
>
> GPL Ghostscript 9.56.1 (2022-04-04)
> Copyright (C) 2022 Artifex Software, Inc. All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO
> WARRANTY:
> see the file COPYING for details.
> Querying operating system for font files...
> Can't find (or can't open) font file %rom%Resource/Font/%rom%Resou.
> Can't find (or can't open) font file Arial-Bold.
> Didn't find this font on the system!
> Substituting font Helvetica-Bold for Arial-Bold.
> Can't find (or can't open) font file %rom%Resource/Font/%rom%Resource/F.
> Can't find (or can't open) font file NimbusSans-Bold.
> Can't find (or can't open) font file %rom%Resource/Font/%rom%Resource/F.
> Can't find (or can't open) font file NimbusSans-Bold.
> Didn't find this font on the system!
> Unable to substitute for font.
> Error: /invalidfont in findfont
> Operand stack:
>Arial-Bold
> Execution stack:
>%interp_exit .runexec2 --nostringval-- .findfontop --nostringval-- 2
> %stopped_push --nostringval-- .findfontop .findfontop false 1
> %stopped_push 1974 1 3 %oparray_pop 1973 1 3 %oparray_pop 1961 1 3
> %oparray_pop 1817 1 3 %oparray_pop --nostringval-- %errorexec_pop
> .runexec2 --nostringval-- .findfontop --nostringval-- 2 %stopped_push
> --nostringval-- 1974 1 3 %oparray_pop 1973 1 3 %oparray_pop 1961 1 3
> %oparray_pop 1817 1 3 %oparray_pop --nostringval-- %errorexec_pop
> .runexec2 --nostringval-- .findfontop --nostringval-- 2 %stopped_push
> --nostringval-- 1909 1 3 %oparray_pop
> Dictionary stack:
>--dict:761/1123(ro)(G)-- --dict:0/20(G)-- --dict:115/200(L)--
> Current allocation mode is local
> Last OS error: Permission denied
> Current file position is 915685
> GPL Ghostscript 9.56.1: Unrecoverable error, exit code 1
> warning: `(gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH
> -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-2513976)'
> failed (256)
>
> /var/home/fede/.local/lilypond/lilypond-2.23.14/share/lilypond/2.23.14/ly/init.ly:65:2:
> error: Guile signaled an error for the expression beginning here
> #
>  (let ((book-handler (if (defined? 'default-toplevel-book-handler)
>   14 #
> In
> /home/lily/lilypond-2.23.14/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm:
>876:16 13 (lilypond-main _)
> 905:4 12 (lilypond-all _)
> In srfi/srfi-1.scm:
> 640:9 11 (for-each # ?)
> In
> /home/lily/lilypond-2.23.14/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm:
> 915:9 10 (_ _)
> In ice-9/boot-9.scm:
> 829:9 9 (catch _ _ # ?)
> In unknown file:
>8 (ly:parse-file "Close-to-Heaven.ly")
>7 (apply-smob/1 #)
>6 (ly:book-process # #< Output_def> #< Output_def> #)
> In
> /home/lily/lilypond-2.23.14/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/backend-library.scm:
> 319:4 5 (postprocess-output #< Output_def> # ?)
> In srfi/srfi-1.scm:
> 640:9 4 (for-each # ?)
> In
> /home/lily/lilypond-2.23.14/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/backend-library.scm:
> 139:4 3 (postscript->pdf _ _ _ _ #f)
>  57:4 2 (ly:gs-cli _ _)
> In ice-9/boot-9.scm:
>751:25 1 (dispatch-exception 0 ly-file-failed ())
> In unknown file:
>0 (apply-smob/1 # #)
> Throw to key `ly-file-failed' with args `()'.
>
>
>
>

Re: Duration lines and dots

[Thomas Morley]

Am Mo., 10. Okt. 2022 um 00:27 Uhr schrieb Jean Abou Samra :
>
> Harm,
>
> On the lilypond-user-fr list, there is a user wondering about this:
>
> \version "2.23.14"
>
> \new Voice \with {
>\consists Duration_line_engraver
>% \override DurationLine.bound-details.left.start-at-dot = ##t
> }
> { d'4.\- 8 }
>
>
> As you can see, the duration line crosses the dot. It does
> not if the override is outcommented. That override is explicitly
> catered for in the duration line code though, making me think
> that you didn't enable it by default on purpose. What is
> your opinion about this? What should the default be? Moving
> the dot up to avoid the duration line?
>
> Jean
>

The main porpose for duration lines is graphical notation as shown in
NR 2.8.3 Graphical notation.
I.e. no stems, flags, beams, dots and the NoteHead is always a filled
black one (duration-log = 2).
The duration line always starts inside the note head.
Though the user should be able to use something like d'4. (and omit
the dots), although it would be prferable to use d'4*3/2.
Thus the default for left.start-at-dot is #f.

Nevertheless, there are cases where this fundamental approach is mixed
with elements of traditional notations.
Then it's up to the user to specify what he wants: beams, flags, dots,
stems, note heads...
I tried to cater for these cases as well.

So far my thought while implementing DurationLine.
Though, I'm open for other thoughts.

Cheers,
  Harm

Re: Tablature full notation rests and tablature aethstetic improvements

[Thomas Morley]

Hi,

Am Fr., 7. Okt. 2022 um 07:44 Uhr schrieb tk5wbps2--- via Discussions
on LilyPond development :
>
> I'm considering contributing to lilypond.
>
welcome to the pond
>
> The two features I propose are as follows.
>
> 1) An option to include rests in tablature (with \tabFullNotation).
>
Afaict, this the default with \tabFullNotation. See the output of:

\new TabStaff \with { \tabFullNotation }
\new TabVoice {
  <<
{ r8 r r r }
\\
{ r4 r }
  >>
  r2
  R1*2
  \compressEmptyMeasures
  R1*7
  R1*20
}
>
> 2) An alternative tablature full notation style that more closely resembles 
> standard notation note heads and stems.
>
Could you provide some images from printed editions?
>
> To my knowledge as of version 12.13.13
>
Most likely you mean 2.23.13. Though the default behaviour is much older.
>
lilypond engraves tablature numbers for half notes as having two stems
and half notes and whole notes without a circle. I propose an option
for lilypond to engrave tablature numbers for half notes or half-note
chords with a circle and a single stem instead of two stems. Whole
notes and whole-note chords would be circled without a stem. In the
case of multiple voices, the tablature numbers of each voice would be
circled in the group of notes that share a stem. For example, this
could be a set of voices that have half notes sharing a stem pointing
up and an eighth note with a stem pointing down. Numbers corresponding
to half notes would be circled together with an upward stem from the
edge of the circle, and the number corresponding to the eighth note
would not be circled or otherwise changed (except to avoid collision
with the circle, see below). If a voice has a half note with stem
pointing up and another voice has a half note with stem pointing down,
then the two numbers would be circled separately, one with an upward
stem starting at the edge of the first circle and another with a
downward stem starting at the edge of the second circle. In scores
I've seen with circled tablature numbers, collisions between numbers
and circles are avoided by shifting numbers out of a straight vertical
column, which I suspect is quite different than how tablature is
currently handled internally and might require significant effort to
implement, but that's just a guess.
>
Here a quick and hacky mockup:
\new TabStaff \with {
\tabFullNotation
\revert Stem.stencil
\override TabNoteHead.layer = 200
\override TabNoteHead.stencil =
  #(grob-transformer 'stencil
(lambda (grob orig)
  (let* ((par-x (ly:grob-parent grob X))
 (nhds
   (if (grob::has-interface par-x 'note-column-interface)
   (ly:grob-object par-x 'note-heads #f)
   #f))
 (thickness 0.1)
 (padding 0.02))
(if (and nhds
 (eqv? (ly:grob-array-length nhds) 1)
 (< (ly:grob-property grob 'duration-log) 2))
(circle-stencil orig thickness padding)
orig

\override NoteColumn.stencil =
  #(lambda (grob)
(let ((nhds (ly:grob-object grob 'note-heads #f))
  (thickness 0.1)
  (padding 0.02))
  (if (and nhds (> (ly:grob-array-length nhds) 1))
  (let ((nhds-x-ext (ly:relative-group-extent nhds grob X))
(nhds-y-ext (ly:relative-group-extent nhds grob Y))
(stem (ly:grob-object grob 'stem)))
(if (< (ly:grob-property stem 'duration-log) 2)
(rounded-box-stencil
  (ly:make-stencil '() nhds-x-ext nhds-y-ext)
  thickness
  padding
  1)
'())
}

\new TabVoice {
  d1 d2 d4 d8 d16 r
  1
  << < gis b e' >2 \\ < e, b, e > >>

  << { g8 a b g } \\ g2 >>
  \mergeDifferentlyHeadedOn
  << { g8 a b g } \\ g2 >>
}

>
> Are either of these features fit for future lilypond?
>
Currently the discussion is about going for a new stable 2.24.
New features will be most likely implemented in 2.25. Though usually
the new stable and the following new devel-version are released at the
same time.
>
> Are either of these features currently present, and I've overlooked them? If 
> so, would you like me to contribute documentation?
>
Above mockup needs some love, if you like...
Once it is ready it should be documented ofcourse.
>
> I'm only familiar with a subset of C++ up to C++03. Would my lack of 
> knowledge of modern C++ exclude me from being a contributor? I'm also not an 
> expert on UB in C++, although I very much want to avoid it. Would that 
> exclude me from being a contributor?
>
As you've seen, it was all scheme-work not C++.
I don't know C++ myself. This excludes me from C++ work ofcourse, but
not from scheme-stuff, etc. Many parts in the source are done in
.scm-files.
So this is nothing excluding you from contribution.
>
> If the project is 

Re: Markup command \simple

[Thomas Morley]

Am So., 2. Okt. 2022 um 16:58 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 02/10/2022 à 15:05, David Kastrup a écrit :
> > If the function itself isn't used as a placeholder.
>
> I haven't found any such use.
>
> I've opened https://gitlab.com/lilypond/lilypond/-/merge_requests/1650
>

Meanwhile I removed all occurrencies of \simple and make-simple-markup form LSR.

Cheers,
  Harm

Re: LSR changes for \textMark/\textEndMark

[Thomas Morley]

Am Mi., 28. Sept. 2022 um 14:32 Uhr schrieb Jean Abou Samra
:
>
> Le 27/09/2022 à 22:07, Jean Abou Samra a écrit :
> > Le 27/09/2022 à 21:05, Thomas Morley a écrit :
> >> Hi Jean,
> >>
> >> will do.
> >> Is it urgent? I'll have not much time before weekend.
> >
> >
> > By the way, it would be great if I could submit the
> > edits myself to LSR, but I haven't found a way to do
> > so. Apparently, I can only submit new snippets.
>
>
>
>
> Upon suggestion from Harm, I have been made an LSR editor now,
> so I'll do the edits myself.
>
> Harm, when I remove the doc tag from a snippet, is there a
> convention for marking that it should be deleted when LSR
> is upgraded to 2.24?
>
> Thanks,
> Jean
>

There's no convention.
Though, some users will probably not have noticed 2.24.-possibilities
and still try to use those snippets.
Thus my suggestion:
For now I'd add [deprecated in 2.24.] to the title and tag it with
"legacy-code".
While moving LSR to 2.24. I'd change the snippets code using
2.24.-syntax/features.
And delete them after a while.

Cheers,
  Harm

Re: LSR changes for \textMark/\textEndMark

[Thomas Morley]

Am Di., 27. Sept. 2022 um 13:30 Uhr schrieb Jean Abou Samra
:
>
> Harm,
>
> As you can see from open MRs, I'm working on moving from \mark 
> to text marks in tests and documentation. Could you please apply the
> following changes in LSR?
>
> These snippets should have their doc tag removed because
> \textMark/\textEndMark
> address limitations that they show how to work around:
>
> - aligning-objects-created-with-the--mark-command, since \textMark and
>\textEndMark have a default alignment that should be the right thing
>in most cases (and !1641 adds a doc example on customizing the alignment
>anyway).
>
> - printing-marks-at-the-end-of-a-line.ly
>
> - creating-simultaneous-rehearsal-marks.ly
>
> -
> how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-{1,2}.ly
>
> These 5 snippets should eventually be removed from LSR when it's
> upgraded to 2.24.
>
> Also, these snippets don't actually need \mark , should be
> changed to use something else:
>
> - wind-headword.ly: replace
>
>\once \override Score.RehearsalMark.self-alignment-X = #-1
>\once \override Score.RehearsalMark.break-align-symbols =
> #'(time-signature)
>\once \override Score.TimeSignature.break-align-anchor-alignment
> = #LEFT
>\once \override Score.RehearsalMark.padding = #4
>\mark \markup \large \bold {Moderato assai}
>
>with just
>
>\tempo \markup \large "Moderato assai"
>
> - table-of-contents.ly: change \mark "A" to \mark \default.
>
>
> I'll take care of the rest by moving snippets to new/ and changing
> them to use \textMark/\textEndMark.
>
> Thanks!
>
> Jean
>

Hi Jean,

will do.
Is it urgent? I'll have not much time before weekend.

Cheers,
  Harm

Re: Moving most initialization to .scm files

[Thomas Morley]

Am Mo., 5. Sept. 2022 um 21:34 Uhr schrieb Jonas Hahnfeld :
>
> On Mon, 2022-09-05 at 21:22 +0200, Thomas Morley wrote:
> > Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via
> > Discussions on LilyPond development :
> > >
> > > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote:
> > > > This needs to be done for lots of code in lots of files, so it will be
> > > > quite a major change to the source even though it is just a 
> > > > straightforward
> > > > translation.
> > >
> > > I don't like this idea very much just two weeks before branching for a
> > > new stable release. No matter how "straightforward", I find the risk
> > > too high that something goes wrong, or that it turns out not to be a
> > > good idea for some other reason, or that we still find it insufficient
> > > and an entirely different solution is required...
> > >
> > > For me, this also means we should go without !1510 for the release.
> > > It's unfortunate, but not the end of the world; and I personally think
> > > it's worse to delay the entire release by weeks / months or even an
> > > undetermined amount of time.
> > >
> > > Jonas
> >
> > I think a stable release without meaningful error-messages as promised
> > by !1510 is unusable for power-users.
>
> So we've had this discussion before:

Indeed

> If I follow the logic, we must not
> have a stable release until the error messages are equally good /
> better than they have been before. This problem has been known for two
> years, with very little activity before Jean started working on it in
> May (?). What I want to avoid is blocking the release for two more
> years. (probably / hopefully exaggerating, but it *will* change the
> schedule)

Well, one could argue the current 2.23.12 without !1510 is as unusable
as a new stable without !1510
Thus no need to postpone 2.24.

For large scheme codings one can just go the route described above.
Maybe document/recommend it somewhere? Not sure, though...

Cheers,
  Harm

Re: Moving most initialization to .scm files

[Thomas Morley]

Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote:
> > This needs to be done for lots of code in lots of files, so it will be
> > quite a major change to the source even though it is just a straightforward
> > translation.
>
> I don't like this idea very much just two weeks before branching for a
> new stable release. No matter how "straightforward", I find the risk
> too high that something goes wrong, or that it turns out not to be a
> good idea for some other reason, or that we still find it insufficient
> and an entirely different solution is required...
>
> For me, this also means we should go without !1510 for the release.
> It's unfortunate, but not the end of the world; and I personally think
> it's worse to delay the entire release by weeks / months or even an
> undetermined amount of time.
>
> Jonas

I think a stable release without meaningful error-messages as promised
by !1510 is unusable for power-users.
While working on zither-ly[*], I was tempted to trash a few weeks of
coding work, because of shitty error messages, making it unpossible to
proceed...
Unless Jean pointed me to the possibility to port all (critical)
scheme-codings in ly-files to scm-files and use GUILE_AUTO_COMPILE=1
I would not have reached the current state without it.

I'm not sure it's the best way but currently it looks like the only one.

Cheers,
  Harm

[*] If someone is interested:
https://gitlab.com/Thomas_Morley/zither-ly/-/tree/development/

Re: Removing a snippet

[Thomas Morley]

Am So., 4. Sept. 2022 um 21:26 Uhr schrieb Dan Eble :
>
> Harm,
>
> The Contributor's Guide has sections on adding, editing, and renaming 
> snippets.  What should I do when I want to stop using a snippet in the 
> Notation Reference?

Well, short answer, adjust NR in
Documentation/*/notation/expressive.itely, and you're done.

Ofcourse the snippet remains in /Documentation/snippets/
If you want to completely remove it from the source, delete it there
and any occurrence in *.snippet-list.

To avoid reimplementing it with next lsr-import, ask a LSR-editor to
remove the doc-tag from it in LSR.

Shall I do so?

> The one I have in mind now is "Inserting a caesura", though there might have 
> been one in the past that I removed from the source without asking this 
> question.
>
> Thanks,
> —
> Dan
>

Cheers,
  Harm

Re: no links in PDFs with gs 9.56.1

[Thomas Morley]

Am So., 7. Aug. 2022 um 13:05 Uhr schrieb Werner LEMBERG :
>
>
> > If I build the docs I use 'extractpdfmark' as well. In the light of
> > this thread I tried ghostscript self-compiled from their most recent
> > master, giving me 9.57.0.  [...]
> >
> > [compilation time] is insane.
>
> I also noticed a slower documentation build with ghostscript's new PDF
> engine, but not as extreme.  Please file a GS bug report.  There is
> already
>
>   https://bugs.ghostscript.com/show_bug.cgi?id=705534
>
> but the reporter wasn't able to provide something useful, so I guess a
> new issue is best.
>
>
> Werner

Well, I don't feel being competent enough to file a bug report there,
at least as soon as it comes to 'how exactly do we invoke GS' and/or a
(minimal) example being able to reproduce the problem.

Sorry,
  Harm

Re: no links in PDFs with gs 9.56.1

[Thomas Morley]

Am Sa., 30. Juli 2022 um 12:39 Uhr schrieb Werner LEMBERG :
>
>
> >> In case you are forced to use 9.56.1, add `-dNEWPDF=false` to the
> >> gs command line options (in file `Documentation/GNUmakefile`) to
> >> make gs use the old PDF engine, which produces good results.
> >
> > So this is about the post-processing step with extractpdfmark + gs,
> > right?
>
> Yes – I always build the documentation with 'extractpdfmark'; maybe
> this gs bug doesn't show up otherwise.
>
>
> Werner

If I build the docs I use 'extractpdfmark' as well. In the light of
this thread I tried ghostscript self-compiled from their most recent
master, giving me 9.57.0.
Though, compile time is bad:
Always doing
time make LANGS='en' doc -j5 CPU_COUNT=5
I get for

Uncompiled guile

real111m56,272s
user190m51,445s
sys17m51,542s

Compiled guile

real98m43,545s
user162m33,293s
sys15m33,015s

This is insane. Tbh, I did not check whether pdf links are present but
directly downgraded to gs 9.55.0, with below timing values:

Uncompiled guile

real50m20,112s
user129m33,921s
sys17m42,618s

Compiled guile

real44m32,826s
user116m10,453s
sys17m1,201s


Better, but still bad, regarding the fact I compiled only the english docs.

Yes, I have a weak laptop...

No idea, if we can do anything to improve the situation.
Anyway, I thought I share my observations.

Cheers,
  Harm

Re: LSR snippet doesn’t appear

[Thomas Morley]

Am Di., 2. Aug. 2022 um 13:32 Uhr schrieb Jean Abou Samra :
>
>
>
> > Le 2 août 2022 à 13:28, Thomas Morley  a écrit :
> >
> > Am Di., 2. Aug. 2022 um 13:21 Uhr schrieb Jean Abou Samra 
> > :
> >>
> >> Some time ago, I entered a snippet entitled "Adding a QR code" in LSR, and 
> >> it appears in the snippet database (even without logging in), but a search 
> >> for "QR code" in the search bar yields no result. Am I doing something 
> >> wrong?
> >>
> >> Thanks,
> >> Jean
> >>
> >>
> >
> > Hi Jean,
> >
> > you did all fine.
> >
> > Tbh, I have seen it already.
> > Though, I wanted to have a closer look at it, couldn't find the time
> > for it til now.
>
>
> OK, so IIUC it’s pending approval from an LSR editor?

Yep, usually I try to understand the proposed snippet and/or muse over
it whether there may be room for improvements.
This may result in simply approving it or in a discussion with the author...

I'll move your snippet a bit up on my todo-list.

Cheers,
  Harm

>
>
> > Is it urgent?
>
>
> Not at all, I just wondered if I had done something wrong when submitting it.
>
> Thanks,
>
> Jean
>
>
>

Re: LSR snippet doesn’t appear

[Thomas Morley]

Am Di., 2. Aug. 2022 um 13:21 Uhr schrieb Jean Abou Samra :
>
> Some time ago, I entered a snippet entitled "Adding a QR code" in LSR, and it 
> appears in the snippet database (even without logging in), but a search for 
> "QR code" in the search bar yields no result. Am I doing something wrong?
>
> Thanks,
> Jean
>
>

Hi Jean,

you did all fine.

Tbh, I have seen it already.
Though, I wanted to have a closer look at it, couldn't find the time
for it til now.

Is it urgent?

Best,
  Harm

Re: Fixing regressions and serious issues

[Thomas Morley]

Am Mi., 20. Juli 2022 um 11:40 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> On Thu, 2022-07-14 at 17:38 +0200, Jean Abou Samra wrote:

> I agree, even though I'd like to note that only those marked ~Critical
> actually block the release. There are a number of ~Regression issues
> that have been there for 2.22.x or even 2.20.0. Whether we want to re-
> classify some of the more recent ones as ~Critical, is of course up for
> discussion. And fixing issues is obviously still a good idea 
>
> > [...]
> > * “Heisen-crashes on Windows with large scores”
> >
> >https://gitlab.com/lilypond/lilypond/-/issues/6361
> >
> >A nasty and poorly understood GC problem on Windows,
> >needs some tough debugging.
>
> This is currently the only issue marked ~Critical, and I agree this
> must be addressed before a stable release.

+1

> I hope I can come back to
> this in the next weeks.
>
> > * “GUILE 2.2 doesn't provide source locations”
> >
> >https://gitlab.com/lilypond/lilypond/-/issues/5992
> >
> >Needs figuring out if executing Scheme code with
> >`compile` is OK performance-wise and how to get
> >it to display source location info.
>
> I agree this is annoying, and it would be great to improve the
> situation. I'm not sure if this should block the release though.

I beg to differ.
For me it's the most pressing and annoying issue. A stable release
without good error messages is unusable for huge custom scheme
codings.
Granted, recently some workarounds were discussed on -user. Alas, I
can't imagine a stable version needing those workarounds right from
it's release date.
Even it does not crash lilypond, I'd label it Critical as well.

Cheers,
  Harm

Re: Nested segno and volta repeats

[Thomas Morley]

Am So., 29. Mai 2022 um 13:25 Uhr schrieb Luca Fascione :
>
> What do you mean Thomas? When the sheet clearly indicates DC al Fine (Da 
> Capo, from the beginning) why would it be normal to ignore such an explicit 
> direction?

Maybe I was not clear enough. For

||:  A:|| B||
  Fine  D.C. Al Fine

The "Fine" may be regarded as ambiguous.
By _convention_ above is played  A A B A and not A A B A A.
But a composer could be expizit in what he wants.
That's all I wanted to say, hope it's clearer now.

Cheers,
  Harm

>
> I wasn't aware of \repeat segno, neat thing, I've always had to do it by hand 
> with cadenza trickeries...
>
> L
>
> On Sun, 29 May 2022, 10:45 Thomas Morley,  wrote:
>>
>> Am So., 29. Mai 2022 um 09:56 Uhr schrieb Jean Abou Samra 
>> :
>> >
>> > Hi Dan,
>> >
>> > Is there any way to get this repeat structure with the recent
>> > repeat additions? This is from a question on the user list.
>> >
>> > ||:  A:|| B||
>> >   Fine  D.C. Al Fine
>> >
>> > -> A A B A
>>
>> From a musicians point of view:
>> I've learned not to repeat the final A here, though as a rule of thumb(!).
>> A composer could be expilzit by adding "con/senza repetizione"
>>
>> Afaict, "senza repetizione" is not supported by now.
>>
>> Cheers,
>>   Harm
>> >
>> >
>> > My first thought was to do
>> >
>> > \version "2.23.10"
>> >
>> > m =
>> > \repeat segno 2 {
>> >\repeat volta 2 {
>> >  a'1
>> >}
>> >\volta 2 \fine
>> >b'1
>> > }
>> >
>> > { \m }
>> > { \unfoldRepeats \m }
>> >
>> >
>> > That works about fine, except that the resulting
>> > structure with \unfoldRepeats is A A B A A and
>> > not A A B A. What I need seems to be a kind of
>> > \volta 2 \fine within the inner \repeat volta
>> > that would apply \volta with the outer \repeat
>> > segno. Did miss something like that? Should
>> > it be registered as a feature request?
>> >
>> > Best,
>> > Jean
>> >
>> >
>>

Re: Nested segno and volta repeats

[Thomas Morley]

Am So., 29. Mai 2022 um 09:56 Uhr schrieb Jean Abou Samra :
>
> Hi Dan,
>
> Is there any way to get this repeat structure with the recent
> repeat additions? This is from a question on the user list.
>
> ||:  A:|| B||
>   Fine  D.C. Al Fine
>
> -> A A B A

>From a musicians point of view:
I've learned not to repeat the final A here, though as a rule of thumb(!).
A composer could be expilzit by adding "con/senza repetizione"

Afaict, "senza repetizione" is not supported by now.

Cheers,
  Harm
>
>
> My first thought was to do
>
> \version "2.23.10"
>
> m =
> \repeat segno 2 {
>\repeat volta 2 {
>  a'1
>}
>\volta 2 \fine
>b'1
> }
>
> { \m }
> { \unfoldRepeats \m }
>
>
> That works about fine, except that the resulting
> structure with \unfoldRepeats is A A B A A and
> not A A B A. What I need seems to be a kind of
> \volta 2 \fine within the inner \repeat volta
> that would apply \volta with the outer \repeat
> segno. Did miss something like that? Should
> it be registered as a feature request?
>
> Best,
> Jean
>
>

Re: checkout releases?

[Thomas Morley]

Thanks all!

Am Do., 26. Mai 2022 um 13:53 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Alas I can't checkout v2.23.7:
> > $ git checkout v23.7
> > error: pathspec 'v23.7' did not match any file(s) known to git
>
> I really hate that damn machine
> I wish that they would sell it
> It never does that what I mean
> But only what I tell it
>
> --
> David Kastrup

LOL

Cheers,
  Harm

checkout releases?

[Thomas Morley]

Hi,

some time ago we decided to use v2.23.7 instead of the old
release/2.23.6-1 in the repository.

Alas I can't checkout v2.23.7:
$ git checkout v23.7
error: pathspec 'v23.7' did not match any file(s) known to git

Though I've success with
$ git checkout release/2.23.6-1
Updating files: [...]

Am I doing something wrong?

Thanks,
  Harm

Re: snippet fails with 2.23.

[Thomas Morley]

Am Di., 17. Mai 2022 um 20:39 Uhr schrieb Jean Abou Samra :
>
> Le 16/05/2022 à 23:07, Thomas Morley a écrit :Well, I _am_ a LSR-editor.
> > Though, sometimes it feels I am the only one (not really true, Werner
> > does a lot but his focus is more on lsr-software and
> > snippets-descriptions).
> > We really need more active LSR-editors.
>
>
>
> This sounds like an advocacy problem, really. To give an outsider's
> point of view, until this message I had no idea who was behind
> the LSR approval process apart from you, and I wasn't aware that
> you wished help. I still only have a vague idea of what kind of
> work this entails. And I am following this list and the user list
> closely for two years or so. If more volunteers are needed, I recommend
> (1) documenting what work they should do and how, and (2) asking
> for volunteers on the user list.
>
> (Please note that I am not proposing myself, I'm already busy
> enough contributing to LilyPond.)
>
> Jean
>

Well, in the last about two (or three?) years, bugs in the
lsr-software accumulated and Sebastiano was not really reponsive.
Thus, there was not much what anyone could have done...

Otoh, I once started lsr-update to 2.20. and did what I could to
support both versions (2.18./2.20.). I was not able to finish it
because of said bugs, though it was a very good base to start the
2.22. update. At least so far as lsr-snippets are concerned.
Iirc, I did already the lsr-2.14-update. That lasted much longer ...
Anyway, this is _not_ the duty of an lsr-editor, but the lsr-updater.
But ofcourse an experienced lsr-editor has a better impression what
needs to be done on questionable snippets, thus the lsr-editor may
become the lsr-updater...

That said, the main duties of an lsr-editor are described in CG 7.3
Approving snippets
In the past we never had many lsr-editors, I could drop some names,
but they are mostly retired or hardly active nowadays.
Thus, yes we should ask on -user for volunteers, every experienced
user would be welcome.


Best,
  Harm

Re: snippet fails with 2.23.

[Thomas Morley]

Am Mo., 16. Mai 2022 um 09:52 Uhr schrieb Mats Bengtsson :

>
>Thanks for your work with this. I happened to stumble upon
>[1]https://lsr.di.unimi.it/LSR/Item?id=1113, "Watermark" that most
>likely does not do exactly what was intended.

It belongs _not_ to the duties of the lsr-updater to check whether
snippets print as supposed.
A snippet should _compile_, that's enough.

Otoh, it is no surprise that several snippets will need further
adjustment/fixing.
Ideally those flaws are reported (as you did) and get fixed by a LSR-editor.

Well, I _am_ a LSR-editor.
Though, sometimes it feels I am the only one (not really true, Werner
does a lot but his focus is more on lsr-software and
snippets-descriptions).
We really need more active LSR-editors.

That said, I followed your suggestion below.
Not the time to dive into it more deeply...


>  The watermark is only
>visible in the upper right corner of the page, but was probably meant
>to appear over the full page. A quick fix is to replace
>
>  \translate #'(-50 . 70)
>by
>  \translate #'(-70 . -120)
>
>in the third line of the snippet, but hopefully there's a better
>solution that doesn't require any magic numbers.
>
>   /Mats
>
> References
>
>1. https://lsr.di.unimi.it/LSR/Item?id=1113

Best,
  Harm

Re: snippet fails with 2.23.

[Thomas Morley]

Am So., 15. Mai 2022 um 21:44 Uhr schrieb Thomas Morley
:
>
> Am So., 15. Mai 2022 um 14:11 Uhr schrieb Jean Abou Samra 
> :
> >
> >
> >
> > Le 15/05/2022 à 14:01, Thomas Morley a écrit :
> > > Hi,
> > >
> > > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > > https://lsr.di.unimi.it/LSR/Item?id=1070
> > >
> > > %%
> > > \paper { tagline = ##f }
> > >
> > > #(define mydrums '((tambourine default #t 0)))
> > >
> > > \new DrumStaff \with { instrumentName = #"Tambourine" }
> > >
> > > \drummode {
> > >\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> > >\override Staff.StaffSymbol.line-positions = #'( 0 )
> > >\override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)
> > >
> > >\time 6/8
> > >tamb8. 16 8 8 8 8 |
> > >tamb4. 8 8 8 |
> > >% the trick with the scaled duration and the shorter rest
> > >% is neccessary for the correct ending of the trill-span!
> > >tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
> > > }
> > > 
> > >
> > > works fine with 2.22. but fails with master even after a run of
> > > convert-ly, returning:
> > >
> > > fatal error: unrecognised percussion sign: "#t"
> > >
> > >tamb8. 16 8 8 8 8 |
> > >
> > > I don't get what's wrong.
> > > Hints?
> > >
> > > Thanks,
> > >Harm
> >
> >
> > It works if you replace '((tambourine default #t 0)) with
> > '((tambourine default #f 0)). That's in line with the documentation:
> >
> > """
> > Existing notations may be redefined as an association list
> > where each entry has to be comprised of four items:
> > a name, the note head style (or @code{default}), an
> > articulation sign if needed (or @code{#f} if not), and
> > the note head's position on the staff.  That list must then
> > be converted into a Scheme hash table, using the
> > @code{alist->hash-table} function.
> > """
> >
> > This apparently changed with
> >
> > commit 61cd3bc1f3254b430bf04acd587c4082253602d4
> > Author: Lukas-Fabian Moser 
> > Date:   Mon Dec 27 01:25:43 2021 +0100
> >
> >  Make articulation-type a symbol? instead of a string?
> >
> > which contains
> >
> > diff --git a/lily/drum-note-engraver.cc b/lily/drum-note-engraver.cc
> > index 7e6e3cef7a..d4078a2e3b 100644
> > --- a/lily/drum-note-engraver.cc
> > +++ b/lily/drum-note-engraver.cc
> > @@ -93,12 +93,12 @@ Drum_notes_engraver::process_music ()
> > if (scm_is_symbol (style))
> >   set_property (note, "style", style);
> >
> > -  if (scm_is_string (script))
> > +  if (scm_is_true (script))
> >   {
> > // Error out if script doesn't exist
> > if (scm_is_false (ly_assoc (script, get_property
> > (context (), "scriptDefinitions"
> >   ev->origin ()->error (_f ("unrecognised percussion
> > sign: \"%s\"",
> > -  ly_scm2string (script)));
> > +  ly_scm_write_string (script)));
> >
> > Item *p = make_item ("Script", ev->self_scm ());
> > make_script_from_event (p, context (), script,
> >
> >
> >
> > Namely, instead of checking (string? the-second-element),
> > it just checks the-second-element, i.e. it searches the
> > script definition if the script is anything but #f.
> >
> > Jean
> >
>
> Hi Jean,
>
> thanks for the background.
> There were some other lsr-snippets with a #t-setting there, which had
> escaped my attention, bombing out 'make doc' after lsr-import.
>
> Next attempt now...
>
> Thanks,
>   Harm

Btw, I found some other snippets worth fixing, currently returning
programming errors or warnings:

incipit.ly  "programming error: Loose column does not have right side
to attach to."
using-marklines-in-a-frenched-score.ly a plethora of "programming
error: cyclic dependency:..."
using-tags-to-produce-mensural-and-modern-music-from-the-same-source.ly
"Loose column ..."

how-to-print-two-rehearsal-marks-above-and-below-the-same-barline-method-2.ly
and
vertical-aligned-staffgroups-without-connecting-systemstartbar.ly
return warnings for conficting rehearsal marks.

Worth fixing

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Mi., 11. Mai 2022 um 23:24 Uhr schrieb Thomas Morley
:
>
> Am Di., 10. Mai 2022 um 00:27 Uhr schrieb Werner LEMBERG :
> >
> >
> > >> All snippets are updated.
> > >
> > > Thanks a lot, Harm!
> >
> > +1.  Good job!
> >
> >
> > Werner
>
> The following snippets from Documentation/snippets/new (compiling with
> 2.22. and not previously in LSR) are now in LSR:
> aiken-head-thin-variant-noteheads.ly
> ambitus-after-key-signature.ly
> analysis-brackets-with-labels.ly
> automatic-fretboards-barre.ly
> measure-spanner.ly
> moving-the-ends-of-hairpins.ly
> replacing-default-midi-instrument-equalization.ly
> turkish-makam-example.ly
> user-defined-time-signatures.ly
>
> In their descriptions the texinfo-tags needed to be changed to
> html-tags. For two snippets I'm not exactly sure, whether I did it
> correctly
> Werner, may I ask you to take a look?
> ambitus-after-key-signature.ly
> https://lsr.di.unimi.it/LSR/Item?u=1=1142
> and
> using-marklines-in-a-frenched-score.ly
> https://lsr.di.unimi.it/LSR/Item?u=1=1150
>
> Next steps:
> (1) Remove above files from Documentation/snippets/new
> (2) Remove files from Documentation/snippets/new which are now already
> in LSR (note to self: check that, before removing)
> (3) Commit above
> (4) Run and commit the results of makelsr.py
>
> Cheers,
>   Harm

patch at:
https://gitlab.com/lilypond/lilypond/-/merge_requests/1360

Cheers,
  Harm

Re: snippet fails with 2.23.

[Thomas Morley]

Am So., 15. Mai 2022 um 14:11 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 15/05/2022 à 14:01, Thomas Morley a écrit :
> > Hi,
> >
> > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > https://lsr.di.unimi.it/LSR/Item?id=1070
> >
> > %%
> > \paper { tagline = ##f }
> >
> > #(define mydrums '((tambourine default #t 0)))
> >
> > \new DrumStaff \with { instrumentName = #"Tambourine" }
> >
> > \drummode {
> >\set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> >\override Staff.StaffSymbol.line-positions = #'( 0 )
> >\override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)
> >
> >\time 6/8
> >tamb8. 16 8 8 8 8 |
> >tamb4. 8 8 8 |
> >% the trick with the scaled duration and the shorter rest
> >% is neccessary for the correct ending of the trill-span!
> >tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
> > }
> > 
> >
> > works fine with 2.22. but fails with master even after a run of
> > convert-ly, returning:
> >
> > fatal error: unrecognised percussion sign: "#t"
> >
> >tamb8. 16 8 8 8 8 |
> >
> > I don't get what's wrong.
> > Hints?
> >
> > Thanks,
> >Harm
>
>
> It works if you replace '((tambourine default #t 0)) with
> '((tambourine default #f 0)). That's in line with the documentation:
>
> """
> Existing notations may be redefined as an association list
> where each entry has to be comprised of four items:
> a name, the note head style (or @code{default}), an
> articulation sign if needed (or @code{#f} if not), and
> the note head's position on the staff.  That list must then
> be converted into a Scheme hash table, using the
> @code{alist->hash-table} function.
> """
>
> This apparently changed with
>
> commit 61cd3bc1f3254b430bf04acd587c4082253602d4
> Author: Lukas-Fabian Moser 
> Date:   Mon Dec 27 01:25:43 2021 +0100
>
>  Make articulation-type a symbol? instead of a string?
>
> which contains
>
> diff --git a/lily/drum-note-engraver.cc b/lily/drum-note-engraver.cc
> index 7e6e3cef7a..d4078a2e3b 100644
> --- a/lily/drum-note-engraver.cc
> +++ b/lily/drum-note-engraver.cc
> @@ -93,12 +93,12 @@ Drum_notes_engraver::process_music ()
> if (scm_is_symbol (style))
>   set_property (note, "style", style);
>
> -  if (scm_is_string (script))
> +  if (scm_is_true (script))
>   {
> // Error out if script doesn't exist
> if (scm_is_false (ly_assoc (script, get_property
> (context (), "scriptDefinitions"
>   ev->origin ()->error (_f ("unrecognised percussion
> sign: \"%s\"",
> -  ly_scm2string (script)));
> +  ly_scm_write_string (script)));
>
> Item *p = make_item ("Script", ev->self_scm ());
> make_script_from_event (p, context (), script,
>
>
>
> Namely, instead of checking (string? the-second-element),
> it just checks the-second-element, i.e. it searches the
> script definition if the script is anything but #f.
>
> Jean
>

Hi Jean,

thanks for the background.
There were some other lsr-snippets with a #t-setting there, which had
escaped my attention, bombing out 'make doc' after lsr-import.

Next attempt now...

Thanks,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 7. Mai 2022 um 00:36 Uhr schrieb Thomas Morley
:
>
> Folks,
>
> currently I'm updating all LSR-files to work with 2.22.
> One step is
> CG 7.7 Updating the LSR to a new version
> [...]
> 5. Copy relevant snippets (i.e. snippets whose version is equal to or
> less than the new version of LilyPond running on the LSR) from
> ‘Documentation/snippets/new/’ into the set of files to be used to make
> the tarball.
> [...]
>
> I've found that the majority of those files in
> ‘Documentation/snippets/new/’ _don't_ _need_ to_ _be_ there_!
> They could have been changed through LSR's web-interface.
> Changing \set instrumentName ... to \with { instrumentName ... }
> worked forever (more or less). Code cleanup for empty lines (missing
> or superfluous), code indentation, etc, etc
>
> Nothing of above warrants a new snippet.
>
> Please stop doing so, please first test, whether it compiles with
> current LSR-version, and please update the snippet _inside_ LSR. If
> you don't have an account please create one. Or please ask me, Pierre,
> Werner and others with permission to do so.
>
>
> Otherwise it exents the workload of the LSR-updater, not pretty for my
> motivation... LSR has currently already 896 files to be maintained!

And, please, _never ever_ introduce a snippet with not matching
doctitle/filename.

Thanks,
  Harm

Re: snippet fails with 2.23.

[Thomas Morley]

Am So., 15. Mai 2022 um 14:08 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > the new doc-tagged LSR-snippet 'tambourine-example.ly'
> > https://lsr.di.unimi.it/LSR/Item?id=1070
> >
> > %%
> > \paper { tagline = ##f }
> >
> > #(define mydrums '((tambourine default #t 0)))
>
> What's the #t supposed to mean here?  Should be a symbol or #f I think.
>
> --
> David Kastrup

Aargh, of course!

Thanks,
  Harm

snippet fails with 2.23.

[Thomas Morley]

Hi,

the new doc-tagged LSR-snippet 'tambourine-example.ly'
https://lsr.di.unimi.it/LSR/Item?id=1070

%%
\paper { tagline = ##f }

#(define mydrums '((tambourine default #t 0)))

\new DrumStaff \with { instrumentName = #"Tambourine" }

\drummode {
  \set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
  \override Staff.StaffSymbol.line-positions = #'( 0 )
  \override Staff.BarLine.bar-extent = #'(-1.5 . 1.5)

  \time 6/8
  tamb8. 16 8 8 8 8 |
  tamb4. 8 8 8 |
  % the trick with the scaled duration and the shorter rest
  % is neccessary for the correct ending of the trill-span!
  tamb2.*5/6 \startTrillSpan s8 \stopTrillSpan |
}


works fine with 2.22. but fails with master even after a run of
convert-ly, returning:

fatal error: unrecognised percussion sign: "#t"

  tamb8. 16 8 8 8 8 |

I don't get what's wrong.
Hints?

Thanks,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 14. Mai 2022 um 09:31 Uhr schrieb Sebastiano Vigna
:
>
>
>
> > On 13 May 2022, at 22:43, Thomas Morley  wrote:
> >
> >
> > I spoke too early...
> > In the tarball the snippets still print \version "2.18.0", although
> > they are compiled with 2.22.
> > Please have a look.
> >
>
> Yep, I forgot to update the version string in the Constants Java class. Fixed.
>
> Ciao,
>
> seba
>

Works now.

Thanks,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Mo., 9. Mai 2022 um 23:45 Uhr schrieb Thomas Morley
:

> LSR-software is running 2.22.
> Last LSR-problem I'm aware of (see above) is fixed.

Hi Seba,

I spoke too early...
In the tarball the snippets still print \version "2.18.0", although
they are compiled with 2.22.
Please have a look.

Thanks,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Di., 10. Mai 2022 um 00:27 Uhr schrieb Werner LEMBERG :
>
>
> >> All snippets are updated.
> >
> > Thanks a lot, Harm!
>
> +1.  Good job!
>
>
> Werner

The following snippets from Documentation/snippets/new (compiling with
2.22. and not previously in LSR) are now in LSR:
aiken-head-thin-variant-noteheads.ly
ambitus-after-key-signature.ly
analysis-brackets-with-labels.ly
automatic-fretboards-barre.ly
measure-spanner.ly
moving-the-ends-of-hairpins.ly
replacing-default-midi-instrument-equalization.ly
turkish-makam-example.ly
user-defined-time-signatures.ly

In their descriptions the texinfo-tags needed to be changed to
html-tags. For two snippets I'm not exactly sure, whether I did it
correctly
Werner, may I ask you to take a look?
ambitus-after-key-signature.ly
https://lsr.di.unimi.it/LSR/Item?u=1=1142
and
using-marklines-in-a-frenched-score.ly
https://lsr.di.unimi.it/LSR/Item?u=1=1150

Next steps:
(1) Remove above files from Documentation/snippets/new
(2) Remove files from Documentation/snippets/new which are now already
in LSR (note to self: check that, before removing)
(3) Commit above
(4) Run and commit the results of makelsr.py

Cheers,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 7. Mai 2022 um 16:46 Uhr schrieb Thomas Morley
:
>
> Am Sa., 7. Mai 2022 um 16:03 Uhr schrieb Thomas Morley
> :
> >
> > Am Sa., 7. Mai 2022 um 14:13 Uhr schrieb Werner LEMBERG :
> > >
> > >
> > > >> I think it's not really used at the moment because the LilyPond
> > > >> version is 8 years old. I at least will definitely use it more when
> > > >> it gets updated to 2.22.
> > > >
> > > > It has been already updated.
> > >
> > > This is excellent news!  However,
> > >
> > >   https://lsr.di.unimi.it/LSR/html/contributing.html
> > >
> > > still says
> > >
> > >   The LSR is currently running LilyPond version 2.18.2.
> > >
> > > An oversight?
> > >
> > > > The snippets haven't tho.
> > >
> > > It seems that Harm is actively working on this.
> > >
> > >
> > > Werner
> >
> > Yep, currently running the final test...
>
> Hi Sebastiano,
>
> attached a tarball with the updated snippets, based on
> lsr-snippets-all-2022-05-06.tar.gz. They are in the all-folder, other
> folders are untouched.
> Everything's working on my machine.
>
> Btw, if I edit a snippet through the lsr-web-interface, the 'preview'
> is sort of broken. Meaning, the image based on the modified code is
> not immediately changed as it used to be, but the next day.
> Could you have a look?
>
> Thansk,
>   Harm

Current state:
LSR-software is running 2.22.
Last LSR-problem I'm aware of (see above) is fixed.
All snippets are updated.

Thanks Seba!

Additionally I (corrected and) approved all so far unapproved snippets
(one exception).

Next steps: work on ‘Documentation/snippets/new/’ as adviced in CG


Cheers,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 7. Mai 2022 um 14:13 Uhr schrieb Werner LEMBERG :
>
>
> >> I think it's not really used at the moment because the LilyPond
> >> version is 8 years old. I at least will definitely use it more when
> >> it gets updated to 2.22.
> >
> > It has been already updated.
>
> This is excellent news!  However,
>
>   https://lsr.di.unimi.it/LSR/html/contributing.html
>
> still says
>
>   The LSR is currently running LilyPond version 2.18.2.
>
> An oversight?
>
> > The snippets haven't tho.
>
> It seems that Harm is actively working on this.
>
>
> Werner

Yep, currently running the final test...

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 7. Mai 2022 um 00:36 Uhr schrieb Thomas Morley
:
> currently I'm updating all LSR-files to work with 2.22.

Btw, current state:
I converted all lsr-snippets to 2.22., inserted those from
Documentation/snippets/new, fixed all crashes and most warnings:

No ERRORs
Some 'programming error's for engravers-one-by-one.ly, on purpose,
won't surpress.
Some warnings for 'combining-two-parts-on-the-same-staff.ly' and
'shortening-volta-brackets.ly'. Likely (long standing) bugs, won't
fix.

I.e. close to finish :)

Cheers,
  Harm

Re: LSR and Documentation/snippets/new

[Thomas Morley]

Am Sa., 7. Mai 2022 um 00:46 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Please stop doing so, please first test, whether it compiles with
> > current LSR-version, and please update the snippet _inside_ LSR. If
> > you don't have an account please create one. Or please ask me, Pierre,
> > Werner and others with permission to do so.
> >
> >
> > Otherwise it exents the workload of the LSR-updater, not pretty for my
> > motivation... LSR has currently already 896 files to be maintained!
> >
> > We should make this a policy, even more prominent as currently.
>
> "even more prominent"?  How is this prominent at all right now?
>
> --
> David Kastrup

In CG 7. LSR work:
7.2 Adding and editing snippets
If a new snippet created for documentation purposes compiles with
LilyPond version currently on LSR, it should be added to LSR [...]
If the new snippet uses new features that are not available in the
current LSR version, the snippet should be added to
‘Documentation/snippets/new’ [...]
This is obviously inside the LSR-section.

"More prominent" probably means to clearify it as well in sections like
5. Documentation work
and
10. Programming work

Maybe others as well.

Cheers,
  Harm

LSR and Documentation/snippets/new

[Thomas Morley]

Folks,

currently I'm updating all LSR-files to work with 2.22.
One step is
CG 7.7 Updating the LSR to a new version
[...]
5. Copy relevant snippets (i.e. snippets whose version is equal to or
less than the new version of LilyPond running on the LSR) from
‘Documentation/snippets/new/’ into the set of files to be used to make
the tarball.
[...]

I've found that the majority of those files in
‘Documentation/snippets/new/’ _don't_ _need_ to_ _be_ there_!
They could have been changed through LSR's web-interface.
Changing \set instrumentName ... to \with { instrumentName ... }
worked forever (more or less). Code cleanup for empty lines (missing
or superfluous), code indentation, etc, etc

Nothing of above warrants a new snippet.

Please stop doing so, please first test, whether it compiles with
current LSR-version, and please update the snippet _inside_ LSR. If
you don't have an account please create one. Or please ask me, Pierre,
Werner and others with permission to do so.


Otherwise it exents the workload of the LSR-updater, not pretty for my
motivation... LSR has currently already 896 files to be maintained!

We should make this a policy, even more prominent as currently.


Cheers,
  Harm

Re: Setting up classical guitar fingerings

[Thomas Morley]

Am So., 20. Feb. 2022 um 22:41 Uhr schrieb Luca Fascione :

>  a) I'm looking for a way to get the fingerings where I want them without
> using one-note-chord tricks

Well, for Fingerings not in chord, like b-1 or -2-1 X-parent
is NoteColumn _not_ NoteHead, Y-parent  is VerticalAxisGroup.
There is no direct way from NoteHead to Fingering and vice versa.

Thus putting Fingering in-chord is unavoidable, imho, even for single notes.
It is _not_ a trick, but a requirement.

Furthermore, you say you set music for classical guitar, then chords
will happen anyway, although not in your example.
Please note, as soon as more than one in-chord Fingering is present a
FingeringColumn is created. Which will make things even more
complicated.
See
https://gitlab.com/lilypond/lilypond/-/issues/6125
https://gitlab.com/lilypond/lilypond/-/merge_requests/732

Sorry to be of not more help,
  Harm

Re: LilyPond 2.23.6 released

[Thomas Morley]

Am Di., 8. Feb. 2022 um 16:54 Uhr schrieb Jonas Hahnfeld via
Discussions on LilyPond development :
>
> We are happy to announce the release of LilyPond 2.23.6. This is termed
> a development release, but these are usually reliable. If you want to
> use the current stable version of LilyPond, we recommend using the
> 2.22.1 version.
>
> This release also marks a transition towards Guile 2.2: The binaries
> available from http://lilypond.org/development are built using GUB with
> Guile 1.8, while the packages available from
> https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1
> were created with the new infrastructure developed over the past
> months, making use of Guile 2.2. We encourage testing with your scores
> to make sure that future releases of LilyPond will continue to work for
> you. If there are problems with the version using Guile 2.2 that cannot
> be reproduced with the binaries using Guile 1.8, we would love to hear
> about them as early as possible.
>
> The binaries with Guile 2.2 are different in a number of ways, the two
> major changes being:
> 1. All binaries are 64-bit only and available for Linux, Windows (via
> mingw), and macOS. In particular, this finally means official binaries
> that work on macOS >= 10.15, which cannot run 32-bit programs anymore.
> 2. There is no installation, simply extract the downloaded tar or zip
> (for Windows) archive and run it. The binaries don't include a GUI
> anymore, we recommend using third-party editors such as Frescobaldi.

Hi Jonas,

I tested 2.23.6 from various sources wrt time, always doing
time lilyversion-to-test file.ly
The results (I post always the second run):

%%
%% repository
%%

self-compiled lilypond-git
out of
9e8645564f (HEAD, tag: release/2.23.6-1) Release: bump Welcome versions.
with guile-2.2.7

real0m47,518s
user0m47,007s
sys0m1,145s

after GUILE_AUTO_COMPILE=1

real0m31,956s
user0m31,420s
sys0m0,868s

%%
%% GitLab-archive
%%

lilypond-2.23.6
from
https://gitlab.com/lilypond/lilypond/-/releases/release%252F2.23.6-1
(with guile-2.2.7)

real0m42,682s
user0m42,008s
sys0m0,900s

%%
%% installer
%%

lilypond-2.23.6
from
http://lilypond.org/development
(with guile-1.8.8)

real0m32,733s
user0m31,364s
sys0m1,337s

Obviously the version from GitLab is significantly slower than the
self-compiled version with compiled guile-code.
No clue why.

Apart from that, the version via installer does (and always did):
"A script in /home/hermann/bin will be created as a shortcut."
With the GitLab-archive I have to care myself. Not a big deal, a
little inconvenient, though.
Any chance to have such a script autogenerated again?

Thanks,
  Harm

Re: Stepping down from Patch Meister role

[Thomas Morley]

Am Sa., 8. Jan. 2022 um 11:06 Uhr schrieb James :
>
> Hello,
>
> I am going to stop doing the Patch countdown at the end of this month.
>
> I'll continue for the next few weeks, but my last countdown will be
> whatever the last date in January ends up being.
>
> Thanks for your understanding.
>
> --
> Regards
>
> James
>

Hi James,

thanks a lot for all your work!
You did a fabulous job!

Best,
  Harm

Re: LilyPond | Various doc issues (!1095)

[Thomas Morley]

Am Mi., 5. Jan. 2022 um 16:45 Uhr schrieb Jean Abou Samra :
>
>
> > Le 05/01/2022 14:04, Thomas Morley  a écrit :
> >
> >
> > Am Mi., 5. Jan. 2022 um 13:28 Uhr schrieb Jean Abou Samra 
> > :
> > >
> > > [Replying via the mailing list because it's unrelated to Werner's MR]
> > > Le 05/01/2022 12:59, Thomas Morley (@Thomas_Morley)
> > >  a écrit :
> > > [1]Thomas Morley commented on a discussion on
> > > [2]Documentation/en/notation/notation-appendices.itely:
> > > Unrelated to this patch
> > > Though, [3]@jeanas
> > > They do. You might be confused by the change of presentation
> > > Indeed, I was wrong. Alas, in IR the former behaviour added to every
> > > interface:
> > > This grob interface is used in the following graphical object(s):
> > > list-of-grobs
> > > Now
> > > This grob interface is added dynamically to grobs of class
> > > Spanner/Item.
> > > is printed.
> > > I miss this list-of-grobs in the docs now.
> > > Any chance to get this back in the IR for item/spanner-interface or
> > > have this list somewhere in IR linked from thoe interfaces?
> > > That is feasible if we define what it means to be "used": basically
> > > should Footnote be included in this list or not since it will sometimes
> > > have it and sometimes not? Should grobs having the interface
> > > conditionally be in a separate list? The info on _allowable_ classes
> > > (and thus interfaces) is all in define-grobs.scm, it's just a matter of
> > > defining how it should be presented.
> > > Cheers,
> > > Jean
> > > References
> > > 1. https://gitlab.com/Thomas_Morley
> > > 2. 
> > > https://gitlab.com/lilypond/lilypond/-/merge_requests/1095#note_801886836
> > > 3. https://gitlab.com/jeanas
> > IIuc, only 5 grobs may be item _or_ spanner:
> > BalloonText
> > ControlPoint
> > ControlPolygon
> > Footnote
> > Parentheses
> > All others are definitely Items or Spanners.
> >
> > If so, then I'd suggest to have three lists to link to in IR: Items,
> > Spanners, Items-or-Spanners
>
>
> In what section of the IR would be the list of
> items-or-spanners though? Currently they all
> have the sticky-grob-interface, but it's an open
> bet whether they will continue to be characterized
> by an interface in the future because other use
> cases can be found (e.g. perhaps we would want to unify
> PercentRepeat and DoublePercentRepeat?). Maybe rather
> list them in spanner-interface and item-interface?
>

Below sounds nice:

> """
> This interface is used in in the following graphical objects: Foo, Bar, Baz
>
> In addition, this interface is conditionally supported by the following 
> objects: Footnote, BalloonText, etc.
> """

Cheers,
  Harm

Re: LilyPond | Various doc issues (!1095)

[Thomas Morley]

Am Mi., 5. Jan. 2022 um 13:28 Uhr schrieb Jean Abou Samra :
>
>[Replying via the mailing list because it's unrelated to Werner's MR]
>
>Le 05/01/2022 12:59, Thomas Morley (@Thomas_Morley)
> a écrit :
>
>[1]Thomas Morley commented on a discussion on
>[2]Documentation/en/notation/notation-appendices.itely:
>
>Unrelated to this patch
>Though, [3]@jeanas
>
>  They do. You might be confused by the change of presentation
>
>Indeed, I was wrong. Alas, in IR the former behaviour added to every
>interface:
>
>  This grob interface is used in the following graphical object(s):
>  list-of-grobs
>
>Now
>
>  This grob interface is added dynamically to grobs of class
>  Spanner/Item.
>
>is printed.
>I miss this list-of-grobs in the docs now.
>Any chance to get this back in the IR for item/spanner-interface or
>have this list somewhere in IR linked from thoe interfaces?
>
>That is feasible if we define what it means to be "used": basically
>should Footnote be included in this list or not since it will sometimes
>have it and sometimes not? Should grobs having the interface
>conditionally be in a separate list? The info on _allowable_ classes
>(and thus interfaces) is all in define-grobs.scm, it's just a matter of
>defining how it should be presented.
>
>Cheers,
>
>Jean
>
> References
>
>1. https://gitlab.com/Thomas_Morley
>2. 
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1095#note_801886836
>3. https://gitlab.com/jeanas

IIuc, only 5 grobs may be item _or_ spanner:
  BalloonText
  ControlPoint
  ControlPolygon
  Footnote
  Parentheses
All others are definitely Items or Spanners.

If so, then I'd suggest to have three lists to link to in IR: Items,
Spanners, Items-or-Spanners

Cheers,
  Harm

Re: RFC: Adding syntax highlighting to the official documentation

[Thomas Morley]

Am Di., 28. Dez. 2021 um 22:22 Uhr schrieb Jean Abou Samra :
>
> On the merge request, Dan proposed the attached style. What do you think?
>
> Thanks,
> Jean

Well, I use jEdit for my own work. There I use a highly customized
syntax highlighting:
Many different colors and apart from comments all is bold (due to
increasing deterioration of my eyes, I'm getting old...)

Though, in the proposed style only things like \glissandoSkipOn use a
somehow red color.
For me red is a color to signal something important or a warning. It
looks like \glissandoSkipOn and friends would be the most important
things in the file.
Otoh, I don't think you can satisfy everyone's wishes. On colors I
have not a too strong opinion.

Alas, using italic makes it more difficult for me to read the file, it
disturbs and distracts me. I strongly object using it.

Thanks for working on it,
  Harm

Re: cross-staff, broken Glissando

[Thomas Morley]

Am Do., 11. Nov. 2021 um 19:24 Uhr schrieb Jean Abou Samra :
>
> Le 07/11/2021 à 12:39, Thomas Morley a écrit :
> > Anyone up for it?
>
> Phooey.
>
> https://gitlab.com/lilypond/lilypond/-/merge_requests/998
>
> Cheers,
> Jean

Looks like it was much more work than expected...
More on gitlab.

Many thanks,
  Harm

Re: TimeSignature with note in denominator

[Thomas Morley]

Am Mo., 8. Nov. 2021 um 21:04 Uhr schrieb Kieren MacMillan
:
>
> Hi Werner,
>
> >> For my first official patch as a Lily-dev, I’m proposing to make the
> >> result of  an official
> >> #'style in TimeSignature.
> >
> > It would be nice to see some real-world examples in printed scores.
> > Do you have links for that?
>
> The most famous one is Carmina Burana (see, for example, 
> https://www.youtube.com/watch?v=HMr5b46Y5ws). It’s *slightly* different, in 
> that the TSes are above the staff, printed as actual “vulgar fractions”… but 
> that would be a separate [later] enhancement to this feature.
>
> I’ll look for other examples and forward them.
>
> Cheers,
> Kieren.
> 
>
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: kie...@kierenmacmillan.info
>

I once made this hackish workaround
https://archiv.lilypondforum.de/index.php/topic,2127.msg11763.html#msg11763
Not worth to be considered for our source, but probably illustrating
the problems to deal with.

Cheers,
  Harm

Re: Manipulating instrument names and staff group names

[Thomas Morley]

Am So., 7. Nov. 2021 um 22:30 Uhr schrieb Jean Abou Samra :
>
> Le 07/11/2021 à 21:59, Kieren MacMillan a écrit :
> > Hi Jonas,
> >
> >> "Defect" is for problems within the "core program",
> >> which means either C++ or Scheme. I would argue that those two are not
> >> really separable in most cases
> > Does that mean for someone like me — with a fighting chance of Scheme-ing, 
> > but very little chance of ever C++-ing — there are very few 
> > [non-documentation] issues I can likely fix?
>
>
> A blatant counter-example is in the person
> of Harm.

Indeed :)
I don't know C++, I don't know python. At the time I discovered
LilyPond I didn't know scheme.

While using LilyPond I felt the wish to get some things from LilyPond,
which were not there - and learned scheme.
Today there are several of my patches in the source:
http://git.savannah.gnu.org/cgit/lilypond.git/log/?qt=author=Thomas+Morley
Ofcourse the range of those patches is very wide: from correcting a
typo somewhere up to implementing new grobs.

May I give you some advice?
Start slowly, maybe with a markup-command you would like to have,
don't look at the partcombiner for now.
At least I'm always scared away looking there.
Make yourself famliar with using the repository, gitLab and the like.

And don't run against walls for more than a day ;)
Ask!

Best,
  Harm

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 14:00 Uhr schrieb Jean Abou Samra :

> >>> That said,...
> >>> If I always compensate the right ending-point with (pseudo-code)
> >>> (ly:grob-relative-coordinate   Y)
> >>> Then the crosses are at those positions Mike's patch promises.
> >> Really System? Isn't this going to create a
> >> cyclic dependency between the stencil and
> >> vertical alignment for non-cross-staff glissandi
> >> via VerticalAxisGroup skylines? Off the top I would
> >> think it should be a matter of correcting
> >> reference points (see above).
> > I compile with recent master, so your added warnings for  cyclic
> > dependencies may pop up.
> > They don't.
>
>
> Ah, because vertical alignment works via
> ly:grob-translate-axis! and doesn't mark the
> dependencies. Sigh.
>
> Look at:
>
> <<
>\new Staff {
>  c'1
>}
>\new Staff {
>  \override Glissando.stencil =
>#(lambda (grob)
>   (ly:message "~s"
>   (ly:grob-relative-coordinate
> grob
> (ly:grob-system grob)
> Y))
>   (ly:line-spanner::print grob))
>  c'1\glissando c''1
>}
>  >>
>
> It prints "0.0". So there's no cyclic dependency
> warned about, but it's not doing what you intend.
> How could it? The glissando is part of the vertical
> skylines of the VerticalAxisGroup. These are the
> basis for vertical alignment. So you need the glissando's
> stencil before you can take the Y coordinate of the
> glissando relative to the system. Unless you have
> a cross-staff glissando, because these aren't part
> of the skylines -- but even then there is usually no
> reason to take the root system and not just a refpoint
> computed generically for both non-cross-staff
> and cross-staff grobs.

For non-cross-staff Glissando it returns always zero, yes, for
cross-staff a certain value is found:

<<
   \new Staff = "top" {
 c'1
   }
   \new Staff {
 \override Glissando.stencil =
   #(lambda (grob)
  (ly:message "~s"
  (ly:grob-relative-coordinate
grob
(ly:grob-system grob)
Y))
  (ly:line-spanner::print grob))
 c'1\glissando \change Staff = "top" c''1
   }
 >>

-> -12.779

I tend to think: nice, let us always add this value, in any case it
only matters for cross-staff at all.

Why not?


Cheers,
  Harm

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 13:47 Uhr schrieb Aaron Hill :
>
> On 2021-11-07 4:26 am, Jean Abou Samra wrote:
> > (Adding Aaron in CC.)
>
> Thanks, Jean.  I am subscribed to lily-devel, so I did see the thread.
>
>
> >> Alas, because my lack of C++-knowledge, I can't do it myself.
> >
> > You should learn C++ someday :-)
>
> As my work schedule allows, I would be willing to assist you both in
> breaking down C++ code into Scheme and providing some educational
> guidance to get you fishing on your own.
>
>
> -- Aaron Hill

Thanks, Aaron!
Once I find the time and energy I may come back to you.

Best.
  Harm

Re: cross-staff, broken Glissando

[Thomas Morley]

Am So., 7. Nov. 2021 um 13:26 Uhr schrieb Jean Abou Samra :
>
> (Adding Aaron in CC.)
>
> Le 07/11/2021 à 12:39, Thomas Morley a écrit :
> > Hi,
> >
> > commit 94860164493ab3a209986b0e3662ff7bd8958cb5
> > Author: Mike Solomon 
> > Date:   Mon Mar 28 10:58:29 2011 -0400
> >
> >  Assures smooth transitions at glissando line breaks.
> >
> >  When a glissando breaks over lines, the left point of the 
> > beginning-of-line
> >  glissando picks up on the y-axis where the right point of the 
> > end-of-line
> >  glissando ends.
> >
> > is not true for cross-staff, broken Glissando.
> > For a down-pointing Glissando, ending in a lower Staff this "pick-up"
> > point is not matched.
> > For an up-pointing Glissando starting in a lower Staff the first part
> > is completely off. This is
> > https://gitlab.com/lilypond/lilypond/-/issues/4806
> > See attachment.
>
>
> I get seemingly correct output in the issue's
> example when adding
>
>\override Glissando.simple-Y = ##f
>
> So I'd start by investigating why simple-Y was
> added in the first place.

Doing so fails for:
{
  \override Glissando.simple-Y = ##f
  e'''1.\glissando s2
  \break
  s2 \once \override NoteColumn.glissando-skip = ##t
  c''
  \break
  s2 bes
}
->
programming error: no note heads for the line spanner on neighbor
line? Confused.
continuing, cross fingers

>
>
> > While attempting to code stemmed Glissandi in scheme, there was a very
> > helpful discussion starting here:
> > https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
> > lastly arriving at
> > https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
> > Basically I try to get start- and end-points of all kinds of
> > Glissandi, printing crosses there.
> > Many thanks to Aaron!
> >
> > That said,...
> > If I always compensate the right ending-point with (pseudo-code)
> > (ly:grob-relative-coordinate   Y)
> > Then the crosses are at those positions Mike's patch promises.
>
> Really System? Isn't this going to create a
> cyclic dependency between the stencil and
> vertical alignment for non-cross-staff glissandi
> via VerticalAxisGroup skylines? Off the top I would
> think it should be a matter of correcting
> reference points (see above).

I compile with recent master, so your added warnings for  cyclic
dependencies may pop up.
They don't.

>
>
> > I attach the new scheme-code and an image (with correct placed
> > crosses, but untouched default-stencil)
> >
> > Ofcourse it's trivial to extend this scheme-code to create
> > Glissando-stencil instead of those crosses.
> > Better ofcourse is fixing the problem in our source.
> >
> > Alas, because my lack of C++-knowledge, I can't do it myself.
>
> You should learn C++ someday :-)

Well, I often read people complaining about ununderstandable scheme...
For me it's more that cyptic C++.
Tbh, my lack of time and energy are the most importing reasons why I
did not really start that challenge.

>
> Best,
> Jean

Thanks,
  Harm

cross-staff, broken Glissando

[Thomas Morley]

Hi,

commit 94860164493ab3a209986b0e3662ff7bd8958cb5
Author: Mike Solomon 
Date:   Mon Mar 28 10:58:29 2011 -0400

Assures smooth transitions at glissando line breaks.

When a glissando breaks over lines, the left point of the beginning-of-line
glissando picks up on the y-axis where the right point of the end-of-line
glissando ends.

is not true for cross-staff, broken Glissando.
For a down-pointing Glissando, ending in a lower Staff this "pick-up"
point is not matched.
For an up-pointing Glissando starting in a lower Staff the first part
is completely off. This is
https://gitlab.com/lilypond/lilypond/-/issues/4806
See attachment.

While attempting to code stemmed Glissandi in scheme, there was a very
helpful discussion starting here:
https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00326.html
lastly arriving at
https://lists.gnu.org/archive/html/lilypond-user/2021-11/msg3.html
Basically I try to get start- and end-points of all kinds of
Glissandi, printing crosses there.
Many thanks to Aaron!

That said,...
If I always compensate the right ending-point with (pseudo-code)
(ly:grob-relative-coordinate   Y)
Then the crosses are at those positions Mike's patch promises.

I attach the new scheme-code and an image (with correct placed
crosses, but untouched default-stencil)

Ofcourse it's trivial to extend this scheme-code to create
Glissando-stencil instead of those crosses.
Better ofcourse is fixing the problem in our source.

Alas, because my lack of C++-knowledge, I can't do it myself.

Anyone up for it?

Thanks,
  Harm


start-end-gradient-06.pdf
Description: Adobe PDF document
\version "2.22.0" % "2.23.3"

%% rewritten by Aaron Hill, many thanks!
%% https://lists.gnu.org/archive/html/lilypond-user/2021-10/msg00354.html

%% Comments/TODOs/amendments by Harm

\paper {
  indent = 0
  ragged-right = ##f
  line-width = 120
}

\layout {
  \context {
\Voice
\override Glissando.layer = 1000
\override Glissando.bound-details.left.padding =  0
\override Glissando.bound-details.right.padding = 0
\override Glissando.breakable = ##t
  }
}

%% cross stencil
#(define*
   (make-cross-stencil coords #:optional (thick 0.1) (sz 0.2))
   (ly:stencil-add
 (make-line-stencil
   thick
   (- (car coords) sz)
   (- (cdr coords) sz)
   (+ (car coords) sz)
   (+ (cdr coords) sz))
 (make-line-stencil
   thick
   (- (car coords) sz)
   (+ (cdr coords) sz)
   (+ (car coords) sz)
   (- (cdr coords) sz

%% glissando stencil
#(define glissando-stencil-proc (lambda (grob) (ly:line-spanner::print grob)))

%% get start/end points
#(define gliss-data
  (lambda (grob)
(let* ((simple-y? (and (ly:grob-property grob 'simple-Y)
   (not (ly:grob-property grob 'cross-staff
   (lbi (ly:grob-property grob 'left-bound-info))
   (rbi (ly:grob-property grob 'right-bound-info))
;;;
;; TODO (1)
;;;
;;  Common refpoint of the spanner-bounds is already grob System
;;  Why searching again, doesn't it will return grob System again?
;;  Is there any ly-counter-example?
;;  See the test-code below inside `pretty-print'
   (common-x (ly:grob-common-refpoint grob
  (ly:grob-common-refpoint
   (ly:spanner-bound grob LEFT)
   (ly:spanner-bound grob RIGHT) X) X))
   (scaling (magstep (ly:grob-property grob 'font-size 0)))
   (left-padding (ly:assoc-get 'padding lbi 0))
   (left-stencil (ly:assoc-get 'stencil lbi #f))
   (left-common-y (ly:assoc-get 'common-y lbi grob))
   (right-padding (ly:assoc-get 'padding rbi 0))
   (right-stencil (ly:assoc-get 'stencil rbi #f))
   (right-common-y (ly:assoc-get 'common-y rbi grob))
   (common-y (ly:grob-common-refpoint left-common-y right-common-y Y))
   (normalized-endpoints
 (ly:grob-property grob 'normalized-endpoints '(0 . 1)))
   (span-left-x (ly:assoc-get 'X lbi 0))
   (span-left-y (ly:assoc-get 'Y lbi 0))
   (span-right-x (ly:assoc-get 'X rbi 0))
   (span-right-y (ly:assoc-get 'Y rbi 0))
   (original-grob (ly:grob-original grob))
   (siblings (ly:spanner-broken-into original-grob)))

  ;; Take relative coords in X/Y direction into account.
  ;; This needs to come before other modifications of x/y values!
  ;; Especially `dy-right' is important for cross-staff spanners
  (let* ((dx (ly:grob-relative-coordinate grob common-x X))
;;;
;; TODO (2)
;;;
;;  Do we need to calculate `dy' at all?
;;  Will (ly:grob-relative-coordinate grob common-y Y) ever be not zero, if
;;  grob and common-Y are equal?
;;  Is it possible at all they are ever unequal? ly-counter-example?!
 (dy (if simple-y?
 0
 (ly:grob-relative-coordinate grob common-y Y)))
;;;
;; TODO (1)
;;;
;; Why call 

Re: markup-command rounded-box is broken

[Thomas Morley]

Am So., 10. Okt. 2021 um 11:06 Uhr schrieb Lukas-Fabian Moser :
>
>
> > this would have the advantage to be inline with the doc-string and
> > solve the issue at hand.
> Should I prepare a MR?

Please, do so.
Additionally, I'll think a bit deeper about below.

Thanks,
  Harm
> > Though, speaking of refactoring rounded-box-stencil.
> > It always bugs me to see some stencil overlaying to get a simple line.
>
> Yes, that's an obvious and unpleasant limitation: Something that should
> behave as transparent (cut-out of another object) is mimicked by a
> hardcoded white area.
>
> I'm not sure this can be remedied easily. I don't understand much of the
> output code, but my impression is that filled-rounded-boxes are created
> by using corresponding features of the respective output engine (PS
> interpreters, SVG standard, Cairo). I may be wrong, but this would seem
> to indicate that, for an actual solution, one would either need actual
> nonfilled-rounded-box support in all these engines, or instead a way to
> remove parts of an already drawn stencil.
>
> But I'm happy to be corrected by those who understand the workings of
> the output engines.
>
> Lukas
>

Re: markup-command rounded-box is broken

[Thomas Morley]

Am So., 10. Okt. 2021 um 10:21 Uhr schrieb Lukas-Fabian Moser :
>
>
> > So in my impression, rounded-box-stencil might deserve a refactoring
> > anyway?
>
> I would propose:
>
> lukas@Aquarium:~/git/lilypond/scm(dev/lfm/rounded-box)$ git diff master
> diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
> index cb99a960fe..8b54fd048a 100644
> --- a/scm/define-markup-commands.scm
> +++ b/scm/define-markup-commands.scm
> @@ -960,8 +960,7 @@ c,8. c16 c4 r
>  thickness))
>   (pad (* (magstep font-size) box-padding))
>   (m (interpret-markup layout props arg)))
> -(ly:stencil-add (rounded-box-stencil m th pad corner-radius)
> -m)))
> +(rounded-box-stencil m th pad corner-radius)))
>
>   (define-markup-command (rotate layout props ang arg)
> (number? markup?)
> diff --git a/scm/stencil.scm b/scm/stencil.scm
> index 0409242a05..e1df561fa6 100644
> --- a/scm/stencil.scm
> +++ b/scm/stencil.scm
> @@ -708,12 +708,11 @@ producing a new stencil."
>(interval-widen xext ideal-thickness)
>(interval-widen yext ideal-thickness)
>ideal-blot))
> - (inner (ly:make-stencil (ly:stencil-in-color
> -  (ly:round-filled-box
> -   xext yext (- ideal-blot
> ideal-thickness))
> -   "white"
> -(set! stencil (ly:stencil-add outer inner))
> -stencil))
> + (inner (ly:stencil-in-color
> + (ly:round-filled-box
> + xext yext (- ideal-blot ideal-thickness))
> + "white")))
> +(ly:stencil-add outer inner stencil)))
>
>   (define-public (flip-stencil axis stil)
> "Flip stencil @var{stil} in the direction of @var{axis}.
>
> Lukas
>

Hi Lukas,

this would have the advantage to be inline with the doc-string and
solve the issue at hand.

Though, speaking of refactoring rounded-box-stencil.
It always bugs me to see some stencil overlaying to get a simple line.
Here it leads to different behaviour of \box and \rounded-box:

\markup
  \overlay {
  \stencil
  #(stencil-with-color (make-filled-box-stencil '(-1 . 4) '(-1 . 3)) red)
  \rounded-box "foo"
  }

\markup
  \overlay {
  \stencil
  #(stencil-with-color (make-filled-box-stencil '(-1 . 4) '(-1 . 3)) red)
  \box "foo"
  }

Though, I've no good idea how to improve it.

Cheers,
  Harm