Re: calculation in scheme causes "assertion failed" as of Ly 2.25.11

[Michael Käppler via bug-lilypond]

Hi Klaus,
thanks for reporting, I can confirm this behaviour on my Windows machine.
Now tracked as https://gitlab.com/lilypond/lilypond/-/issues/6710

Michael

Am 21.04.2024 um 18:39 schrieb K. Blum:

Hi Michael,

Am 12.04.2024 um 18:00 schrieb bug-lilypond-requ...@gnu.org:

This seems to be:

https://gitlab.com/lilypond/lilypond/-/issues/6687

Should be fixed in the upcoming release 2.25.15.


Thanks for that information.
Unfortunately the problem still persists in the 2.25.15 Windows build.
Does that mean it is not related to issue 6687?

Cheers,
Klaus

Re: calculation in scheme causes "assertion failed" as of Ly 2.25.11

[K. Blum via bug-lilypond]

Hi Michael,

Am 12.04.2024 um 18:00 schrieb bug-lilypond-requ...@gnu.org:

This seems to be:

https://gitlab.com/lilypond/lilypond/-/issues/6687

Should be fixed in the upcoming release 2.25.15.


Thanks for that information.
Unfortunately the problem still persists in the 2.25.15 Windows build.
Does that mean it is not related to issue 6687?

Cheers,
Klaus

Re: Fix aclocal.m4 fontforge version detection

[Werner LEMBERG]

> I am forwarding this bug report here:
> 
> https://bugs.gentoo.org/913928

Thanks for the report!  I've fixed the problem with the FontForge
version and with the non-portable `test` options.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2301


Werner

Re: calculation in scheme causes "assertion failed" as of Ly 2.25.11

[Michael Käppler via bug-lilypond]

Am 11.04.2024 um 22:05 schrieb Aaron Hill via bug-lilypond:


Seems to be something specific to the Windows build.  I could not
reproduce the failing assertion on the Linux builds of LilyPond also
running Guile 3.0.9.  I could reproduce it with the 2.25.14 Windows
build using scheme-sandbox.ly as well as using the -e command-line
option:

  lilypond -e "(let* ((a 1) (b -3) (c (+ b 0.3))) (> (- b (/ a 2)) c))"

This seems to be:

https://gitlab.com/lilypond/lilypond/-/issues/6687

Should be fixed in the upcoming release 2.25.15.

Michael

Re: calculation in scheme causes "assertion failed" as of Ly 2.25.11

[Aaron Hill via bug-lilypond]

On 2024-04-11 10:12 am, K. Blum via bug-lilypond wrote:

Starte lilypond.exe 2.25.14 [mwe scheme.ly]...
»C:/Users/Flower/Desktop/mwe scheme.ly« wird verarbeitet
Analysieren.../home/lily/lilypond-2.25.14/release/binaries/mingw/dependencies/src/guile-3.0.9/libguile/integers.c:115:
assertion failed
Wurde mit dem Return-Code 3 beendet.



Assertion [1] is from the negative_long function in integers.c:

 112 static inline long
 113 negative_long (unsigned long mag)
 114 {
 115   ASSERT (mag <= (unsigned long) LONG_MIN);
 116   return ~mag + 1;
 117 }

[1]: 
https://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/integers.c;h=cc62d1c7847a0eef47b86e340295f43df01a9f50;hb=9b20ca275dba758a194073936cde7c95311bd51e#l115



Seems to be something specific to the Windows build.  I could not 
reproduce the failing assertion on the Linux builds of LilyPond also 
running Guile 3.0.9.  I could reproduce it with the 2.25.14 Windows 
build using scheme-sandbox.ly as well as using the -e command-line 
option:


  lilypond -e "(let* ((a 1) (b -3) (c (+ b 0.3))) (> (- b (/ a 2)) c))"


-- Aaron Hill

Re: Snippet 960 fails with Ly 2.25

[K. Blum via bug-lilypond]

Hi Harm, hi Aaron,

thanks a million for your immediate help. Good to know that this will
continue working in 2.25.

Aaron, I don't entirely agree that this is obsolete... it shows a
mechanism that can be further expanded. It is also the base for
https://lsr.di.unimi.it/LSR/Item?id=1000
and (even further developped)
https://github.com/openlilylib/analysis/wiki/Frames

I'll see what I can do to update those in a similar manner.

Cheers,
Klaus


Am 02.04.2024 um 01:11 schrieb Aaron Hill:

On 2024-04-01 3:20 pm, K. Blum via bug-lilypond wrote:

Hello,

LSR snippet 960 works alright with LilyPond 2.24.3 and earlier.
Ly 2.25.1 (and later) aborts with an error message, see below.
In the docs I haven't found any changes to the functions in use.
Also tried convert-ly, but it did not change anything from the code.
Am I missing something or is this a bug?

Snippet 960: https://lsr.di.unimi.it/LSR/Item?id=960



It's an obsolete snippet that will likely need to be removed when LSR
moves to 2.26 as the stable version.  This type of functionality is
directly supported in LilyPond via staff highlights [1].

[1]:
https://lilypond.org/doc/v2.25/Documentation/notation/staff-highlights

The source of the error is how colors need to be handled.  Add an
explicit call to normalize-color:


    (ly:make-stencil (list 'color (normalize-color color)



-- Aaron Hill

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Werner LEMBERG]

>> In contrast to Jean, I have a different point of view.  I think it
>> would be *very* valuable to have documentation strings of *all*
>> functions that might be useful in the long run
> 
> Oh, that's also my point of view — it *would* be very valuable.
> Just... IMO not realistic. It already took me weeks to write the
> extending-lilypond guide (not counting the effort to understand the
> code base in the first place). "rg '```\{func\}' | wc -l" tells me
> that currently 76 functions are documented in the guide, so the
> multiplier to get more usable documentation for all functions that
> are already documented is already ~10, and there are the
> undocumented ones also.

I'm very grateful for your work (and I should eventually have a closer
look whether some of the documentation can be ported to the IR)!
However, you probably did a systematic approach to the functions as
needed for the guide – this is something I don't suggest here.
Instead, I plead that interested users who stumble upon insufficient
documentation should be encouraged to provide patches *for whatever
they are interested in*.  No need for being thorough; even the
smallest breadcrumbs are potentially useful for all users.


Werner

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Jean Abou Samra]

> In contrast to Jean, I have a different point of view.  I think it
> would be *very* valuable to have documentation strings of *all*
> functions that might be useful in the long run


Oh, that's also my point of view — it *would* be very valuable.
Just... IMO not realistic. It already took me weeks to write
the extending-lilypond guide (not counting the effort to understand
the code base in the first place). "rg '```\{func\}' | wc -l" tells
me that currently 76 functions are documented in the guide, so the
multiplier to get more usable documentation for all functions that
are already documented is already ~10, and there are the undocumented
ones also.



signature.asc
Description: This is a digitally signed message part

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Werner LEMBERG]

> The naming of lilypond scheme functions can be really unintuitive
> sometimes.  At the very least, the internals reference could use
> some major extensions making clear what the functions do and how,
> with examples.  Via [1], it would have been impossible for me to
> understand what scorify-music does or that I need this function over
> ly:make-score.  Am I missing some other place where this is already
> documented in more detail?

In contrast to Jean, I have a different point of view.  I think it
would be *very* valuable to have documentation strings of *all*
functions that might be useful in the long run (of course, it is
debatable which functions these are exactly).  A lot of code is
written in Guile and C++, which is sometimes very hard to read for
non-C++ programmers.  So...

> If not, I'd be happy to start investing my time to contribute to the
> Internals reference documentation, especially Section 4 "Scheme
> functions".  In addition to better explanatory texts this section
> could benefit from more crosslinks and examples - or maybe the
> examples should be in a different (new) section to keep this
> reference concise.  I'd be happy to discuss this further.

... I'm very grateful for your offer.

> As a start, here are my suggestions for the two functions in
> question: [...]

Thanks, see

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2294

> If someone else is already working improving this Section, you may
> let me know - I'd love to join in.

You will be mostly a lone fighter, sorry :-|  

> Otherwise, as my understanding of the internals is still
> fragmentary, I'd need some help getting things right.  I could just
> continue to send improvement suggestions as mentioned in [2] to this
> mailinglist (or lilypond-devel?) and someone corrects me if I get
> things wrong? Or is someone willing to "proofread" some suggestions
> of mine in advance so I do not add too much noise to the
> mailinglists?  I could also give larger-scale structural improvement
> suggestion as a start for debate if you would consider this
> appropriate from a "newbie" to the mailinglists.

I think the best way to contribute is to get an account on GitLab,
clone the 'lilypond' git repository and submit Merging Requests,
closely following the formatting of other documentation strings.  All
documentation that goes into the IR uses Texinfo syntax.

And yes, larger-scale stuff should be discussed first on
'lilypond-devel'.


 Werner

Re: Snippet 960 fails with Ly 2.25

[Aaron Hill via bug-lilypond]

On 2024-04-01 3:20 pm, K. Blum via bug-lilypond wrote:

Hello,

LSR snippet 960 works alright with LilyPond 2.24.3 and earlier.
Ly 2.25.1 (and later) aborts with an error message, see below.
In the docs I haven't found any changes to the functions in use.
Also tried convert-ly, but it did not change anything from the code.
Am I missing something or is this a bug?

Snippet 960: https://lsr.di.unimi.it/LSR/Item?id=960



It's an obsolete snippet that will likely need to be removed when LSR 
moves to 2.26 as the stable version.  This type of functionality is 
directly supported in LilyPond via staff highlights [1].


[1]: 
https://lilypond.org/doc/v2.25/Documentation/notation/staff-highlights


The source of the error is how colors need to be handled.  Add an 
explicit call to normalize-color:



(ly:make-stencil (list 'color (normalize-color color)



-- Aaron Hill

Re: Snippet 960 fails with Ly 2.25

[Thomas Morley]

Am Di., 2. Apr. 2024 um 00:21 Uhr schrieb K. Blum via bug-lilypond
:
>
> Hello,
>
> LSR snippet 960 works alright with LilyPond 2.24.3 and earlier.
> Ly 2.25.1 (and later) aborts with an error message, see below.
> In the docs I haven't found any changes to the functions in use.
> Also tried convert-ly, but it did not change anything from the code.
> Am I missing something or is this a bug?
>
> Snippet 960: https://lsr.di.unimi.it/LSR/Item?id=960
>
> Here is a (not quite) MWE:
> %%
> colorSpan =
> #(define-music-function (y-lower y-upper color)
> (number? number? color?)
> #{
>   \once \override HorizontalBracket.stencil =
>   $(lambda (grob)
>  (let* (
>  (area (ly:horizontal-bracket::print grob))
>  (X-ext (ly:stencil-extent area X))
>  (Y-ext (ly:stencil-extent area Y)))
>(set! Y-ext (cons y-lower y-upper))
>(ly:grob-set-property! grob 'layer -10)
>(ly:make-stencil (list 'color color
>   (ly:stencil-expr (ly:round-filled-box
> X-ext Y-ext 0))
>   X-ext Y-ext
>   \once\override HorizontalBracket.Y-offset = #0
> #})
>
> \score {
>{
>  \colorSpan #-4 #4 #green
>  c'2\startGroup g' c'\stopGroup r
>}
>\layout {
>  \context {
>\Voice
>\consists "Horizontal_bracket_engraver"
>  }
>}
> }
> %%
>
> The error message from Ly 2.25.1 reads:
> ---
> Starte lilypond.exe 2.25.1 [mwe.ly]...
> »C:/Users/Flower/AppData/Local/Temp/frescobaldi-0hwxag11/tmp9kixmwyv/mwe.ly«
> wird verarbeitet
> Analysieren...
> Interpretation der Musik...
> Vorverarbeitung der grafischen Elemente...
> Ideale Seitenanzahl wird gefunden...
> Musik wird auf eine Seite angepasst...
> Systeme erstellen...
> C:/Portable/lilypond-2.25.1/share/lilypond/2.25.1/ly/init.ly:64:2:
> Fehler: Guile signaled an error for the expression beginning here
> #
>   (let ((book-handler (if (defined? 'default-toplevel-book-handler)
> In procedure cadddr: Wrong type (expecting pair): ()
> Wurde mit dem Return-Code 1 beendet.
>

Fixed in LSR.
Works now for 2.24 and 2.25

Cheers,
  Harm

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Jean Abou Samra]

> Thank you so much, that did the trick. 
> 
> The naming of lilypond scheme functions can be really unintuitive
> sometimes. At the very least, the internals reference could use
> some major extensions making clear what the functions do and how,
> with examples. Via [1], it would have been impossible for me to
> understand what scorify-music does or that I need this function
> over ly:make-score. Am I missing some other place where this is
> already documented in more detail?
> 
> If not, I'd be happy to start investing my time to contribute to
> the Internals reference documentation, especially Section 4 "Scheme
> functions". In addition to better explanatory texts this section
> could benefit from more crosslinks and examples - or maybe the
> examples should be in a different (new) section to keep this
> reference concise. I'd be happy to discuss this further.


Not that improvements like this are not welcome, but if you want
my honest opinion, documenting public functions to the degree that
one could use them just from the manual is a lost cause. There
are way too many of them (740 functions in the current Internals
Reference, but many more exist which are undocumented). I think
we just have to accept that, these functions being largely the deep
guts of LilyPond exposed for anyone to use, you have to be a bit
familiar with the source code in order to use them correctly.

I think the best we can do is high-level extending documentation
— like what I've tried to do in https://extending-lilypond.gitlab.io —
supplemented by a dose of "read the source code" for advanced usage.

Note that I didn't know about scorify-music before you sent this
bug report. I just knew that chord repeats are expanded by a music
function in toplevel-music-functions, and I did a bit of grepping
in order to find the call site.

Best,
Jean



signature.asc
Description: This is a digitally signed message part

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Lovis B. Suchmann]

On Saturday, March 30th, 2024 at 18:01, Jean Abou Samra  
wrote:

> Le samedi 30 mars 2024 à 16:47 +, Lovis B. Suchmann a écrit :
> 
> > \version "2.24.3"
> > 
> > % Repeated chords (via "q") are not rendered when using ly:book-process.
> > 
> > test = { r4  r q | }
> > 
> > \book { \score { \test \layout {} } }
> > 
> > #(ly:book-process (ly:make-book $defaultpaper
> > #f
> > (ly:make-score test))
> > $defaultpaper
> > $defaultlayout
> > (string-append (ly:parser-output-name) "-1"))
> 
> 
> 
> 
> This isn't a bug. You probably want to use scorify-music instead of
> the low-level function ly:make-score.


Thank you so much, that did the trick. 

The naming of lilypond scheme functions can be really unintuitive sometimes. At 
the very least, the internals reference could use some major extensions making 
clear what the functions do and how, with examples. Via [1], it would have been 
impossible for me to understand what scorify-music does or that I need this 
function over ly:make-score. Am I missing some other place where this is 
already documented in more detail?

If not, I'd be happy to start investing my time to contribute to the Internals 
reference documentation, especially Section 4 "Scheme functions". In addition 
to better explanatory texts this section could benefit from more crosslinks and 
examples - or maybe the examples should be in a different (new) section to keep 
this reference concise. I'd be happy to discuss this further.

As a start, here are my suggestions for the two functions in question:

- - - - -
A) In Internals, Section 4 "Scheme functions", change the explanation text for 
"scorify-music" as follows:

Preprocess _music_ and encapsulate it into a score smob. 

Among other things, preprocessing replaces chord repetitions via `q` with the 
correct actual chords.

B) In Internals, Section 4 "Scheme functions", change the explanation text for 
"ly:make-score" as follows:

Encapsulate _music_ into a score smob. 

Note: This is a low-level function that does not preprocess _music_ in any way. 
You might be looking for `scorify-music` instead, which also preprocesses 
_music_.
- - - - -


If someone else is already working improving this Section, you may let me know 
- I'd love to join in. Otherwise, as my understanding of the internals is still 
fragmentary, I'd need some help getting things right. I could just continue to 
send improvement suggestions as mentioned in [2] to this mailinglist (or 
lilypond-devel?) and someone corrects me if I get things wrong? Or is someone 
willing to "proofread" some suggestions of mine in advance so I do not add too 
much noise to the mailinglists? I could also give larger-scale structural 
improvement suggestion as a start for debate if you would consider this 
appropriate from a "newbie" to the mailinglists.

I'd be thankful for any pointers on the best way to keep contributing to this 
part of the documentation and help this amazing project (which I have been 
using for many years!) become even better.

Cheers!
Lovis



[1] https://lilypond.org/doc/v2.24/Documentation/internals/scheme-functions
[2] 
https://lilypond.org/doc/v2.24/Documentation/contributor/documentation-suggestions

Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.

[Jean Abou Samra]

Le samedi 30 mars 2024 à 16:47 +, Lovis B. Suchmann a écrit :
> \version "2.24.3"
> 
> % Repeated chords (via "q") are not rendered when using ly:book-process.
> 
> test = { r4  r q | }
> 
> \book { \score { \test \layout {} } }
> 
> #(ly:book-process (ly:make-book $defaultpaper
> #f
> (ly:make-score test))
> $defaultpaper
> $defaultlayout
> (string-append (ly:parser-output-name) "-1"))



This isn't a bug. You probably want to use scorify-music instead of
the low-level function ly:make-score.


signature.asc
Description: This is a digitally signed message part

Re: Glossary: "simile mark" and German translation "Faulenzer"

[Werner LEMBERG]

> A suggestion for the Glossary in the documentation since I just
> learned that percent repeats are called "Faulenzer" in colloquial
> German after I had sought the word in vain in the Lilypond glossary
> and documentation. Or two suggestions, really.  [...]

Thanks, this is now part of a merge request, see

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2291


 Werner

Re: Failure of convert-ly to run

[Werner LEMBERG]

> I have a file for which convert-ly crashes.  [...]
>
> It seems to be fixed by changing line 2152 of convertrules.py by
> putting the second argument as a raw string:
>
> ```
> s = re.sub(r'''((\\"|})\s*){''', r'\2 \\line {', s)
> ```

Thanks for the report!

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2289


 Werner

Re: Incorrectly-placed slur when hide-tied-accidental-after-break sometimes

[Werner LEMBERG]

> In the following example, when a note has a slur and a tie and
> hide-tied-accidental-after-break is enabled, the slur is incorrectly
> placed when another staff has many accidentals.

Thanks for the report.  However, I don't think the problem is
especially related to accidentals; it's rather one of the many cases
where LilyPond's automatic tie and slur positioning algorithm makes
bad choices – there are plenty of issues already registered in our bug
tracker, some of them older than 15 years and still unresolved, alas.
Just look up the labels 'ties' and 'slurs'.

Note that you get almost the same bad results in your example if you
omit 'hide-tied-accidental-after-break'.  Similarly, the results are
differently bad if you omit the accidentals altogether.

```
\version "2.25.13"

<<
  \new Staff {
\override Tie.color = #red
\override Accidental.hide-tied-accidental-after-break = ##t
cis''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>

<<
  \new Staff {
\override Tie.color = #red
cis''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>

<<
  \new Staff {
\override Tie.color = #red
c''1~( \break 1)
  }
  \new Staff {
R1 1
  }
>>
```


Werner

Re: Chord names collide with span bar

[Werner LEMBERG]

>> Since I don't have experience with chord names I ask users who need
>> this feature to check whether it works as expected in general.
> 
> It works like a charm in my source!  Thanks for researching this.

:-)

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2281


 Werner

Re: Chord names collide with span bar

[Knute Snortum]

On Thu, Mar 21, 2024 at 2:30 PM Werner LEMBERG  wrote:

>
> I think I've found the real fix for the problem.  Suddenly remembering
> that we already have the `Span_bar_stub_engraver` to handle exactly
> such situations I wondered why it works for lyrics but not for chord
> names.  Comparing the definitions of the two contexts in
> `engraver-init.ly` I found out that the `Pure_from_neighbor_engraver`
> was missing, and adding it seems to do the trick.
>
>
> ```
> \version "2.25.13"
>
> \layout {
>   \context {
> \ChordNames
> \consists Pure_from_neighbor_engraver
>   }
> }
>
> \score {
>   \new GrandStaff <<
> \new Staff \relative { c''4 c c c | c c c c }
> \new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
> \new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
>   >>
> }
> ```
>
>
> Since I don't have experience with chord names I ask users who need
> this feature to check whether it works as expected in general.
>

It works like a charm in my source!  Thanks for researching this.


--
Knute Snortum

Re: Chord names collide with span bar

[Werner LEMBERG]

>>> I remembered that you can add the Bar_engraver to ChordNames.
>>> Making them transparent so they do not visually interfere with the
>>> SpanBar, but they still take up space.
>>
>> Nice!  This begs the question whether we have a real bug or 'just'
>> insufficient documentation...
>
> I was thinking about commands like \textLengthOn.  Would there be
> value in providing a more consistent way to handle this use case
> without having to manually do what I did?  It feels a little bit
> hacky to be instantiating transparent BarLines.  I could see an LSR
> snippet being created to demonstrate the technique, but would we
> want it in the docs?

I think I've found the real fix for the problem.  Suddenly remembering
that we already have the `Span_bar_stub_engraver` to handle exactly
such situations I wondered why it works for lyrics but not for chord
names.  Comparing the definitions of the two contexts in
`engraver-init.ly` I found out that the `Pure_from_neighbor_engraver`
was missing, and adding it seems to do the trick.


```
\version "2.25.13"

\layout {
  \context {
\ChordNames
\consists Pure_from_neighbor_engraver
  }
}

\score {
  \new GrandStaff <<
\new Staff \relative { c''4 c c c | c c c c }
\new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
\new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
  >>
}
```


Since I don't have experience with chord names I ask users who need
this feature to check whether it works as expected in general.


Werner

Re: Chord names collide with span bar

[Knute Snortum]

On Wed, Mar 20, 2024 at 8:54 AM Aaron Hill  wrote:

> Oh, I think I found another option:
>
> 
> \version "2.25.13"
>
> #(ly:set-option 'debug-skylines #t)
> \layout {
>\context { \Score
>  \override NonMusicalPaperColumn.show-horizontal-skylines = ##t
>}
>\context { \ChordNames
>  \consists "Bar_engraver"
>  \override BarLine.bar-extent = #'(0 . 1)
>  \override BarLine.transparent = ##t
>}
> }
>
>
Yes, that fixes everything!  Thank you so much.

-- 
Knute Snortum

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-20 9:01 am, Werner LEMBERG wrote:

I remembered that you can add the Bar_engraver to ChordNames.
Making them transparent so they do not visually interfere with the
SpanBar, but they still take up space.


Nice!  This begs the question whether we have a real bug or 'just'
insufficient documentation...



I was thinking about commands like \textLengthOn.  Would there be value 
in providing a more consistent way to handle this use case without 
having to manually do what I did?  It feels a little bit hacky to be 
instantiating transparent BarLines.  I could see an LSR snippet being 
created to demonstrate the technique, but would we want it in the docs?



-- Aaron Hill

Re: Chord names collide with span bar

[Werner LEMBERG]

> Oh, I think I found another option:
>
> 
> \version "2.25.13"
>
> #(ly:set-option 'debug-skylines #t)
> \layout {
>   \context { \Score
> \override NonMusicalPaperColumn.show-horizontal-skylines = ##t
>   }
>   \context { \ChordNames
> \consists "Bar_engraver"
> \override BarLine.bar-extent = #'(0 . 1)
> \override BarLine.transparent = ##t
>   }
> }
>
> \score {
>   \new GrandStaff <<
> \new Staff \relative { c''4 c c c | c c c c }
> \new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
> \new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
>   >>
> }
> 
>
> I remembered that you can add the Bar_engraver to ChordNames.
> Making them transparent so they do not visually interfere with the
> SpanBar, but they still take up space.

Nice!  This begs the question whether we have a real bug or 'just'
insufficient documentation...


Werner

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-20 8:14 am, Knute Snortum wrote:
Ah, I see this is just for debugging.  Thank you.  Your solution helps 
when

put into my bigger project.  Some -- but not all -- of the bars are now
wide enough.



Oh, I think I found another option:


\version "2.25.13"

#(ly:set-option 'debug-skylines #t)
\layout {
  \context { \Score
\override NonMusicalPaperColumn.show-horizontal-skylines = ##t
  }
  \context { \ChordNames
\consists "Bar_engraver"
\override BarLine.bar-extent = #'(0 . 1)
\override BarLine.transparent = ##t
  }
}

\score {
  \new GrandStaff <<
\new Staff \relative { c''4 c c c | c c c c }
\new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
\new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
  >>
}


I remembered that you can add the Bar_engraver to ChordNames.  Making 
them transparent so they do not visually interfere with the SpanBar, but 
they still take up space.



-- Aaron Hill

Re: Chord names collide with span bar

[Knute Snortum]

On Wed, Mar 20, 2024 at 8:01 AM Aaron Hill  wrote:

> ly:separation-item::print no longer exists, as all grobs support the
> properties show-horizontal-skylines and show-vertical-skylines.
>
> So, swap out that \override with:
>
> 
>\override NonMusicalPaperColumn.show-horizontal-skylines = ##t
> 
>
>
Ah, I see this is just for debugging.  Thank you.  Your solution helps when
put into my bigger project.  Some -- but not all -- of the bars are now
wide enough.

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-20 8:07 am, Jean Abou Samra wrote:

Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit :

Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit :
> Your solution requires version 2.22 and I'm using 2.24
> (with the \alternative command so it's not easy to change)

The old \alternative syntax is still supported in 2.24.



Ah, sorry. Somehow, I “autocorrected” your reply as
“Your solution requires version 2.24 and I'm on 2.22”.
Forget about it.



No worries, my guy.  It's my fault for still running 2.22 as my go-to 
version and introducing the older version into threads.



-- Aaron Hill

Re: Chord names collide with span bar

[Knute Snortum]

On Wed, Mar 20, 2024 at 8:07 AM Jean Abou Samra  wrote:

> Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit :
> > Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit :
> > > Your solution requires version 2.22 and I'm using 2.24
> > > (with the \alternative command so it's not easy to change)
> >
> > The old \alternative syntax is still supported in 2.24.
>
>
> Ah, sorry. Somehow, I “autocorrected” your reply as
> “Your solution requires version 2.24 and I'm on 2.22”.
> Forget about it.
>

Not a problem!

-- 
Knute Snortum

Re: Chord names collide with span bar

[Jean Abou Samra]

Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit :
> Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit :
> > Your solution requires version 2.22 and I'm using 2.24
> > (with the \alternative command so it's not easy to change)
> 
> The old \alternative syntax is still supported in 2.24.


Ah, sorry. Somehow, I “autocorrected” your reply as
“Your solution requires version 2.24 and I'm on 2.22”.
Forget about it.


signature.asc
Description: This is a digitally signed message part

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-20 7:51 am, Knute Snortum wrote:
Thank you so much for this fix and for entering an issue!  There is 
just
one thing that is a problem for me.  Your solution requires version 
2.22

and I'm using 2.24 (with the \alternative command so it's not easy to
change).  When I your solution convert to 2.24 (no changes) I get an 
error

executing the file:

/home/foo/bar/chords-bar-line.ly:7:9 <0>: error: Guile signaled an 
error

for the expression beginning here

#

ly:separation-item::print

Unbound variable: ly:separation-item::print


ly:separation-item::print no longer exists, as all grobs support the 
properties show-horizontal-skylines and show-vertical-skylines.


So, swap out that \override with:


  \override NonMusicalPaperColumn.show-horizontal-skylines = ##t



-- Aaron Hill

Re: Chord names collide with span bar

[Jean Abou Samra]

Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit :
> Your solution requires version 2.22 and I'm using 2.24
> (with the \alternative command so it's not easy to change)

The old \alternative syntax is still supported in 2.24.


signature.asc
Description: This is a digitally signed message part

Re: Chord names collide with span bar

[Knute Snortum]

On Tue, Mar 19, 2024 at 4:34 PM Aaron Hill  wrote:

> ...
>


> Curious.  The skylines look interesting, almost like the SpanBar is not
> being factored in, only the parts of the BarLine.
>
> Below, I attempted to add some virtual height to the ChordName, and it
> seemed to allow the ChordName to push the BarLine (and SpanBar) to the
> right:
>
> 
> \version "2.22.0"
>
> #(ly:set-option 'debug-skylines #t)
> \layout {
>\context { \Score
>  \override NonMusicalPaperColumn.stencil =
>#ly:separation-item::print
>}
>\context { \ChordNames
>  \override ChordName.extra-spacing-height =
>#'(0 . 2)
>}
> }
>
> \score {
>\new GrandStaff <<
>  \new Staff \relative { c''4 c c c | c c c c }
>  \new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
>  \new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
>>>
> }
> 
>
> Still sounds like a defect of some sort, as the default behavior should
> probably be handling things.  But perhaps this trick above might be
> useful in whatever score you are working on as a stopgap.


Aaron,

Thank you so much for this fix and for entering an issue!  There is just
one thing that is a problem for me.  Your solution requires version 2.22
and I'm using 2.24 (with the \alternative command so it's not easy to
change).  When I your solution convert to 2.24 (no changes) I get an error
executing the file:

/home/foo/bar/chords-bar-line.ly:7:9 <0>: error: Guile signaled an error
for the expression beginning here

#

ly:separation-item::print

Unbound variable: ly:separation-item::print


--

Knute Snortum

Re: Chord names collide with span bar

[Werner LEMBERG]

>> Aaron, please file an issue, referring to this e-mail thread.
> 
> First time creating an issue, so hopefully this is up to snuff.

Thanks a lot!

> Added: https://gitlab.com/lilypond/lilypond/-/issues/6703
> 
> By the by, I do not appear to have permissions for setting labels,
> but I think this issue would qualify for the "Ugly" tag.

I've just set appropriate tags.


Werner

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-20 1:45 am, Werner LEMBERG wrote:

In some situations, chord names collide with the span bar of a
Grand or Piano Staff.  Here is an example:  [...]


[...] Still sounds like a defect of some sort, as the default
behavior should probably be handling things.


Aaron, please file an issue, referring to this e-mail thread.



First time creating an issue, so hopefully this is up to snuff.

Added: https://gitlab.com/lilypond/lilypond/-/issues/6703

By the by, I do not appear to have permissions for setting labels, but I 
think this issue would qualify for the "Ugly" tag.



-- Aaron Hill

Re: Chord names collide with span bar

[Werner LEMBERG]

>> In some situations, chord names collide with the span bar of a
>> Grand or Piano Staff.  Here is an example:  [...]
> 
> [...] Still sounds like a defect of some sort, as the default
> behavior should probably be handling things.

Aaron, please file an issue, referring to this e-mail thread.


Werner

Re: Chord names collide with span bar

[Aaron Hill via bug-lilypond]

On 2024-03-19 2:29 pm, Knute Snortum wrote:
I ran into something today -- it's not quite a bug; more of an "ugly."  
In
some situations, chord names collide with the span bar of a Grand or 
Piano

Staff.  Here is an example:

\version "2.25.13"

\score {
  \new GrandStaff <<
\new Staff \relative { c''4 c c c | c c c c }
\new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
\new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
  >>
}



Curious.  The skylines look interesting, almost like the SpanBar is not 
being factored in, only the parts of the BarLine.


Below, I attempted to add some virtual height to the ChordName, and it 
seemed to allow the ChordName to push the BarLine (and SpanBar) to the 
right:



\version "2.22.0"

#(ly:set-option 'debug-skylines #t)
\layout {
  \context { \Score
\override NonMusicalPaperColumn.stencil =
  #ly:separation-item::print
  }
  \context { \ChordNames
\override ChordName.extra-spacing-height =
  #'(0 . 2)
  }
}

\score {
  \new GrandStaff <<
\new Staff \relative { c''4 c c c | c c c c }
\new ChordNames \chordmode { c2. q8. des16:maj9 | q1 }
\new Staff { \improvisationOn b'4 4 4 8. 16~ | 4 4 4 4 }
  >>
}


Still sounds like a defect of some sort, as the default behavior should 
probably be handling things.  But perhaps this trick above might be 
useful in whatever score you are working on as a stopgap.



-- Aaron Hill

Re: Reply to digest

[Simon Albrecht via bug-lilypond]

On 04.03.24 14:12, David Kastrup wrote:

Did you really have to_quote_  all of the quoted messages of last week
_again_  to make that point?

That will make all of those nonsensically quoted messages from last week
appear_twice_  in next week's digest.


I did not have to, and that was again inconsiderate. Sorry!

Re: Reply to digest

[David Kastrup]

Simon Albrecht via bug-lilypond  writes:

> Hi Cameron,
>
> please never reply to the digest form. The email will have incorrect
> headers, be displayed incorrectly in thread views, and mixing replies
> to different threads is wholly inconvenient as well. Bear in mind that
> this is sent to very many people who may or may not be interested in
> all topics on the list.

Did you really have to _quote_ all of the quoted messages of last week
_again_ to make that point?

That will make all of those nonsensically quoted messages from last week
appear _twice_ in next week's digest.

-- 
David Kastrup

Re: Re: (non-bug) lilypond-book & secondary source files

[Cameron Crowe via bug-lilypond]

Thank you- good points, RE backups and copyrights.

Similar punishment!



Sent with Proton Mail secure email.

On Sunday, March 3rd, 2024 at 12:00 PM, bug-lilypond-requ...@gnu.org 
 wrote:

> Send bug-lilypond mailing list submissions to
> bug-lilypond@gnu.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
> or, via email, send a message with subject or body 'help' to
> bug-lilypond-requ...@gnu.org
> 
> You can reach the person managing the list at
> bug-lilypond-ow...@gnu.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-lilypond digest..."
> 
> 
> Today's Topics:
> 
> 1. (non-bug) lilypond-book & secondary source files (Cameron Crowe)
> 2. Re: (non-bug) lilypond-book & secondary source files
> (David Kastrup)
> 3. copyright date (Cameron Crowe)
> 4. Re: copyright date (Ruud Harmsen)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 02 Mar 2024 17:50:28 +
> From: Cameron Crowe cameron.cr...@protonmail.com
> 
> To: "bug-lilypond@gnu.org" bug-lilypond@gnu.org
> 
> Subject: (non-bug) lilypond-book & secondary source files
> Message-ID:
> KdjNdh4gfHFebEWvNLLMS0ROWa9MuFHJvGlv9nj0nztVvZf2lnJ_4_jhuAYAmPccVwQ8LqbOWMrOlYYKqOj5MqWHNXGkFpu6Fega7o_Y3PM=@protonmail.com
> 
> 
> Content-Type: text/plain; charset=utf-8
> 
> Just a thought--not a bug.
> 
> lilypond-book refuses to overwrite a main source file, but happily overwrites 
> secondary source files included into the main source file. Irritating if you 
> use the .tex extension for included chapters of a musicological document and 
> even just accidentally call lilypond-book without specifying a separate 
> output dir.
> 
> "Don't do that." and "Version control!" would be perfectly good responses, 
> and I probably have a few other minor (shrug-worth?) points if there is 
> interest in hearing them.
> 
> In any case, I'm hugely fond of LP. Truly, thank you, devs and other 
> contributors!
> 
> - Cam
> 
> --
> 
> Message: 2
> Date: Sat, 02 Mar 2024 19:04:33 +0100
> From: David Kastrup d...@gnu.org
> 
> To: bug-lilypond@gnu.org
> Subject: Re: (non-bug) lilypond-book & secondary source files
> Message-ID: 87y1b05x3i@fencepost.gnu.org
> 
> Content-Type: text/plain
> 
> Cameron Crowe via bug-lilypond bug-lilypond@gnu.org writes:
> 
> > Just a thought--not a bug.
> > 
> > lilypond-book refuses to overwrite a main source file, but happily
> > overwrites secondary source files included into the main source
> > file. Irritating if you use the .tex extension for included chapters
> > of a musicological document and even just accidentally call
> > lilypond-book without specifying a separate output dir.
> > 
> > "Don't do that." and "Version control!" would be perfectly good
> > responses,
> 
> 
> Version control is not a substitute for backups.
> 
> > and I probably have a few other minor (shrug-worth?) points if there
> > is interest in hearing them.
> 
> 
> Just anecdotally: on MSDOS file systems, writing a file whatever.tex.aux
> was equivalent to writing a file whatever.tex and when writing
> \include{something} in a LaTeX file, this caused a file something.aux to
> be created/written.
> 
> This made the punishment for writing \include{something.tex} instead of
> the correct \include{something} pretty severe (until MikTeX was made to
> detect this special case and refuse the operation).
> 
> --
> David Kastrup
> 
> 
> 
> --
> 
> Message: 3
> Date: Sat, 02 Mar 2024 21:01:14 +
> From: Cameron Crowe cameron.cr...@protonmail.com
> 
> To: "bug-lilypond@gnu.org" bug-lilypond@gnu.org
> 
> Subject: copyright date
> Message-ID:
> 9ZBjOvJUSI-FNgj-nQJLy1aEQv_S3jtAXlUA4Ke5SrGbbnnCXmyR_XNlj_wf9JXlbR2LyiUUhl8UE44CRxXuSmWvhYTULXIjx8pxWPpmHFs=@protonmail.com
> 
> 
> Content-Type: text/plain; charset=utf-8
> 
> I think the copyright is out of date for versions 2.24 and 2.25
> 
> GNU LilyPond 2.24.3 (running Guile 2.2)
> 
> Copyright (c) 1996--2023 by
> Han-Wen Nienhuys han...@xs4all.nl
> 
> Jan Nieuwenhuizen jann...@gnu.org
> 
> and others.
> 
> GNU LilyPond 2.25.13 (running Guile 3.0)
> 
> Copyright (c) 1996--2023 by
> Han-Wen Nienhuys han...@xs4all.nl
> 
> Jan Nieuwenhuizen jann...@gnu.org
> 
> and others.
> 
> --
> 
> Message: 4
> Date: Sun, 03 Mar 2024 10:25:58 +0100

Re: copyright date

[Ruud Harmsen]

10:01 PM 3/2/2024, Cameron Crowe via bug-lilypond:
I think the copyright is out of date for versions 2.24 and 2.25 
GNU LilyPond 2.24.3 (running Guile 2.2) Copyright (c) 1996--2023 
by Han-Wen Nienhuys  Jan Nieuwenhuizen 
 and others. GNU LilyPond 2.25.13 (running 
Guile 3.0) Copyright (c) 1996--2023 by Han-Wen Nienhuys 
 Jan Nieuwenhuizen  and others.


By the way, dating a copyright to make it valid was only required 
by US law, not elsewhere, and even in the US that requirement was 
abolished in I think it was 1970. Nowadays the copyright exists 
even without any copyright notice, dated or not. What is required 
is a maker, and creative content.


--
Ruud Harmsen, https://rudhar.com

Re: (non-bug) lilypond-book & secondary source files

[David Kastrup]

Cameron Crowe via bug-lilypond  writes:

> Just a thought--not a bug.
>
> lilypond-book refuses to overwrite a main source file, but happily
> overwrites secondary source files included into the main source
> file. Irritating if you use the .tex extension for included chapters
> of a musicological document and even just accidentally call
> lilypond-book without specifying a separate output dir.
>
> "Don't do that." and "Version control!" would be perfectly good
> responses,

Version control is not a substitute for backups.

> and I probably have a few other minor (shrug-worth?) points if there
> is interest in hearing them.

Just anecdotally: on MSDOS file systems, writing a file whatever.tex.aux
was equivalent to writing a file whatever.tex and when writing
\include{something} in a LaTeX file, this caused a file something.aux to
be created/written.

This made the punishment for writing \include{something.tex} instead of
the correct \include{something} pretty severe (until MikTeX was made to
detect this special case and refuse the operation).

-- 
David Kastrup

Re: Distance between top margin and title text in 25.2.+

[bodensohn--- via bug-lilypond]

Ok, then it's not a bug but a feature. In my opinion, it would make more sense to set "top-markup-spacing" to "0" by default instead of having some ghost value that moves the text further down. I have always done this with raise/lower when I needed it. As I said, I'm usually still using an old version of Lilypond and am not up to date with all the changes. The reason was/is the musicxml import, which was corrupted starting with some of the newer versions. 


Thanks you for the tips!!!
Andreas


Translated with www.DeepL.com/Translator (free version)

On 02.03.24 10:55, Aaron Hill via bug-lilypond  wrote:

On 2024-03-02 1:32 am, Anbo via bug-lilypond wrote:
> Hello,
>
> I don't know if this is a bug, but with the very latest Lilypond 
> versions (2.25.+) the distance between the top margin and the title 
> text does not match the value I specified, in this case 5 millimeters. 
> The distance is always significantly larger. Version 2.19.31, which I 
> still use as default, does not have this problem. The example in the 
> attachment is from Mutopia and was updated using convert-ly. I only 
> added the margins to \paper. You can see the difference if you render 
> the original (also in the attachment).


top-margin is the spacing from the edge of the paper to the inside of 
the margin.  top-markup-spacing is the spacing from the margin to the 
first markup/text on the page.  (See also top-system-spacing.)  As it 
is, you are leaving some spacing variables set to default values which 
could have changed between versions, resulting in different behavior.


You might want to utilize annotate-spacing as well, as it might help 
visualize where spacing occurs.



-- Aaron Hill

Re: Distance between top margin and title text in 25.2.+

[Anbo via bug-lilypond]

Sorry, Werner, unfortunately I didn't do that. It really didn't occur to 
me that this could be a feature. However, I don't understand why the 
default is not "0". Space is rare and you often can't waste it, 
especially not in the title.


Thanks
Andreas

PS I had already inserted "top-markup-spacing = 0\mm"

Am 02.03.2024 um 11:14 schrieb Werner LEMBERG:

I don't know if this is a bug, but with the very latest Lilypond
versions (2.25.+) the distance between the top margin and the title
text does not match the value I specified, in this case 5
millimeters.  [...]

Have you looked into the 'changes' file from LilyPond?  The first
entry for the 2.25.x series is

   Margins are now wider by default following the general layout of
   several publishers (and the recommendations of Elaine Gould).

   In order to switch back to the previous settings (e.g., to keep the
   same layout when upgrading an existing score to version 2.25.14),
   add the following code:

   ```
   \paper {
 top-margin = 5\mm
 bottom-margin = 10\mm
 top-system-spacing.basic-distance = 1
 top-markup-spacing.basic-distance = 0
 left-margin = 10\mm
 right-margin = 10\mm
 inner-margin = 10\mm
 outer-margin = 20\mm
 binding-offset = 0\mm
   }
   ```

It seems to me that you should adjust the `top-markup-spacing` value
in your settings.


 Werner

Re: Distance between top margin and title text in 25.2.+

[Werner LEMBERG]

> [...] I don't understand why the default is not "0".  Space is rare
> and you often can't waste it, especially not in the title.

If you look at *any* score from a good publisher like Henle you can
see that there is plenty of whitespace around the music *and* the text
– for good reasons, since it increases legibitily enormously.

There might be exceptional situations to reduce the space.  However,
the new values are *much* better defaults IMHO.


Werner

Re: Distance between top margin and title text in 25.2.+

[Werner LEMBERG]

> I don't know if this is a bug, but with the very latest Lilypond
> versions (2.25.+) the distance between the top margin and the title
> text does not match the value I specified, in this case 5
> millimeters.  [...]

Have you looked into the 'changes' file from LilyPond?  The first
entry for the 2.25.x series is

  Margins are now wider by default following the general layout of
  several publishers (and the recommendations of Elaine Gould).

  In order to switch back to the previous settings (e.g., to keep the
  same layout when upgrading an existing score to version 2.25.14),
  add the following code:

  ```
  \paper {
top-margin = 5\mm
bottom-margin = 10\mm
top-system-spacing.basic-distance = 1
top-markup-spacing.basic-distance = 0
left-margin = 10\mm
right-margin = 10\mm
inner-margin = 10\mm
outer-margin = 20\mm
binding-offset = 0\mm
  }
  ```

It seems to me that you should adjust the `top-markup-spacing` value
in your settings.


Werner

Re: Distance between top margin and title text in 25.2.+

[Aaron Hill via bug-lilypond]

On 2024-03-02 1:32 am, Anbo via bug-lilypond wrote:

Hello,

I don't know if this is a bug, but with the very latest Lilypond 
versions (2.25.+) the distance between the top margin and the title 
text does not match the value I specified, in this case 5 millimeters. 
The distance is always significantly larger. Version 2.19.31, which I 
still use as default, does not have this problem. The example in the 
attachment is from Mutopia and was updated using convert-ly. I only 
added the margins to \paper. You can see the difference if you render 
the original (also in the attachment).


top-margin is the spacing from the edge of the paper to the inside of 
the margin.  top-markup-spacing is the spacing from the margin to the 
first markup/text on the page.  (See also top-system-spacing.)  As it 
is, you are leaving some spacing variables set to default values which 
could have changed between versions, resulting in different behavior.


You might want to utilize annotate-spacing as well, as it might help 
visualize where spacing occurs.



-- Aaron Hill

Re: lilypond-book loglevel

[Werner LEMBERG]

> lilypond-book accepts --loglevel=WARN, but not --loglevel=WARNING.
> 
> I think WARN is for lilypond, not lilypond-book (according to the
> documentation), so maybe just misdocumented?

Indeed, it is incorrectly documented; it should be 'WARN' everywhere.
Note that the `lilypond` binary is less restrictive than the scripts;
it also accepts 'warning' or 'WARNING_FOOBAR' as possible values since
only the first few characters are checked, ignoring the case.
However, it is best to stick with the standard uppercase values.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2265

Thanks for the report!


 Werner

Re: \alternative fails if \repeat unfold proceeds it

[Knute Snortum]

On Sat, Feb 24, 2024 at 11:26 AM Jean Abou Samra  wrote:

> Le samedi 24 février 2024 à 11:05 -0800, Knute Snortum a écrit :
> > I've run into something that I think is a bug -- or I'm not understanding
> > something.  It happens when you are in a \repeat volta section and use a
> > \repeat unfold just before the \alternative section.
> >
> > \version "2.25.13"
> >
> > \relative {
> >   c''4 c c c |
> >   \repeat volta 2 {
> > \repeat unfold 2 { d4 d d d }
> > % d4 d d d % uncomment me and everything's fine
>
>
> That's legacy \alternative syntax kicking in for backwards compatibility.
> The \alternative gets attached to \repeat unfold. Try inserting {} here.
>

That works, thanks!  Do you think this deserves a "Known issues and
warnings" section in
https://lilypond.org/doc/v2.24/Documentation/notation/long-repeats#alternative-endings
?


--
Knute Snortum

Re: \alternative fails if \repeat unfold proceeds it

[Jean Abou Samra]

Le samedi 24 février 2024 à 11:05 -0800, Knute Snortum a écrit :
> I've run into something that I think is a bug -- or I'm not understanding
> something.  It happens when you are in a \repeat volta section and use a
> \repeat unfold just before the \alternative section.
> 
> \version "2.25.13"
> 
> \relative {
>   c''4 c c c |
>   \repeat volta 2 {
>     \repeat unfold 2 { d4 d d d }
>     % d4 d d d % uncomment me and everything's fine


That's legacy \alternative syntax kicking in for backwards compatibility.
The \alternative gets attached to \repeat unfold. Try inserting {} here.

>     \alternative {
>   \volta 1 { e4 e e e }
>   \volta 2 { f4 f f f }
>     }
>   }
>   g4 g g g
> }
> 
> The work around is to have one line of non-repeated notes just before the
> \alternative section.



signature.asc
Description: This is a digitally signed message part

Re: Dashed bar lines fail requirements at some sizes

[Thomas Morley]

Hi,

thanks for your report.
Apart from the last point (see below), it's mostly caused by:

commit cff90246a32186f450bab1f8cd415d320b8c0cf2
Author: Thomas Morley 
Date:   Wed Oct 4 16:18:30 2023 +0200

Dashed bar lines do not stick out

Give BarLine a little less, SpanBar a little more height.
As a result they overlap inside of a staff symbol line.

Closes #

Embarrassingly...

I'll take a closer look soon.

Am Di., 20. Feb. 2024 um 20:17 Uhr schrieb Cameron Crowe via
bug-lilypond :
>
> A few potential bugs to consider. Much appreciation!
>
> % 1. Dashed bar lines fail requirement at some sizes:
> % > The dashes in a dashed bar line covers staff lines exactly. Dashed bar
> % > lines between staves start and end on a half dash precisely.
>
> \version "2.24.3"
> #(set-global-staff-size 10)
>
> % Top missing
> \relative { d' \bar "!" }
>
> % Tiny and centered
> \score {
> \relative { d' \bar "!" }
> \layout { #(layout-set-staff-size 33) }
> }
>
> % 2. Dashed bar line appearance affected by global staff size even
> % when layout staff size fixed. Compare A and B:
>
> % A
> \version "2.24.3"
>
> #(set-global-staff-size 10)\score {
> \relative { d' \bar "!" }
> \layout { #(layout-set-staff-size 33) }
> }
>
> % B
> \version "2.24.3"
>
> \score {
> \relative { d' \bar "!" }
> \layout { #(layout-set-staff-size 33) }}
>

> % 3. Cannot end score with all bar line styles.
>
> \version "2.24.3"
> \relative { d' \bar ":" }
> \relative { d' \bar ".|" }

":" is not a predefined bar-line, i.e no bar-line is printed.
".|" has a #f-setting for line-end, i.e. no bar-line will happen there.
Thus, both are no bugs.

Cheers,
  Harm

Re: Snippets omission

[Werner LEMBERG]

> Snippets manual, MIDI chapter, Staff.midiInstrument list omits "guitar
> harmonics" between "distorted guitar" and "acoustic bass" (position
> 32).

Thanks for report; fixed in LSR #338, and the next import will fix it
in the LilyPond documentation.


Werner

Re: Imprecise font scaling

[Alexander Slávik]

> https://gitlab.com/lilypond/lilypond/-/merge_requests/2258

Great, thanks!

AS

Re: partCombine Issues Warnings When Divisi Begins Within Tied Notes

[Werner LEMBERG]

Hello Chris,


sorry for the late reply.

> Issuing a \partCombineApart between two tied notes results in a
> warning that the tie is unterminated and omits the tie from the
> printed score.  Printing the top part by itself creates the tie
> without issues.
> 
> Omitting the tie from the top part as a workaround moves the divisi
> notation backwards one note to include the first tied note.

Alas, this is a fundamental limitation of LilyPond: The part-combiner
uses different voices for single and combined parts, and currently
there is no way to have ties between voices.  I can imagine that the
part-combiner becomes more sophisticated to identify such situations
emitting a work-around; however, I don't know whether this is
possible.

Please file an issue in LilyPond's bug tracker at

  https://gitlab.com/lilypond/lilypond/-/issues

so that it is not forgotten.


Werner

Re: Imprecise font scaling

[Werner LEMBERG]

> I personally lacked this information on the page "1.8.2 Formatting
> text – Selecting font and font size", mainly the fact that
> text-font-size is in pt (as defined in other sections).

https://gitlab.com/lilypond/lilypond/-/merge_requests/2258


Werner

Re: Imprecise font scaling

[Werner LEMBERG]

> This is perhaps not the best place to discuss that, but thinking
> about it, I don't understand why text-font-size is dimensionless
> (when it actually does have a dimension).  Wouldn't text-font-size =
> 12 \pt be more intuitive (and, at the same time, allowing also other
> units)?

This is due to history.  I agree that it would be better if it had a
dimension attached to it.


Werner

Re: Imprecise font scaling

[Alexander Slávik]

This is perhaps not the best place to discuss that, but thinking about it, I 
don't understand why text-font-size is dimensionless (when it actually does 
have a dimension). Wouldn't
text-font-size = 12 \pt
be more intuitive (and, at the same time, allowing also other units)?

AS

Re: Imprecise font scaling

[Alexander Slávik]

"


Actually "NR 4.2.2 Setting the staff size" kind of document it:


The default staff size is 20 points, which corresponds to a staff height of
7.03mm (one point is equal to 100/7227 of an inch, or 2540/7227 mm).


"



Thanks! Even more info on the units can be found "5.4.2 Distances and
measurements". So there is actually quite some documentation. I personally
lacked this information on the page "1.8.2 Formatting text – Selecting font
and font size", mainly the fact that text-font-size is in pt (as defined in
other sections).




AS

"





"

Re: Imprecise font scaling

[Xavier Scheuer]

On Thu, 15 Feb 2024 at 12:35, Jean Abou Samra  wrote:
>
> IMHO, this also falls in the "not worth documenting" category. But yes,
> lily/include/dimensions.hh contains
>
> const Real INCH_TO_PT = 72.270;

Hello,

Actually "NR 4.2.2 Setting the staff size" kind of document it:
The default staff size is 20 points, which corresponds to a staff height of
7.03mm (one point is equal to 100/7227 of an inch, or 2540/7227 mm).

Kind regards,
Xavier

Re: Imprecise font scaling

[Jean Abou Samra]

> Perhaps it might be worth clarifying what sort of "pt" does LilyPond use. Or
> did I just overlook this information?


IMHO, this also falls in the "not worth documenting" category. But yes,
lily/include/dimensions.hh contains

const Real INCH_TO_PT = 72.270;




signature.asc
Description: This is a digitally signed message part

Re: Imprecise font scaling

[Alexander Slávik]

Perhaps it might be worth clarifying what sort of "pt" does LilyPond use. Or
did I just overlook this information?





For instance, run




\version "2.25.12"
\pointAndClickOff
\header { tagline = "" }
\paper { text-font-size = 12 }

\markup { LOL }




and either use -dbackend=cairo --eps, or produce standard PDF and decompress
it (e.g. with qpdf). Look for the BT command in the resulting file. You'll
find that the font size is actually ca. 11.9531, not 12. This would suggest
that the unit used is rather the TeX pt (1/72.27 in) instead of the
PostScript pt (1/72 in).





The difference

12 * 72 / 72.27 - 11.9531

is quite close to 2/1024, again, although not convincingly close.





AS

Re: Imprecise font scaling

[Ruud Harmsen]

07:25 PM 2/10/2024, Jean Abou Samra:
expects an integer size scaled by PANGO_SCALE, which is 1024. 
That is, we are

limited to a precision of 1/1024 points on the font size.


As I understand it from 
https://en.wikipedia.org/wiki/Point_(typography), nowadays a 
point is fixed to 1/72 inch or 0.353 mm. That makes 1/1024 of 
that 0.3445 µm or 344.5 nm. That is approxiately the wavelength 
of violet light, or the early beginnings of ultra violet.


Are such differences even visible on paper or on a screen? I 
doubt it very much. But I am not a DTP expert.

--
Ruud Harmsen, https://rudhar.com

Re: Imprecise font scaling

[Jean Abou Samra]

> Shall we document this somehow?

Not everything is necessarily worth documenting.



signature.asc
Description: This is a digitally signed message part

Re: Imprecise font scaling

[Alexander Slávik]

"
…expects an integer size scaled by PANGO_SCALE, which is 1024. That is, we
are


limited to a precision of 1/1024 points on the font size.
"



An "evidence" for this might be that the difference
7.73242188 - 7.73046876

is pretty close to 2/1024.




AS

Re: Imprecise font scaling

[Werner LEMBERG]

>> However, 2 * 3.86523438 = 7.73046876 != 7.73242188.

> I'm quite sure this is because of
>
>  int pango_size = static_cast (
>     std::lround (static_cast (requested_size) * PANGO_SCALE));
>
>
> in lily/font-select.cc, which we cannot really do anything about,
> because the Pango API
>
> https://docs.gtk.org/Pango/method.FontDescription.set_size.html
>
> expects an integer size scaled by PANGO_SCALE, which is 1024. That
> is, we are limited to a precision of 1/1024 points on the font size.

Shall we document this somehow?


Werner

Re: Imprecise font scaling

[Jean Abou Samra]

Sorry, my mail client changed the formatting in a way I didn't expect.
Resending.

> I'm running the following code
> 
> \version "2.25.12"
> \markup { LOL }
> \markup { \magnify #2.0 LOL }
> 
> and the results are not really precise. When producing --eps, the relevant
> output lines are
> 
> /C059-Roman 3.86523438 output-scale div selectfont
> /C059-Roman 7.73242188 output-scale div selectfont
> 
> However, 2 * 3.86523438 = 7.73046876 != 7.73242188. Basically the same
> behaviour
> can be observed when using Cairo (both for EPS and SVG).
> (Producing SVG without Cairo is pretty disastrous in this regard, but
> that doesn't bother me too much at the moment.)


I'm quite sure this is because of


 int pango_size = static_cast (
    std::lround (static_cast (requested_size) * PANGO_SCALE));


in lily/font-select.cc, which we cannot really do anything about, because
the Pango API

https://docs.gtk.org/Pango/method.FontDescription.set_size.html

expects an integer size scaled by PANGO_SCALE, which is 1024. That is, we are
limited to a precision of 1/1024 points on the font size.




signature.asc
Description: This is a digitally signed message part

Re: Imprecise font scaling

[Jean Abou Samra]

I'm running the following code

\version "2.25.12"
\markup { LOL }
\markup { \magnify #2.0 LOL }

and the results are not really precise. When producing --eps, the relevant 
output lines are

/C059-Roman 3.86523438 output-scale div selectfont
/C059-Roman 7.73242188 output-scale div selectfont

However, 2 * 3.86523438 = 7.73046876 != 7.73242188. Basically the same 
behaviour can be observed when using Cairo (both for EPS and SVG).
> (Producing SVG without Cairo is pretty disastrous in this regard, but
> that doesn't bother me too much at the moment.)


I'm quite sure this is because of

  int pango_size = static_cast (
std::lround (static_cast (requested_size) * PANGO_SCALE));

in lily/font-select.cc, which we cannot really do anything about, because
the Pango API

https://docs.gtk.org/Pango/method.FontDescription.set_size.html

expects an integer size scaled by PANGO_SCALE, which is 1024. That is, we are
limited to a precision of 1/1024 points on the font size.






signature.asc
Description: This is a digitally signed message part

Re: bug-reporting instructions need clarification

[Jean Abou Samra]

> Follow-up replies, on the other hand, come
> through without further moderation – at least I think this is the
> case, but I'm not sure.


When approving a message, the moderator can optionally choose to
add the sender to a whitelist of automatically approved addresses.
I usually do this on bug-lilypond (though not on lilypond-user).



signature.asc
Description: This is a digitally signed message part

Re: bug-reporting instructions need clarification

[Werner LEMBERG]

>> I think that postings by non-subscribers may go through moderation,
>> so they have a delay, sometimes considerable, before they appear
>> and require some manual interaction.
> 
> My last reply showed up in the email archive
> (https://lists.gnu.org/r/bug-lilypond/2024-02/msg6.html) within
> three minutes of my sending it, so either that turnaround time was
> an aberration, or your supposition is incorrect.

This remark is true for first-time posters; you were apparently lucky
that one of the (human) moderators of `bug-lilypond` found some spare
time at the right moment.  Follow-up replies, on the other hand, come
through without further moderation – at least I think this is the
case, but I'm not sure.


Werner

Re: bug-reporting instructions need clarification

[Jace Toronto via bug-lilypond]

On Wednesday, February 5, 2020, David Kastrup  wrote:
> I think that postings by non-subscribers may go through moderation, so
> they have a delay, sometimes considerable, before they appear and
> require some manual interaction.

My last reply showed up in the email archive 
(https://lists.gnu.org/r/bug-lilypond/2024-02/msg6.html) within three 
minutes of my sending it, so either that turnaround time was an aberration, or 
your supposition is incorrect.

Re: bug-reporting instructions need clarification

[Jace Toronto via bug-lilypond]

On Wednesday, February 5, 2020, David Kastrup  wrote:
> Jace Toronto via bug-lilypond  writes:
> 
> > This is a bug report on the bug-reporting instructions at
> > http://lilypond.org/website/bug-reports.html, rather than in lilypond
> > itself, but this seems the likeliest place to reach someone who can
> > address that.
> >
> > The instructions in step 3 on this page strongly imply that one has to
> > be subscribed to bug-lilypond in order to post to it (in that if
> > that's not the case, the fact that there's no longer an interface for
> > doing so seems irrelevant).  But this email proves that being
> > subscribed is not necessary to post.  Could this step be reworded to
> > take out the mention of the lack of a posting interface -- or, if that
> > is relevant somehow, clarify what functionality is missing by not
> > having it?  Thank you.
> 
> I think that postings by non-subscribers may go through moderation, so
> they have a delay, sometimes considerable, before they appear and
> require some manual interaction.  For some people, that delay may be
> more of a nuisance than subscribing would be.

Thank you, this clarifies the situation to readers of this list.

My original post, of course, concerns readers of 
http://lilypond.org/website/bug-reports.html who aren't subscribed to this 
list.  That page still has the unclear instructions cited above.

If this email list is not the right place to address bugs on lilypond.org, 
could someone direct me to the proper place?  Thank you.

Re: old \alternative-syntax in documentation

[Werner LEMBERG]

>> The issue affects all of the other translations:
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ca.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.de.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.es.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.it.html
>> https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ja.html

The French translation is usually up to date.


   Werner

Re: old \alternative-syntax in documentation

[Aaron Hill via bug-lilypond]

Sorry, I thought the bug alias was still on the CC line.  Resending to 
ensure broad visibility.



On 2024-02-04 4:37 am, Aaron Hill wrote:

On 2024-02-04 12:40 am, Rudi Radler wrote:

it shows german to me.


Okay, this section of the documentation is out-of-date for some 
translations.


For reference, here is the relevant index page in the English version, 
where the French version also appears to match.


https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.html

1.4.1 Long repeats
This section discusses how to input long (usually multi-measure) 
repeats.


Written-out repeats
Simple repeats
Alternative endings
Other variation in repeated sections
Al-fine repeats
Segno repeat structure
Segno repeat appearance
Manual repeat marks


As you can see, there no longer is a section on "normal repeats".  
Going back to 2.22 shows the documentation for the older \repeat 
syntax/usage:


https://lilypond.org/doc/v2.22/Documentation/notation/long-repeats

1.4.1 Long repeats
This section discusses how to input long (usually multi-measure) 
repeats.
The repeats can take two forms: repeats enclosed between repeat signs; 
or

written-out repeats, used to input repetitious music. Repeat signs can
also be controlled manually.

Normal repeats
Manual repeat marks
Written-out repeats


The issue affects all of the other translations:

https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ca.html
https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.de.html
https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.es.html
https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.it.html
https://lilypond.org/doc/v2.25/Documentation/notation/long-repeats.ja.html


-- Aaron Hill


-- Aaron Hill

Re: old \alternative-syntax in documentation

[Aaron Hill via bug-lilypond]

On 2024-02-03 6:42 am, Rudi Radler via bug-lilypond wrote:

https://lilypond.org/doc/v2.25/Documentation/notation/normal-repeats


Is this an orphaned doc page?  It shows French for me with no option to 
see the English version.  Navigating up one level to the parent index 
page shows no corresponding link back to the URL above.



-- Aaron Hill

Re: Warnings during make

[Werner LEMBERG]

> main.cc:641:23: warning: loop variable 'keyval' creates a copy from
> type 'const std::pair,
> std::__cxx11::basic_string >' [-Wrange-loop-construct]
>   641 |   for (const auto keyval : init_scheme_variables_global)
>   |   ^~
> main.cc:641:23: note: use reference type to prevent copying
>   641 |   for (const auto keyval : init_scheme_variables_global)
>   |   ^~
>   |   &

Thanks for the report.  The fixes suggested by the compiler are now
this MR.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2250


Werner

Re: musicxml2ly chord names

[Knute Snortum]

On Mon, Jan 29, 2024 at 12:55 AM Silvain Dupertuis <
silvain-dupert...@bluewin.ch> wrote:

> I could write an issue... but the webpage did recomment to write a message
> first
>

This is now issue https://gitlab.com/lilypond/lilypond/-/issues/6694


--
Knute Snortum

Re: musicxml2ly chord names

[Silvain Dupertuis]

I could write an issue... but the webpage did recomment to write a message first

Here is a folder with an example
you will find the orignal MuseScore, with it’s PDF and mxl export
(mxl is just a compressed archive containing the xml file)
and the import into Lilypond plus PDF export

https://nextcloud.silvain-dupertuis.net/index.php/s/W5J8owidipexxTa

It is easy for me to correct the ~/lilypond/usr/bin/musicxml2ly file
(a text file)
But I thought it might be useful to others...

Moreover, it would be great to have a lily2musicxml conversion tool!

The xml code for the first note with a chord is like this


  
    
      C
      
    major
    
  
    
      E
      4
      
    4
    1
    half
    up
    
      single
      tu
      
    
    ...



Le 28.01.24 à 23:09, Knute Snortum a écrit :


On Sun, Jan 28, 2024 at 8:50 AM Silvain Dupertuis 
 wrote:

These first 2 lines of the dictionary for chords in musicxml2ly
contains a faulty 5 for simple major and minor chords
(I discovered it with a conversion from a MuseScore sheet converted into 
xml)

chordkind_dict = {
     'major': ':5',
     'minor': ':m5',

should be

chordkind_dict = {
     'major': '',
     'minor': ':m',

a:5 results in a two notes chord 


Could you supply a short musicxml file that demonstrates this?  I would do it, but I 
don't know musicxml.


That, or you could enter an issue at 
https://gitlab.com/lilypond/lilypond/-/issues



--
Silvain Dupertuis
Route de Lausanne 335
1293 Bellevue (Switzerland)
tél. +41-(0)22-774.20.67
portable +41-(0)79-604.87.52
web: silvain-dupertuis.org 

Re: musicxml2ly chord names

[Knute Snortum]

On Sun, Jan 28, 2024 at 8:50 AM Silvain Dupertuis <
silvain-dupert...@bluewin.ch> wrote:

> These first 2 lines of the dictionary for chords in musicxml2ly
> contains a faulty 5 for simple major and minor chords
> (I discovered it with a conversion from a MuseScore sheet converted into
> xml)
>
> chordkind_dict = {
>  'major': ':5',
>  'minor': ':m5',
>
> should be
>
> chordkind_dict = {
>  'major': '',
>  'minor': ':m',
>
> a:5 results in a two notes chord 
>

Could you supply a short musicxml file that demonstrates this?  I would do
it, but I don't know musicxml.

That, or you could enter an issue at
https://gitlab.com/lilypond/lilypond/-/issues

Re: Incorrect transposition via musicxml2ly

[Knute Snortum]

On Sun, Jan 28, 2024 at 10:30 AM Alexander Slávik <
slavik.alexan...@seznam.cz> wrote:

> > I can write this up as an issue unless you want to...
>
> Please do so; thanks!
>

It is now https://gitlab.com/lilypond/lilypond/-/issues/6693.  I hope I
explained it sufficiently.


--
Knute Snortum

Re: Incorrect transposition via musicxml2ly

[Alexander Slávik]

> I can write this up as an issue unless you want to...

Please do so; thanks!

AS

Re: Incorrect transposition via musicxml2ly

[Knute Snortum]

On Sun, Jan 28, 2024 at 12:01 AM Alexander Slávik <
slavik.alexan...@seznam.cz> wrote:

> Seems like this didn't get much attention…
>

It looks like a bug to me.  I can write this up as an issue unless you want
to...


--
Knute Snortum

Re: MMRests cause weirdness following \cadenzaOff

[bobr...@centrum.is]

It's been accepted as a bug.

-David

- Original Message -
> From: "Craig Fearing" 
> To: "bug-lilypond" 
> Sent: Sunday, January 28, 2024 8:16:15 AM
> Subject: Re: MMRests cause weirdness following \cadenzaOff

> Using 2.25.12 I got this:
> 
> Craig
> 
> On 2024-01-27 20:24, bobr...@centrum.is wrote:
>> %%% BEGIN LILY-CODE %%%
>>
>> \version "2.24.2"
>>
>> melody = \relative c' {
>>\repeat unfold 4 { c4 d e f }
>>\cadenzaOn
>>\repeat unfold 4 { c,4 c c c }
>>\cadenzaOff
>>\bar "||"
>>\break
>>\repeat unfold 5 { r1 } % This will not cause it.
>>R1*5  % the MMRest causes this
>> }
>>
>> \score {
>>\relative {
>>  \compressMMRests
>>  \melody
>>}
>> }
>>
> > %%% END LILY-CODE %%%

Re: MMRests cause weirdness following \cadenzaOff

[Craig Fearing]

Using 2.25.12 I got this:

Craig

On 2024-01-27 20:24, bobr...@centrum.is wrote:

%%% BEGIN LILY-CODE %%%

\version "2.24.2"

melody = \relative c' {
   \repeat unfold 4 { c4 d e f }
   \cadenzaOn
   \repeat unfold 4 { c,4 c c c }
   \cadenzaOff
   \bar "||"
   \break
   \repeat unfold 5 { r1 } % This will not cause it.
   R1*5  % the MMRest causes this
}

\score {
   \relative {
 \compressMMRests
 \melody
   }
}

%%% END LILY-CODE %%%

Re: Incorrect transposition via musicxml2ly

[Alexander Slávik]

Seems like this didn't get much attention…

AS

Re: MMRests cause weirdness following \cadenzaOff

[bobr...@centrum.is]

Just a brief follow-up.  If this trick:

cadenzaMeasure = {
  \cadenzaOff
  \partial 1024 s1024
  \cadenzaOn
}

... is used, the rests don't get duplicated but then the MMRest is not created, 
but rather the single measure rests are printed out in multiple measures.

-David

- Original Message -
> From: "Werner LEMBERG" 
> To: "bobroff" 
> Cc: "bug-lilypond" 
> Sent: Saturday, January 27, 2024 7:53:51 PM
> Subject: Re: MMRests cause weirdness following \cadenzaOff

>> I've been wrestling with this mystery for some hours.  I've finally
>> found how to trigger it. The multimeasure rest causes the
>> duplication of the rests in the display in previous measures.  A
>> non-multimeasure rest does not result in the weird duplication.  If
>> this is a known issue I missed the notice.
> 
> It's a bug, now filed as
> 
>  https://gitlab.com/lilypond/lilypond/-/issues/6692
> 
> Thanks for the report.
> 
> 
> Werner

Re: MMRests cause weirdness following \cadenzaOff

[Werner LEMBERG]

> I've been wrestling with this mystery for some hours.  I've finally
> found how to trigger it. The multimeasure rest causes the
> duplication of the rests in the display in previous measures.  A
> non-multimeasure rest does not result in the weird duplication.  If
> this is a known issue I missed the notice.

It's a bug, now filed as

  https://gitlab.com/lilypond/lilypond/-/issues/6692

Thanks for the report.


Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Michael Käppler via bug-lilypond]

This is now

https://gitlab.com/lilypond/lilypond/-/issues/6691

Am 26.01.2024 um 20:32 schrieb Werner LEMBERG:

I would like to hear your opinions on this one:

 snip
\version "2.25.10"

{ \acciaccatura { c'8 } d'4 }
{ \appoggiatura { c'8 } d'4 }


The hyperlinks of both the acciaccatura and the appoggiatura slurs
point to ly/grace-init.ly, which is kind of logical, but also
confusing from a user perspective.

I think this a bug, so please open an issue.


 Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Michael Käppler via bug-lilypond]

Hi Knute,
no worries.

I think this list is exactly the right place to discuss, whether some
behaviour
should be considered a bug or not.
That was the reason I wrote here in the first place.
Otherwise I simply would have opened an issue on GitLab.

Michael


Am 26.01.2024 um 21:05 schrieb Knute Snortum:

On Fri, Jan 26, 2024 at 11:53 AM Werner LEMBERG  wrote:


>> > The hyperlinks of both the acciaccatura and the appoggiatura
>> > slurs point to ly/grace-init.ly , which
is kind of logical, but
>> > also confusing from a user perspective.
>>
>> I think this a bug, so please open an issue.
>
> I apologise.

Why?


I told Michael to post to the user list but he actually was reporting
a bug.

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Werner LEMBERG]

> Here you can find a
> preview: 
> https://www.schott-music.com/de/preview/viewer/index/?idx=NTI0Mjcx=524271=0
> 
> Voice tenor bar 9 to 10 into first alternative it is bound, were as
> from bar 9 to 13 (page 2) it isn't.  It is officially published by
> SCHOTT Music, so I think its correct...

Well, this is simply bad typography – or an error.  You should write
to Schott Music complaining about this.

If I start a tie, I *have* to have an end of the tie!  Just imagine
that the seconda volta starts on the next page – you hold the note and
as soon as you turn the page you discover that holding it is
incorrect, and it's too late to re-articulate the new syllable.

My conclusion: LilyPond's documentation is correct.


Werner

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Thomas Morley]

Am Sa., 27. Jan. 2024 um 12:14 Uhr schrieb Arne Ploese via
bug-lilypond :
>
> Here you can find a
> preview: 
> https://www.schott-music.com/de/preview/viewer/index/?idx=NTI0Mjcx=524271=0
>
> Voice tenor bar 9 to 10 into first alternative it is bound, were as
> from bar 9 to 13 (page 2) it isn't.
> It is officially published by SCHOTT Music, so I think its correct...
>
> Arne
>
> > > There might be a small misunderstanding in "When a note is tied over
> > > into two or more alternative endings [...]" this is also needed if
> > > the tie goes only into the first alternative as well [...]
> >
> > From a logical point of view you either have no tie, or you have a tie
> > that goes into *all* alternative endings.  In other words, 'a tie that
> > goes only into the first alternative' is incorrect.  If you have such
> > a situation you should consider changing where the alternatives
> > actually start.
> >
> > Maybe there is a misunderstanding on my side, so please provide an
> > example (with an image) that illustrates what you mean.
> >
> >
> > Werner
>

What should the Tenor do: tie into second alternative or not...?
Schott is wrong.

Cheers,
  Harm

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Arne Ploese via bug-lilypond]

Here you can find a
preview: 
https://www.schott-music.com/de/preview/viewer/index/?idx=NTI0Mjcx=524271=0

Voice tenor bar 9 to 10 into first alternative it is bound, were as
from bar 9 to 13 (page 2) it isn't.
It is officially published by SCHOTT Music, so I think its correct...
 
Arne

> > There might be a small misunderstanding in "When a note is tied over
> > into two or more alternative endings [...]" this is also needed if
> > the tie goes only into the first alternative as well [...]
> 
> From a logical point of view you either have no tie, or you have a tie
> that goes into *all* alternative endings.  In other words, 'a tie that
> goes only into the first alternative' is incorrect.  If you have such
> a situation you should consider changing where the alternatives
> actually start.
> 
> Maybe there is a misunderstanding on my side, so please provide an
> example (with an image) that illustrates what you mean.
> 
> 
>     Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Knute Snortum]

On Fri, Jan 26, 2024 at 11:53 AM Werner LEMBERG  wrote:

>
> >> > The hyperlinks of both the acciaccatura and the appoggiatura
> >> > slurs point to ly/grace-init.ly, which is kind of logical, but
> >> > also confusing from a user perspective.
> >>
> >> I think this a bug, so please open an issue.
> >
> > I apologise.
>
> Why?
>

I told Michael to post to the user list but he actually was reporting a
bug.

Re: PDF hyperlinks pointing to internal LilyPond code

[Werner LEMBERG]

>> > The hyperlinks of both the acciaccatura and the appoggiatura
>> > slurs point to ly/grace-init.ly, which is kind of logical, but
>> > also confusing from a user perspective.
>>
>> I think this a bug, so please open an issue.
>
> I apologise.

Why?


Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Knute Snortum]

I apologise.

--
Knute Snortum



On Fri, Jan 26, 2024 at 11:33 AM Werner LEMBERG  wrote:

>
> > I would like to hear your opinions on this one:
> >
> >  snip
> > \version "2.25.10"
> >
> > { \acciaccatura { c'8 } d'4 }
> > { \appoggiatura { c'8 } d'4 }
> > 
> >
> > The hyperlinks of both the acciaccatura and the appoggiatura slurs
> > point to ly/grace-init.ly, which is kind of logical, but also
> > confusing from a user perspective.
>
> I think this a bug, so please open an issue.
>
>
> Werner
>
>

Re: PDF hyperlinks pointing to internal LilyPond code

[Werner LEMBERG]

> I would like to hear your opinions on this one:
> 
>  snip
> \version "2.25.10"
> 
> { \acciaccatura { c'8 } d'4 }
> { \appoggiatura { c'8 } d'4 }
> 
> 
> The hyperlinks of both the acciaccatura and the appoggiatura slurs
> point to ly/grace-init.ly, which is kind of logical, but also
> confusing from a user perspective.

I think this a bug, so please open an issue.


Werner

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Werner LEMBERG]

> There might be a small misunderstanding in "When a note is tied over
> into two or more alternative endings [...]" this is also needed if
> the tie goes only into the first alternative as well [...]

>From a logical point of view you either have no tie, or you have a tie
that goes into *all* alternative endings.  In other words, 'a tie that
goes only into the first alternative' is incorrect.  If you have such
a situation you should consider changing where the alternatives
actually start.

Maybe there is a misunderstanding on my side, so please provide an
example (with an image) that illustrates what you mean.


Werner

Re: PDF hyperlinks pointing to internal LilyPond code

[Knute Snortum]

Hi Michael,

These sorts of questions should go to another list,

lilypond-u...@gnu.org

This list is only for reporting bugs.

--
Knute Snortum



On Fri, Jan 26, 2024 at 5:48 AM Michael Käppler via bug-lilypond <
bug-lilypond@gnu.org> wrote:

> Hi all,
> I would like to hear your opinions on this one:
>
>  snip
> \version "2.25.10"
>
> { \acciaccatura { c'8 } d'4 }
> { \appoggiatura { c'8 } d'4 }
> 
>
> The hyperlinks of both the acciaccatura and the appoggiatura slurs point
> to ly/grace-init.ly, which is kind of logical, but also confusing from a
> user perspective.
>
> Shouldn't they both point to the user code?
>
> Michael
>
>

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Arne Ploese via bug-lilypond]

Thank you for the speedy reply!

At first, the example fixed the issue - thank you again.
 
There might be a small misunderstanding in "When a note is tied over
into two or more alternative endings [...]" this is also needed if the
tie goes only into the first alternative as well - Anyone fix the
incorrect documentation?

Arne

Am Freitag, dem 26.01.2024 um 12:43 +0100 schrieb Xavier Scheuer:
> On Fri, 26 Jan 2024 at 11:50, Arne Ploese via bug-lilypond
>  wrote:
> >
> > Hi,
> >
> > after the tie into the first alternative the bar of second
> alternative
> > seems to be out of sync.
> > In the example it seems that the alternative 2 has only space for 3
> > quarter  notes, if the alternative 2 does not start with "r4".
> > This happens only, if I add the lyrics.
> 
> Hello,
> 
> Please read NR 2.1.2 Techniques specific to lyrics > Lyrics and
> repeats > Repeats with alternative endings
> 
> When a note is tied over into two or more alternative endings [...]
> to align the lyrics correctly it is necessary to disable the
> automatic creation of melismata over the volta section and insert
> manual skips
> 
> There is also an example which deals with almost exactly the same as
> your code.
> 
> Kind regards,
> Xavier
> 

Re: Melody bars are out of sync after tie into first alternative and added lyrics

[Xavier Scheuer]

On Fri, 26 Jan 2024 at 11:50, Arne Ploese via bug-lilypond <
bug-lilypond@gnu.org> wrote:
>
> Hi,
>
> after the tie into the first alternative the bar of second alternative
> seems to be out of sync.
> In the example it seems that the alternative 2 has only space for 3
> quarter  notes, if the alternative 2 does not start with "r4".
> This happens only, if I add the lyrics.

Hello,

Please read NR 2.1.2 Techniques specific to lyrics > Lyrics and repeats >
Repeats with alternative endings

When a note is tied over into two or more alternative endings [...]
to align the lyrics correctly it is necessary to disable the automatic
creation of melismata over the volta section and insert manual skips

There is also an example which deals with almost exactly the same as your
code.

Kind regards,
Xavier

Re: problem with \after on last note of DS al fine

[Michael Werner]

One other thing. I missed noticing that you sent this to the lilypond-bug
list. You'd be better off sending things like this to the lilypond-user
list instead. See https://lists.gnu.org/mailman/listinfo/lilypond-user
-- 
Michael

Re: problem with \after on last note of DS al fine

[Michael Werner]

Hi Kris,

On Thu, Jan 18, 2024 at 4:53 AM Kris Van Bruwaene via bug-lilypond <
bug-lilypond@gnu.org> wrote:

> I want to put a decrescendo on the last note of a DS al Fine section, but
> it generates an error message (version 2.24.3)
> Example:% lily test \after with DSaF
> \version "2.24.3"
> music = \relative c' {
> c1
> \repeat segno 2
> {
> c1
> \volta 2 \fine
> c1\> \after 1 \!
> }
> }
>


According to
https://lilypond.org/doc/v2.25/Documentation/notation/available-music-functions
the \after function is used as follows:
\after [music] - delta (duration) ev (music) mus (music)

Add music ev (usually a post-event) with a delay of delta after the onset
of mus.
All that needs done is flip the order of the statements.

\version "2.24.3"

music = \relative c' {
  c1
  \repeat segno 2
  {
c1
\volta 2 \fine
\after 1 \! c1\>
  }
}

Might seem a bit counter-intuitive to put the \after function before the
note. Just bear in mind that \after is a function that takes the note as
one of its arguments, and it should make more sense.
-- 
Michael

Re: documentacion bug

[Karlin High]

On 1/16/2024 12:13 PM, Robert Garrigos wrote:

report an error in the documentation?


Yes, according to these instructions:


--
Karlin High
Missouri, USA