Re: \compressEmptyMeasures wrong position

[William Rehwinkel via bug-lilypond]

Sehr Geehrter Dietmar,

Leider hat layout-set-staff-size altbekannte Probleme. Vielleicht können 
Sie vorerst das Folgende benützen... / Unfortunately 
layout-set-staff-size seems to have some problems for a while. Perhaps 
you can use the following workaround for now...


-William

\version "2.25.18"
#(use-modules (lily accreg))% Akkordeon Register
staffSize = #(define-music-function (new-size) (number?)
  #{
\set fontSize = #new-size
\override StaffSymbol.staff-space = #(magstep new-size)
\override StaffSymbol.thickness = #(magstep new-size)
  #})
Noten = {
 \relative c' {
  \discant "111"
  c2 d
  R1*2
  \discant "20"
  e2 f
 }
 \bar "|."
}
\book {
 \score {
  \Noten
  \layout {
%#(layout-set-staff-size 30)
\compressEmptyMeasures
\context {
  \Staff
  \staffSize #4
}
  }
 }
}


On 7/23/24 12:11, dietmar.vier...@dvisoft.de wrote:

Abhängig von layout-set-staff-size gibt es Fehler in der Darstellung.

  


\version "2.24.4"

  


#(use-modules (lily accreg))% Akkordeon Register

  


Noten = {

  \relative c' {

   \discant "111"

   c2 d

   R1*2

   \discant "20"

   e2 f

  }

  \bar "|."

}

\book {

  \header {

   title = "Mehrtaktpause und Register richtig"

   }

  \score {

   \layout {

 #(layout-set-staff-size 20)

 \compressEmptyMeasures

   }

   \Noten

  }

}

\book {

  \header {

   title = "Mehrtaktpause und Register falsch"

   }

  \score {

   \layout {

 #(layout-set-staff-size 30)

 \compressEmptyMeasures

   }

   \Noten

  }

}

  


Im Anhang sind die beiden PDF-Dateien, richtig und falsch.

In meiner Datei trat der Fehler allerdings schon bei #(layout-set-staff-size
20) auf.

Hier habe ich es mit 30 versucht, bei 22 ist es jedoch schon zu erkennen.

  


Viele Grüße

Dietmar Viertel



--
William Rehwinkel (any pronouns)
Juilliard School '26 - Oberlin Conservatory '24
will...@williamrehwinkel.net - https://williamrehwinkel.net
PGP Public Key: https://ftp.williamrehwinkel.net/pubkey.txt


OpenPGP_signature.asc
Description: OpenPGP digital signature

\staffHighlight with tempo indication and whole bar rest incorrect

[Thomas via bug-lilypond]

Hello,

"\staffHighlight" does not work properly if there is a tempo marking and
a whole bar rest in the first bar.

In this case, the marking only starts at the end of the tempo marking.

See attached file "staffHighlight.ly"

Regards Thomas

% The marking should start at "\staffHighlight".

% If there is a full-bar rest and a tempo marking in the first bar, 
% the marking starts at the end of the tempo marking and ends at 
% "\stopStaffHighlight". If there is a long tempo marking, the 
% marking starts at "\stopStaffHighlight" and ends at the end of the 
% tempo marking.

% If there is a full rest instead of a full-bar rest, or if there are 
% notes, the marking starts at "\staffHighlight". The same applies if 
% there is no tempo marking.



\version "2.24.3"

{
\staffHighlight yellow R1 \stopStaffHighlight
R1-\markup "without Tempomark"
}

{
\tempo "Tempomark"
\staffHighlight yellow R1 \stopStaffHighlight
R1
}

{
\tempo "Tempo"
\staffHighlight yellow R1 \stopStaffHighlight
R1
}

{
\tempo "Tpo."
\staffHighlight yellow R1 \stopStaffHighlight
R1
}

{
\tempo "Very long Tempomark"
\staffHighlight yellow R1 \stopStaffHighlight
R1 
}

{
\tempo "Tempo with r1 instead of R1"
\staffHighlight yellow r1 \stopStaffHighlight
R1
}

{
\tempo "Tempo with c1 instead of R1"
\staffHighlight yellow c'1 \stopStaffHighlight
R1
}

{
R1
\tempo "Tempo in 2nd bar"
\staffHighlight yellow R1 \stopStaffHighlight
}

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

[Michael Käppler via bug-lilypond]

Good.
Could you give some other scores a try with the patched release?

Michael

Am 07.06.2024 um 15:55 schrieb K. Blum:

Hi Michael,

yes, the initial MWE that I've posted now works fine with your patched
release.
Thank you for working on this!

Cheers,
Klaus


Am 06.06.2024 um 22:39 schrieb Michael Käppler:

Hi Klaus,
I think I could track this down, see
https://gitlab.com/lilypond/lilypond/-/issues/6710 for an update.

It would be great if you could test the following patched release with
the
file that failed initially. I uploaded the zip archive on WeTransfer:
https://we.tl/t-kW6yGIdJau

Unfortunately, while working on this, I found other severe problems with
Guile in the Windows build, like
https://gitlab.com/lilypond/lilypond/-/issues/6717

Michael


Am 23.04.2024 um 10:12 schrieb Michael Käppler:

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,

yes, the initial MWE that I've posted now works fine with your patched
release.
Thank you for working on this!

Cheers,
Klaus


Am 06.06.2024 um 22:39 schrieb Michael Käppler:

Hi Klaus,
I think I could track this down, see
https://gitlab.com/lilypond/lilypond/-/issues/6710 for an update.

It would be great if you could test the following patched release with
the
file that failed initially. I uploaded the zip archive on WeTransfer:
https://we.tl/t-kW6yGIdJau

Unfortunately, while working on this, I found other severe problems with
Guile in the Windows build, like
https://gitlab.com/lilypond/lilypond/-/issues/6717

Michael


Am 23.04.2024 um 10:12 schrieb Michael Käppler:

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

[Michael Käppler via bug-lilypond]

Hi Klaus,
I think I could track this down, see
https://gitlab.com/lilypond/lilypond/-/issues/6710 for an update.

It would be great if you could test the following patched release with the
file that failed initially. I uploaded the zip archive on WeTransfer:
https://we.tl/t-kW6yGIdJau

Unfortunately, while working on this, I found other severe problems with
Guile in the Windows build, like
https://gitlab.com/lilypond/lilypond/-/issues/6717

Michael


Am 23.04.2024 um 10:12 schrieb Michael Käppler:

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: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)

[Michael Käppler via bug-lilypond]

Can't reproduce this here on x86_64, Ubuntu 22.04.
I did 100 subsequent runs without a single failure.

Jean, which system are you on?
If you can reproduce this often enough, could you share a core dump?

Am 02.06.2024 um 14:41 schrieb Jean Abou Samra:

On my Linux machine with 2.25.16, that file nondeterministically compiles,
segfaults, or triggers a floating point exception. No time to investigate
more, though.

cautionary accidental styles with doubly altered notes

[Helmut Kastenholz via bug-lilypond]

Dear LilyPond developers,

the accidental styles piano-cautionary, modern-cautionary, and
modern-voice-cautionary don't seem to work correctly with doubly altered
notes, cf. attached example:

If d flat follows d double flat in a different octave or on a different
staff, the accidental is printed in parentheses. The same holds for
sharps instead of flats and for other notes instead of d.

To my understanding, the single flats and single sharps, resp., should
be printed without parentheses, because they are essential: omitting
them would change the pitch of the note. Please correct me, if
I'm wrong.

Moreover, placing an exclamation point after the note does not remove
the parentheses. This may be related to
https://gitlab.com/lilypond/lilypond/-/issues/2810

Best regards,
Helmut


cautionary-bug.ly
Description: Binary data

Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)

[aaron--- via bug-lilypond]

   If there's a connection to Guile, we know there are some differences in
   the distributions by platform.
   I would try on my Win10 system, but I managed to find myself in
   hospital again. (Nothing to serious.)
   On May 31, 2024 12:28 AM, Craig Fearing via bug-lilypond
wrote:

 FWIW I ran this 15 consecutive times on my Win 11, Ryzen 7 system.
 One
 time it took 2 seconds to compile, the rest were all 1.9 seconds.
 No
 errors any time.
 On 2024-05-30 23:24, Trevor Bača wrote:
 > Hi,
 >
 > I have what appears to be a very difficult bug.
 [snip]
 > ... I suspect it may take two or three
 > successive attempts to interpret music.ly before triggering the
 loop on
 > some operating systems (or chip architectures), ...
 >
 > [snip]
 >
 > Trevor.
 >

Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)

[Craig Fearing via bug-lilypond]

FWIW I ran this 15 consecutive times on my Win 11, Ryzen 7 system.  One 
time it took 2 seconds to compile, the rest were all 1.9 seconds.  No 
errors any time.



On 2024-05-30 23:24, Trevor Bača wrote:

Hi,

I have what appears to be a very difficult bug.

[snip]

... I suspect it may take two or three
successive attempts to interpret music.ly before triggering the loop on
some operating systems (or chip architectures), ...

[snip]

Trevor.

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: 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

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

[K. Blum via bug-lilypond]

I often need mathematical calculations for graphic stuff.
Now I've found a weird problem in Ly 2.25.11 and newer (Windows 10 64bit).
It seems that certain operations with fractions fail whereas the same
value as real number works fine.

Here is my code:
% --
#(define step 1)  % for testing, replace by 1.0 (real number instead of
integer)
#(define cnt -3)
#(define limit (+ cnt 0.3))  % always greater than cnt
#(display   (/ step 2) )  % value:  1/2 (or  0.5
respectively)
#(newline)
#(display    (- cnt (/ step 2))    )  % value: -7/2 (or -3.5
respectively)
#(newline)
% This line causes the error:
#(display (> (- cnt (/ step 2)) limit) )  % value: #f because -7/2 is
not > -3

% fails, but stops failing if you...
%   define 'step' as 1.0 instead of 1
% or
%   change 'cnt' to an integer > -3
% or
%   change the comparison from '>' to '<'
% --

With Ly 2.25.11 (also .12 and .13 and .14) this results in the following
error:
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.

In the past, I never had this problem (2.20, 2.18, ...).
Also tested now with 2.24.3, 2.25.1, 2.25.6, 2.25.9 and 2.25.10 - they
work fine without problems.

P.S.: Thanks for the amazing work on this amazing software!

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: 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

Snippet 960 fails with Ly 2.25

[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.

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

[William Rehwinkel via bug-lilypond]

Dear list,

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.


\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
  }
>>

Thanks,
-William

--
William Rehwinkel - Oberlin College and Conservatory '24

will...@williamrehwinkel.net

PGP key: https://ftp.williamrehwinkel.net/pubkey.txt


OpenPGP_signature.asc
Description: OpenPGP digital signature

Adding quote with a custom context inside throws warning

[Simon Albrecht via bug-lilypond]

Hello,

when \addQuote is used and the music within creates a custom context, 
this works as intended but outputs a warning:


%%%
\version "2.25.12"

\layout {
  \context {
    \Voice
    \name VocalVoice
    \alias Voice
  }
}

sop = \new VocalVoice { 1 }
\addQuote "sop" \sop
%

=>

Starting lilypond 2.25.12 [Untitled]...
Processing `/tmp/frescobaldi-x5k4p__3/tmpinzgj_k6/document.ly'
Parsing...
/tmp/frescobaldi-x5k4p__3/tmpinzgj_k6/document.ly:12:17: warning: cannot 
create context: VocalVoice

\addQuote "sop"
    \sop
Success: compilation successfully completed
Completed successfully in 0.2".

Best regards
Simon

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

[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

[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

[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

[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

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

[Ole V. Villumsen via bug-lilypond]

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.

#1. The entry percent repeat 
(https://lilypond.org/doc/v2.24/Documentation/music-glossary/percent-repeat) 
already mentions that percent repeats are also called simile marks in English. 
Or more precisely percent repeats are repeats notated through simile marks. 
Simile marks are the signs used in percent repeats. I suggest a separate entry 
for "simile mark" with reference to "percent repeat" and/or the other way 
around.

#2 While many (most?) glossary entries give the terms in many languages, the 
percent repeat entry does not, which makes sense. I still suggest that the 
German translation "Faulenzer" be included.

One way could be:

percent repeat
LilyPond-specific term to indicate the repetition of a musical expression 
through simile marks. See (link:) simile mark.

simile mark
D: Faulenzer (colloquial)

Symbol to indicate a percent repeat, the repetition of a musical expression on 
a single staff, as opposed to the more usual definition of repeat, which 
affects all parts. The musical expression can be anything from a single note or 
note pattern to one or more measures. There are other names for this symbol:

(the remainder of the text and the music example from the current percent 
repeat entry goes here)

Sent with [Proton Mail](https://proton.me/) secure email.

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

bar-extents in magnified staves and staff groups

[Cameron Crowe via bug-lilypond]

1. It might be nice

to have the

systemStartDelimiter

(or whatever it's called) of a

StaffGroup

extend out to the

bar-extent

.

Here is an example with exaggerated bar extents to make the point clear

:

\new

StaffGroup

<<

\new

DrumStaff

\with

{

\override

StaffSymbol.line-count =

#1

\override

BarLine.bar-extent =

#'(-2.5 . 2.5)

}

\drummode

{ sn4 sn

\bar

"|"

sn sn

\bar

"|."

}

\relative

{

d'

d

d

d

}

>>

2. Additionally, it might be nice to add bar-extent to the list of props to fix 
on cue-sized/magnified staves in the docs?  Maybe there are a million other 
such things I just haven't run into, yet.
https://lilypond.org/doc/v2.25/Documentation/notation/setting-the-staff-size

#(define bar-line-props

'((BarLine thick-thickness)

(BarLine bar-extent)

(BarLine hair-thickness)

(BarLine kern)))

Here's a slightly simplified version of the cow and ride example where it 
becomes relevant
https://lilypond.org/doc/v2.25/Documentation/snippets/rhythms_003a-cow-and-ride-bell-example

#(define bar-line-props-a

'((BarLine thick-thickness)

(BarLine bar-extent)

(BarLine hair-thickness)

(BarLine kern)))

#(define bar-line-props-b

'((BarLine thick-thickness)

(BarLine hair-thickness)

(BarLine kern)))

<<

\new

DrumStaff

\with

{

instrumentName =

"Good Cue"

\magnifyStaff

#0.63

\override

StaffSymbol.line-positions =

#'(-2 3)

\override

BarLine.bar-extent =

#'(-1.0 . 1.5)

clefPosition =

0

.

5

#(revert-props 'magnifyStaff 0 bar-line-props-a)

}

\drummode

{ hh4 hh

\bar

"|"

tomfh tomfh

\bar

"|."

}

\new

DrumStaff

\with

{

instrumentName =

"Bad Cue"

\magnifyStaff

#0.63

\override

StaffSymbol.line-positions =

#'(-2 3)

\override

BarLine.bar-extent =

#'(-1.0 . 1.5)

clefPosition =

0

.

5

#(revert-props 'magnifyStaff 0 bar-line-props-b)

}

\drummode

{ hh4 hh

\bar

"|"

tomfh tomfh

\bar

"|."

}

\new

DrumStaff

\with

{

instrumentName =

"Regular"

%\magnifyStaff #0.63

\override

StaffSymbol.line-positions =

#'(-2 3)

\override

BarLine.bar-extent =

#'(-1.0 . 1.5)

clefPosition =

0

.

5

}

\drummode

{ hh4 hh

\bar

"|"

tomfh tomfh

\bar

"|."

}

>>

% Thanks!

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!

Reply to digest

[Simon Albrecht via bug-lilypond]

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.


Best, Simon


On 03.03.24 19:11, Cameron Crowe via bug-lilypond wrote:

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
From: Ruud Harmsen ru...@rudhar.com

To: bug-lilypond@gnu.org
Subject: Re: copyright date
Message-ID: 20240303092600.00bb969...@rudhar.com

Content-Type: text/plain; charset="us-ascii"; format=flowed

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)

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

copyright date

[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.

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

[Cameron Crowe via bug-lilypond]

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

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.+

[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

Distance between top margin and title text in 25.2.+

[Anbo via bug-lilypond]

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).


Regards
Andreas

\version "2.25.13"

\layout {
  \context {
\Score
\override VerticalAxisGroup.remove-first = ##t
  }
  \context {
\Staff
\RemoveEmptyStaves
  }
  \context {
\PianoStaff
\consists #Span_stem_engraver
  }
}

\midi {
  \tempo 4 = 45
  \context {
\Voice
\remove "Dynamic_performer"
  }
}

myStaffSize = #20

#(set-global-staff-size myStaffSize)

\paper {
  left-margin   = 7.5\mm
  right-margin   = 5\mm
  top-margin= 5\mm
  bottom-margin = 5\mm
  indent = 0\mm 
  %%set to ##t if your score is less than one page: 
  ragged-last-bottom = ##f
  ragged-bottom = ##f
  print-page-number = ##f
}

\header {
  title = "What power art thou"
  composer = "Henry Purcell (1659-1695)"
  arranger = "Sir George Alexander Macfarren (1813-1887)"
  poet = "John Dryden (1631-1700)"

  maintainer = "Anonymous"
  mutopiacomposer = "PurcellH"
  mutopiainstrument = "Voice (Bass), Piano"
  mutopiapoet = "John Dryden"
  mutopiatitle = "What power art thou (King Arthur)"
  license = "Public Domain"
  source = "Dryden's Opera of / King Arthur / The Music Composed by / Henry Purcell / With a Piano Forte Accomp. / Compressed from the Score / By / G. Alex. Macfarren, / Professor of Harmony / at the Royal Academy of Music / London, Printed & Sold by Chappell. / Music Seller to Her Majesty / 50, New Bond Street. (IMSLP82155-PMLP69503)"
  style = "Baroque"
  footer = "Mutopia-2019/07/12-2243"
  copyright = \markup {\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0) \right-column {\with-url "http://www.MutopiaProject.org; {\abs-fontsize #9  "Mutopia " \concat {\abs-fontsize #12 \with-color #white "ǀ" \abs-fontsize #9 "Project "}}}\override #'(font-name . "DejaVu Sans, Bold") \override #'(baseline-skip . 0 ) \center-column {\abs-fontsize #11.9 \with-color #grey \bold {"ǀ" "ǀ"}}\override #'(font-name . "DejaVu Sans,sans-serif") \override #'(baseline-skip . 0) \column { \abs-fontsize #8 \concat {"Typeset using " \with-url "http://www.lilypond.org; "LilyPond " "by " \maintainer " — " \footer}\concat {\concat {\abs-fontsize #8 { "Placed in the " \with-url "http://creativecommons.org/licenses/publicdomain; "Public Domain" " by the typesetter " " — free to distribute, modify, and perform" }}\abs-fontsize #13 \with-color #white "ǀ" }}}
  tagline = ##f
}

TB = #(make-span-event 'TextSpanEvent START)
TE = #(make-span-event 'TextSpanEvent STOP)

global = {
  \tempo Slow
  \key c \minor
  \time 2/2

  \repeat unfold 2 {
s1 \noBreak s \noBreak s \noBreak s \noBreak s \break
  }
  s1*4 \break
  s1*4 \break
  s1*4 \break

\barNumberCheck 23 \pageBreak

  s1*4 \break
  s1*3 \break
  s1*3 \break
  s1*3 \bar "|."

  \key c \major \time 3/4 s2
}

voice = \relative c {
  \override TextSpanner.style = #'trill
  \override TextSpanner.bound-details.right.padding = #-1.2

  R1*5 |

\barNumberCheck 6

  R1*3 |
  r4 c8[\TB c]\TE c[\TB c c]\TE c |
  \stemUp d8[\TB d d]\TE d d[\TB d d]\TE d \stemNeutral |

\barNumberCheck 11

  es8[\TB es es]\TE es e8[\TB e e]\TE e |
  f8[\TB f f]\TE f fis fis fis fis |
  g8[\TB\melisma g]\TE g4\melismaEnd r a8[\TB a]\TE |
  bes8[\TB bes bes]\TE bes b[\TB b b]\TE b |

\barNumberCheck 15

  c8[\TB \melisma c c c]\TE c[\TB c c]\TE \melismaEnd b |
  c8[ \melisma c] c4 \melismaEnd r2 |
  R1 |
  r2 c8[\TB c c]\TE c |

\barNumberCheck 19

  c8[\TB bes bes]\TE bes bes[\TB bes bes]\TE bes |
  bes8[\TB a a]\TE a as[\TB as as]\TE as |
  g8[\TB g g]\TE c c[\TB f, f]\TE f |
  e8[\TB e e]\TE e f[\TB f f]\TE b, |

\barNumberCheck 23

  c8[ c c] c f[\TB f f]\TE f |
  R1 |
  r4 f8 f f[\TB f f]\TE f |
  g8[\TB g g]\TE g a[\TB a a]\TE a |

\barNumberCheck 27

  bes8[\TB bes bes]\TE bes b[\TB b b]\TE b |
  c8[\TB c c]\TE c d[\TB d d]\TE d |
  es[\TB es es \TE es] r4 es8 d |
  d8 d d c d[\TB d d]\TE d |

\barNumberCheck 31

  b8[\TB b b b]\TE r4 c8 c |
  c8 bes bes[\TB bes bes]\TE as! as as |
  as4( g) g8 g g f |
  f8[\TB es es]\TE es \stemUp d4. \stemNeutral c8 |

\barNumberCheck 35

  c2 r |
  r4 r
}

text = \lyricmode {
  What power art thou, who, from be --
  low, Has

lilypond-book loglevel

[Cameron Crowe via bug-lilypond]

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?

Using 2.24.3

Thank you,
C

>> lilypond-book --loglevel=WARN book.lytex

> lilypond-book: error: file not found: book.lytex

>> lilypond-book --loglevel=WARNING book.lytex
>
> lilypond-book: error: Unknown or invalid loglevel 'WARNING'
> lilypond-book (GNU LilyPond) 2.24.3
> lilypond-book: error: file not found: book.lytex

>

lilypond-book

-l loglevel --loglevel=loglevel

Set the output verbosity to loglevel. Possible values are NONE, ERROR, WARNING, 
PROGRESS (default), and DEBUG. If this option is not used and the environment 
variable LILYPOND_BOOK_LOGLEVEL is set, its value is used as the log level.

lilypond

-l, --loglevel=level

Set the verbosity of the console output to level. Possible values are:

NONE

No output at all, not even error messages.

ERROR

Only error messages, no warnings or progress messages.

WARN

Warnings and error messages, no progress.

BASIC_PROGRESS

Basic progress messages (success), warnings and errors.

PROGRESS

All progress messages, warnings and errors.

INFO

Progress messages, warnings, errors and further execution information. This is 
the default.

DEBUG

Dashed bar lines fail requirements at some sizes

[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 ".|" }

Snippets omission

[David via bug-lilypond]

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

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

[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

old \alternative-syntax in documentation

[Rudi Radler via bug-lilypond]

Thanks for that great tool! small bug found - see below Regards from
Radler
https://lilypond.org/doc/v2.25/Documentation/notation/normal-repeats
\relative{
c''1
\repeatvolta2{c4def~}
*\alternative{ {f2d} {f2\repeatTief,} }*
} By the way: The new syntax is shown at this web-side as well:
\relativec''{
\time3/4
c4cc
\setScore.voltaSpannerDuration=\musicLength2.
\repeatvolta5{
d4dd
\alternative{
*\volta1,2,3,4{*
e4ee
f4ff}
\volta5{
g4gg}}}
}

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

[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: 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
> 

PDF hyperlinks pointing to internal LilyPond code

[Michael Käppler via bug-lilypond]

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

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

[Arne Ploese via bug-lilypond]

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.

Thank You for looking into this issue.

Arne Plöse
\version "2.24.2"

% Melody bar in alternative 2 out of sync after tie into alternative 1.
% "DD" should be the last note in bar 4, not the first in partial bar 5!
% If the alternative 2 starts with "r2" this error shows up as well.
% If the alternative 2 starts with "r4" this error does not show up.

\relative c'' {
  \time 4/4
  \repeat volta 2 {
g1~ |
\alternative {
  {
g4 g2. |
  }
  {
g4 r2 r4 |
  }
}
  }
  g4 g4 g4 g4 |
}

\addlyrics {
  \lyricmode {
\repeat volta 2 {
  A __
}
\alternative {
  {
B |
  }
  {
C |
  }
}
DA DB DC DD |
  }
}

problem with \after on last note of DS al fine

[Kris Van Bruwaene via bug-lilypond]

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 \!
}
}

Errors:GNU LilyPond 2.24.3 (running Guile 2.2)
Verwerken van 'test.ly'
Ontleden...
test.ly:11:1: fout: syntax error, unexpected '}', expecting \header

}
fatale fout: mislukte bestanden: "test.ly"

Re: Skipping syllables / LyricExtender

[Michael Käppler via bug-lilypond]

Thanks a lot! So this is clearly a documentation issue.

Am 04.01.2024 um 10:34 schrieb Paul Hodges:

This came up in the user list just a month ago, when I asked about the
use of _ instead of \skip1 causing a lyric to be misaligned because it
started a melisma.  By chance I found the only (?) documented
reference to "", which solved my problem with a less ugly notation
than \skip1!  It seems that \skip1, _, and "" all have subtle
differences which the documentation doesn't make sufficiently clear...

Below is the mail that summarised these findings.

Paul

*From: *Michael Werner 
*To: *Paul Hodges 
*Cc: *
*Sent: *04/12/2023 12:37
*Subject: *Re: Centering a word before a gap in the lyrics

Hi Paul,

On Mon, Dec 4, 2023 at 6:56 AM Paul Hodges mailto:p...@cassland.org>> wrote:

I don't know where in the documentation the difference in
behaviour between \skip1 and "" as opposed to _ is explained.


It isn't much of an explanation, but in

http://lilypond.org/doc/v2.25/Documentation/notation/lyrics-and-repeats#index-_005cskip-1
is the line Note: do not use an underscore, |_|, to skip notes –
an underscore indicates a melisma, causing the preceding syllable
to be left-aligned.
A bit terse, to be sure. But mentioning an alignment issue I've
always stayed with using \skip to skip over a note, and only used
_ when it really was a melisma not explicitly notated in the music
(such as a tie or a slur).

But the opportunity is missed on these pages, the first of
which actually conflates the "" and _ notation:


https://lilypond.org/doc/v2.25/Documentation/snippets/rhythms_003a-skips-in-lyric-mode-_00282_0029

https://lilypond.org/doc/v2.25/Documentation/snippets/rhythms_003a-skips-in-lyric-mode


This was the first time I'd seen the use of "" for something like
this. I'll have to keep it in mind. And looking at those two
snippet pages you linked they make it seem like all three options
are equivalent. Yet in the NR page I linked it says they are
different.

Well, I guess the important bit is you found something that does
what you need, and does it in a way that you're okay with.
--
Michael



*From: * Michael Käppler 
*To: * Paul Hodges , "bug-lilypond@gnu.org"

*Sent: * 04/01/2024 9:07
*Subject: * Re: Skipping syllables / LyricExtender

Thanks, Paul, but is this mentioned somewhere in the docs?
AFAICS, they recommend using \skip everywhere for skipping notes.

"" is shorter and more logical, since, unlike `\skip (dur)` it
does not request the duration argument, which
is ignored in Lyrics, anyway.

Michael

Am 04.01.2024 um 00:12 schrieb Paul Hodges:

Replace the \skip 4 with "", as in:

%
\version "2.25.0"

{ c' (d') e' f' }
\addlyrics { foo __ "" bar }
    %

Paul

*From: * Michael Käppler via bug-lilypond 
<mailto:bug-lilypond@gnu.org>

Hi all,
please consider the following example:

\version "2.25.0"

{ c' (d') e' f' }
\addlyrics { foo __ \skip 4 bar }

The \skip command does not terminate the extender line. This
is at least
unexpected.
Opinions?

Michael

Re: Skipping syllables / LyricExtender

[Michael Käppler via bug-lilypond]

Thanks, Paul, but is this mentioned somewhere in the docs?
AFAICS, they recommend using \skip everywhere for skipping notes.

"" is shorter and more logical, since, unlike `\skip (dur)` it does not
request the duration argument, which
is ignored in Lyrics, anyway.

Michael

Am 04.01.2024 um 00:12 schrieb Paul Hodges:

Replace the \skip 4 with "", as in:

%
\version "2.25.0"

{ c' (d') e' f' }
\addlyrics { foo __ "" bar }
%

Paul

*From: * Michael Käppler via bug-lilypond 

Hi all,
please consider the following example:

\version "2.25.0"

{ c' (d') e' f' }
\addlyrics { foo __ \skip 4 bar }

The \skip command does not terminate the extender line. This is at
least
unexpected.
Opinions?

Michael

Skipping syllables / LyricExtender

[Michael Käppler via bug-lilypond]

Hi all,
please consider the following example:

\version "2.25.0"

{ c' (d') e' f' }
\addlyrics { foo __ \skip 4 bar }

The \skip command does not terminate the extender line. This is at least
unexpected.
Opinions?

Michael

Re: lilypond book preamble not cropping page

[Gilberto Agostinho via bug-lilypond]

Hi Klaus,

Thanks for the quick reply!

On 30/12/2023 17:09, K. Blum wrote:

try adding these options to your LY file:
#(ly:set-option 'tall-page-formats 'eps,png,pdf)
#(ly:set-option 'separate-page-formats 'eps,png,pdf)


I can confirm those work. Thanks for pointing me to the previous 
discussion on this topic, I wasn't aware of these changes until now. 
I'll start including those two lines after including 
lilypond-book-preamble when wanting the cropping behaviour from now on.


Best wishes!
Gilberto

Re: lilypond book preamble not cropping page

[K. Blum via bug-lilypond]

Hi Gilberto,

try adding these options to your LY file:

#(ly:set-option 'tall-page-formats 'eps,png,pdf)
#(ly:set-option 'separate-page-formats 'eps,png,pdf)


Alternatively, you can add these options to your command line:
-dtall-page-formats=eps,png,pdf
-dseparate-page-formats=eps,png,pdf

Here is where I got my knowledge from:
https://gitlab.com/lilypond/lilypond/-/issues/6235

Hope this helps,
Klaus

lilypond book preamble not cropping page

[Gilberto Agostinho via bug-lilypond]

Hello everyone,

I hope you are all well and had a great year. I noticed that since 
version 2.24.x, lilypond-book-preamble has stopped automatically 
cropping the output around the music grobs.


*1) *This is the behaviour of 2.22.2, which is what I expect when using 
lilypond-book-preamble:


```
\version "2.22.2"
\include "lilypond-book-preamble.ly"

{
    c'4 d' e' f'
}
```
Produces: 
https://i.postimg.cc/hvstwZx3/Screenshot-from-2023-12-30-11-46-14.png


*2) *And below is the behaviour introduced sometime after 2.22.2, 
possibly post 2.24.x:


```
\version "2.24.1"
\include "lilypond-book-preamble.ly"

{
    c'4 d' e' f'
}
```
Produces: 
https://i.postimg.cc/44QymyMb/Screenshot-from-2023-12-30-11-46-35.png


Is this an intended new behaviour of lilypond-book-preamble or is it a 
bug? If the former, is there a way of enabling the old automatic crop?


Best wishes,
Gilberto

Re: Ugly ties in chord clusters

[fa61bd7a-bab1-4a88-80e0-a065116a0a04--- via bug-lilypond]

 > Do you mean without the override?  With the override, the ties look fine.

Hi Knute,

Note how there only seem to be five ties for six notes. If you zoom in 
on the
second-highest "tie" at a higher resolution, you'll see it's actually 
two ties
almost wholly overlapping.

Re: Ugly ties in chord clusters

[William Rehwinkel via bug-lilypond]

I think what OP was referring to is that two ties are placed on top of 
each other (it looks a bit thicker). Perhaps something like the 
following would be preferable.


-William

\version "2.24.2"
\relative {
  \override Score.SpacingSpanner.shortest-duration-space = #3
   q
}


On 12/25/23 18:00, Knute Snortum wrote:

On Mon, Dec 25, 2023 at 10:31 AM fa61bd7a-bab1-4a88-80e0-a065116a0a04---
via bug-lilypond  wrote:


Hi LilyPond developers,

In dense chord clusters, ties sometimes fail to keep at least one staff
space away from each other.
\version "2.24.2"
\relative {
   \override Score.SpacingSpanner.shortest-duration-space = #3
   ~ q
}



Do you mean without the override?  With the override, the ties look fine.

--
Knute Snortum


--
William Rehwinkel - Oberlin College and Conservatory '24

will...@williamrehwinkel.net

PGP key: https://ftp.williamrehwinkel.net/pubkey.txt


OpenPGP_signature.asc
Description: OpenPGP digital signature

Ugly ties in chord clusters

[fa61bd7a-bab1-4a88-80e0-a065116a0a04--- via bug-lilypond]

   Hi LilyPond developers,

   In dense chord clusters, ties sometimes fail to keep at least one staff
   space away from each other.
\version "2.24.2"
\relative {
  \override Score.SpacingSpanner.shortest-duration-space = #3
  ~ q
}


signature.asc
Description: OpenPGP digital signature

Vertical spacing is broken when \change Staff and \showStaffSwitch on \pageBreak

[Zbyněk Burget via bug-lilypond]

Hi,
here is example of this bug:

\version "2.24.3"

\score {
  <<
\new StaffGroup
<<
  \new Staff \relative c''{ \clef treble c1 | \pageBreak c1 }
  \new Staff \relative c'{ \clef treble c1 | c1 }
>>
\new StaffGroup
<<
  \new Staff \relative c'' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef alto c1 | c1 }
  \new Staff \relative c' { \clef alto c1 | c1 }
  \new Staff \relative c { \clef bass c1 | c1 }
>>
\new StaffGroup
<<
  \new Staff \relative c'' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef treble c1 | c1 }
  \new Staff \relative c' { \clef alto c1 | c1 }
  \new Staff \relative c' { \clef alto c1 | c1 }
  \new Staff \relative c { \clef bass c1 | c1 }
>>
\new PianoStaff
<<
  \new Staff = "1" <<
\new Voice \relative c'' { \voiceOne \clef treble c1 | c1 }
\new Voice\relative e' { \voiceTwo e1 | e1 }
  >> \new Staff = "2" <<
\new Voice \relative c' { \voiceOne \clef bass c1 | \showStaffSwitch \change 
Staff = "1" c1 }
\new Voice \relative c { \voiceTwo c1 | c1}
  >>
>>

  >>
}



The problem occurs only if the \showStaffSwitch command is found.



--
Zbyněk Burget
Mlýnská 397
798 26 Nezamyslice

tel: 588 580 000, 739 930 931
http://www.burgnet.cz
IČ:  606 88 220; DIČ: CZ7210184674

Duration dots are badly arranged

[Zbyněk Burget via bug-lilypond]

Hi,
I found bug in arrangement duration dots in a specific case:

\version "2.24.3"

\score {
  \new PianoStaff <<
\new Staff = "1" <<
\new Voice \relative a' { \voiceOne a2 g4 c }
\new Voice \relative e' { \voiceTwo 2. g4 }
  >> \new Staff = "2" <<
\new Voice \relative c' { \clef bass \voiceOne \change Staff = "1" \hideNotes c2. 
\showStaffSwitch \unHideNotes \change Staff = "2" c4 }

\new Voice \relative a, { \voiceTwo a4. b8 c4 e }
  >>
  >>
}


--
Zbyněk Burget
Mlýnská 397
798 26 Nezamyslice

tel: 588 580 000, 739 930 931
http://www.burgnet.cz
IČ:  606 88 220; DIČ: CZ7210184674

[v2.24.2, v2.25.9] Compilation to PDF fails with Ghostscript 10.02.1

[Elias Elwyn via bug-lilypond]

OS: Arch Linux (Up to date 2023-11-02)
LilyPond Versions: 2.24.2 (Stable), 2.25.9 (Devel)

This bug was not observed with Ghostscript 10.02.0.

Compilation fails with the following input (lilypond -l DEBUG test.ly):

  \version "2.24.2"
  % Or the following when testing v2.25.9
  % \version "2.25.9"
  { c }

The full error logs are attached (my username has been substituted with
${USER}). The relevant section is probably:

  Converting to `test.pdf'...
  Preparing Ghostscript command to `/tmp/lilypond-tmp-2084349': mark 
/OutputFile (./lilypond-tmp-1279846.pdf) /CompatibilityLevel 1.4 /PageSize 
[595.28 841.89] (pdfwrite) finddevice putdeviceprops pop (pdfwrite) 
selectdevice newpath fill (/tmp/lilypond-tmp-1279846) (r) file .setsafe run
  Invoking `gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dAutoRotatePages=/None 
-dPrinted=false /tmp/lilypond-tmp-2084349'...

  GPL Ghostscript 10.02.1 (2023-11-01)
  Copyright (C) 2023 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.
  Error: /undefined in finddevice
  Operand stack:   --nostringval--   OutputFile   (./lilypond-tmp-1279846.pdf)  
 CompatibilityLevel   1.4   PageSize   --nostringval--   (pdfwrite)
  Execution stack:   %interp_exit   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--   
--nostringval--   --nostringval--   false   1   %stopped_push   1944   1   3   
%oparray_pop   1943   1   3   %oparray_pop   1928   1   3   %oparray_pop   1801 
  1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   
--nostringval--   --nostringval--   --nostringval--   2   %stopped_push   
--nostringval--
  Dictionary stack:   --dict:754/1123(ro)(G)--   --dict:0/20(G)--   
--dict:85/200(L)--
  Current allocation mode is local
  Current file position is 118
  GPL Ghostscript 10.02.1: Unrecoverable error, exit code 1
  warning: `(gs -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dAutoRotatePages=/None 
-dPrinted=false /tmp/lilypond-tmp-2084349)' failed (256)

  /usr/share/lilypond/2.24.2/ly/init.ly:65:2: error: Guile signaled an error 
for the expression beginning here
  #
   (let ((book-handler (if (defined? 'default-toplevel-book-handler)
  /usr/share/lilypond/2.24.2/scm/lily/lily.scm  14 (# #)
Log level set to 287
GNU LilyPond 2.25.9 (running Guile 2.2)

Relocation
  Absolute file name of LilyPond binary computed from PATH:
PATH=/home/${USER}/.local/bin:/home/${USER}/.local/x-tools/x86_64-linux-musl/bin:/home/${USER}/.local/x-tools/aarch64-linux-musl/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
argv0=lilypond
  Setting INSTALLER_PREFIX to '/usr'
  Using run-time value for datadir,
setting it to '/usr/share/lilypond/2.25.9'
  Using run-time value for libdir,
setting it to '/usr/lib/lilypond/2.25.9'
  Using run-time value for localedir,
setting it to '/usr/share/locale'
  Using compile-time value for relocdir,
setting it to ''
  Prepending '/usr/bin' to PATH
  Setting PATH to '/usr/bin:/home/${USER}/.local/bin:/home/${USER}/.local/x-tools/x86_64-linux-musl/bin:/home/${USER}/.local/x-tools/aarch64-linux-musl/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl'
Setting GUILE_AUTO_COMPILE to '0'
Setting GUILE_WARN_DEPRECATED to 'detailed'
Setting GC_INITIAL_HEAP_SIZE to '40M'
Setting GC_NPROCS to '1'
Setting GC_FREE_SPACE_DIVISOR to '1'


Effective prefix: '/usr/share/lilypond/2.25.9'
PATH="/usr/bin:/home/${USER}/.local/bin:/home/${USER}/.local/x-tools/x86_64-linux-musl/bin:/home/${USER}/.local/x-tools/aarch64-linux-musl/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl"

[]
[/usr/share/lilypond/2.25.9/scm/lily/operators.scm]
[/usr/share/lilypond/2.25.9/scm/lily/lily-library.scm]
[/usr/share/lilypond/2.25.9/scm/lily/output-lib.scm]
[/usr/share/lilypond/2.25.9/scm/lily/markup-macros.scm]
[/usr/share/lilypond/2.25.9/scm/lily/parser-ly-from-scheme.scm]
[/usr/share/lilypond/2.25.9/scm/lily/file-cache.scm]
[/usr/share/lilypond/2.25.9/scm/lily/define-event-classes.scm]
[/usr/share/lilypond/2.25.9/scm/lily/define-music-callbacks.scm]
[/usr/share/lilypond/2.25.9/scm/lily/define-music-types.scm]
[/usr/share/lilypond/2.25.9/scm/lily/define-note-names.scm]
[/usr/share/lilypond/2.25.9/scm/lily/c++.scm]
[/usr/share/lilypond/2.25.9/scm/lily/chord-entry.scm]
[/usr/share/lilypond/2.25.9/scm/lily/skyline.scm]
[/usr/share/lilypond/2.25.9/scm/lily/markup.scm]
[/usr/share/lilypond/2.25.9/scm/lily/define-markup-commands.scm]
[/usr/share/lilypond/2.25.9/scm/lily/stencil.scm]
[/usr/share/lilypond/2.25.9/scm/lily/modal-transforms.scm]
[/usr/share/lilypond/2.25.9/scm/lily/chord-ignatzek-names.scm]
[/usr/share/lilypond/2.25.9/scm/lily/music-functions.scm
[/usr/share/lilypond/2.25.9/scm/lily/define-music-disp

Re: Lilypond only respects override of Score.SpacingSpanner.strict-grace-spacing at the beginning of the score

[Ole V. Villumsen via bug-lilypond]

Thanks, Jean, that works in the first example I tried and is very, very 
helpful. Seems I had not really studied NR 4.5.6 and 4.5.2. Will go through 
chapter 4.
/Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Sunday, September 24th, 2023 at 11:28, Jean Abou Samra  
wrote:

> Le dimanche 24 septembre 2023 à 09:21 +, Ole V. Villumsen via 
> bug-lilypond a écrit :
>
>> \version "2.24.2"
>>
>> \relative {
>> g'1 |
>> % The following has no effect.
>> \override Score.SpacingSpanner.strict-grace-spacing = ##t
>> \grace { a4 } g1 |
>> }
>>
>> \relative {
>> % This works.
>> \override Score.SpacingSpanner.strict-grace-spacing = ##t
>> g'1 |
>> \grace { a4 } g1 |
>> }
>>
>> As a consequence we cannot change this property dynamically in the course of 
>> the score.
>
> This is expected. The \newSpacingSection command can be used to start a new 
> SpacingSpanner that will respond to the current active spacing settings.

Lilypond only respects override of Score.SpacingSpanner.strict-grace-spacing at the beginning of the score

[Ole V. Villumsen via bug-lilypond]

\version "2.24.2"

\relative {
  g'1 |
  % The following has no effect.
  \override Score.SpacingSpanner.strict-grace-spacing = ##t
  \grace { a4 } g1 |
}

\relative {
  % This works.
  \override Score.SpacingSpanner.strict-grace-spacing = ##t
  g'1 |
  \grace { a4 } g1 |
}

As a consequence we cannot change this property dynamically in the course of 
the score.

Context: My score contains all of \grace, \acciaccatura, \appoggiatura, 
\slashedGrace and \afterGrace. I want the first four to have the space that 
Lilypond assigns to them by default. I do not want \afterGrace to influence 
spacing of other parts on other staves. In other words I am trying to work 
around Lilypond bug #1329 (from 2010, still not solved). I can do this with a 
combination of spacers as described in NR 1.2.6 and the above mentioned 
property. But then the other kinds of grace notes get hurt. From NR 1.2.6:

\new Voice \relative {
  <<
{ d''1^\trill_( }
{ s2 s4. \grace { c16 d } }
  >>
  c1)
}

Being able to change the strict-grace-spacing for each kind of grace note would 
allow my workaround for #1329 to work.

/Ole

Link: Issue #1329 "\afterGrace placement/behaviour to be discussed":
https://gitlab.com/lilypond/lilypond/-/issues/1329

Sent with Proton Mail secure email.

Bug: Disconnected finger glide line due to colliding tuplet number

[oaap5s8g--- via bug-lilypond]

I may have found a bug where a finger glide line does
not connect to a finger number on one side when said
finger number collides with and is placed above a tuplet
number.

\version "2.24.2"

\relative c'' {
\stemUp
\override Staff.Fingering.outside-staff-priority = #1
\tuplet 3/2 { c8 c\glide-1 c-1 }
}

I checked the internals manual, but I did not see a property
that I could adjust to work around this issue. If this is not a bug
and/or there is a way to get desired behavior, then please tell
me what I can change for lilypond to produce desired output.

Re: Ugly multiple slurs over line break

[Ole V. Villumsen via bug-lilypond]

Merci, Jean, thank you.
It belongs nicely there. Sorry that my search hadn’t already determined that.
Cheers, Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Saturday, August 5th, 2023 at 00:52, Jean Abou Samra  
wrote:

> Le vendredi 04 août 2023 à 20:38 +, Ole V. Villumsen via bug-lilypond a 
> écrit :
>
>> % Multiple slurs in a Voice work nicely on one staff, as described in NR.
>> % 
>> https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-as-curves#slurs
>> % Multiple slurs crossing over a line break are ugly and collide easily.
>>
>> % I suppose modifying the shapes could be a workaround (I have not tried).
>> % 
>> https://lilypond.org/doc/v2.24/Documentation/notation/modifying-shapes#modifying-ties-and-slurs
>>
>> \version "2.24.1"
>>
>> \layout {
>> ragged-right = ##t
>> }
>>
>> \relative {
>>  
>>  \break }
>
> Wheew, that's hideous. Thank you for this example, which I've added to 
> https://gitlab.com/lilypond/lilypond/-/issues/5616
>
>>

Ugly multiple slurs over line break

[Ole V. Villumsen via bug-lilypond]

% Multiple slurs in a Voice work nicely on one staff, as described in NR.
% 
https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-as-curves#slurs
% Multiple slurs crossing over a line break are ugly and collide easily.

% I suppose modifying the shapes could be a workaround (I have not tried).
% 
https://lilypond.org/doc/v2.24/Documentation/notation/modifying-shapes#modifying-ties-and-slurs

\version "2.24.1"

\layout {
ragged-right = ##t
}

\relative {
 
 \break }

Sent with [Proton Mail](https://proton.me/) secure email.

Re: Faulty extra beam with manual beam and cross-staff stems

[Ole V. Villumsen via bug-lilypond]

Hi Will,
Thanks for your question.

My first wish would be to have cross-staff stems explained in the NR proper, 
not just in a snippet. Maybe it would fit somewhere under 2.2.1 Common notation 
for keyboards? The description would obviously best make the requirements clear 
in the text, not only implicit from an example.

The snippet that you link to was one of the two examples I had also looked at. 
And yes, I had seen \autoBeamOff and \voiceOne in the Lilypond source, but 
their significance was not clear to me. Since the text preceding the snippet 
already states that the stem length needs not be specified, I would find it 
natural also to add the requirement that \autoBeamOff is needed.

Finally a warning message from Lilypond would be nice when I do it wrong so 
that I don’t start suspecting a bug. Explanatory and with suggestion how to fix 
if possible.

Cheers, Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Tuesday, August 1st, 2023 at 22:15, William Rehwinkel 
 wrote:

> I can see "\autoBeamOff" pretty clearly here, which was the first link found 
> from googling "lilypond cross-staff stems"
>
> https://lilypond.org/doc/v2.25/Documentation/snippets/staff-notation_003a-cross-staff-stems
>
> -will
>
> On 8/1/23 15:22, Ole V. Villumsen via bug-lilypond wrote:
>
>> Hi Jean,
>> indeed. I retract my bug report.
>> Your solution works in the case where I specify \crossStaff in the lower 
>> staff (or both) and, as you say, the manual beams only in the upper staff.
>> And no, this is pretty far from perfect and could also benefit from being 
>> made clear in the NR.
>> Cheers,
>> Ole
>>
>> Sent with Proton Mail secure email.
>>
>> --- Original Message ---
>> On Tuesday, August 1st, 2023 at 20:46, Jean Abou Samra
>> [](mailto:j...@abou-samra.fr)
>> wrote:
>>
>>> Le mardi 01 août 2023 à 18:34 +, Ole V. Villumsen via bug-lilypond a 
>>> écrit :
>>>
>>>> % Manual beams and cross-staff stems don’t seem to work together.
>>>> % Expected result: Shared stems across staves; beams above notes in upper 
>>>> staff only.
>>>>
>>>> % I have tried all possible combinations of specifying beams and 
>>>> \crossStaff in the
>>>> % upper staff, the lower one and both. I always get unwanted beams in the 
>>>> lower staff.
>>>
>>> You should add \autoBeamOff in the lower staff, and remove the manual beams 
>>> there.
>>>
>>> \version "2.25.7"
>>>
>>> \layout {
>>> \context {
>>> \PianoStaff
>>> \consists "Span_stem_engraver"
>>> }
>>> }
>>>
>>> \new PianoStaff <<
>>> \new Staff \relative {
>>> r8 e'[ e] r
>>> r e e r |
>>> r e[ e] r
>>> r e[ e] r |
>>> r e e r
>>> r e[ e] r |
>>> r e[ e] r
>>> r e e r |
>>> r e[ e] r
>>> r2 |
>>> }
>>> \new Staff \relative {
>>> \clef bass
>>> \stemUp
>>> \autoBeamOff
>>> \crossStaff {
>>> r8 g g r
>>> r g g r |
>>> r g g r
>>> r g g r |
>>> r g g r
>>> r g g r |
>>> r g g r
>>> r g g r |
>>> r g g r
>>> r2 |
>>> }
>>> }
>>>
>>> \crossStaff requires an explicit \autoBeamOff. I'm not saying that this is
>>> the perfect user interface, but there is no bug here.
>>>
>>> Jean
>
> --
> + --- +
> |   William Rehwinkel - Oberlin College and   |
> |  Conservatory '24   |
> |
> will...@williamrehwinkel.net
> |
> | PGP key:|
> |
> https://ftp.williamrehwinkel.net/pubkey.txt
> |
> + --- +

Re: Faulty extra beam with manual beam and cross-staff stems

[William Rehwinkel via bug-lilypond]

I can see "\autoBeamOff" pretty clearly here, which was the first link 
found from googling "lilypond cross-staff stems"


https://lilypond.org/doc/v2.25/Documentation/snippets/staff-notation_003a-cross-staff-stems

-will

On 8/1/23 15:22, Ole V. Villumsen via bug-lilypond wrote:

Hi Jean,
indeed. I retract my bug report.
Your solution works in the case where I specify \crossStaff in the lower staff 
(or both) and, as you say, the manual beams only in the upper staff.
And no, this is pretty far from perfect and could also benefit from being made 
clear in the NR.
Cheers,
Ole

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, August 1st, 2023 at 20:46, Jean Abou Samra  
wrote:



Le mardi 01 août 2023 à 18:34 +, Ole V. Villumsen via bug-lilypond a écrit :


% Manual beams and cross-staff stems don’t seem to work together.
% Expected result: Shared stems across staves; beams above notes in upper staff 
only.

% I have tried all possible combinations of specifying beams and \crossStaff in 
the
% upper staff, the lower one and both. I always get unwanted beams in the lower 
staff.


You should add \autoBeamOff in the lower staff, and remove the manual beams 
there.

\version "2.25.7"


\layout {
\context {
\PianoStaff
\consists "Span_stem_engraver"
}
}

\new PianoStaff <<
\new Staff \relative {
r8 e'[ e] r
r e e r |
r e[ e] r
r e[ e] r |
r e e r
r e[ e] r |
r e[ e] r
r e e r |
r e[ e] r
r2 |
}
\new Staff \relative {
\clef bass
\stemUp
\autoBeamOff
\crossStaff {
r8 g g r
r g g r |
r g g r
r g g r |
r g g r
r g g r |
r g g r
r g g r |
r g g r
r2 |
}
}




\crossStaff requires an explicit \autoBeamOff. I'm not saying that this is
the perfect user interface, but there is no bug here.

Jean


--
+ --- +
|   William Rehwinkel - Oberlin College and   |
|  Conservatory '24   |
|will...@williamrehwinkel.net  |
| PGP key:|
|https://ftp.williamrehwinkel.net/pubkey.txt  |
+ --- +



OpenPGP_signature
Description: OpenPGP digital signature

Re: Faulty extra beam with manual beam and cross-staff stems

[Ole V. Villumsen via bug-lilypond]

Hi Jean,
indeed. I retract my bug report.
Your solution works in the case where I specify \crossStaff in the lower staff 
(or both) and, as you say, the manual beams only in the upper staff.
And no, this is pretty far from perfect and could also benefit from being made 
clear in the NR.
Cheers,
Ole

Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, August 1st, 2023 at 20:46, Jean Abou Samra  
wrote:


> Le mardi 01 août 2023 à 18:34 +, Ole V. Villumsen via bug-lilypond a 
> écrit :
> 
> > % Manual beams and cross-staff stems don’t seem to work together.
> > % Expected result: Shared stems across staves; beams above notes in upper 
> > staff only.
> > 
> > % I have tried all possible combinations of specifying beams and 
> > \crossStaff in the
> > % upper staff, the lower one and both. I always get unwanted beams in the 
> > lower staff.
> 
> 
> You should add \autoBeamOff in the lower staff, and remove the manual beams 
> there.
> 
> \version "2.25.7"
> 
> 
> \layout {
> \context {
> \PianoStaff
> \consists "Span_stem_engraver"
> }
> }
> 
> \new PianoStaff <<
> \new Staff \relative {
> r8 e'[ e] r
> r e e r |
> r e[ e] r
> r e[ e] r |
> r e e r
> r e[ e] r |
> r e[ e] r
> r e e r |
> r e[ e] r
> r2 |
> }
> \new Staff \relative {
> \clef bass
> \stemUp
> \autoBeamOff
> \crossStaff {
> r8 g g r
> r g g r |
> r g g r
> r g g r |
> r g g r
> r g g r |
> r g g r
> r g g r |
> r g g r
> r2 |
> }
> }
> 
> 
> 
> 
> \crossStaff requires an explicit \autoBeamOff. I'm not saying that this is
> the perfect user interface, but there is no bug here.
> 
> Jean

Faulty extra beam with manual beam and cross-staff stems

[Ole V. Villumsen via bug-lilypond]

% Manual beams and cross-staff stems don’t seem to work together.
% Expected result: Shared stems across staves; beams above notes in upper staff 
only.

% I have tried all possible combinations of specifying beams and \crossStaff in 
the
% upper staff, the lower one and both. I always get unwanted beams in the lower 
staff.

% Might be related to https://gitlab.com/lilypond/lilypond/-/issues/3390

\version "2.24.1"

\layout {
  \context {
    \PianoStaff
    \consists "Span_stem_engraver"
  }
}

\new PianoStaff <<
  \new Staff \relative {
    r8 \crossStaff { e'[ e] } r
    r \crossStaff { e e } r |
    r \crossStaff { e[ e] } r
    r e[ e] r |
    r e e r
    r e[ e] r |
    r \crossStaff { e[ e] } r
    r \crossStaff { e e } r |
    r \crossStaff { e[ e] } r
    r2 |
  }
  \new Staff \relative {
    \clef bass
    \stemUp
    r8 g g r
    r g[ g] r |
    r g[ g] r
    r \crossStaff { g g } r |
    r \crossStaff { g[ g] } r
    r \crossStaff { g[ g] } r |
    r \crossStaff { g g } r
    r \crossStaff { g[ g] } r |
    r \crossStaff { g[ g] } r
    r2 |
  }
>>

--
Ole V. Villumsen
Jelshøjvænget 13
DK - 8270  Højbjerg
+45 - 86 27 29 26
Text +45 - 30 22 29 26

Sent with Proton Mail secure email.

tuplets with tupletFullLength collide with barline

[Gilberto Agostinho via bug-lilypond]

Hello Bug Squad,

When using tuplets with tupletFullLength set to True, the last tuplet 
bracket in a system extends all the way to the barline. This results in 
potential collisions when barlines cross several staves. E.g., in the 
output of the code below, the right ending of the last tuplet of the 
bottom staff is colliding with the barline. All other previous tuplet 
brackets avoid the barlines.


\version "2.25.5"

\new PianoStaff <<
    \new Staff {
    \set tupletFullLength = ##t
    \tuplet 3/2 {c'2 c'2 c'2}
    \tuplet 3/2 {c'2 c'2 c'2}
    \tuplet 3/2 {c'2 c'2 c'2}
    }
    \new Staff {
    \set tupletFullLength = ##t
    \tuplet 3/2 {c'2 c'2 c'2}
    \tuplet 3/2 {c'2 c'2 c'2}
    \tuplet 3/2 {c'2 c'2 c'2}
    }
>>

Resulting in: https://i.postimg.cc/44Fm8vLv/tuplets.png

Best wishes,
Gilberto

Barline doesn't whiteout stave lines sometimes

[William Rehwinkel via bug-lilypond]

Dear list,

In the following example, the stave lines overlap the barlines at the 
end of the bottom two staves (the expected behavior would have been for 
the stave lines to be interrupted by the bar lines like the others).


Thank you,
-William

% ---

\version "2.25.4"


notes = \repeat unfold 6 \relative c' { c4 c c c \bar "." }

\score {
  <<
    \new Staff \notes
    \new Staff \notes
    \new Staff \notes
    \new Staff \notes
    \new Staff \notes
  >>
  \layout {
    \context {
  \Staff
  \override BarLine.color = #red
    }
  }
}

% ---

--
+ --- +
|   William Rehwinkel - Oberlin College and   |
|  Conservatory '24   |
|will...@williamrehwinkel.net  |
| PGP key:|
|https://ftp.williamrehwinkel.net/pubkey.txt  |
+ --- +



OpenPGP_signature
Description: OpenPGP digital signature

Re: Crash in 2.25.4

[Gwyn Ciesla via bug-lilypond]

Wonderful, thank you!




\--


Gwyn Ciesla


she/her/hers


\


in your fear, seek only peace


in your fear, seek only love


\-d. bowie







Sent from Proton Mail mobile



\ Original Message 
On May 18, 2023, 12:53 PM, Jean Abou Samra < j...@abou-samra.fr> wrote:

>
>
>
> Le jeudi 18 mai 2023 à 11:27 +0200, Jean Abou Samra a écrit :
>
> > Gwyn, is it convenient for you to test patches? I think I see what this is 
> > caused by, but I cannot reproduce the bug in a local build (knowing what 
> > exact compiler flags are used in Fedora's builds might help).
> >
> > I'd like to know if this fixes it:
> >
> > ```
> > [...]
> >
> > Thank you.
> > ```
>
>
>
>
>
>
>
>
>
>
> Thanks for the info you provided privately.
>
>
>
>
> The fix 
> [https://gitlab.com/lilypond/lilypond/-/merge\_requests/2007][https_gitlab.com_lilypond_lilypond_-_merge_requests_2007]
>  has been merged. LilyPond 2.25.5 is planned for this weekend.
>
>
>


[https_gitlab.com_lilypond_lilypond_-_merge_requests_2007]: 
https://gitlab.com/lilypond/lilypond/-/merge_requests/2007

signature.asc
Description: OpenPGP digital signature

Crash in 2.25.4

[Gwyn Ciesla via bug-lilypond]

Attaching reproducer.

>From Fedora bug:

When I attempt to build a score using a PianoStaff or GrandStaff (which 
contains more than one sub-staff), lilypond crashes.

Reproducible: Always

Steps to Reproduce:
1. Attempt to build a minimal reproducer (which I will attach) with 
lilypond-2.25.4
Actual Results:  
Slightly varying modes of crashing.

#1) Without dumping core:

--- 8< ---
nils@makake:~/music> lilypond minimal.ly 

GNU LilyPond 2.25.4 (running Guile 2.2)
Processing `minimal.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
/usr/share/lilypond/2.25.4/ly/init.ly:64:2: error: Guile signaled an error for 
the expression beginning here
#
 (let ((book-handler (if (defined? 'default-toplevel-book-handler)
In procedure scm_hash_fn_create_handle_x: Error while printing exception.
--- >8 ---

#2) With dumping core:

--- 8< ---
nils@makake:~/music> lilypond minimal.ly 

GNU LilyPond 2.25.4 (running Guile 2.2)
Processing `minimal.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
/usr/share/lilypond/2.25.4/ly/init.ly:64:2: error: Guile signaled an error for 
the expression beginning here
#
 (let ((book-handler (if (defined? 'default-toplevel-book-handler)
In procedure scm_hash_fn_create_handle_x: Wrong type argument in position 1 
(expecting hash-table): Segmentation fault (core dumped)
--- >8 ---

Expected Results:  
It builds a PDF from the score.

- I get the same behavior on Fedora 38 and Rawhide.
- Using the lilypond-2.25.3 Fedora package _or_ the 2.25.4 binary from upstream 
doesn’t exhibit the issue.


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.\version "2.25.3"

global = {
  \key c \major
  \time 4/4
}

right = \relative c'' {
  \global
  % Music follows here.

  c4 d e f | g f e d | c1
}

left = \relative c' {
  \global
  % Music follows here.

  c4 d e f | g f e d | c1
}

\score {
  %% This could also be a GrandStaff
  \new PianoStaff <<
%% It must contain two staves to show the problem
\new Staff = "right" \right
\new Staff = "left" { \clef bass \left }
  >>
  \layout { }
}


signature.asc
Description: OpenPGP digital signature

\autoChange behaves inconsistently when rests are present

[Gilberto Agostinho via bug-lilypond]

Hi all,

I've came across a strange bug with \autoChange which was not present in 
version 2.22.2 but is present in version 2.24.1 (and was probably 
introduced somewhere in between these two versions). Basically, 
autoChange will sometimes change staves inconsistently and display some 
notes in the wrong staff depending on whether a)rests are present in the 
preceding music, or b) whether the affected note is the last one of the 
staff, in which case it seems to behave normally. It seems like a 
complex behaviour and I haven't been able to pin it down completely, but 
here are two screenshots showing the output of the two versions.


Version 2.22.2: https://i.postimg.cc/bvnV7JKG/ly2-22-2.png
Version 2.24.1: https://i.postimg.cc/B6G7430m/ly2-24-1.png

The example used is:

   \new PianoStaff {
  \autoChange {
    g4 a b c'
    d'4 r a g
    g4 c' d' e'
  }
    }
    \new PianoStaff {
  \autoChange {
    g4 a b c'
    d'4 r a g
    g4 c' d' e'
    g4 c' d' e'
  }
    }
    \new PianoStaff {
  \autoChange {
    g4 a b c'
    d'4 g a g
    g4 c' d' e'
    g4 c' d' e'
  }
    }
    \new PianoStaff {
  \autoChange {
    g4 a b c'
    d'4 r a g
    g4 c' d' e'
    R1
    g4 c' d' e'
  }
    }

The behaviour in 2.22.2 is exactly as expected, with changes happening 
around middle C by default; C4's stay in the current staff of previous 
notes, and rests are placed in the staff corresponding to the next 
pitched note.


The list of issues in version 2.24.1 in my minimal example are:

 * Stave 1: due to the presence blue rest, the next C4 is placed in the
   wrong staff. Notice how the last E4 is correctly place for now
 * Stave 2: once again, due to the rest present, the C4s are
   incorrectly placed, and so is now the E4 (which is not the last note
   of the staff any longer)
 * Stave 3: there are no rests any more, so the behaviour is as
   expected and identical to version 2.22.2
 * Stave 4: once again, the presence of rests messes some notes up,
   this time also affecting the G4 in the final bar


Best wishes,
Gilberto

Re: I would like to fix some documentation issues

[Jonas Hahnfeld via bug-lilypond]

On Mon, 2023-03-27 at 18:06 -0500, Jason Yip via bug-lilypond wrote:
> Hi, I'm following the steps listed at 
> https://lilypond.org/doc/v2.25/Documentation/contributor/introduction-to-issues
>  
> to get started.
> 
> My gitlab id: ljyip

Note that these instructions are for issue *triage*, ie adding labels.
For fixing issues, ie submitting merge requests, you don't need to be
in the group, strictly speaking. But since you are hopefully going to
work on more MRs during your GSoC, I went accepted your membership
application ️ (and sorry for not making the connection between your
posts on the different mailing lists)

Jonas


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

Apply @code{} to two instances of `\book` in NR

[Jason Yip via bug-lilypond]

In NR 3.2.1 "Structure of a score", 2 references to the `\book` command 
are not in a `@code{}` command in the 2nd last paragraph.



diff --git a/Documentation/en/notation/input.itely 
b/Documentation/en/notation/input.itely

index f7a6ea6..9e7bfd3 100644
--- a/Documentation/en/notation/input.itely
+++ b/Documentation/en/notation/input.itely
@@ -235,7 +235,7 @@ block, and inside or outside the single music 
expression within a

 @code{\score} block.

 Remember that even in a file containing only a @code{\score} block, it
-is implicitly enclosed in a \book block.  A \book block in a source
+is implicitly enclosed in a @code{\book} block.  A @code{\book} block 
in a source

 file produces at least one output file, and by default the name of the
 output file produced is derived from the name of the input file, so
 @file{fandangoforelephants.ly} will produce


--
- Jason Yip



OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

I would like to fix some documentation issues

[Jason Yip via bug-lilypond]

Hi, I'm following the steps listed at 
https://lilypond.org/doc/v2.25/Documentation/contributor/introduction-to-issues 
to get started.


My gitlab id: ljyip

Thanks!

- Jason Yip



OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bug related to breve rests in Lilypond version 2.24.1

[William Rehwinkel via bug-lilypond]

I just tested this on my machine, and this didn't seem to happen. The 
rest was rendered with a line above and below, which I think is how it 
is supposed to be drawn, similarly to half and whole rests.


-William

On 3/23/23 14:39, thysupremematrix--- via bug-lilypond wrote:

Code:

\version "2.24.1"
\new ChoirStaff \relative c {
   % breve rest has lines on either side, like a normal breve note, when it 
shouldn't  c\breve\rest
}

By Matrix :)


--
+ -- +
|William Rehwinkel - Oberlin College and |
|   Conservatory '24 |
|  will...@williamrehwinkel.net  |
| PGP key:   |
| https://williamrehwinkel.net/static/pubkey.txt |
+ -- +


OpenPGP_0x55FE8F99DD713D20.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug related to breve rests in Lilypond version 2.24.1

[thysupremematrix--- via bug-lilypond]

Code:

\version "2.24.1"
\new ChoirStaff \relative c {
  % breve rest has lines on either side, like a normal breve note, when it 
shouldn't  c\breve\rest
}

By Matrix :)

Re: Standard paper size too big

[Federico Bruni via bug-lilypond]

Il giorno ven 3 mar 2023 alle 11:45:08 +0100, Jean Abou Samra 
 ha scritto:

Le vendredi 03 mars 2023 à 11:26 +0100, Ruben du Pon a écrit :
 That may be the case, but as I said when I print straight from 
Frescobaldi the score doesn't fit the page (the bottom staff is 
mostly missing) and when I open it in acrobat reader it fits at 89%, 
so something is off about the paper size.



I don't think so. Try printing any A4 document from Acrobat or 
Frescobaldi and seeing if you get the same behavior. Pretty sure you 
will. Then you should either find the proper settings in Acrobat (I 
don't have it), or in Frescobaldi, or write a bug report to 
Frescobaldi. From LilyPond's point of view, I don't see anything 
wrong here.


I remember old discussions about this issue in Frescobaldi. IIRC 
Frescobaldi simply relies on some default linux printing command. 
Probably printer settings and drivers are playing a role.

Let's follow up here:
https://github.com/frescobaldi/frescobaldi/issues/1365

Re: Standard paper size too big

[samarutuk via bug-lilypond]

Hi, the margins must also fit the printer specifications. If you choose 
e.g. 2 mm for top, bottom, left or right, many printers will not be able 
to print that, because there is a minimum margin depending on the 
printer. Acrobat will then adjust the document to fit the printer (89% 
in your case). You can also tell Acrobat to print the page without 
adjusting to the printer's minimum margins, which is 100%. But then what 
is missing is what the printer cannot print because it is too close to 
the edge of the page. Under Document Properties in Acrobat you can also 
see the dimensions of the paper. If they differ, enter the dimensions of 
the paper directly in the lilypond code under \paper, if it really 
should not be A4.

\paper {
paper-height = 297\mm
paper-width = 210\mm
}


Am 03.03.2023 um 12:06 schrieb Jean Abou Samra:



Le 3 mars 2023 à 11:45, Jean Abou Samra  a écrit :



Le vendredi 03 mars 2023 à 11:26 +0100, Ruben du Pon a écrit :

That may be the case, but as I said when I print straight from Frescobaldi the 
score doesn't fit the page (the bottom staff is mostly missing) and when I open 
it in acrobat reader it fits at 89%, so something is off about the paper size.


I don't think so. Try printing any A4 document from Acrobat or Frescobaldi and 
seeing if you get the same behavior. Pretty sure you will. Then you should 
either find the proper settings in Acrobat (I don't have it), or in 
Frescobaldi, or write a bug report to Frescobaldi. From LilyPond's point of 
view, I don't see anything wrong here.



Also, make sure your are printing to A4 paper. US letter paper is about 2cm 
less than A4 in height, so if your printer dialog is trying to fit A4 into US 
letter, that could indeed crop the bottom.

Re: weinberg-drums-style doesn't comply with the Guide to Standardized Notation

[Jonas Hahnfeld via bug-lilypond]

(CC'ing Alen Šiljak, the author of the weinberg-drums-style)

On Wed, 2023-02-01 at 10:09 -0800, Stu McKenzie wrote:
> I'm referring to the web page 
> https://lilypond.org/doc/v2.24/Documentation/changes/ where it is stated 
> that
> "The drum notation style weinberg-drums-style was added. It is based on 
> Norman Weinberg’s standardization work".
> 
> This is indeed a sterling effort on the part of the development team, 
> which I appreciate greatly.  As Weinberg states, there is a definite 
> need for standardization of drum scores.
> 
> There are however a few implementation and documentation issues.
> 
> The weinberg-drums-style is documented in "LilyPond — Notation Reference 
> v2.24.0" at
> https://lilypond.org/doc/v2.24/Documentation/notation/common-notation-for-percussion
> 
> Section "2.5.1 Common notation for percussion",  sub-section "Percussion 
> staves" includes the predefined layout for "weinberg-drums-style. Based 
> on the work of Norman Weinberg, published in his Guidelines for Drumset 
> Notation."
> 
> 1)
> On the first staff, Bass drum 1 (bd) and bass drum 2 (bda) are the same.

This has been addressed in 2.25.0, see the documentation of the
unstable release:
https://lilypond.org/doc/v2.25/Documentation/notation/common-notation-for-percussion.html#percussion-staves
It will also be available in the bugfix release 2.24.1.

> 2)
> On the second staff, sidestick (ss) should be referred to as 
> Cross-Stick, and should not have a cross notehead.
> 
> The Weinberg book has a section on Noteheads, where he states "The 
> indication of the cross-stick technique should be a circled notehead".
> 
> I've been using my own notehead to date, but it would be great if 
> someone could add a notehead to do this.
> 
> In the past, I've had to generate my own cross-stick with the following 
> code:
> 
> CircleNoteHead =
> \once \override NoteHead.stencil = #(lambda (grob)
>   (let* ((note (ly:note-head::print grob))
>      (combo-stencil (ly:stencil-add
>      note
>      (circle-stencil note 0.1 0.2
>     (ly:make-stencil (ly:stencil-expr combo-stencil)
>   (ly:stencil-extent note X)
>   (ly:stencil-extent note Y
> 
> CrossStickQtr = \drummode { \CircleNoteHead sn4 }
> 
> I'm sure that those who are familiar with noteheads can provide a better 
> solution with a new notehead for this.
> 
> 3)
> On the second and third staves, tom-toms are wrongly positioned.
> 
> The notation documentation example has 6 tom-toms (toms).
> 
> The Weinberg Guidelines book has a section on TOM-TOMS, where he states 
> "The staff position for tom-toms depends upon the total number of toms 
> required for performance".
> 
> The book has examples of from 1 to 10 toms.
> 
> The "6 Toms" example has:
> 
>   *   Tom 1 on the top line
>   *   Tom 2 on the top space
>   *   Tom 3 on the 2nd line
>   *   Tom 4 on the middle line
>   *   Tom 5 on the 3rd space
>   *   Tom 6 on the 4th line
> 
> 
> The Notation example doesn't match this configuration.
> 
> The LilyPond documentation for "weinberg-drums-style" has 6 toms, so the 
> staff positioning should be (using the documented voice names):
> 
>   *   tommh line 1   (I would prefer tomhh)
>   *   tomh  space 1  (I would prefer tomhl)
>   *   tomml line 2   (I would prefer tommh)
>   *   toml  line 3   (I would prefer tomml)
>   *   tomfh space 3  (I would prefer tomlh or continue with tomfh)
>   *   tomfl line 4   (I would prefer tomll or continue with tomfl)
> 
> 
> A standard drum kit usually has 3 toms, so dependant on the number of 
> toms, one could implement a different style for each, e.g. 
> weinberg-drums-style-three-toms, or name the current version 
> weinberg-drums-style-six-toms and authors could use a subset as required.

I think tommh and tomh being the same is equally addressed. Changing
the other note names would be tough and quite a breaking change...

> 4)
> On the fourth staff, cymc & cymr are correctly positioned, but the 
> others do not match the position & noteheads as detailed in the guide book.
> 
> 5)
> If a standardized notation is to be defined, any variation to the 
> standard would require a Custom percussion stave and a legend, and the 
> ability to do that is currently available.
> 
> _*Conclusion*_
> 
> It seems that the weinberg-drums-style implementation does not reflect 
> the Weinberg guide very well.  Perhaps the implementation should be 
> corrected or removed.
> 
> Any change would require a "convertly" tool to convert e

Re: New breathing mark

[samarutuk via bug-lilypond]

Thank you, Carl,
for me it is already a visual bug ;-), but I will take that to heart 
next time and rather contact lilypond-devel in such a case. Regarding 
the breath sign, I will start a request via gitlab.

Kind regards
Andreas

Am 12.11.2022 um 21:47 schrieb Carl Sorensen:

On Sat, Nov 12, 2022 at 10:00 AM  wrote:

From: samarutuk

To: bug-lilypond
Cc:
Bcc:
Date: Sat, 12 Nov 2022 10:10:35 +0100
Subject: Breath mark style in LilyPond 2.23.80
Dear all,
when I tried version 2.23.80 for the first time yesterday, I was
absolutely shocked to see the new, very mundane comma as a breath mark
when rendering. I know that other notation programs also use the comma,
but for me the more caesura-like character used before was always a
reason to use Emmentaler/Feta, also and especially in MuseScore. The
normal text style comma, with its delicate tadpole continuation, goes
down much more easily in an opulent score with lyrics, staccato dots,
and other expressive marks. It's a misstep aesthetically and for
readability reasons, in my humble opinion. As a brass player, breath
marks are very important and actually occur in large numbers, so this
comma will really haunt me constantly.
However, since I don't expect you to undo it, then I do ask that you
still preserve the old style so that each Lilypondian can decide for
themselves whether to use the snappy comma or the Emmental original
breath mark (tm). If MuseScore (which I still use) adopts the modified
font, I may add the old breath mark there as well.
Sorry for the long text... and yes, I'm still shocked (and sticking with
older versions for now).
Kind regards
Andreas



Andreas,

This was an intentional change, implemented in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1576

At least two developers prefer the new breath mark.

Perhaps you could request that the old mark be added back to Feta, and that
code allowing one to use the old mark be developed.

Since this was an intentional change, it's not a bug, so bug-lilypond is
not the best place to discuss it.  Either lilypond-user or lilypond-devel
would be a better place.

Sincerely,

Carl
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Breath mark style in LilyPond 2.23.80

[samarutuk via bug-lilypond]

I think users can't help me there, Mark,
the old default \breathe character was replaced by the developers in the 
font and exchanged for a text style-like comma. I would like to see the 
old breath mark symbol preserved somewhere in the font, so you can still 
use it. By the way, here are all the breath marks now available listed, 
the "old" one is not there: 
https://lilypond.org/doc/v2.23/Documentation/notation/list-of-breath-marks

kind regards
Andreas

Am 12.11.2022 um 10:19 schrieb Mark Knoop:

At 10:10 on 12 Nov 2022, samarutuk via bug-lilypond wrote:

Dear all, when I tried version 2.23.80 for the first time yesterday, I
was absolutely shocked to see the new, very mundane comma as a breath
mark when rendering. I know that other notation programs also use the
comma, but for me the more caesura-like character used before was
always a reason to use Emmentaler/Feta, also and especially in
MuseScore. The normal text style comma, with its delicate tadpole
continuation, goes down much more easily in an opulent score with
lyrics, staccato dots, and other expressive marks. It's a misstep
aesthetically and for readability reasons, in my humble opinion. As a
brass player, breath marks are very important and actually occur in
large numbers, so this comma will really haunt me constantly. However,
since I don't expect you to undo it, then I do ask that you still
preserve the old style so that each Lilypondian can decide for
themselves whether to use the snappy comma or the Emmental original
breath mark (tm). If MuseScore (which I still use) adopts the modified
font, I may add the old breath mark there as well. Sorry for the long
text... and yes, I'm still shocked (and sticking with older versions
for now).

Search for \breathe on this page.

https://lilypond.org/doc/v2.23/Documentation/changes/index.html

Perhaps the user list might be more appropriate for these sort of questions?


--
Mark Knoop

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Breath mark style in LilyPond 2.23.80

[samarutuk via bug-lilypond]

Dear all,
when I tried version 2.23.80 for the first time yesterday, I was 
absolutely shocked to see the new, very mundane comma as a breath mark 
when rendering. I know that other notation programs also use the comma, 
but for me the more caesura-like character used before was always a 
reason to use Emmentaler/Feta, also and especially in MuseScore. The 
normal text style comma, with its delicate tadpole continuation, goes 
down much more easily in an opulent score with lyrics, staccato dots, 
and other expressive marks. It's a misstep aesthetically and for 
readability reasons, in my humble opinion. As a brass player, breath 
marks are very important and actually occur in large numbers, so this 
comma will really haunt me constantly.
However, since I don't expect you to undo it, then I do ask that you 
still preserve the old style so that each Lilypondian can decide for 
themselves whether to use the snappy comma or the Emmental original 
breath mark (tm). If MuseScore (which I still use) adopts the modified 
font, I may add the old breath mark there as well.
Sorry for the long text... and yes, I'm still shocked (and sticking with 
older versions for now).

Kind regards
Andreas
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: musicxml2ly

[Federico Bruni via bug-lilypond]

Il giorno mer 9 nov 2022 alle 09:14:44 +0100, Denis Penard 
 ha scritto:

So I use your program musixml2py. It works very well.

I would like to have no repetition of note duration, for example if I
have four c8, I would like to get c8 c c c in lily.

I have studied the python code, but I am not very skilled in Python. 
It is

complicated to have this possibility?


I don't think that musicxml2ly has an option for this.

The easiest option is fixing the input afterwards in Frescobaldi: 
select the music, then Tools>Musical transformation>Rhythm>Make 
implicit.

Maybe python-ly has a command to do this on the command line:
https://python-ly.readthedocs.io/en/latest/




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Articulations in same spot where slur ends

[Ole V. Villumsen via bug-lilypond]

Hi Kevin!

Thanks. Indeed it is.

I am sorry, of course, that I had not already found it. I had not been aware 
that I had to sign in to GitLab for search there to work, and my search engine 
had not found it.

Best, Ole

Sent with Proton Mail secure email.

--- Original Message ---
On Saturday, October 29th, 2022 at 11:36, Kevin Barry  wrote:


> On Sat, Oct 29, 2022 at 06:29:05AM +, Ole V. Villumsen via bug-lilypond 
> wrote:
> 
> > Thanks, Pierre! That looks good and isn’t so hacky as my own workaround.
> > I will do some further experimentation to see if it fulfils my need
> > and wishes. I still think there’s a bug, though. Best regards, Ole
> 
> 
> Yes, this is a known bug. It's currently being tracked here:
> https://gitlab.com/lilypond/lilypond/-/issues/6120
> 
> Kevin

_______
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Articulations in same spot where slur ends

[Ole V. Villumsen via bug-lilypond]

Thanks, Pierre! That looks good and isn’t so hacky as my own workaround.
I will do some further experimentation to see if it fulfils my need and wishes. 
I still think there’s a bug, though.
Best regards, Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Saturday, October 29th, 2022 at 08:08, Pierre Perol-Schneider 
 wrote:

> Hi Ole,
> I'd do:
>
> \relative c' {
> d'8( c\prall-\tweak avoid-slur #'outside \turn)
> }
>
> Cheers,
> Pierre
>
> Le sam. 29 oct. 2022 à 07:58, Ole V. Villumsen via bug-lilypond 
>  a écrit :
>
>> A possible workaround is something like
>>
>> d'8( c\prall-\tweak extra-offset #'(0 . 1.3)\turn)
>>
>> /Ole
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> --- Original Message ---
>> On Saturday, October 29th, 2022 at 07:01, Ole V. Villumsen 
>>  wrote:
>>
>>> Hi,
>>> Often, not always, when a slur ends on a note with the \prall\turn 
>>> combination (custom in baroque music), the prall and the turn are printed 
>>> colliding/overlapping in one spot rather than the turn above and the prall 
>>> below as they should. Please see the attachments.
>>>
>>> Best regards, Ole
>>>
>>> --
>>> Ole V. Villumsen
>>> Jelshøjvænget 13
>>> DK–8270 Højbjerg
>>> Denmark
>>> +45 - 86 27 29 26
>>> SMS +45 - 30 22 29 26
>>>
>>> Sent with [Proton Mail](https://proton.me/) secure email.
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Articulations in same spot where slur ends

[Ole V. Villumsen via bug-lilypond]

A possible workaround is something like

d'8( c\prall-\tweak extra-offset #'(0 . 1.3)\turn)

/Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Saturday, October 29th, 2022 at 07:01, Ole V. Villumsen 
 wrote:

> Hi,
> Often, not always, when a slur ends on a note with the \prall\turn 
> combination (custom in baroque music), the prall and the turn are printed 
> colliding/overlapping in one spot rather than the turn above and the prall 
> below as they should. Please see the attachments.
>
> Best regards, Ole
>
> --
> Ole V. Villumsen
> Jelshøjvænget 13
> DK–8270 Højbjerg
> Denmark
> +45 - 86 27 29 26
> SMS +45 - 30 22 29 26
>
> Sent with [Proton Mail](https://proton.me/) secure email.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Articulations in same spot where slur ends

[Ole V. Villumsen via bug-lilypond]

Hi,
Often, not always, when a slur ends on a note with the \prall\turn combination 
(custom in baroque music), the prall and the turn are printed 
colliding/overlapping in one spot rather than the turn above and the prall 
below as they should. Please see the attachments.

Best regards, Ole

--
Ole V. Villumsen
Jelshøjvænget 13
DK–8270 Højbjerg
Denmark
+45 - 86 27 29 26
SMS +45 - 30 22 29 26

Sent with [Proton Mail](https://proton.me/) secure email.

prall-turn-bug.ly
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

Hi Pierre,
Thank you, merci beaucoup! For my situation that is extremely helpful. The 
documentation link too. I much prefer your solution over the ones by Paul, Mark 
and Kevin pretending that the incomplete 3/4 measure is an upbeat, which it 
isn’t. The way I read the documentation, in theory there might be situations 
where telling Lilypond that 3/4 is 2/4 would give improper beaming, but 
certainly not in my case, and in other cases this can be easily corrected by 
hand.

A happy weekend to all,
Best regards, Ole

Sent with Proton Mail secure email.

--- Original Message ---
On Friday, October 28th, 2022 at 17:29, Kevin Barry  wrote:


> On Fri, Oct 28, 2022 at 03:15:48PM +, Ole V. Villumsen wrote:
> 
> > > If you use \partial at the beginning of a score it treats the resulting
> > > duration as the length of music preceding the first bar. This is how bar
> > > numbering generally works for upbeats/anacrusis.
> > 
> > Obviously confirmed.
> 
> 
> I mean that it is documented behaviour. The NR says "When \partial is
> used at the beginning of a score, duration is the length of the music
> preceding the first bar."
> 
> > I admit that I wondered more than a bit about the requirement in the
> > Notation Reference to insert a \partial "when the time signature
> > changes in mid measure". Composers do not always want an
> > upbeat/fractional pick-up there. Maybe supplying a zero duration is a
> > hack; but what is the alternative? At least NR doesn’t give one.
> 
> 
> It used to be the case that you had to use a different (more
> complicated) syntax to do that, but since the functionality was quite
> similar to partial, partial was updated to work when used at times other
> than the beginning of a piece.
> 
> > > All of the examples of \partial in the documentation use it at the
> > > beginning of a bar and supply the duration. If you do the same it should
> > > work for you.
> > 
> > I didn’t see any examples of a zero partial in the docs either. I have
> > trouble making good sense of your last statement, though, sorry. What
> > are you suggesting to do when the composer did not intend nor supply
> > an upbeat? (My example is from C.Ph.E. Bach (1714 - 88): Fantasia C
> > major H.291, bars 71 - 72.)
> 
> 
> Partial only inserts an upbeat when used at the beginning of a score. To
> quote the NR: "When \partial is used after the beginning of a score,
> duration is the remaining length of the current measure. It does not
> create a new numbered bar."
> 
> You should imitate the examples in the NR: put \partial 2 at the
> beginning of the shortened measure. Something like this (based on the
> image you attached):
> 
> \relative {
> \time 3/4
> g'8( fis e' d c b)
> \partial 2
> a4( gis)
> \bar "||"
> \tempo "Presto di molto"
> \time 2/4
> R2
> }
> 
> Kevin

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

Hi Kevin,

Thank you for your input.

> If you use \partial at the beginning of a score it treats the resulting
> duration as the length of music preceding the first bar. This is how bar
> numbering generally works for upbeats/anacrusis.

Obviously confirmed.

> Partial expects to be given a duration. I think it will not work as you
> expect if you multiply the duration by 0 (which is probably a kind of
> intpu that was not anticipated). At the point when you used it it's
> already effectively "between" bars and if you supply a duration it will
> apply to the next bar, not the previous bar.

I admit that I wondered more than a bit about the requirement in the Notation 
Reference to insert a \partial "when the time signature changes in mid 
measure". Composers do not always want an upbeat/fractional pick-up there. 
Maybe supplying a zero duration is a hack; but what is the alternative? At 
least NR doesn’t give one.

> All of the examples of \partial in the documentation use it at the
> beginning of a bar and supply the duration. If you do the same it should
> work for you.

I didn’t see any examples of a zero partial in the docs either. I have trouble 
making good sense of your last statement, though, sorry. What are you 
suggesting to do when the composer did not intend nor supply an upbeat? (My 
example is from C.Ph.E. Bach (1714 - 88): Fantasia C major H.291, bars 71 - 72.)

FWIW if I leave out "\partial 8*0" (in direct conflict with NR), the typeset 
music is identical. It still prints the rest wrong. Only I now also get the 
expected warning from Lilypond: "mid-measure time signature without \partial".

Best regards,
Ole

Attachment: How my example time signature change looks in the Carl Krebs 
edition (1895), from 
https://imslp.org/wiki/2_Sonaten%2C_2_Fantasien_und_2_Rondos_f%C3%BCr_Kenner_und_Liebhaber%2C_Wq.61_(Bach%2C_Carl_Philipp_Emanuel).___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

Hi Paul,
that’s an interesting suggestion. The following can be considered working:

\time 3/4
\partial 4*2 % defines an upbeat holding two crotchets
f'4 f' |
\time 2/4
\set Score.currentBarNumber = #2
R2 |
R2 |

The incomplete 3/4 measure still has not got bar number 1. For most purposes we 
can probably live with that. Setting the current bar number explicitly to 1 did 
not help (apparently upbeats don’t have bar numbers). But setting it to 2 for 
the following bar fixes it for the remainder of the score.

I consider it a workaround not to say a hack. I still firmly believe that the 
bug I was reporting is real.

Thanks for the workaround, though. It helps. As I said, I had not found any 
myself. Have a nice weekend.

Best,
Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Friday, October 28th, 2022 at 14:22, Paul Hodges  wrote:

> Is this not you want:
>
> \version "2.22.2"
>
> {
> \time 3/4
> \partial 4*2 % defines bar as holding two crotchets
> f'4 f' |
> \time 2/4
> R2 |
> R2 |
> }
>
> Paul
>
> From:  Ole V. Villumsen via bug-lilypond 
> To:  "bug-lilypond@gnu.org" 
> Sent:  28/10/2022 10:52
> Subject:  Full bar rest printed incorrectly after time signature change
>
>> I have found no really acceptable workaround for this bug. Please see the 
>> attachments.
>> Thx
>> Ole
>>
>> --
>> Ole V. Villumsen
>> Jelshøjvænget 13
>> DK - 8270 Højbjerg
>> Denmark
>> +45 - 86 27 29 26
>> Text +45 - 30 22 29 26
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

Sorry, a new full 2/4 measure. Hope it wasn’t too confusing.

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Friday, October 28th, 2022 at 12:44, Ole V. Villumsen 
 wrote:

> Thanks, Paul, for your reply.
> You are correct, of course: I tried to say from the outset that I knew I was 
> changing the time signature in the middle of the measure (after 2 out of 3 
> crotchets).
>
> From 
> https://lilypond.org/doc/v2.22/Documentation/notation/displaying-rhythms#upbeats:
>
>> The \partial command is required when the time signature changes in mid 
>> measure, but it may also be used alone.
>
> and
>
>> The \partial command sets the Timing.measurePosition property, which is a 
>> rational number that indicates how much of the measure has passed.
>
> The answer to your question is: So since I explicitly state that the upbeat 
> is zero (\partial 8*0), I expect a new full 2/2 measure to begin right there. 
> When I put anything else in the new bar, it also works the way I expect. I 
> tried r2, and I tried f'4 f'.
>
> Best regards, Ole
>
> Sent with [Proton Mail](https://proton.me/) secure email.
>
> --- Original Message ---
> On Friday, October 28th, 2022 at 12:16, Paul Hodges  wrote:
>
>> There are only two crotchets between your 3/4 signature and your 2/4 
>> signature - what do you expect to happen?
>>
>> Paul
>>
>> From:  Ole V. Villumsen via bug-lilypond 
>> To:  "bug-lilypond@gnu.org" 
>> Sent:  28/10/2022 10:52
>> Subject:  Full bar rest printed incorrectly after time signature change
>>
>>> I have found no really acceptable workaround for this bug. Please see the 
>>> attachments.
>>> Thx
>>> Ole
>>>
>>> --
>>> Ole V. Villumsen
>>> Jelshøjvænget 13
>>> DK - 8270 Højbjerg
>>> Denmark
>>> +45 - 86 27 29 26
>>> Text +45 - 30 22 29 26
>>>
>>> Sent with [Proton Mail](https://proton.me/) secure email.
>>>
>>> ___
>>> bug-lilypond mailing list
>>> bug-lilypond@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

Thanks, Paul, for your reply.
You are correct, of course: I tried to say from the outset that I knew I was 
changing the time signature in the middle of the measure (after 2 out of 3 
crotchets).

From 
https://lilypond.org/doc/v2.22/Documentation/notation/displaying-rhythms#upbeats:

> The \partial command is required when the time signature changes in mid 
> measure, but it may also be used alone.

and

> The \partial command sets the Timing.measurePosition property, which is a 
> rational number that indicates how much of the measure has passed.

The answer to your question is: So since I explicitly state that the upbeat is 
zero (\partial 8*0), I expect a new full 2/2 measure to begin right there. When 
I put anything else in the new bar, it also works the way I expect. I tried r2, 
and I tried f'4 f'.

Best regards, Ole

Sent with [Proton Mail](https://proton.me/) secure email.

--- Original Message ---
On Friday, October 28th, 2022 at 12:16, Paul Hodges  wrote:

> There are only two crotchets between your 3/4 signature and your 2/4 
> signature - what do you expect to happen?
>
> Paul
>
> From:  Ole V. Villumsen via bug-lilypond 
> To:  "bug-lilypond@gnu.org" 
> Sent:  28/10/2022 10:52
> Subject:  Full bar rest printed incorrectly after time signature change
>
>> I have found no really acceptable workaround for this bug. Please see the 
>> attachments.
>> Thx
>> Ole
>>
>> --
>> Ole V. Villumsen
>> Jelshøjvænget 13
>> DK - 8270 Højbjerg
>> Denmark
>> +45 - 86 27 29 26
>> Text +45 - 30 22 29 26
>>
>> Sent with [Proton Mail](https://proton.me/) secure email.
>>
>> ___
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Full bar rest printed incorrectly after time signature change

[Ole V. Villumsen via bug-lilypond]

I have found no really acceptable workaround for this bug. Please see the 
attachments.
Thx
Ole

--
Ole V. Villumsen
Jelshøjvænget 13
DK - 8270 Højbjerg
Denmark
+45 - 86 27 29 26
Text +45 - 30 22 29 26

Sent with [Proton Mail](https://proton.me/) secure email.% In the output from this file, the first full bar rest (R2) is printed
% incorrectly as a 2 bars rest between the previous and the current bar.
% The rest comes immediately after a mid-measure time signature change
% with zero upbeat.
% The second full bar rest is printed correctly.
% The first one should be printed in the same way.

\version "2.22.2"

{
  \time 3/4
  f'4 f'
  \time 2/4
  \partial 8*0 % Required, NR 1.2.3
  R2 | % Prints incorrectly
  R2 | % Prints correctly
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Glitch in the documentation?

[Andrew Bernard via bug-lilypond]

Not that it is any help, but I recall reporting the same thing about 
Catalan some years ago.


Andrew


___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond