Re: Snippet 960 fails with Ly 2.25

[Thomas Morley]

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

Fixed in LSR.
Works now for 2.24 and 2.25

Cheers,
  Harm

Re: Dashed bar lines fail requirements at some sizes

[Thomas Morley]

Hi,

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

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

Dashed bar lines do not stick out

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

Closes #

Embarrassingly...

I'll take a closer look soon.

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

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

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

Cheers,
  Harm

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

[Thomas Morley]

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

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

Cheers,
  Harm

Re: 2.25.1 bug

[Thomas Morley]

Am Di., 14. Feb. 2023 um 22:06 Uhr schrieb Jean Abou Samra :
>
> Le mardi 14 février 2023 à 19:55 +0100, Craig Fearing a écrit :
> > The attached file is a minimized version of an official snippet.
> >
> > If run as version 2.25.*0* it compiles perfectly.
> >
> > If run as version 2.25.*1* it fails.
>
> The snippet comes from LSR and is not tagged as a doc snippet,
> therefore it's not an official snippet. LSR is kept at 2.24,
> it will be updated to 2.26 when that's released.

Jean beats me :)

Anyway, I applied a fix. Now working for all mentioned versions.
https://lsr.di.unimi.it/LSR/Snippet?id=969

Cheers,
  Harm

Re: Error in Extending Lilypond example

[Thomas Morley]

Am Mi., 1. Feb. 2023 um 04:16 Uhr schrieb Saul Tobin
:
>
> The fourth example engraver here:
> https://extending-lilypond.readthedocs.io/en/latest/extending/translation.html#fourth-engraver-example
>
> Running this code in 2.24 crashes on initializing the engraver with In
> procedure ly:spanner-set-bound!: Wrong type argument in position 3
> (expecting Item): ().

Fwiw, looks like (ly:context-property ctx 'currentCommandColumn) is
not longer available in the initialize-step of an engraver.
Not the time to bisect when and why this happened,
Here a stripped down code-example:

\version "2.24.0"

\new Voice
  \with {
\consists
#(lambda (ctx)
  (make-engraver
((initialize this-engraver)
  (newline)(display (ly:context-property ctx 'currentCommandColumn)
  }
  { b1 }

Cheers,
  Harm

Re: Custom percussion style is ignored for the first note when it is a grace note

[Thomas Morley]

Am Mi., 25. Jan. 2023 um 17:54 Uhr schrieb David Kastrup :
>
> Stu McKenzie  writes:
>
> > There seems to have been various reports of bugs when the first note
> > is a grace note, but this bug has been in many LilyPond versions to
> > date.
> >
> > When the first note of a drum score has a grace note, LilyPond outputs
> > the default note, rather than the custom percussion style.
> >
> > In this case, \acciaccatura is used to create each grace note - main
> > note combination.
> >
> > Here's a "Tiny example":
> >
> > \version "2.24.0"
> > #(define mydrums '( (hightom default #f 3)))
> > \score {
> >   \new DrumStaff <<
> > \set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
> > \new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura
> > tomh8 tomh4 \acciaccatura tomh8 tomh4 } }
> >   >>
> > }
>
> This is not a bug.  You specify you _want_ simultaneous music by using
> << ... >> and the settings of DrumStaff.drumStyleTable are performed
> _on_ the beat while the grace notes are performed _before_ the beat.
>
> This is _exactly_ as you tell LilyPond you want things to happen.  If
> you want to have things to happen in sequence, you have to write them in
> sequence.
>
> Using { ... } instead of << ... >> here probably gives something closer
> to your expectations.
>
> Now for things that _pervade_ a context rather than switch around, it
> makes sense not to set them at the first time step but generally, by
> using a \with block:
>
> \version "2.24.0"
> #(define mydrums '( (hightom default #f 3)))
> \score {
>   \new DrumStaff \with { drumStyleTable = #(alist->hash-table mydrums) }
>   {
> \new DrumVoice { \voiceTwo \drummode { \partial 2 \acciaccatura tomh8 
> tomh4 \acciaccatura tomh8 tomh4 } }
>   }
> }
>
> --
> David Kastrup
>

It's unfortunate that we provide an example like:

\new DrumStaff <<
  \set DrumStaff.drumStyleTable = #(alist->hash-table mydrums)
  \new DrumVoice { \voiceOne \up }
  \new DrumVoice { \voiceTwo \down }
>>

as first code example in NR 2.5 Percussion Custom percussion staves.

I've put up https://gitlab.com/lilypond/lilypond/-/merge_requests/1822
to fix the docs

Cheers,
  Harm

programming error in doc-snippet

[Thomas Morley]

Hi,

with 2.25.0
/Documentation/snippets/new/ancient-notation-templatemodern-transcription-of-gregorian-music.ly
emits:
programming error: no stem for note column

Cheers,
  Harm

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

Crash with clip-systems.ly from /Documentation/snippets

[Thomas Morley]

Hi,

in /Documentation/snippets we have clip-systems.ly (attached).
In 2.24.0 it always crashes for me with
fatal error: cannot find file: `clip-systems-1-from-2.0.1-to-4.0.1-clip.eps'

Afaict, the emitted .eps-files are always converted to .pdf.
Thus trying to call such an eps via \epsfile crashes.

Furthermore the NR 3.5.1 "Extracting fragments of music" reads
"By default, each music fragment will be output as a separate EPS
file, but other formats such as PDF or PNG can also be created if
required."
This is obviously not correct, currently.

Otoh,we print the result of said snippet in the Snippets-manual. No
clue how we avoid the crash, alas the image is wrong.
Compare https://lsr.di.unimi.it/LSR/Item?id=602 (running 2.22.2) with
http://lilypond.org/doc/v2.24/Documentation/snippets/paper-and-layout#paper-and-layout-clip-systems

Cheers,
  Harm
%% DO NOT EDIT this file manually; it was automatically
%% generated from the LilyPond Snippet Repository
%% (http://lsr.di.unimi.it).
%%
%% Make any changes in the LSR itself, or in
%% `Documentation/snippets/new/`, then run
%% `scripts/auxiliar/makelsr.pl`.
%%
%% This file is in the public domain.

\version "2.23.13"

\header {
  lsrtags = "paper-and-layout"

  texidoc = "
This code shows how to clip (extract) snippets from a full score.

This file needs to be run separately with @code{-dclip-systems}; the
snippets page may not adequately show the results. The result will be
files named
@samp{@emph{base}-from-@emph{start}-to-@emph{end}[-@emph{count}].eps}.

If system starts and ends are included, they include extents of the
System grob, e.g., instrument names.

Grace notes at the end point of the region are not included.

Regions can span multiple systems.  In this case, multiple EPS files
are generated.
"

  doctitle = "Clip systems"
} % begin verbatim


#(ly:set-option 'clip-systems)
#(define output-suffix "1")

origScore = \score {
  \relative c' {
\new Staff \with { instrumentName = "Instrument" }
c1
d1
\grace c16 e1
\key d \major
f1 \break
\clef bass
g,1
fis1
  }
}

\book {
  \score {
\origScore
\layout {
  % Each clip-region is a (START . END) pair
  % where both are rhythmic-locations.

  % (make-rhythmic-locations BAR-NUMBER NUM DEN)
  % means NUM/DEN whole-notes into bar numbered BAR-NUMBER

  clip-regions = #(list
  (cons
   (make-rhythmic-location 2 0 1)
   (make-rhythmic-location 4 0 1))

  (cons
   (make-rhythmic-location 0 0 1)
   (make-rhythmic-location 4 0 1))

  (cons
   (make-rhythmic-location 0 0 1)
   (make-rhythmic-location 6 0 1))
  )
}
  }
}

%#(ly:set-option 'clip-systems #f)
#(define output-suffix #f)

\book {
  \score { \origScore }
  \markup { \bold \fontsize #6 clips }
  \score {
\lyrics {
  \markup { from-2.0.1-to-4.0.1-clip.eps }
  \markup {
\epsfile #X #30.0 #(format #f "~a-1-from-2.0.1-to-4.0.1-clip.eps"
(ly:parser-output-name)) }
}
  }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Misplaced dashed barlines in vertically compressed score

[Thomas Morley]

Am Di., 14. Juni 2022 um 01:25 Uhr schrieb Thomas Morley
:
>
> Am Mo., 13. Juni 2022 um 19:39 Uhr schrieb William Rehwinkel via
> bug-lilypond :
> >
> > Dear Lilypond,
> >
> > After not being able to find any bugs discussing this in the tracker, I
> > would like to share the following miniature example which I believe
> > shows that dashed bar-lines are misplaced in vertically compressed
> > scores (using default lilypond spacing settings). After testing in
> > 2.22.2 and 2.23.9, the same behavior persists. The dashed lines should
> > have rendered in the same way as the double bar and dotted bar did, but
> > it does not connect between the two Piano Staves and extends above the
> > top staff. Note that if the spacing of systems is manually expanded, via
> > "\paper{ systems-per-page = 4 }", for example, the dashed bar-lines are
> > rendered properly.
> >
> > Thank you,
> >
> > -William
> >
> > ---
> >
> > \version "2.23.9" % "2.22.2"
> > \score {
> >  <<
> >  \new PianoStaff <<
> >  \new Staff \repeat unfold 32 { 8 8 8 8 \bar "!" 8 8 8 8
> > \bar "||" 8 8 8 8 \bar ";" 8 8 8 8 }
> >  \new Staff \repeat unfold 32 { 8 8 8 8 8 8 8 8 8 8 8 8 8 8
> > 8 8 }
> >  >>
> >  \new Staff \repeat unfold 32 { 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 }
> >  >>
> > }
>
> Confirmed.
>
> Here a more tiny example:
>
> mus = {
>   \override Staff.BarLine.bar-extent =
> #(lambda (grob) (interval-widen (ly:bar-line::calc-bar-extent grob) 0.5))
>
>   f'4 \bar "!" f''4
> }
>
> \new PianoStaff
>   <<
>   \new Staff \mus
>   \new Staff \mus
>   >>
>
> Actually a dashed bar line uses dashed-line _or_ a line constructed
> from filled boxes, depending on certain conditions.
> Iirc, this is due to wished different behaviour if BarLine.color is
> different from StaffSymbol.color. I may be wrong here though...
>
> If a _SpanBar_ is dashed with filled boxes the result needs to be
> moved between the staves.Though, this is a very rare case and not
> covered by any regtest afaict, thus it was undetected so far.
>
> Many thanks for your report.
> On it ...
>
> Cheers,
>   Harm

https://gitlab.com/lilypond/lilypond/-/merge_requests/1408
is a basic fix.
Probably it should be amended by a regtest triggering the problem ...

Cheers,
  Harm

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

Re: \incipit sometimes returns programming error

[Thomas Morley]

Am Do., 26. Mai 2022 um 17:36 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 26/05/2022 à 17:12, Thomas Morley a écrit :
> > Hi,
> >
> > consider:
> >
> > \score {
> >\new Staff \with { instrumentName = "" }  { \incipit { c'1. } R1 }
> >\layout {
> >  indent = 5\cm
> >  incipit-width = 3\cm
> >}
> > }
> >
> > with recent versions it returns:
> > programming error: Loose column does not have right side to attach to.
> >
> > First bad comit is:
> > commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
> > Author: Dan Eble 
> > Date:   Thu Mar 10 20:08:31 2022 -0500
> >
> >  Refactor BarLine engraving
> >  [...]
> >
> > Dan?
> >
> >
> > The example above can be fixed by inserting an explicit \bar "" at end
> > of incipit-music.
> >
> >
> > Cheers,
> >Harm
>
>
> That looks like an old bug uncovered to me. \incipit
> uses a MensuralStaff, and indeed I can reproduce it
> with
>
> \version "2.23.10"
>
> \new MensuralStaff {
>c'1.
> }
>
>
> The definition of MensuralStaff contains measureBarType = "",
> and this also triggers the bug:
>
> \version "2.23.10"
>
> \new Staff \with {
>measureBarType = ""
> } {
>c'1.
> }
>
> which is an instance of our old
>
> https://gitlab.com/lilypond/lilypond/-/issues/4084
>
> I can't tell why the commit "Refactor BarLine engraving" had that
> effect (and I'm not investigating). Dan, any thoughts? Should
> MensuralStaff simply be changed to have measureBarType = ##f
> (instead of "")?
>
> Jean
>
>
>
Currently I'm testing LSR-upgrade to current master, anticipating the
next stable. In the past doing so served me well as soon as the next
stable is actually out and updating LSR is really a TODO-NOW.
I stumbled upon a handful snippets (I may post about them, if I don't
find my way), one of them is incipit.ly,
https://lsr.di.unimi.it/LSR/Item?id=582
It works fine with 2.22. and before, I wonder why #4084 raises its
head now and not before.

Wouldn't it be a possibility to just change  our `incipit':
$ git diff
diff --git a/ly/property-init.ly b/ly/property-init.ly
index f8e6ee37be..c0605757be 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -323,6 +323,7 @@ incipit =
 \override InstrumentName.self-alignment-X = #align-x
 \override InstrumentName.self-alignment-Y = #align-y
 instrumentName = #instrument-name
+measureBarType = ##f
   }
   {
 $incipit-music

At least it fixes the here reported bug.

Thanks,
  Harm

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

\incipit sometimes returns programming error

[Thomas Morley]

Hi,

consider:

\score {
  \new Staff \with { instrumentName = "" }  { \incipit { c'1. } R1 }
  \layout {
indent = 5\cm
incipit-width = 3\cm
  }
}

with recent versions it returns:
programming error: Loose column does not have right side to attach to.

First bad comit is:
commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
Author: Dan Eble 
Date:   Thu Mar 10 20:08:31 2022 -0500

Refactor BarLine engraving
[...]

Dan?


The example above can be fixed by inserting an explicit \bar "" at end
of incipit-music.


Cheers,
  Harm

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

Re: Snippet in NR needs modification

[Thomas Morley]

Am Sa., 30. Apr. 2022 um 19:41 Uhr schrieb Dan Eble :
>
> On Apr 30, 2022, at 13:34, Thomas Morley  wrote:
> >
> > I'd offer to change it in LSR to use
> > \repeat volta 2 ...
> > Would be available after next LSR-import.
>
> That makes sense.  Thanks.
> —
> Dan
>

Fixed in LSR

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

Snippet in NR needs modification

[Thomas Morley]

Hi,

in NR 1.2.5 Bars
Automatic bar lines
Documentation/snippets/setting-the-double-repeat-default-for-volte.ly
is used, a doc tagged LSR snippet.
http://lilypond.org/doc/v2.23/Documentation/notation/bars#automatic-bar-lines

Alas, due to recent changes about
\repeat volta 1 ...
it does not print what was expected any more.

I'd offer to change it in LSR to use
\repeat volta 2 ...
Would be available after next LSR-import.

Ok? Dan?

Cheers,
  Harm

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

IR badly formated in html

[Thomas Morley]

Hi,

in IR 4. Scheme functions
entries containing "::" are formated badly: up to "::" it's printed
bold, after it italic is used,

in IR A.2 Function index
all after "::" is omitted.

This holds for html, pdf looks ok.

Cheers,
  Harm

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

Re: convert-ly shows wrong version

[Thomas Morley]

Am Do., 7. Apr. 2022 um 10:41 Uhr schrieb Jean Abou Samra :

> Doesn't reproduce for me.
>
> $ build/out/bin/convert-ly --version
> 2.23.8
> $ ~/lilypond2.23.7/bin/convert-ly --version
> 2.23.7
>
> Are you very sure that the convert-ly you're invoking is from 2.23.7 or 
> master?

You're right, I called the wrong convert-ly. The correct one is fine.

Sorry for the noise,
  Harm

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

convert-ly shows wrong version

[Thomas Morley]

Hi,

invoking convert-ly from released 2.23.7 or current master shows a
wrong version:

$ convert-ly --version
2.22.1

Similar for $ convert-ly -h

Cheers,
  Harm

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

Re: Re: Language "deutsch" should still give default chord names

[Thomas Morley]

Am Sa., 12. März 2022 um 17:47 Uhr schrieb Ole V. Villumsen
:
>
> Thanks for looking into this.
>
> I can live with this being turned into the sum of:
>  1. A bug report for German chord names. The German names for h, his and b 
> chords would be H, H# and B, but I showed that in the last case Hb was 
> printed instead, which I believe that no German will recognize as the 
> expected chord name.
>  2. A documentation issue. As you said, it is not currently in the notation 
> reference that Lilypond tries to print chord names in the input language.
>  3. A feature request. The feature request may be to add a \defaultChords or 
> \englishChords command that would give me what I had expected.
>
> I am not sure that we want the implicit coupling between input note name 
> language and output chord name language, though. Also we seem to have 12 
> input languages and 5 chord name languages, so what should be the expected 
> output in the remaining 7 cases? I am afraid that even with proper 
> documentation this could turn confusing. I will let others decide about that.
>
> Best regards,
> Ole

Hi Ole,

this is now
https://gitlab.com/lilypond/lilypond/-/issues/6305

Best,
  Harm

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

Re: Language "deutsch" should still give default chord names

[Thomas Morley]

Am Sa., 12. März 2022 um 17:10 Uhr schrieb Thomas Morley
:
>
> Am Sa., 12. März 2022 um 09:58 Uhr schrieb Ole V. Villumsen via
> bug-lilypond :
> >
> > % When input language is "deutsch" (German),
> > % Lilypond does not seem to print the default chord names
> > % given in the notation reference
> > % 
> > https://lilypond.org/doc/v2.22/Documentation/notation/displaying-chords#customizing-chord-names
> > % The only workaround I have found was to use a different input language.
> >
> > \version "2.22.2"
> > \language "deutsch"
> >
> > <<
> > \new ChordNames {
> > % Expecting default chord names: B B# Bb
> > % Instead getting: H H# Hb
> > \chordmode {
> > h1 his b
> > }
> > }
> > >>
> >
> > [billede.png]
> >
> > --
> > Ole V. Villumsen
> > Jelshøjvænget 13
> > 8270 Højbjerg
> > 86 27 29 26
> > SMS 30 22 29 26
> >
> > Sendt med [ProtonMail](https://protonmail.com/) sikker e-mail.
> > ___
> > bug-lilypond mailing list
> > bug-lilypond@gnu.org
> > https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> Hi Ole,
>
> thanks for the report. Here my current understanding.
>
> The behaviour is expected.
> Granted, we have the possibility to transform input in the
> default-language into german/italian/french chordnames. Via
> \germanChords etc.
> But not from a different input-language into english chordnames.
> So this may turn this bugreport into a feature request?
>
> If \language is specified LilyPond tries to print chordnames in that language.
> This is not documented, afaict.
> So this may be an doc-issue?
>

I withdraw below, it doesn't work as I thought...

> > % The only workaround I have found was to use a different input language.
>
> Do you mean something like below?
>
> \language "deutsch"
>
> <<
>   \new ChordNames {
> \languageSaveAndChange #default-language
> \chordmode {
>   b bis bes
> }
> \languageRestore
>   }
>   \new Staff {
>   h his b
>   }
> >>
>
> Then I'd vote for better documentation of languageSaveAndChange and
> languageRestore, currently there's none.
>
> Cheers,
>   Harm

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

Re: Language "deutsch" should still give default chord names

[Thomas Morley]

Am Sa., 12. März 2022 um 09:58 Uhr schrieb Ole V. Villumsen via
bug-lilypond :
>
> % When input language is "deutsch" (German),
> % Lilypond does not seem to print the default chord names
> % given in the notation reference
> % 
> https://lilypond.org/doc/v2.22/Documentation/notation/displaying-chords#customizing-chord-names
> % The only workaround I have found was to use a different input language.
>
> \version "2.22.2"
> \language "deutsch"
>
> <<
> \new ChordNames {
> % Expecting default chord names: B B# Bb
> % Instead getting: H H# Hb
> \chordmode {
> h1 his b
> }
> }
> >>
>
> [billede.png]
>
> --
> Ole V. Villumsen
> Jelshøjvænget 13
> 8270 Højbjerg
> 86 27 29 26
> SMS 30 22 29 26
>
> Sendt med [ProtonMail](https://protonmail.com/) sikker e-mail.
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Ole,

thanks for the report. Here my current understanding.

The behaviour is expected.
Granted, we have the possibility to transform input in the
default-language into german/italian/french chordnames. Via
\germanChords etc.
But not from a different input-language into english chordnames.
So this may turn this bugreport into a feature request?

If \language is specified LilyPond tries to print chordnames in that language.
This is not documented, afaict.
So this may be an doc-issue?

> % The only workaround I have found was to use a different input language.

Do you mean something like below?

\language "deutsch"

<<
  \new ChordNames {
\languageSaveAndChange #default-language
\chordmode {
  b bis bes
}
\languageRestore
  }
  \new Staff {
  h his b
  }
>>

Then I'd vote for better documentation of languageSaveAndChange and
languageRestore, currently there's none.

Cheers,
  Harm

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

Re: triplet bracket restricted by event which does not restrict the notes under it

[Thomas Morley]

Am Di., 1. März 2022 um 11:58 Uhr schrieb Thomas Morley
:
>
> Am Mo., 28. Feb. 2022 um 21:30 Uhr schrieb Paul Hodges :
> >
> > I've had this several times in my present project, each time with a clef in 
> > the other Piano Staff - the triplet bracket, but not the triplet notes, is 
> > forced not to share horizontal space with the clef.  I can't see anything 
> > I'm doing wrong which might prevent this being a bug.
> >
> >
> > I've managed for now with a hacky workaround (I reduce the length of the 
> > item before the clef and put a tiny spacer rest after it), but obviously 
> > I'd rather not do that in general.
> >
> >
> > Paul___
> > bug-lilypond mailing list
> > bug-lilypond@gnu.org
> > https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> Hi Paul,
>
> this is
> https://gitlab.com/lilypond/lilypond/-/issues/610
> Does adding
> \set tupletFullLengthNote = ##t
> help?
> If not, you may need to lengthen the TupletBracket manually, via shorten-pair.
>
> Cheers,
>   Harm

tupletFullLengthNote is not documented apart from:
http://lilypond.org/doc/v2.23/Documentation/snippets/rhythms#rhythms-modifying-tuplet-bracket-length
I'd vote for an entry in NR.

Cheers,
  Harm

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

Re: triplet bracket restricted by event which does not restrict the notes under it

[Thomas Morley]

Am Mo., 28. Feb. 2022 um 21:30 Uhr schrieb Paul Hodges :
>
> I've had this several times in my present project, each time with a clef in 
> the other Piano Staff - the triplet bracket, but not the triplet notes, is 
> forced not to share horizontal space with the clef.  I can't see anything I'm 
> doing wrong which might prevent this being a bug.
>
>
> I've managed for now with a hacky workaround (I reduce the length of the item 
> before the clef and put a tiny spacer rest after it), but obviously I'd 
> rather not do that in general.
>
>
> Paul___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Paul,

this is
https://gitlab.com/lilypond/lilypond/-/issues/610
Does adding
\set tupletFullLengthNote = ##t
help?
If not, you may need to lengthen the TupletBracket manually, via shorten-pair.

Cheers,
  Harm

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

Re: Accordion notation

[Thomas Morley]

Am Mo., 25. Okt. 2021 um 00:20 Uhr schrieb Timothy Lanfear :
>
> I noticed part of the source code for the accordion example is missing,
> hiding the information that the use-modules statement has been changed
> from #(use-modules (scm accreg)) to #(use-modules (lily accreg)).
>
> http://lilypond.org/doc/v2.23/Documentation/notation/accordion
>
> --
> Timothy Lanfear, Bristol, UK.

Confirmed.

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

Re: Changing time signature in percent repeats

[Thomas Morley]

Am Sa., 24. Apr. 2021 um 16:54 Uhr schrieb Vaylor Trucks :
>
> % If you combine the 3/8 bar and 2/4 bar into a single 7/8 bar it works
> % but like this you get warning: mid-measure time signature without \partial
>
> \version "2.22.0"
> \score { << \new DrumStaff << \drummode {
>   \repeat percent 2 {
> \time 3/8 sn8 sn sn
> \time 2/4 sn8 sn sn sn  }
>   \time 4/4 sn8 sn sn sn sn sn sn sn
> } >> >> }
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi,

this is a known issue and covered in "Known issues and warnings" of
http://lilypond.org/doc/v2.22/Documentation/notation/short-repeats#percent-repeats

Until the underlying issue is fixed, there's nothing to do.

Cheers,
  Harm

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

Weird behaviour with after-line-breaking and minimum-length-after-break

[Thomas Morley]

Hi,

consider the following code:

\version "2.23.1"

\paper { ragged-right = ##t }

{
  \override TrillSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
  \override TrillSpanner.minimum-length-after-break = 60
  \override TrillSpanner.minimum-length = 60
  \override TrillSpanner.after-line-breaking = ##t

  b1\startTrillSpan \break b\stopTrillSpan
}

I see two bugs here:
(1)
Setting after-line-breaking = ##t should enable printing the
TrillSpanner on second line.
It does not - for every tested version, starting with 2.12.3.

(2) minimum-length-after-break takes affect on second line although
TrillSpanner is not continued there.
If minimum-length-after-break is unset, minimum-length is applied to
the not printed part of the broken TrillSpanner.
This happens even if after-line-breaking = ##f

We currently have seven grobs with after-line-breaking set to
ly:spanner::kill-zero-spanned-time:
DurationLine, Glissando, Hairpin, LyricHyphen, TrillSpanner,
VoiceFollower and VowelTransition

TrillSpanner is the only one with bug (1)
All of them suffer from bug (2)

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

Re: Segmentation fault in check_meshing_chords()

[Thomas Morley]

Am Do., 25. Feb. 2021 um 04:32 Uhr schrieb :
>
> % The following source causes a segmentation fault
>
> % in versions 2.20.0 and a local build from the latest master (2.23.1)
>
> \version "2.20.0"
> \language "english"
>
> << { a2  b2 } \\ { \tweak X-offset #2 f'1 ~ f'1 } >>
>
> %%
>
> Call stack from 2.23.1 is
>
> (gdb) where
> #0  0x55b7a97836bb in check_meshing_chords(Grob*, Grob*, Grob*) 
> (me=0x55b7aa7f80c0, clash_up=, clash_down=)
>  at /usr/include/c++/10/bits/stl_vector.h:1043
> #1  0x55b7a978573e in check_meshing_chords(Grob*, Grob*, Grob*) 
> (clash_down=0x55b7aa7f74c0, clash_up=0x55b7aa7f6dc0, me=0x55b7aa7f80c0)
>  at /home/john/src/gitlab/lilypond/lily/note-collision.cc:47
> #2  Note_collision_interface::automatic_shift(Grob*, 
> Drul_array > >)
>  (me=me@entry=0x55b7aa7f80c0, clash_groups=...) at 
> /home/john/src/gitlab/lilypond/lily/note-collision.cc:489
> #3  0x55b7a9786357 in 
> Note_collision_interface::calc_positioning_done(scm_unused_struct*) 
> (smob=)
>  at 
> /home/john/src/gitlab/lilypond/build/../flower/include/drul-array.hh:30
> #4  0x7f75f24f306d in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #5  0x7f75f24f8d5d in scm_call_n () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #6  0x7f75f2475d0c in scm_call_1 () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #7  0x55b7a9718435 in Grob::try_callback_on_alist(scm_unused_struct**, 
> scm_unused_struct*, scm_unused_struct*)
>  (this=this@entry=0x55b7aa7f80c0, alist=alist@entry=0x55b7aa7f8148, 
> sym=0x7f75ee741b00, proc=0x7f75ee650840)
>  at /home/john/src/gitlab/lilypond/lily/include/smobs.hh:321
> #8  0x55b7a971871f in Grob::internal_get_property(scm_unused_struct*) 
> const (this=this@entry=0x55b7aa7f80c0, sym=)
>  at /home/john/src/gitlab/lilypond/lily/grob-property.cc:203
> #9  0x55b7a971c33b in Grob::x_parent_positioning(scm_unused_struct*) 
> (smob=) at /home/john/src/gitlab/lilypond/lily/grob.cc:865
> #10 0x7f75f24f306d in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #11 0x7f75f24f8d5d in scm_call_n () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #12 0x7f75f2475d0c in scm_call_1 () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #13 0x55b7a9718435 in Grob::try_callback_on_alist(scm_unused_struct**, 
> scm_unused_struct*, scm_unused_struct*)
>  (this=this@entry=0x55b7aa7f6dc0, alist=alist@entry=0x55b7aa7f6e48, 
> sym=sym@entry=0x7f75ee69b7e0, proc=0x7f75ee6930e0)
>  at /home/john/src/gitlab/lilypond/lily/include/smobs.hh:321
> #14 0x55b7a971871f in Grob::internal_get_property(scm_unused_struct*) 
> const (this=this@entry=0x55b7aa7f6dc0, sym=sym@entry=0x7f75ee69b7e0)
>  at /home/john/src/gitlab/lilypond/lily/grob-property.cc:203
> #15 0x55b7a971da5b in Grob::get_offset(Axis) const 
> (this=this@entry=0x55b7aa7f6dc0, a=a@entry=X_AXIS)
>  at /home/john/src/gitlab/lilypond/lily/include/lily-guile-macros.hh:64
> #16 0x55b7a971e2be in Grob::relative_coordinate(Grob const*, Axis) const 
> (a=X_AXIS, refp=0x55b7aa3bc1e0, this=0x55b7aa7f6dc0)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:338
> #17 Grob::relative_coordinate(Grob const*, Axis) const (a=X_AXIS, 
> refp=0x55b7aa3bc1e0, this=0x55b7aa7f6dc0)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:329
> #18 Grob::parent_relative(Grob const*, Axis) const (a=X_AXIS, 
> refp=0x55b7aa3bc1e0, this=0x55b7aa3a3d10)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:345
> #19 Grob::relative_coordinate(Grob const*, Axis) const (a=X_AXIS, 
> refp=0x55b7aa3bc1e0, this=0x55b7aa3a3d10)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:338
> #20 Grob::relative_coordinate(Grob const*, Axis) const (a=X_AXIS, 
> refp=0x55b7aa3bc1e0, this=0x55b7aa3a3d10)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:329
> #21 Grob::extent(Grob const*, Axis) const (this=this@entry=0x55b7aa3a3d10, 
> refp=refp@entry=0x55b7aa3bc1e0, a=a@entry=X_AXIS)
>  at /home/john/src/gitlab/lilypond/lily/grob.cc:455
> #22 0x55b7a9737981 in 
> Ledger_line_spanner::set_spacing_rods(scm_unused_struct*) (smob= out>)
>  at /home/john/src/gitlab/lilypond/lily/ledger-line-spanner.cc:129
> #23 0x7f75f24f306d in  () at /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #24 0x7f75f24f8d5d in scm_call_n () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #25 0x7f75f2475d0c in scm_call_1 () at 
> /usr/lib/x86_64-linux-gnu/libguile-2.2.so.1
> #26 0x55b7a9718435 in Grob::try_callback_on_alist(scm_unused_struct**, 
> scm_unused_struct*, scm_unused_struct*)
>  (this=this@entry=0x55b7aa3a56d0, alist=alist@entry=0x55b7aa3a5758, 
> sym=0x7f75ee6941a0, proc=0x7f75ee67e680)
>  at /home/john/src/gitlab/lilypond/lily/include/smobs.hh:321
> #27 0x55b7a971871f in Grob::internal_get_property(scm_unused_struct*) 
> const (this=this@entry=0x55b7aa3a56d0, sym=)
>  at 

Re: Final volta bracket closed unexpectedly

[Thomas Morley]

Am Mo., 15. Feb. 2021 um 09:35 Uhr schrieb Jonas Hahnfeld via
bug-lilypond :
>
> Am Sonntag, dem 14.02.2021 um 16:27 -0500 schrieb Dan Eble:
> > As I read Behind Bars, p.237, the bracket for volta 2 should not turn down 
> > at the end in this case.  Either way, it's strange that the outcome depends 
> > on line breaking.  If someone is willing to second this, I am willing to 
> > investigate it.
> > —
> > Dan
> >
> > \version "2.20.0"
> >
> > \layout {
> >   ragged-right = ##t
> > }
> >
> > piece = \fixed c' {
> >   \repeat volta 2 R1 \alternative { R1 R1 }
> >   \repeat volta 2 R1
> > }
> >
> > \new Score \new Staff << \piece >>
> > \new Score \new Staff << \piece { s1*3 \break } >>
>
> Yes, looks strange, especially given that the brackets in the following
> two don't turn down:
> \new Score \new Staff << { \repeat volta 2 R1 \alternative { R1 R1 } R1 } >>
> \new Score \new Staff << { \repeat volta 2 R1 \alternative { R1 R1 } \bar 
> "||" R1 } >>
>
> It turns down with \bar ".|" and \bar "|.", but neither with \bar ".",
> \bar "..", nor \bar "|.|" - weird.
>
> I went to check some scores I have, but both instances I found (Phantom
> of the Opera and Themes from 007) coincide with a line break - but at
> least the not-turning-down matches what LilyPond does in that case.
> I've found another one without line breaks in a custom score, but I
> didn't enter it and I'd have to ask the author what program he used.
> Whatever it was, the output looks visually unpleasant (some text sizes
> don't match), so I'm not sure it should be taken as reference...
>
> Jonas
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Currently volta-hooks are allowed only for certain bar-lines.

This is controlled by `allow-volta-hook` from bar-line.scm and
`allowVoltaHook` from property-init.ly, both filling
`volta-bracket-allow-volta-hook-list`.
Defaulting to:
#(pretty-print
  (module-ref (resolve-module '(lily)) 'volta-bracket-allow-volta-hook-list))
->
(":|."
 ".|:"
 "|."
 ":..:"
 ":|.|:"
 ":|.:"
 ".|"
 ":|.S"
 ":|.S-S"
 ":|.S.|:"
 ":|.S.|:-S"
 ":|]"
 ":|][|:")

Here the ".|:"-bar-line is split into "|" at line-end and ".|:" at
line-begin, but the volta-hook is not allowed for "|".

This is the situation, as far as I can tell.
The printed outcome is always the same since 2.12.3, although the
implementation of the whole bar-line-stuff changed somewhere in 2.14.
or 2.16..
I don't remember exactly

No clue how to improve, though.

Cheers,
  Harm

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

Re: Incorrect example in documentation

[Thomas Morley]

Am Sa., 23. Jan. 2021 um 17:44 Uhr schrieb Nate Whetsell
:
>
> Hi there,
>
> Thank you for all your work on LilyPond!
>
> The syntax for \revert-ing certain properties appears to have changed after 
> LilyPond 2.18, which makes the “Altering the length of beamed stems” example 
> in the documentation slightly incorrect. At
>
> http://lilypond.org/doc/v2.18/Documentation/snippets/pitches#pitches-altering-the-length-of-beamed-stems
>  
> 
>
> note that the last six notes have default length. At
>
> http://lilypond.org/doc/v2.22/Documentation/snippets/pitches#pitches-altering-the-length-of-beamed-stems
>  
> 
>
> the stems of the last six notes are still 8.5 staff spaces long. This can be 
> fixed by changing the third-to-last line of the example code to
>
> \revert Stem.details.beamed-lengths
>
> For the sake of completeness, here’s an example that illustrates the issue:
>
> ```
> \version "2.22.0"
> {
>   \override Stem.details.beamed-lengths = #'(10)
>   c'8 8 8 8
>   \revert Stem.details
>   8 8 8 8 % These stems are still too long.
>   \revert Stem.details.beamed-lengths
>   8 8 8 8
> }
> ```
>
> All the best,
> Nate
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Nate,

thanks for the report.

Said snippet is a doc-tagged LSR-snippet.
While the LSR still runs 2.18.2 the proposed fix will work for this
version and upstream.
Thus I fixed it inside LSR.
http://lsr.di.unimi.it/LSR/Item?id=681
With next LSR-import the corrected version will be present in NR.

Regards,
  Harm

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

Wrong/misleading images

[Thomas Morley]

Hi,

at https://lilypond.org/macos-x.html
the images
./Documentation/pictures/Learning_Macos_welcome.png
./Documentation/pictures/Learning_Macos_pdf_output.png
are not longer correct.

The first one is intended to show the code for the scale demonstrated
in the latter.
Alas, the meaning of \relative { ... }, i.e.without reference pitch,
changed somewhere in 2.17.x.
So nowadays, the scale would come out one octave below.
Likely both images should be replaced.

Probably the same for https://lilypond.org/windows.html

Cheers,
  Harm

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

Re: partCombine returns wrongly if \tags are used

[Thomas Morley]

Am Sa., 26. Dez. 2020 um 20:46 Uhr schrieb Dan Eble :
>
> On Dec 26, 2020, at 13:29, Thomas Morley  wrote:
> >
> > Hi,
> >
> > the following code gives bad output.
> >
> > %% Start
> > \version "2.20.0"
> >
> > one = { e''2 \tag #'score f'' \tag #'part fis'' g''1 }
> > two = { e''2 d'' g'1 }
> >
> > \removeWithTag #'score \partCombine \one \two
> > %% end
> >
> > it looks like tags are not
> > respected for the length of `skip`, but both are counted, thus the
> > length is off.
>
> Harm,
>
> I would call this a known issue, and there are other features that similarly 
> interfere with \partCombine.  If it ever seemed to work in the past, it 
> depended on the specifics of the music.
>
> \partCombine is a two-pass feature.  In your example, the first pass does not 
> know that you will be removing tagged music, so the information it records is 
> inconsistent with the music when it comes time for the second pass.  If you 
> want to use \partCombine with filtering, unfolded repeats, or other 
> transformations, you must transform first so that the music is in its final 
> form before the first pass, something like this:
>
> \partCombine { \removeWithTag … \one } { \removeWithTag … \two }
>
> Merry Christmas,
> —
> Dan
>

Hi Dan,

the initial example works at least since 2.8.0 (yes, I've a working 2.8.0)
A long time...
Tbh, I couldn't figure why it works before 2.19.21, though, if it
doesn't anymore, it should be documented either as it is done for
\relative already or in "Known issues and warnings" probably together
with \relative.
See also this post on the user-list:
https://lists.gnu.org/archive/html/lilypond-user/2020-11/msg00243.html

All the best,
  Harm

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

partCombine returns wrongly if \tags are used

[Thomas Morley]

Hi,

the following code gives bad output.

%% Start
\version "2.20.0"

one = { e''2 \tag #'score f'' \tag #'part fis'' g''1 }
two = { e''2 d'' g'1 }

\removeWithTag #'score \partCombine \one \two
%% end

Afaict, first bad commit is

commit 615571eda2393eba537c3ad0eb2d424f8dd218b0
Author: Dan Eble 
Date:   Wed May 27 21:23:45 2015 -0400

Issue 4423: eliminate part combiner's array of context handles (4/4)

The Part_combine_iterator no longer creates or keeps alive the Voice
contexts that it uses.  make-directed-part-combine-music does it.

When the Part_combine_iterator needs to redirect a child iterator, it
finds the new Voice by name among the siblings of the current Voice.

which is 2.19.21

Since then the code changed a lot.
As a guess, in `make-directed-part-combine-music` from
music-functions-init.ly of current master, it looks like tags are not
respected for the length of `skip`, but both are counted, thus the
length is off.

Cheers,
  Harm

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

Re: Bad slur shape at line break with change of clef

[Thomas Morley]

Am So., 13. Dez. 2020 um 16:56 Uhr schrieb James Lowe :
>
> On 13/12/2020 15:29, Jonas Hahnfeld via bug-lilypond wrote:
> > Hi all, Harm,
> >
> > Am Sonntag, dem 13.12.2020 um 13:53 +0100 schrieb Thomas Morley:

> >> Hopefully somebody with more knowledge, chimes in.
> > Could you create a GitLab issue for the bug report and transfer your
> > findings? This will make it easier to find the details in the future.
>
> https://gitlab.com/lilypond/lilypond/-/issues/6071
>
> James

Thanks James for stepping in!

Regards,
  Harm

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

Re: Bad slur shape at line break with change of clef

[Thomas Morley]

Am Sa., 12. Dez. 2020 um 21:07 Uhr schrieb Timothy Lanfear :
>
> The part of the slur before the line break is badly shaped when another
> staff has a clef change.
>
> \version "2.20.0"
>
> <<
>\new Staff {
>  R1*2
>  r2 r4 r8 r16 r32 e''32( |
>  \break
>  d''8) r r4 r2 |
>  R1*3
>}
>
>\new Staff {
>  R1*3
>  \clef "bass"
>  R1*4
>}
>  >>
>
>
> --
> Timothy Lanfear, Bristol, UK.
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

As far as I can tell it was introduced with

commit 16a328617e867892e8d5608f95bd6127196e03a2
Author: Keith OHara 
Date:   Sun Jun 17 21:45:26 2012 -0700

Consistent bounds for slurs; issue 427 and 379

in 2.15.41.

I reverted it maually with below, (my C++-skils are approx. zero, all
done by c/p and comments):

diff --git a/lily/include/slur-scoring.hh b/lily/include/slur-scoring.hh
index bddc6c3ce8..e63b23b71b 100644
--- a/lily/include/slur-scoring.hh
+++ b/lily/include/slur-scoring.hh
@@ -138,7 +138,8 @@ public:
   std::vector get_extra_encompass_infos () const;
   Real move_away_from_staffline (Real y, Grob *on_staff) const;

-  Interval breakable_bound_extent (Direction) const;
+  Grob *breakable_bound_item (Direction) const;
+//  Interval breakable_bound_extent (Direction) const;
 };

 void set_slur_control_points (Grob *me);
diff --git a/lily/slur-scoring.cc b/lily/slur-scoring.cc
index 8f98deedd7..93fc8ec232 100644
--- a/lily/slur-scoring.cc
+++ b/lily/slur-scoring.cc
@@ -451,12 +451,14 @@ Slur_score_state::get_best_curve () const
   return best;
 }

-Interval
-Slur_score_state::breakable_bound_extent (Direction d) const
+Grob *
+Slur_score_state::breakable_bound_item (Direction d) const
+// Interval
+// Slur_score_state::breakable_bound_extent (Direction d) const
 {
   Grob *paper_col = slur_->get_bound (d)->get_column ();
-  Interval ret;
-  ret.set_empty ();
+//  Interval ret;
+//  ret.set_empty ();

   extract_grob_set (slur_, "encompass-objects", extra_encompasses);

@@ -464,10 +466,11 @@ Slur_score_state::breakable_bound_extent
(Direction d) const
 {
   Item *item = dynamic_cast (extra_encompasses[i]);
   if (item && paper_col == item->get_column ())
-ret.unite (robust_relative_extent (item, common_[X_AXIS], X_AXIS));
+return item;
+//ret.unite (robust_relative_extent (item, common_[X_AXIS], X_AXIS));
 }
-
-  return ret;
+  return 0;
+//  return ret;
 }

 /*
@@ -583,12 +586,20 @@ Slur_score_state::get_base_attachments () const
   Real x = 0;
   Real y = 0;

-  Interval ext = breakable_bound_extent (d);
-  if (ext.is_empty ())
-ext = Axis_group_interface::
-  generic_bound_extent (extremes_[d].bound_,
-common_[X_AXIS], X_AXIS);
-  x = ext[-d];
+  if (Grob *g = breakable_bound_item (d))
+{
+  x = robust_relative_extent (g, common_[X_AXIS], X_AXIS)[RIGHT];
+}
+  else if (d == RIGHT)
+x = robust_relative_extent (extremes_[d].bound_,
common_[X_AXIS], X_AXIS)[d];
+  else
+x = slur_->get_broken_left_end_align ();
+//  Interval ext = breakable_bound_extent (d);
+//  if (ext.is_empty ())
+//ext = Axis_group_interface::
+//  generic_bound_extent (extremes_[d].bound_,
+//common_[X_AXIS], X_AXIS);
+//  x = ext[-d];

   Grob *col = (d == LEFT) ? note_columns_[0] : note_columns_.back ();

diff --git a/lily/spanner.cc b/lily/spanner.cc
index 5713c13d3f..bfd5765ef5 100644
--- a/lily/spanner.cc
+++ b/lily/spanner.cc
@@ -324,6 +324,34 @@ Spanner::is_broken () const
   return broken_intos_.size ();
 }

+/*
+  If this is a broken spanner, return the amount the left end is to be
+  shifted horizontally so that the spanner starts after the initial
+  clef and key on the staves. This is necessary for ties, slurs,
+  crescendo and decrescendo signs, for example.
+*/
+Real
+Spanner::get_broken_left_end_align () const
+{
+  Paper_column *sc = dynamic_cast
(spanned_drul_[LEFT]->get_column ());
+
+  // Relevant only if left span point is first column in line
+  if (sc != NULL
+  && sc->break_status_dir () == RIGHT)
+{
+  /*
+We used to do a full search for the Break_align_item.
+But that doesn't make a difference, since the Paper_column
+is likely to contain only a Break_align_item.
+  */
+  return sc->extent (sc, X_AXIS)[RIGHT];
+}
+
+  return 0.0;
+}
+
+
+
 void
 Spanner::derived_mark () const
 {

Then I used the following ly-tests:

 start
<<
   \new Staff {
 R1*2
 r2 r4 r8 r16 r32 e''32( |
 \break
 d''8) r r4 r2 |
 R1*3
   }

   \new Staff {
 R1*3
 \clef "bass"
 R1*4
   }
>>

%% from issue 427

\relative c'' {
  \key c \minor
  

Wrongly read property with MetronomeMark

[Thomas Morley]

Hi,

the following code

{
  \tempo 4 = 60
  \override TupletBracket.after-line-breaking =
#(lambda (grob)
(format #t "\nstyle is: '~a" (ly:grob-property grob 'style)))
  \override TupletBracket.style = #'dashed-line
  \tuplet 3/2 { 2 2 2 }
}

prints in terminal:

style is: 'line

As soon as \tempo is commented 'dashed-line is written.
This happens at least since 2.21.6
2.20.0 is ok

Cheers,
  Harm

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

Re: Update for http://lilypond.org/doc/v2.20/Documentation/snippets/tweaks-and-overrides

[Thomas Morley]

Am Do., 29. Okt. 2020 um 18:18 Uhr schrieb Johannes Feulner
:
>
> I suggest to update code and picture of the snippet  "Adding Links to
> objects".
>
> Changes:
>
> * Update link URLs to a more current version of the documentation
>
> * Fix link for accidental
>
> #(define (add-link url-strg)
>(lambda (grob)
>  (let* ((stil (ly:grob-property grob 'stencil)))
>(if (ly:stencil? stil)
>  (begin
>(let* (
>   (x-ext (ly:stencil-extent stil X))
>   (y-ext (ly:stencil-extent stil Y))
>   (url-expr (list 'url-link url-strg `(quote ,x-ext) `(quote
> ,y-ext)))
>   (new-stil (ly:stencil-add
>   (ly:make-stencil url-expr x-ext y-ext) stil)))
>(ly:grob-set-property! grob 'stencil new-stil)))
>  #f
>
>  test
>
> urlI =
> "http://lilypond.org/doc/v2.20/Documentation/notation/writing-pitches;
>
> urlII =
> "http://lilypond.org/doc/v2.20/Documentation/notation/rhythms;
>
> urlIII =
> "http://lilypond.org/doc/v2.20/Documentation/notation/note-heads;
>
> urlIV =
> "http://lilypond.org/doc/v2.20/Documentation/notation/beams;
>
> urlV =
> "http://lilypond.org/doc/v2.20/Documentation/notation/note-head-styles;
>
> urlVI =
> "http://lilypond.org/doc/v2.20/Documentation/notation/writing-pitches;
>
> \relative c' {
>\key cis \minor
>
>\once \override Staff.Clef.color = #green
>\once \override Staff.Clef.after-line-breaking =
>  #(add-link urlI)
>
>\once \override Staff.TimeSignature.color = #green
>\once \override Staff.TimeSignature.after-line-breaking =
>  #(add-link urlII)
>
>\once \override NoteHead.color = #green
>\once \override NoteHead.after-line-breaking =
>  #(add-link urlIII)
>
>cis'1
>\once \override Beam.color = #green
>\once \override Beam.after-line-breaking =
>  #(add-link urlIV)
>cis8 dis e fis gis2
> \tweak Accidental.color #green
> \tweak Accidental.after-line-breaking #(add-link urlVI)
> \tweak color #green
> \tweak after-line-breaking #(add-link urlV)
> \tweak style #'harmonic
> bis
> dis
> fis
>>1
>
> }
>
> Now with colored accidental and link on the accidental:
>
> Before:
>
> --
> Johannes Feulner
> Tel: +49 721 33500158  johannes.feul...@scorio.com
>
> scorio GmbH  Bonhoefferweg 3   76327 Pfinztal
> Geschäftsführer Johannes Feulner
> Sitz der Gesellschaft Karlsruhe
> Amtsgericht Mannheim HRB 713486
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Johannes.


this one is actually one of my early doc-tagged lsr-snippets...

Instead of manually updating the urls, I let them point to the docs of
the actually used version.
I hope it will be less maintaining effort.
While on it, I did some cleanup, code-formating etc.

lsr.di.unimi.it/LSR/Item?u=1=865

Since this snippet is tagged doc, it will be automatically catched for
Documentations/snippets with next lsr-import

Cheers,
  Harm

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

Re: Undesired MultiMeasureRest X position when clef change at end of measure

[Thomas Morley]

Am Sa., 10. Okt. 2020 um 16:14 Uhr schrieb Owain Evans :
>
> Hi Bug-Lily,
>
> MultiMeasureRest and  "clef change at end of measure" events in different 
> staffs but same measure: undesired MultiMeasureRest X position.
>
> MultiMeasureRest needs to be centered in this case.
> I.e. The rest's centring between the two barlines presides over the addition 
> of the clef symbol.
>
> Gould p. 160: says "When the rest bar contains a clef, key signature or time 
> signature, place the rest at the centre of the remaining blank space.
>
>
> \version "2.20.0"
> {
>   \new StaffGroup
>   <<
> \new Dynamics { s1-great s1-no s1-great s1-great }
> \new Staff  \relative c'' { \clef bass R1 \clef treble | g4 f e d \clef 
> bass | c,,1 | R1 | }
> \new Staff  \relative c'' { R1 | R1 | R1 \clef bass | R1 | }
>   >>
> }
>
> I am correcting this with:
> \once \override score.MultiMeasureRest.X-offset = 1.5 %but ofcourse 
> varies
>
> Many thanks,
>
> Owain Evans
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Owain,

per default left/right spacing of a MultiMeasureRest (MMR) is done
according to left/right break-alignment (a clef change belongs to it).
This is done score-wide, thus the spacing of MMRs is equal for all of
them even if only in one Staff a clef change happens.

You can affect this by overriding the spacing-pair-property:

work-around =
\once \override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)

{
  \new StaffGroup
  <<
\new Dynamics { s1-great s1-fixed s1-great s1-great }
\new Staff
  \relative c'' {
\clef bass R1 \clef treble | g4 f e d \clef bass | c,,1 | R1 |
  }
\new Staff
  \relative c'' { R1 | \work-around R1 | R1 \clef bass | R1 | }
  >>
}

Alas, I'm undecided whether it's a bug or not, look at the output of:

<<
  \new Staff { R1 R \clef bass R }
  \new Staff { R1 \work-around R R }
>>

The MMRs don't line up, no surprise. Though, I seem to remember some
users prefer this, but other users want the MMRs to be aligned.
And we have the demonstrated and documented override to fulfill both wishes.
Admittedly the documentation is poor and hard to find, perhaps we
should created a snippet in NR or at least i Documentation/snippets

Cheers,
  Harm

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

cannot find Voice `uniqueContext0' with \context Staff

[Thomas Morley]

Hi,

this came up in the german forum:

\context Staff { b1 }
\addlyrics { foo }

results in not printed lyrics and the warning:

warning: cannot find Voice `uniqueContext0'
\addlyrics
   { foo }

It worked up to 2.18.2 but fails for 2.20.0 and upstream

Changing the code to use
\context Voice or \new Voice or \new Staff
works.

Cheers,
  Harm

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

Re: Old completion engraver bug

[Thomas Morley]

Am Sa., 15. Aug. 2020 um 18:49 Uhr schrieb Jon Arnold
:
>
> Hi all-
>
> I'm working on 14 pieces for my dissertation that use the completion
> engravers heavily. I've just noticed a problem with lyrics alignment, which
> is documented in this old bug:
> https://sourceforge.net/p/testlilyissues/issues/1928/
>
> Is there any more current work around or hope of getting this fixed? It
> shows up all over my pieces, and I am really hoping not to have to fix it
> manually.
>
> Thanks!
>
> Jon Arnold
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi,

probably below.
Please report back if it's a sufficient workaround worth adding to the issue


#(define lyric-text-at-splitted-notes
;; Left-align LyricText if the NoteHead is splitted by Completion_heads_engraver
  (lambda (grob)
(let* (;; x-parent is usually NoteColumn
   (x-parent (ly:grob-parent grob X))
   ;; NoteHeads (as array)
   (x-parent-nhds-array (ly:grob-object x-parent 'note-heads))
   ;; NoteHeads (as list or #f)
   (x-parent-nhds
 (if (ly:grob-array? x-parent-nhds-array)
 (ly:grob-array->list x-parent-nhds-array)
 #f)))
  ;; If NoteHeads are splitted by Completion_heads_engraver, the
  ;; 'autosplit-end prob-property is true
  (if x-parent-nhds
  (for-each
(lambda (nhd)
  (let* ((cause (ly:grob-property nhd 'cause))
 (splitted? (ly:prob-property cause 'autosplit-end #f)))
(if splitted?
(ly:grob-set-property! grob 'self-alignment-X LEFT
x-parent-nhds)

\layout {
  \context {
  \Lyrics
  \override LyricText.before-line-breaking = #lyric-text-at-splitted-notes
  }
}

mel = \relative c'' {
  c2 d1 c1 c2
}

lyr = \lyricmode {
  One -- two __ three -- four.
}

\score {
  <<
\new Staff \new Voice = "normal" \mel
\new Lyrics \lyricsto "normal" \lyr

\new Staff <<
  \new Voice = "completion"
\with {
  \remove "Note_heads_engraver"
  \consists "Completion_heads_engraver"
}
  \mel
>>
\new Lyrics \lyricsto "completion" \lyr

\new Staff \new Voice = "revisited" \relative c'' { c2 c~ c c~ c c }
\new Lyrics \lyricsto "revisited" \lyr
  >>
}

Cheers,
  Harm

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

Re: Possible regression with changing time-signatures and order of input

[Thomas Morley]

Am Mi., 29. Juli 2020 um 23:39 Uhr schrieb Thomas Morley
:
>
> Am Mi., 29. Juli 2020 um 23:37 Uhr schrieb Thomas Morley
> :
> >
> > Hi,
> >
> > this just popped up in the german forum:
> >
> > The two scores below return different output since 2.20.0. (see
> > attached) and warnings/errors are emitted for the first score:
> > warning: barcheck failed at: 1/4
> >   R1
> >
> > programming error: Multi_measure_rest::get_rods (): I am not spanned!
> >
> > With 2.18.2 it's the same.
> >
> > \version "2.20.0"
> >
> > takte = { \time 3/4 s2.*2 \time 4/4 s1*2 }
> >
> > noten = {
> >   \repeat volta 2 { R2. }
> >   \alternative { { r2. } { r1  }
> >   }
> >   R1
> > }
> >
> > \score { \new Staff << \takte \noten >> }
> > \score { \new Staff << \noten \takte >> }
> >
> > Cheers,
> >   Harm
>
> And the image:

Here some more research on it, with extended test-cases:

control = {
  \time 3/4
  \repeat volta 2 { s2. }
  \alternative { { s2. } { \time 4/4 s1 } }
  s1
}

notes = {
  \repeat volta 2 { R2.  }
  \alternative { { R2. } { R1 }
  }
  R1
}

%% Order matters
\score { \new Staff \with { instrumentName = "1" } << \control \notes >> }
\score { \new Staff \with { instrumentName = "2" } << \notes \control >> }


%% From commit-message of f372c695a52cf83ea00ff3be40acc542b4d46cbd
\new Staff \with { instrumentName = "3" }
\relative {
  \partial 4
  \repeat volta 4 { e'4 | c2 d2 | e2 f2 | }
  \alternative { { g4 g g } { a a a a } }
  a b2.
}

%% Accidental missing
\new Staff \with { instrumentName = "4" }
\relative {
  \partial 4
  \repeat volta 2 { d'4 | g1 | }
  \alternative { { fis2. } { fis1 } }
  g1
}

(1)
With released 2.18.2
Scores 1+2 look good, 3+4 not, score-4 misses the accidental in 2nd repeat.
No error/warning

(2)
With a build out of
commit f372c695a52cf83ea00ff3be40acc542b4d46cbd
Author: David Kastrup 
Date:   Sun Nov 3 15:01:10 2013 +0100

Issue 355: \repeat bar lines get messed up

% the second repeat should start at the beginning of a bar, not
% continue from the incomplete bar in the first ending.

\version "2.17.30"
\new Staff \relative {
  \partial 4
  \repeat volta 4 { e' | c2 d2 | e2 f2 | }
  \alternative { { g4 g g } { a a a a } }
  a b2.
}

(first commit changing the previous behaviour)

Scores 1+2 look bad and emit barcheck-warnings and errors about not
spanned MultiMeasureRest
Score 3 looks good
Score 4 looks good as well, apart from the missing Accidental

(3)
With a build out of

commit b79db5deaf2159b569b1f9dab9c0fd59c3ff0533 (HEAD)
Author: David Kastrup 
Date:   Mon Jan 13 12:45:33 2014 +0100

Issue 3792: \time change under last \alternative does not persist

(first commit changing the previous behaviour)

Score 1 looks bad and emits barcheck-warnings and errors about not
spanned MultiMeasureRest
Score 2, 3, 4 look good (no warning or error)
Score 4 still misses the Accidental

This is still the behavior for current master.


I don't understand why score-1 is still bad and of course the
Accidental shouldn't be suppressed.

David I cc you, because you're the author of the mentioned patches,
any idea to improve?

Thanks,
  Harm

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

Re: Possible regression with changing time-signatures and order of input

[Thomas Morley]

Am Mi., 29. Juli 2020 um 23:37 Uhr schrieb Thomas Morley
:
>
> Hi,
>
> this just popped up in the german forum:
>
> The two scores below return different output since 2.20.0. (see
> attached) and warnings/errors are emitted for the first score:
> warning: barcheck failed at: 1/4
>   R1
>
> programming error: Multi_measure_rest::get_rods (): I am not spanned!
>
> With 2.18.2 it's the same.
>
> \version "2.20.0"
>
> takte = { \time 3/4 s2.*2 \time 4/4 s1*2 }
>
> noten = {
>   \repeat volta 2 { R2. }
>   \alternative { { r2. } { r1  }
>   }
>   R1
> }
>
> \score { \new Staff << \takte \noten >> }
> \score { \new Staff << \noten \takte >> }
>
> Cheers,
>   Harm

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

Possible regression with changing time-signatures and order of input

[Thomas Morley]

Hi,

this just popped up in the german forum:

The two scores below return different output since 2.20.0. (see
attached) and warnings/errors are emitted for the first score:
warning: barcheck failed at: 1/4
  R1

programming error: Multi_measure_rest::get_rods (): I am not spanned!

With 2.18.2 it's the same.

\version "2.20.0"

takte = { \time 3/4 s2.*2 \time 4/4 s1*2 }

noten = {
  \repeat volta 2 { R2. }
  \alternative { { r2. } { r1  }
  }
  R1
}

\score { \new Staff << \takte \noten >> }
\score { \new Staff << \noten \takte >> }

Cheers,
  Harm

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

Re: Doc bug in Snippets HTML: "indepently" should be "independently"

[Thomas Morley]

Am Mi., 24. Juni 2020 um 22:05 Uhr schrieb Kenneth Wolcott
:
>
> Doc bug in Snippets HTML: "indepently" should be "independently" in
> the snippet titled "Changing the number of augmentation dots per note"
> in the  "Rhythms" section.
>
> Ken Wolcott

Hi Ken,

thanks for your report.
It's a doc-tagged LSR-snippet, thus I've fixed it inside LSR
http://lsr.di.unimi.it/LSR/Item?id=800

Will appear corrected in our docs after next lsr-import.

Cheers,
  Harm

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

Re: Simultaneous accents broken in drum mode.

[Thomas Morley]

Am So., 14. Juni 2020 um 22:31 Uhr schrieb Luke Tidd :
>
> % simultaneous above+below bar staff accent works in non-drum mode:
> \relative c' {
>   1
> }
>
> % unaware of any workaround to make this work in drum mode:
> \drums {
>   1^>_>
>
>   1
> }
>
> % example of usage (see first note of second bar):
> https://i.imgur.com/N28jCYt.png
>

Hi,

I've no clue what happens here.
Below an ugly, hackish workaround, though.

accents = -\tweak #'script-stencil #'(feta . ("sforzato" . "sforzato")) _. ^>

\drums {
  \stemUp
  16\accents hh^> bd^> hh^>
}

I hope someone comes up with a better idea.

Cheers,
  Harm

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

Re: Problems with horizontal brackets

[Thomas Morley]

Am So., 31. Mai 2020 um 06:35 Uhr schrieb Jon Arnold
:
>
> Hi-
> I'm using horizontal brackets to analyze a piece that makes heavy use of
> the completion engravers, and I've discovered that the brackets do not
> extend the full length of a note when tied over a bar. The bracket only
> goes as far as the beginning of the expanded value.
>
> Perhaps the last bit should be filed separately, but the brackets do not
> appear at all when using full measure rests.
>
> Here's my example:
>
> %horizontal brackets do not extend the full length of the note
> %if used on a note expanded by completion engravers
>
> %they also do not appear at all on full measure rests
>
> \version "2.21.1"
>
> \score {
>   \new Staff {
> a1-\startGroup c'\breve-\stopGroup  \break
> r1-\startGroup r\breve-\stopGroup \break
> R1-\startGroup R\breve-\stopGroup
>   }
>   \layout {
> \context {
>   \Voice
>   \remove "Note_heads_engraver"
>   \consists "Completion_heads_engraver"
>   \remove "Rest_engraver"
>   \consists "Completion_rest_engraver"
>   \consists "Horizontal_bracket_engraver"
> }
>   }
> }
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Hi Jon,

thanks for your report.

If I understand correctly, the Horizontal_bracket_engraver works
before Completion_heads/rest_engraver.
Furthermore Horizontal_bracket_engraver works with NoteColumns only.
Thus MultiMeasureRests (MMRs) are not taken into account. Same holds
for skip-events.

I can't provide a proper fix.
Though, below a workaround using David's \at, in case of MMRs an ugly
workaround...

\version "2.20.0"

at =
#(define-music-function (time event music)
  (ly:duration? ly:music? ly:music?)
"Place @var{event} at a relative duration @var{time} in relation
to @var{music}."
  #{ \context Bottom << { \skip $time <>$event } $music >> #})

\score {
  \new Staff {
a1-\startGroup \at 1 \stopGroup c'\breve \break
r1-\startGroup \at 1 \stopGroup r\breve \break
%% fine-tuning HorizontalBracket
\override HorizontalBracket.shorten-pair = #'(-0.5 . 1)
\omit Rest
\at 4 r4-\startGroup R1 \at 1. r4-\stopGroup R\breve
\undo \omit Rest
  }
  \layout {
\context {
  \Voice

  \consists "Horizontal_bracket_engraver"

  \remove "Note_heads_engraver"
  \consists "Completion_heads_engraver"

  \remove "Rest_engraver"
  \consists "Completion_rest_engraver"

}
  }
}

HTH a bit,
  Harm

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

Re: Fingering inside staff

[Thomas Morley]

Am Sa., 30. Mai 2020 um 13:18 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Alas, I've not the time and energy to write a patch myself and fight
> > my way through the new GitLab process.
>
> git push -o merge_request.create -o merge_request.title="My patch" -o 
> merge_request.remove_source_branch origin HEAD:my-proposed-branch-name
>
> The push message gives you a HTTP link to your newly created merge
> request.  You can follow the progress there.
>
> > I have to admit I have skipped most of GitLab discussions and hints.
> > This will ofcourse give me some problems once my time allows to
> > participate more activ again.
> > Right now I'm too tired ...
>
> You don't need something like git-cl: the basic setup is really quite
> simple.  The most efficient way to organise continuous ongoing work is
> something we are still figuring out, but you are talking about entry
> hurdles here.  Those are not really high.
>
> --
> David Kastrup

Thanks David.
I've copied your advice to my personal "how to do"-file.

Cheers,
  Harm

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

Re: Fingering inside staff

[Thomas Morley]

Am Sa., 30. Mai 2020 um 10:15 Uhr schrieb Valentin Villenave
:
>
> On 5/30/20, Thomas Morley  wrote:
> > Fingering.add-stem-support is per default set to 'only-if-beamed'
>
> Of course!!  I vaguely remembered having come across something like
> that.  Sorry for making a fool of myself.
>
> > Try:
> > \override Fingering.add-stem-support = #'()
> > and it'll work
>
> Excellent; NOTABUT then.
>
> Thanks!
>
> Cheers,
> -- V.

Hi Valentin,

add-stem-support is not really documented.
In NR we have it in a snippet and in the index. In 'Snippets' there
two additional ones.
Though, a explanation is not really done.

'only-if-beamed' is completely undocumented.

Some more stuff can be found in the regtests, though we usually don't
expect users to look there.

Maybe worth some doc-additions.

Alas, I've not the time and energy to write a patch myself and fight
my way through the new GitLab process.
I have to admit I have skipped most of GitLab discussions and hints.
This will ofcourse give me some problems once my time allows to
participate more activ again.
Right now I'm too tired ...

Cheers,
  Harm

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

Re: Fingering inside staff

[Thomas Morley]

Am Sa., 30. Mai 2020 um 00:08 Uhr schrieb Valentin Villenave
:
>
> On 5/29/20, Pierre Perol-Schneider  wrote:
> > Hi Simone,
> > A basic solution:
> > \relative c' {
> >   \stemUp
> >   \override Fingering.staff-padding = #'()
> >   4 8 
> > }
>
> Sure there are workarounds, but: shouldn’t we be treating this as a
> bug? There’s no obvious reason why unsetting staff-padding should be
> ignored on a beamed note and not on an unbeamed note.
>
> 
>
> \relative c' {
> \stemUp
> \override Fingering.staff-padding = #'()
> 4 8
> }
>
> \relative c' {
> \stemUp
>   \override Fingering.staff-padding = #'()
>   4 8 
> }
>
> 
>
> I can’t find a glyph small enough to trigger it with other grobs
> (a.k.a StringNumber, Script or anything else), so I can’t tell if it’s
> limited to fingerings.
>
> Cheers,
> -- V.
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

Fingering.add-stem-support is per default set to 'only-if-beamed'
Try:
\override Fingering.add-stem-support = #'()
and it'll work

HTH,
  Harm

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

Re: Missing link: Rhythms

[Thomas Morley]

Am Mo., 20. Apr. 2020 um 13:16 Uhr schrieb Bernhard Kleine
:
>
> When in
> http://lilypond.org/doc/v2.19/Documentation/notation/bars#bar-lines I
> engage the link "Schnipsel":Rhythms it is not found:
>
> http://lilypond.org/doc/v2.19/Documentation/snippets/rhythmus.

After doing some random testing, I think every link from non-english
docs to snippets fails, because the keyword is translated.

Thus moving this one to the bug-list.

Cheers,
  Harm

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

Re: SystemStart changes after stop/startStaff - how to get it back

[Thomas Morley]

Hi Aaron,

Am Di., 14. Apr. 2020 um 06:20 Uhr schrieb Aaron Hill
:
>
> I think I have addressed the original issue in this patched version of
> the System_start_delimiter_engraver.  This is implemented in Scheme, but
> the changes should be easily ported back to C++.
>
> The strategy is to acknowledge the end of StaffSymbols to be able to
> remove their corresponding entries in the internal structure.
> Additionally, the context in which the StaffSymbol correlates is
> recorded so a future StaffSymbol of the same context takes the same
> place.  This should keep things stable if staves stop and start at odd
> places.

many thanks for your work!

For now I tested your engraver with my workaround in
mid-staff-gap-04.ly (see my previous post in this thread).
All works fine.

Though as nice as my current workaround looks like, it's still that: a
workaround.
I'll have a closer look at your engraver. Now that the functionality
is available in scheme I may find a proper fix (or not ...)
First step as always: I need to understand the given code ...

>
> One thing I noticed was the C++ engraver acknowledges
> SystemStartDelimiters (of which it is the one creating them) and calls
> the Bracket_nesting_group::add_support function.  However, in my porting
> of the engraver to Scheme, I could not get this acknowledger to trigger.
>   Does LilyPond have code coverage tests that could confirm whether that
> logic is necessary?  In any event, I omitted it from my Scheme engraver.

Can't help here, sorry.


Best,
  Harm

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

Re: Setting SystemStartBracket style to 'brace failing

[Thomas Morley]

Am Sa., 11. Apr. 2020 um 14:01 Uhr schrieb Thomas Morley
:
>
> Hi,
>
> consider the following code:
>
> mus =
>   \relative c''
> <<
>   \new Staff { c1 }
>   \new Staff { c1 }
> >>
>
> \new StaffGroup
>   \with {
> \override SystemStartBracket #'style = #'brace
>   }
>   \mus
>
> \new StaffGroup
>   \with {
> \override SystemStartBracket #'style = #'bar-line
>   }
>   \mus
>
> \new StaffGroup
>   \with {
> \override SystemStartBracket #'style = #'line-bracket
>   }
>   \mus
>
> \new StaffGroup
>   \with {
> \override SystemStartBracket #'style = #'bracket
>   }
>   \mus
>
> The style-override for 'brace results in _not_ printing a
> SystemStartBrace or anything, while all other settings work (image
> attached).
> This happens for every version since 2.14.2
> It worked for 2.12.3, thus the ancient syntax (image attached).
>
> I'm aware I can get a brace by setting systemStartDelimiter
> accordingly, though above is a minimal boiled down from a larger
> custom coding, where this currently failing override is needed.
>
> Cheers,
>   Harm

https://sourceforge.net/p/testlilyissues/issues/5899/

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

Re: SystemStart changes after stop/startStaff - how to get it back

[Thomas Morley]

Am So., 12. Apr. 2020 um 14:00 Uhr schrieb Aaron Hill
:
>
> On 2020-04-12 3:50 am, Thomas Morley wrote:
> > Hi,
> >
> > consider the following code:
> >
> >
> > mus = \new Staff { R1 \break R \stopStaff s \startStaff R \break R
> > \break R }
> >
> > \new StaffGroup
> >   \with {
> >   systemStartDelimiterHierarchy =
> > #'(SystemStartBracket (SystemStartBrace a b c))
> >   }
> >   << \mus \mus \mus >>
> >
> >
> > The SystemStartBrace vanishes after stop/startStaff.
> > I'm at a loss here, it does not work out of the box for every version
> > from 2.12.3 up to master.
> >
> > Any chance to get the additional SystemStartBrace back?
>
> Yes, but it might have side-effects:
>
> 
> systemStartDelimiterHierarchy =
>#'(SystemStartBracket
>(SystemStartBrace a b c)
>(SystemStartBrace a b c))
> 
>
> Since \stopStaff and \startStaff create new StaffSymbols, it appears the
> System_start_delimiter_engraver thinks that these are extra staves in
> parallel, so your hierarchy says to do this:
>
> ( / =
> < | =
> ( | =
>   | =
>   | =
>   \ =
>
> Of course, the StaffSymbols never appear at the same time, because they
> are meant to be replacements.  But the SystemStartBrace only spans the
> first three staves, so it does not apply in the latter part of the
> score.
>
> Knowing that a duplicate set of staves will appear at some point, you
> can lie about the hierarchy as my hack above does.  This allows the
> second set of StaffSymbols to be grouped as desired.
>
> Ultimately, System_start_delimiter_engraver needs to be watching for
> \stopStaff and \startStaff events so it can clean up and rebuild its
> StaffSymbol collection rather than just append to the existing one.
>
>
> -- Aaron Hill

Hi Valentin, Aaron,

many thanks for your insights and hints.
I'll play around with it. Ofcourse my actual usecase is far more
complex than the minimal above...

Any thoughts for
http://lilypond.1069038.n5.nabble.com/Setting-SystemStartBracket-style-to-brace-failing-td231524.html
as well?
This is another showstopper...


Best,
  Harm

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

Setting SystemStartBracket style to 'brace failing

[Thomas Morley]

Hi,

consider the following code:

mus =
  \relative c''
<<
  \new Staff { c1 }
  \new Staff { c1 }
>>

\new StaffGroup
  \with {
\override SystemStartBracket #'style = #'brace
  }
  \mus

\new StaffGroup
  \with {
\override SystemStartBracket #'style = #'bar-line
  }
  \mus

\new StaffGroup
  \with {
\override SystemStartBracket #'style = #'line-bracket
  }
  \mus

\new StaffGroup
  \with {
\override SystemStartBracket #'style = #'bracket
  }
  \mus

The style-override for 'brace results in _not_ printing a
SystemStartBrace or anything, while all other settings work (image
attached).
This happens for every version since 2.14.2
It worked for 2.12.3, thus the ancient syntax (image attached).

I'm aware I can get a brace by setting systemStartDelimiter
accordingly, though above is a minimal boiled down from a larger
custom coding, where this currently failing override is needed.

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

Re: Wrong alignment when adding additional lyrics multiple times on the same line

[Thomas Morley]

Am Mo., 6. Apr. 2020 um 00:20 Uhr schrieb Benedikt Wilde :
>
> Hello,
>
> I believe to have encountered a bug in LilyPond. When one adds
> additional lyrics multiple times on the same line of the resulting sheet
> music using alignBelowContext, the alignment of the first instance is
> shifted down. (It is shifted below the second instance.) If this is
> attempted more than twice on a line, these extra shifts stack up.
> When the two instances are not on the same line in the resulting sheet
> music, this problem does not occur. (This can be observed by removing
> the 'landscape option in the attached file.)
>
> The example I attached is basically taken from the official
> documentation [1], with the last two bars repeated.
>
> Best regards
>
> Benedikt Wilde
>
>
> [1]:
> http://lilypond.org/doc/v2.19/Documentation/notation/techniques-specific-to-lyrics#lyrics-and-repeats

Hi Benedikt,

thanks for your bug-report.
The behaviour you observe is expected, although you may not want it.

The docs say new contexts are always aligned below already existing ones.
Because the first occurrence of \new Lyrics = "secondVerse" is not
immediately continued, it dies. The second  \new Lyrics =
"secondVerse" then initiates a _new_ Lyrics-context aligned below the
first. Actually you created 5 different Lyric-contexts.
Using alignBelowContext obfuscates it a bit, alas it's not suitable to
align those contexts as you wish.

Instead you should initiate the three needed Lyrics right from the
beginning and keep them alive throughout the score. Then let
additional lyrics be distributed to the correct Lyric-context by using
\context Lyrics = "..."
How to keep contexts alive is covered in the docs, as well as the
difference of \new and \context (although not in the section about
lyrics, iirc).

Your example could be done like:

\paper {
  #(set-paper-size "a4" 'landscape)
}

\score {
  <<
\new Staff {
  \new Voice = "melody" {
\relative {
  a'4 a a a
  \repeat volta 3 { b4 b b b }
  c4 c c c
  \repeat volta 3 { b4 b b b }
  c4 c c c
}
  }
}
\new Lyrics = "firstVerse" s1*5
\new Lyrics = "secondVerse" s1*5
\new Lyrics = "thirdVerse" s1*5
\context Lyrics = "firstVerse" \lyricsto "melody" {
  Not re -- peat -- ed.
  <<
{ The first time words.}
\context Lyrics = "secondVerse"
  \with { alignBelowContext = "firstVerse" }
  {
  \set associatedVoice = "melody"
  Sec -- ond time words.
  }
\context Lyrics = "thirdVerse"
  \with { alignBelowContext = "secondVerse" }
  {
  \set associatedVoice = "melody"
  The third time words.
  }
  >>
  The end sec -- tion.
  <<
{ The first time words.}
\context Lyrics = "secondVerse"
  \with { alignBelowContext = "firstVerse" }
  {
  \set associatedVoice = "melody"
  Sec -- ond time words.
  }
\context Lyrics = "thirdVerse"
  \with { alignBelowContext = "secondVerse" }
  {
  \set associatedVoice = "melody"
  The third time words.
  }
  >>
  The end sec -- tion.
}
\new Voice = "harmony" {
  \relative {
f'4 f f f
\repeat volta 2 { g8 g g4 g2 }
a4 a8. a16 a2
\repeat volta 2 { g8 g g4 g2 }
a4 a8. a16 a2
  }
}
  >>
}

Again, thanks for your report.
No bug, though.

Best,
  Harm

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

associatedVoice in multi-staff score

[Thomas Morley]

Hi,

this came out of the german forum:

The naive attempt to set associatedVoice for lyrics in a multi-Staff
score fails silently:

\version "2.20.0"

musI = { c'4 d' s2 }
musII = { s2 e'4 f' }
lyr = \lyricmode { foo \set associatedVoice = "v2" bar buzz puh }

<<
  \new Staff = "1" \new Voice = "v1" \musI
  \new Lyrics \lyricsto "v1" \lyr
  \new Staff = "2" \new Voice = "v2" \musII
>>

I suppose the v2-Voice is not fully "acknowledged" at the time Lyrics
tries to switch to it.
Instead one needs to put the Lyrics at the end and insert them at
correct position with alignAbove/BelowContext:

<<
  \new Staff = "1" \new Voice = "v1" \musI
  \new Staff = "2" \new Voice = "v2" \musII
  \new Lyrics
\with { alignAboveContext = "2" }
\lyricsto "v1" \lyr
>>

Not sure, if I'd call it a bug.
At least it should be documented, probably as "known issues and warnings"
Btw, all doc-examples and regtests using associatedVoice are singel-staff ones.
Should we add a multi-staff example?

Opinions?

Cheers,
  Harm

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

Re: Ottavation markups

[Thomas Morley]

Am Mo., 2. März 2020 um 21:28 Uhr schrieb Jean Abou Samra :
>
>Hi,
>
>The recent possibility to define ottavation markups introduced a bug
>when exporting to MIDI.
>
>For example,
>\version "2.21.0" % compiled with HEAD being
>ede0457988716a5e6fa0dd1757db0ebd96107bbc
>\score {
>{ \ottava 1 c'1 }
>\midi { }
>}
>will trigger the warning
>Could not find ottavation markup for 1 octaves up.
>CCing Malte Meyne since he's the author of the patch that introduced
>the warning -- see
>http://lilypond.1069038.n5.nabble.com/Add-user-definable-ottavation-mar
>kups-issue-568970043-by-lilypond-maltemeyn-de-tc223988.html
>
>The MIDI output is fine though.

Not sure whether it's a proper fix.
For now you could do:

\version "2.21.0"

\score {
  { \ottava 1 c'1 }
  \midi {
\context {
  \Staff
  ottavationMarkups = #ottavation-numbers
}
  }
}

HTH,
  Harm

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

Re: LSR 2.20 #724 cannot be upgrated automagically

[Thomas Morley]

Am Do., 27. Feb. 2020 um 11:09 Uhr schrieb David Kastrup :
>
> Pierre Perol-Schneider  writes:
>
> > Hi BugSquad,
> > Making some tests for the LSR v.2.20, I'm stuck with:
> > http://lsr.di.unimi.it/LSR/Item?id=724
> >
> > Starting lilypond-windows.exe 2.19.84 [
> > autochange-music-with-a-different-pitch.ly]...
> > Processing `C:/Users/Pierre/Documents/LilyPond/000 LSR/
> > autochange-music-with-a-different-pitch.ly'
> > Parsing...C:/Users/Pierre/Documents/LilyPond/000
> > LSR/autochange-music-with-a-different-pitch.ly:24:14: In procedure
> > make-autochange-music in expression (make-autochange-music (if ref # ...)):
> > C:/Users/Pierre/Documents/LilyPond/000
> > LSR/autochange-music-with-a-different-pitch.ly:24:14: Wrong number of
> > arguments to #
> > Exited with return code 1.
> >
> > Any idea?
>
> commit e6e59e19a164f0d3af53b0bde3798940de162d66
> Author: Thomas Morley 
> Date:   Thu Jul 30 20:39:22 2015 +0200
>
> Let \autochange accept optional arguments for the turning-point and clefs
>
> Issue 4530
>
> With the fix for issue 4465 bassStaffProperties and trebleStaffProperties 
> are gone.
> This patch reimplements the functionality to set clefs for the staves and 
> offers the
> possibility to set another turning-point apart from middle-C.
> This is done with optional arguments for \autochange.
>
> Two regtests are added to reflect these possibilities.
> Documentation/notation/keyboards.itely is extended accordingly.
>
> Also inserting the usual remarks about license, etc in autochange.scm.
>
> was implemented in a non-upwards-compatible manner (like using an
> optional argument in the Scheme function) and without a convert-ly rule.

Yep, I overlooked that.

>
> We are a bit late in the game, but stable is stable and unstable is
> unstable: I'd lean towards making the ref-pitch argument of the
> make-autochange function optional and come _last_ to correspond to the
> typical placement of Scheme optional arguments.  Then we'd need no
> convert-ly rule.  With the same order as the LilyPond scheme-function,
> we'd have to count arguments to do the right thing (or check types), and
> that's more awkward.
>
> It's worth noting, however, that the given LSR is quite redundant now
> exactly because of that commit by Thomas that turns the normal
> \autochange command into an \autochangeWithPitch anyway.

Since it's now documented in Documentation/notation/keyboards.itely, I
suggest to simply delete http://lsr.di.unimi.it/LSR/Item?id=724 from
LSR during 2.20 upgrade.

>
> I'd still suggest changing make-autopitch because an optional argument
> just is nicer.
>
> Tracker issue: 5798 (https://sourceforge.net/p/testlilyissues/issues/5798/)
> Rietveld issue: 567280043 (https://codereview.appspot.com/567280043)
> Issue description:
>   Make make-autochange function upwards-compatible to 2.18  This
>   entails putting the ref-pitch argument last and making it an
>   optional argument.

Thanks,
  Harm

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

Re: dynamic is strange since 2.19.26

[Thomas Morley]

Am So., 23. Feb. 2020 um 16:52 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > consider the following code
> >
> > \version "2.19.84"
> > \markup \dynamic { s f m z p r }
> >
> > output attached.
> >
> > And compare with the output of
> >
> > \version "2.19.84"
> > { R1 }
> > \markup \dynamic { s f m z p r }
> >
> > The markup does not use the same font (from visual inspection). Most
> > noticeable with "z", but the others are slightly off as well.
> >
> > No clue whats happening here...
> > It happened somewhere between 2.19.25 and 2.19.26
> >
> > Also
> > {
> >   \override DynamicText.stencil =
> > #(make-stencil-boxer 0 0 ly:text-interface::print)
> > c'2_\f
> > }
> > shows significant differencies for 2.19.25 and 2.19.84, attached as well.
> > This one leads to changed appearance for combined dynamics like mf,
> > sfz and the like.
>
> The mf directory shows the following commits in that version range:
>
> commit 2ce9d3b0ac456df77a73342fdf802f2e198c3b4e
> Author: Masamichi Hosoda 
> Date:   Fri Aug 14 22:45:20 2015 +0900
>
> Issue 4552 / 5: Remove makefiles to convert and install URW++ fonts
>
> This commit removes makefiles to convert to OTF and install URW++ fonts.
> (Century Schoolbook L, Nimbus Sans L, Nimbus Mono L)
>
> commit bb66d05c73dbc038b994430545c85966fd9edc12
> Author: Masamichi Hosoda 
> Date:   Fri Aug 14 20:11:33 2015 +0900
>
> Issue 4552 / 3: Replace LilyPond default font to TeX Gyre fonts
>
> fromto
> Century Schoolbook L -> TeX Gyre Schola
> Nimbus Sans L-> TeX Gyre Heros
> Nimbus Mono L-> TeX Gyre Cursor
>
> commit 7c30014f110ee407b56c91d3b451b28ce7a89f8a
> Author: Masamichi Hosoda 
> Date:   Mon Aug 10 10:47:49 2015 +0900
>
> Issue 4552 / 2: Add makefiles to install TeX Gyre font OTF files
>
> This commit adds makefiles
> to install TeX Gyre font OTF files.
>
> commit ebd5a4af248c95178abb8490a32c0b8d3af4e1d7
> Author: Masamichi Hosoda 
> Date:   Sat Aug 8 21:15:37 2015 +0900
>
> Issue 4544 / 3: Fix makefiles for LilyPond local fontconfig conf file 
> dividing
>
> This commit fixes LilyPond local fontconfig conf file dividing.
>
> commit 0fbbdc6c58432060770d3d4f76e063c2028c0023
> Author: Masamichi Hosoda 
> Date:   Sat Aug 8 19:06:50 2015 +0900
>
> Issue 4544 / 2: Fix LilyPond default fonts definition
>
> Due to conf file loading order, generic font aliases
> `serif', `sans-serif', 'monospace' were unavailable
> in LilyPond default fonts definition.
> So the glyphs that are not contained
> in the list of font definition,
> like Japanese glyphs were used unexpected font.
>
> This commit changes
> LilyPond default fonts definition loading order
> for enabling the aliases.
>
>
> There will probably be a few more commits outside of the mf directory
> that belong to the same issues.
>
> Could any of those commits have an effect like that?  Would that likely
> show just on one particular computer, or might other systems also be
> affected?
>
> Hosoda-san, do you have any idea here?
>
> Thank you
> David
>
> --
> David Kastrup

Looks like LilyPond was confused by several fonts in several folders. See:
https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00389.html

While this is my own fault, I still think LilyPond should be more
robust in this regard.
I.e. always use emmentaler, unless explicitely specified differently.

Cheers,
  Harm

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

Re: dynamic is strange since 2.19.26

[Thomas Morley]

Am So., 23. Feb. 2020 um 16:26 Uhr schrieb Aaron Hill
:
>
> On 2020-02-23 4:47 am, Thomas Morley wrote:
> > consider the following code
> >
> > \version "2.19.84"
> > \markup \dynamic { s f m z p r }
> >
> > output attached.
> >
> > And compare with the output of
> >
> > \version "2.19.84"
> > { R1 }
> > \markup \dynamic { s f m z p r }
> >
> > The markup does not use the same font (from visual inspection). Most
> > noticeable with "z", but the others are slightly off as well.
>
> I cannot reproduce against 2.19.84 I installed from the linux-64 sh
> script.  (lilybin.com running 2.19.55 also behaves as expected.)  The
> dynamics font looks the same regardless of the presence of a score.
>
> Could this be an issue with font caching?

How to verify it's font caching?
Can you confirm different bounding-boxes (the seciónd here reported issue)?

Thanks,
  Harm

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

dynamic is strange since 2.19.26

[Thomas Morley]

Hi,

consider the following code

\version "2.19.84"
\markup \dynamic { s f m z p r }

output attached.

And compare with the output of

\version "2.19.84"
{ R1 }
\markup \dynamic { s f m z p r }

The markup does not use the same font (from visual inspection). Most
noticeable with "z", but the others are slightly off as well.

No clue whats happening here...
It happened somewhere between 2.19.25 and 2.19.26

Also
{
  \override DynamicText.stencil =
#(make-stencil-boxer 0 0 ly:text-interface::print)
c'2_\f
}
shows significant differencies for 2.19.25 and 2.19.84, attached as well.
This one leads to changed appearance for combined dynamics like mf,
sfz and the like.

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

Re: ly:page-turn-breaking core dumps

[Thomas Morley]

Am Sa., 1. Feb. 2020 um 15:46 Uhr schrieb Pierre-Luc Gauthier
:
>
> Hi there,
>
> So, this problem comes up once in awhile but, I do not know why, its
> now recurrent on multiple projects now.
> All my orchestral projects compile about 96 PDF all using the
> ly:page-turn-breaking algorithm that I love so very very much. But
> sometimes, it fails with the error bellow. By sometimes I mean, it
> *always* breaks until I do significant music changes that, I suppose,
> changes the page layout until the problem is avoided by chance.
>
> Here is the interesting tail of the output :
>
> Calculating page and line breaks (8 possible page breaks)...lilypond:
> /tmp/packerbuild-1000/lilypond-git/lilypond-git/src/lilypond/lily/page-turn-page-breaking.cc:218:
> void Page_turn_page_breaking::calc_subproblem(vsize): Assertion
> `!std::isinf (best.demerits_) && start < end - 1' failed.
> ./publish.sh: line 11: 63598 Aborted (core dumped)
> lilypond -dno-point-and-click -ddelete-intermediate-files
> -dembed-source-code --pdf -o ./upload/ ./parts-book-template.ily
>
> I'm sure there is a way to create a MWE but I've never manage to do
> so. It's sort of a "once in a specific while" kind of problem.
>
> How can I help this bug along?
> --
> Pierre-Luc Gauthier
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond

This may be related to https://sourceforge.net/p/testlilyissues/issues/4943/
Currently intensively discussed.

May I ask which OS you use, 32 or 64 bit ?

Cheers,
  Harm

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

Re: Documentation suggestions.

[Thomas Morley]

Hi Peter,

many thanks for your suggestions.

Without any intent to offend you, let me (partly) play the devil's
advocate... ;)

Am Mo., 30. Dez. 2019 um 17:11 Uhr schrieb Peter Toye :
>
> As an occasional and fairly new Lilypond user I've found that the 
> documentation is occasionally obscure or misleading. I've made a few 
> suggestions below.
>
> I've used the 2.19.83 documentation as the baseline.
>
> Have a great 2020.
>
> Regards,
>
> Peter
> mailto:lilyp...@ptoye.com
> www.ptoye.com
>
> 1. There is no index entry in NR for the \language command. It is mentioned 
> only once: in Section 1.1.1 'Note names in other languages' - I suggest 
> adding an index entry for it.

Well, there _is_ an entry in NR for "language" in
D. LilyPond command index
E. LilyPond index

In the 2.21.0 Docs it's changed to "\language"


> 2. Neither LM nor NR mention that the default language for entering pitches 
> is English. This might be confusing to non-English newbie engravers. I 
> suggest adding to LM Section 1.2.1 'Pitches' something like:
>
> 'By default, note names are written using English notation. You can change 
> this using the \language command. See [add reference to NR 1.1.1 "Note names 
> in other languages"]'

Here I'm confused.
The default note names are dutch.

> 3. In NR 1.2.5 'Bar and bar number checks' I suggest adding a paragraph at 
> the bottom of the section:
>
> 'Note that if MIDI output is selected and volta repeats are in place, the bar 
> number check will fail. It is best to suppress MIDI output whle checking bar 
> numbers.'

Can't comment on this, I've never used bar number checks.

> 4. The characters allowed in variable names are only briefly touched upon: in 
> LR 2.4.1 the use of only alphabetic characters is mentioned as a convention, 
> while NR 3.1.5 states this as a requirement. In a LilyPond-user email David 
> Kastrup said "It's alphabetic characters in the ASCII set plus all non-ASCII 
> characters, potentially interspersed with isolated single underlines or 
> dashes." From other hints and experiments it appears that any characters are 
> allowed if the name is enclosed in double quotation marks. I suggest in NR 
> 3.1.5 'File Structure' in the bullet point 'A variable...' the last sentence 
> is replaced by:
>
> 'By convention, the name of a variable consists of upper- and lower-case 
> alphabetic characters only. In addition, non-ASCII characters and 
> non-adjacent single underscores and dashes are also allowed. Any combination 
> of characters is allowed if the variable name is enclosed in double quotation 
> marks.'
>
> I've changed David's wording slightly to be marginally more accurate (IMO). 
> This may need to be checked for accuracy.

Here I'm undecided.
For a while I used non-ASCII characters frequently. But menwhile I
went back to use upper- and lower-case alphabetic characters only.
Less cinfusing, imho

Ofcourse, that's not the point...

As long as it is allowed to use non-ASCII characters, it should be documented.
The possibility to use arbitrary signs inside "" should be documented
by all means.

> 5. The context of the various \tag commands is not described. I had assumed 
> that they were lexical items, similar to many directives for conditional 
> compilation; this was not correct! I suggest adding the following text to NR 
> 3.3.2 'Using Tags', but I'm not sure of the best placement. Either close to 
> the top of the section, before the examples, or at the very end, before "see 
> also":
>
> 'Note that \keepWithTag and \removeWithTag are themselves music expressions 
> and so must appear within a \score block.'

(devil's advokat:)
\keepWithTag and \removeWithTag are music-functions and documented as
such. They return music.
Every music-function checks its argument(s), \keepWithTag needs music
not score like multiple others, e.g. \transpose.
This holds for every music-function (expecting music) and is
documented at least in Extending 2.3.2 Music function usage.

Is there any need to explain this for every music-function expecting music?
Isn't the error-message sufficient?

> 6. NR Section 3.2 'Titles and Headers" is very confusing: the word "header" 
> is used both for the \header command and for page headers. It is obviously 
> far too late to change the former, so I suggest that where page headers are 
> implied they should be mentioned explicitly. In detail, in NR 3.2.1 and 3.2.2 
> the sections '...layout of headers and footers' be retitled:
>
>  '...layout of page headers and footers'.

Well, headers are a complete mess, imho.
We do not only need to differentiate between, header and page-header,
but headers for multiple books of a file, headers for each book of a
file, header for each score and probably even for bookpart as well
(can't remember).
Each level, at least book(part)-level may take its own page-headers,
and footers ...
So your suggestion is likely only a first step.

> 7. Contributor's Guide is a bit confusing. Section 1.2 'Overview of work 
> 

Strange "programming error: Loose column ..."

[Thomas Morley]

Hi,

the following code returns
programming error: Loose column does not have right side to attach to.
for all versions from 2.14.2 up to 2.21.0
No error for 2.12.3

{
  \set Score.defaultBarType = #""
  r2
  b1\glissando
  c'
}


Cheers,
  Harm

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

Re: Grace notes cause wrong Hairpin.to-barline behaviour

[Thomas Morley]

Am Di., 12. Nov. 2019 um 09:13 Uhr schrieb Rutger Hofman :
>
> Good morning bug list,
>
> if a grace note occurs in another Staff or another Voice, a hairpin that
> should end before the barline (to-barline = ##t) behaves as if
> to-barline = ##f. I have no doubt that this is a bug.
>
> It occurs in all lilypond versions I have on my system: 2.18.2, 2.19.83,
> 2.21.0 (self-compiled on Ubuntu).
>
> Attached .ly and .pdf files. It contains two cases: (1) grace note in
> another Staff and (2) grace note in another Voice in the same Staff. The
> third & fourth bar in the examples show the correct (to-barline = ##t)
> behaviour.
>
> Rutger Hofman
> Amsterdam

The problem is "Grace note synchronization", see NR.
Issue 34 is involved ...

Try:

\score {
<<
\new Staff {
\relative c'' {
c1 | \grace b8 c1 | c1 |  c1 |
}
}
\new Staff {
\relative c'' {
c1\< | \grace s8\! c1 | c1\< | c1\! |
}
}
>>
}

\score {
\new Staff <<
\relative c'' {
c1 | \grace b8 c1 |
c1 | c1 |
}
\new Voice \relative c' {
c1\< | \grace s8\! c1 | c1\< | c1\! |
}
>>
}

HTH,
  Harm

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

Re: Entering and leaving polyphony with lyrics behaving oddly

[Thomas Morley]

Hi,

Am Di., 29. Okt. 2019 um 17:09 Uhr schrieb Jacob Page :
>
> I'm encountering something odd.
>
> \version "2.18.2"

you use stable 2.18.2, nevertheless current devel-version is 2.19.83,
which is meant to be a prerelease for next stable 2.20.
2.19.83 is by no means unstable, furthermore:

>
> \new Staff = "bass" {
>   \time 4/4
>   \clef bass
>   \key g \major
>
>   <<
> \new Voice = "bs" {
>   \voiceTwo
>   g,1
> }
>
> \new Lyrics \lyricsto "bs" {
>   Don't
> }
>
> \new Voice = "br" {
>   \voiceOne
>   r4 d2.
> }
>
> \new Lyrics \with { alignAboveContext = "bass" } {
>   \lyricsto "br" {
> it
>   }
> }
>   >>
>
>   \new Voice = "unis" {
> \relative c {
>   \oneVoice
>   c4. a8 g2
> }
>   }
>   \new Lyrics \lyricsto "unis" {
> seem to go?
>   }
> }
>
> This is outputting the polyphonic measure just fine, but the subsequent
> notes once moving to one voice don't output.

this problem (about dying contexts) is fixed in 2.19.83.
Thus I'd switch to this version.


In general I'd recommend not to created a whole bunch of new contexts
(even of different kind: Voices and Lyrics) while being in another
context.
LilyPond may not be able to sort out what you intend.
Better initiate what you need right from the start (probably keeping
them alive) and distribute content as you like.

<<
\new Staff = "bass" {
  \time 4/4
  \clef bass
  \key g \major

  <<
\new Voice = "bs" { \voiceTwo g,1 }
\new Voice = "br" { \voiceOne r4 d2. }
  >>

  \new Voice = "unis" \relative c { \oneVoice c4. a8 g2 }
}

\new Lyrics \lyricsto "bs" { Don't }
\new Lyrics \with { alignAboveContext = "bass" }  \lyricsto "br" { it }
\new Lyrics \lyricsto "unis" { seem to go? }
>>

Then it works even for 2.18.2.

Even if LilyPond wasn't able to sort what you entered, I see no bug,
but unfavorable user-input.
Others may differ, though...

Cheers,
  Harm

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

Re: Clef change and measure length

[Thomas Morley]

Am Sa., 26. Okt. 2019 um 10:30 Uhr schrieb foxfanfare :
>
> Hi all,
>
> I think this is a bug: when a clef change appears after a full measure rest,
> the rest is no longer centered properly in the measure. The result looks
> weird. See that example:
>
> \version "2.19.82"
>
> \new Staff
> \relative c' {
>   c1
>   R-"default"
>   \bar "||"
>   R_"not centered"
>   \clef bass
>   \once \override MultiMeasureRest.X-offset = #1
>   R-"tweaked"
>   \clef treble
>   c
> }
>
> What do you think?
>
> clefchange.ly
> 
> clefchange.pdf
> 

Well, while centering a MMR the question is "center between which items?"
Default LilyPond centers between left and right break-alignment.
That's what's done and what you see.
So no bug, but intended.

Nevertheless you can change this behaviour by applying
[\once]
\override MultiMeasureRest.spacing-pair = #'(staff-bar . staff-bar)
as stated in the IR.


Cheers,
  Harm

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

Re: \instrumentSwitch adds the name twice in contexts with multiple voices

[Thomas Morley]

Am Di., 15. Okt. 2019 um 04:36 Uhr schrieb Chris J. M. :
>
> \version "2.18.2"
>  \addInstrumentDefinition #"timpani"
>   #`((instrumentCueName . ,(make-bold-markup "timp.")))
> << { s1 } { \instrumentSwitch "timpani" d1 } >>
>
> It outputs the word “timp.” twice.  It should only say it once.  The attached 
> expanded example includes using the empty voice with the s1 for controlling 
> time & key signatures (which would be useful in multi-part scores).
>
> — Chris

Hi Chris,

thanks for your report.
\instrumentSwitch naturely affects the whole Staff, but multiple
Voices shouldn't cause multiple output of instrumentCueName.
So I'd agree, it's buggy.

Not sure, if it's the correct fix, the following seems to work:

instrumentSwitch =
#(define-music-function
   (name) (string?)
   (_i "Switch instrument to @var{name}, which must be predefined with
@code{\\addInstrumentDefinition}.")
   (let* ((handle (assoc name instrument-definitions))
  (instrument-def (if handle (cdr handle) '(

 (if (not handle)
 (ly:input-warning (*location*) "No such instrument: ~a" name))
 (
  ;; context-spec-music
  ;; changed to:
  descend-to-context
  (make-music 'SimultaneousMusic
  'elements
  (map (lambda (kv)
 (make-property-set
  (car kv)
  (cdr kv)))
   instrument-def))
  'Staff)))


Cheers,
  Harm

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

Re: \balloonText applied to single note errors with symbol->string ??

[Thomas Morley]

Am Sa., 28. Sept. 2019 um 21:54 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > the code below
> >
> > \layout { \context { \Voice \consists "Balloon_engraver" } }
> > { c'-\balloonText #'(2 . 0) \markup { "1" } }
> >
> > returns (in 2.21.0):
> > ERROR: In procedure symbol->string:
> > ERROR: Wrong type argument in position 1 (expecting symbol): ()
> >
> > 2.18.2 gives a more useful message:
> > /home/hermann/lilypond/usr/share/lilypond/current/scm/lily-library.scm:242:8:
> > In procedure symbol->string in expression (process-procedure book
> > paper ...):
> > /home/hermann/lilypond/usr/share/lilypond/current/scm/lily-library.scm:242:8:
> > Wrong type argument in position 1 (expecting symbol): ()
> >
> > Though, I've no clue where symbol->string comes into the game...
>
> In lily/balloon-engraver.cc
>
> > Ofcourse the NR recommends to use balloonText _inside_ of chords, and
> > indeed the problem goes away, wrapping the note in an event-chord.
> > But shouldn't it work as a postevent to a single note, too??
>
> The implementation does not work with separate AnnotateOutput events
> (more exactly, they require specifying the particular grob type to use
> since usually a number of grobs could be annotated).  One could try to
> capture all rhythmic-events and annotate them all.  It's all reasonably
> icky stuff that should at one point of time be upgraded to look like
> what we do with footnotes.  As a stopgap measure, one could use the
> following patch for a bit nicer behavior.

Hi David,

thanks for the explanations.
A warning directly pointing to the problem is of course very helpful.

Though, how about making balloonText work outside of chords? Therefore
one could provide an optional default argument, i.e. NoteHead, for
in-chord usage.
balloonGrobText could rely on it then.
See the code below.
The persisting problem is ofcourse how to annotate a single item of
multiple others of the same kind in an event-chord?
I found no nice way to do so, neither with current state of master nor
with my suggestion.

\version "2.21.0" %% works for lower versions as well

balloonText-test =
#(define-event-function (grob offset text)
  ((symbol? 'NoteHead) number-pair? markup?)
   (_i "Attach @var{text} at @var{offset} (use like @code{\\tweak})")
   (make-music 'AnnotateOutputEvent
   'symbol grob
   'X-offset (car offset)
   'Y-offset (cdr offset)
   'text text))

balloonGrobText-test =
#(define-music-function (grob-name offset text)
   ((symbol? 'NoteHead) number-pair? markup?)
   (_i "Attach @var{text} to @var{grob-name} at offset @var{offset}
 (use like @code{\\once})")
   (make-event-chord (list (balloonText-test grob-name offset text


%% EXAMPLES


\layout { \context { \Voice \consists "Balloon_engraver" } }

{
\balloonLengthOn
%% "post-event" for NoteHead (default), Flag, Rest, Fingering, NoteHead in
%% event-chord
c'4-\balloonText-test #'(1 . 5) "NoteHead"
d'8-\balloonText-test Flag #'(2 . -2) "Flag"
r-\balloonText-test Rest #'(2 . 4) "Rest"
e'4-1-\balloonText-test Fingering #'(1 . 5) "Fingering"

}

{
  %% "\once \override" for Stem, Rest, NoteHead (default)
  \balloonGrobText-test Stem #'(3 . 4) "I'm a Stem"
  b4
  \balloonGrobText-test Rest #'(-4 . -4) "I'm a rest"
  r
  \balloonGrobText-test #'(4 . -4) "I'm a note head"
  c'
  %% How to annotate a single Item in an event-chord, like one Fingering among
  %% multiple ones?
  %% balloonGrobText-test catches all, \balloonText-test always the NoteHead
  %%   (as well as the default \balloonGrobText and \balloonText)
  \balloonGrobText-test StringNumber #'(1 . 1) "I'm a string number"
  <
e'\2 -\balloonText-test StringNumber #'(1 . 2) "Fail for StringNumber"
g'\4
  >
}


Thanks,
  Harm

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

\balloonText applied to single note errors with symbol->string ??

[Thomas Morley]

Hi,

the code below

\layout { \context { \Voice \consists "Balloon_engraver" } }
{ c'-\balloonText #'(2 . 0) \markup { "1" } }

returns (in 2.21.0):
ERROR: In procedure symbol->string:
ERROR: Wrong type argument in position 1 (expecting symbol): ()

2.18.2 gives a more useful message:
/home/hermann/lilypond/usr/share/lilypond/current/scm/lily-library.scm:242:8:
In procedure symbol->string in expression (process-procedure book
paper ...):
/home/hermann/lilypond/usr/share/lilypond/current/scm/lily-library.scm:242:8:
Wrong type argument in position 1 (expecting symbol): ()

Though, I've no clue where symbol->string comes into the game...

Ofcourse the NR recommends to use balloonText _inside_ of chords, and
indeed the problem goes away, wrapping the note in an event-chord.
But shouldn't it work as a postevent to a single note, too??


Btw, it's present in all tested versions down to 2.12.3

Cheers,
  Harm

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

Re: Non default tuplet error with 2.21

[Thomas Morley]

Am Fr., 20. Sept. 2019 um 02:19 Uhr schrieb Andrew Bernard
:
>
> Using 2.21 from git, the non-default tuplet example in the NR throws an
> error.
>
>
> \relative c'' {
>\once \override TupletNumber.text =
>  #(tuplet-number::non-default-tuplet-denominator-text 7)
>\tuplet 3/2  { c4. c4. c4. c4. }
>\once \override TupletNumber.text =
>  #(tuplet-number::non-default-tuplet-fraction-text 12 7)
>\tuplet 3/2  { c4. c4. c4. c4. }
>\once \override TupletNumber.text =
>  #(tuplet-number::append-note-wrapper
>(tuplet-number::non-default-tuplet-fraction-text 12 7) "8")
>\tuplet 3/2  { c4. c4. c4. c4. }
>\once \override TupletNumber.text =
>  #(tuplet-number::append-note-wrapper
>tuplet-number::calc-denominator-text "4")
>\tuplet 3/2  { c8 c8 c8 c8 c8 c8 }
>\once \override TupletNumber.text =
>  #(tuplet-number::append-note-wrapper
>tuplet-number::calc-fraction-text "4")
>\tuplet 3/2  { c8 c8 c8 c8 c8 c8 }
>\once \override TupletNumber.text =
>  #(tuplet-number::fraction-with-notes "4." "8")
>\tuplet 3/2  { c4. c4. c4. c4. }
>\once \override TupletNumber.text =
>  #(tuplet-number::non-default-fraction-with-notes 12 "8" 4 "4")
>\tuplet 3/2  { c4. c4. c4. c4. }
> }
>
> Interpreting music...
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> fatal error: make-note-markup: Invalid argument in position 1. Expect:
> duration, found: "8".
> Exited with return code 1.
>
>
> The code compiles fine in 2.19.83.
>
> Has the syntax changed?
>
>
> Andrew

Yep, \note espects a duration in 2.21.0:
\markup \note {4..} #UP
See the example in the markup-command's definition or the 2.21.-docs
(if you build them)
2.21.-convert-ly should cope with it.

Cheers,
  Harm

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

Re: break-visibility of KeySignature and KeyCancellation inconsistent

[Thomas Morley]

Am Sa., 17. Aug. 2019 um 18:17 Uhr schrieb Malte Meyn :
>
> Hi list,
>
> I wonder why there is two different ways to change the break-visibility
> of KeySignature and KeyCancellation grobs:
>
> %%%
> \version "2.21.0"
>
> {
>\set Staff.explicitKeySignatureVisibility = #end-of-line-invisible
>\override Staff.KeyCancellation.break-visibility = #end-of-line-invisible
>\key g \major
>R1
>\break \key f \major
>R
> }
> %%%
>
> \overriding KeySignature.break-visibility has no effect and there is no
> context property explicitKeyCancellationVisibility, however there is
> printKeyCancellation which is a boolean, not a boolean vector. That’s
> inconsistent and I cannot imagine why this would be necessary. I
> searched the tracker and the mailing list archives but I couldn’t find
> any hints … Should we consider this a bug?
>
> Cheers,
> Malte

Hi Malte,

I stumbled across it as well.
Though I seem to remember there was a reason for it, but can't find a
link to the discussion anymore.
So I even can't say whether it was a _good_ reason...

Sorry to be of not more help,
  Harm

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

Re: Lilypond 2.19.83 - ragged-right problem

[Thomas Morley]

Am Mo., 1. Juli 2019 um 17:54 Uhr schrieb John McWilliam
:
>
> Windows 10
> Lilypond 2.19.83
>
> Hi,
> I have written a bagpipe tune (25th_kosbs) which has four parts, each 
> with a repeat which should start on a new line. The format is A4 in lanscape 
> mode. I cannot get this to work and at the same time maintain a flush right 
> margin. Suggestions please
>
> John McWilliam
>
> PS I know this should have gone into the Lilypond-User list but am waiting 
> for my registration to go through the system.
>
> Sent from Mail for Windows 10

Hi John,

please only post to the bug-list, if you are sure you noticed a bug.
Even if you're sure about the bug, it may be none, people here can
sort it out ...

Never ask for usage-problems here, but on the user-list.
If you ask there please reduce your score to a minimal working example
exposing the problem.
Please double check its a _minimal_ _working_ example.

The three files you posted are far from minimal, so much code,
unrelated settings, unrelated comments etc etc
I can't imagine how you are not completely confused by your own code.
P.e. you have settings for the paper-size at toplevel, as well as in
\paper of an included file
And it even not compiles, your \include "..." is spelled wrongly.

Additionally, with a minimal working example (MWE) you probably would
have seen the problem yourself.
Such a MWE could be:

\version "2.19.82"
#(set-default-paper-size "a4" 'landscape)
{ R1 }

Then you could have looked into the NR's index:
http://lilypond.org/doc/v2.19/Documentation/notation/lilypond-index
looking for landscape leads to
http://lilypond.org/doc/v2.19/Documentation/notation/paper-size-and-automatic-scaling#index-paper-size_002c-landscape
Which demonstrates all about 'landscape.

I don't understand the ragged-right problem, probably because I'm not
a native speaker.
If it persists after solving the 'landscape thingy reask on user-list.


-Harm

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

Re: Request: Print actual number of pages after compiling

[Thomas Morley]

Am Mo., 10. Juni 2019 um 00:07 Uhr schrieb Christopher Heckman
:
>
> This isn't so much a bug as an annoyance.
>
> Frequently when I'm typesetting music, I'm trying to resize the output
> to fit on the minimum number of pages (while remaining readable, of
> course). When Lilypond is compiling, one of its messages is "Fitting
> music on 1 or 2 pages..." Obviously, in this situation, I want to know
> the exact number of pages without re-opening the .pdf file. Could
> someone add a one-line statement to print out the actual number of
> pages, near the "Success: compilation successfully completed" message?
>
> --- Christopher Heckman

A ly-file can contain multiple books or bookparts or a mix of it.
I don't know how to cover every case, but for the case of a single
book(part) you could do:

\paper {
  #(define (page-post-process layout pages)
(format #t "\n\tCurrent book-(part) has ~a pages" (length pages)))
}

\score { { R1 \pageBreak R } }

Cheers,
  Harm

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

Re: Clef changes, while NoteNames-context is active

[Thomas Morley]

Am Di., 14. Mai 2019 um 11:15 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Hi,
> >
> > consider the following snippet:
> >
> > musI = { \clef soprano e'4 }
> > musII = { \clef alto c'4 }
> >
> > <<
> >   \new Staff \musI
> >   \new Staff \musII
> >   \new NoteNames \musII
> >>>
> >
> > As long as the NoteNames-context is not commented/deleted the first
> > unrelated Staff changes it's clef.
> >
> > Any insights?
>
> The NoteNames context does not belong to a Staff.  \clef effectively
> contains a \context Staff setting which is consequently picked up by the
> next Staff in its vicinity.
>
> Should NoteNames be aliased to Staff in order to pick up (and usually
> ignore) this kind of setting?
>
> Possibly.  It does have an Axis_group_engraver so it is Staff-like in
> several ways.
>
> --
> David Kastrup

I'd vote for it. Can't see any disadvantage.
Probably one would need to have a closer look at spacing-settings of
VerticalAxisGroup, though, eventually they need to be modified.
I'll give it a try as soon I can spare some time.

For now a workaround is:

\layout {
  \context {
\NoteNames
\alias Staff
  }
}

This one doesn't work:
\new NoteNames \with { \alias Staff } ...
Is this expected?


Btw, same happens for Lyrics, if I try to enter \clef there. Ofcourse
I don't expect someone to do this other than by accident.



Thanks,
  Harm

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

Clef changes, while NoteNames-context is active

[Thomas Morley]

Hi,

consider the following snippet:

musI = { \clef soprano e'4 }
musII = { \clef alto c'4 }

<<
  \new Staff \musI
  \new Staff \musII
  \new NoteNames \musII
>>

As long as the NoteNames-context is not commented/deleted the first
unrelated Staff changes it's clef.

Any insights?

Present at least since 2.12.3

Cheers,
  Harm

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

Re: Percent repeats in lyrics causes error in 2.18.2

[Thomas Morley]

Am Mi., 8. Mai 2019 um 01:11 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:
>
> > Am Mi., 8. Mai 2019 um 00:25 Uhr schrieb David Kastrup :
> >>
> >> Thomas Morley  writes:
> >
> >> > I tried a quick adhoc coding.
> >> >
> >> > Works with \unfoldRepeats, regrettable prints nothing without it.
> >> > I'd expect to see it at least one time printed without \unfoldRepeats.
> >> >
> >> > Anyway, here my coding so far, what do I miss?
> >>
> >> An iterator creator ?
> >
> > I've exactly zero experience with this topic.
> >
> > I tried to get some more info, we have:
> > http://lilypond.org/doc/v2.19/Documentation/contributor-big-page.html#iterator-tutorial
> >
> > Which reads:
> > "
> > 10.10 Iterator tutorial
> > TODO – this is a placeholder for a tutorial on iterators
> > Iterators are routines written in C++ that process music expressions
> > and sent the music events to the appropriate engravers and/or
> > performers.
> > See a short example discussing iterators and their duties in
> > Articulations on EventChord.
> > "
> > Not that enlightening... Admittedly there a some more hints spread over CG.
> > Though, right now I'm not even sure, if it's possible in scheme at all.
> >
> > Is there any scheme-example?
>
> In scm/define-music-types.scm I read
>
> (RepeatedMusic
>  . ((description . "Repeat music in different ways.")
> (types . (repeated-music))
> ))
>
> so it would appear that the default iterator should actually work as
> intended if you fill the expression in the usual way (element containing
> the main stuff, elements containing the alternatives).

Not sure, if this is the case yet.
I'll check tomorrow evening (hopefully)
Too late ...

Good night and thanks,
  Harm

> Unless
> RepeatedMusic is not actually being used.  No idea.
>
> --
> David Kastrup

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

Re: Percent repeats in lyrics causes error in 2.18.2

[Thomas Morley]

Am Mi., 8. Mai 2019 um 00:25 Uhr schrieb David Kastrup :
>
> Thomas Morley  writes:

> > I tried a quick adhoc coding.
> >
> > Works with \unfoldRepeats, regrettable prints nothing without it.
> > I'd expect to see it at least one time printed without \unfoldRepeats.
> >
> > Anyway, here my coding so far, what do I miss?
>
> An iterator creator ?

I've exactly zero experience with this topic.

I tried to get some more info, we have:
http://lilypond.org/doc/v2.19/Documentation/contributor-big-page.html#iterator-tutorial

Which reads:
"
10.10 Iterator tutorial
TODO – this is a placeholder for a tutorial on iterators
Iterators are routines written in C++ that process music expressions
and sent the music events to the appropriate engravers and/or
performers.
See a short example discussing iterators and their duties in
Articulations on EventChord.
"
Not that enlightening... Admittedly there a some more hints spread over CG.
Though, right now I'm not even sure, if it's possible in scheme at all.

Is there any scheme-example?

Cheers,
  Harm

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

Re: Percent repeats in lyrics causes error in 2.18.2

[Thomas Morley]

Am Di., 7. Mai 2019 um 23:20 Uhr schrieb David Kastrup :

> >> > It sounded to me like what desired was more like \repeat fold , namely
> >> > something that doesn't do anything except be subject to \repeat unfold

> >> More like subject to \unfoldRepeats .  Sorry, got confused.

> When used with appropriate markup, it could be used for creating dal
> segno al coda structures behaving reasonably sensibly in Midi.

I tried a quick adhoc coding.

Works with \unfoldRepeats, regrettable prints nothing without it.
I'd expect to see it at least one time printed without \unfoldRepeats.

Anyway, here my coding so far, what do I miss?

#(define-event-class 'folded-music-event 'music-event)

#(define folded-music-types
  '(
(FoldedMusicEvent
 . ((description . "DOCME")
(types . (folded-music-event repeated-music))
))
))

#(set!
  folded-music-types
  (map (lambda (x)
 (set-object-property! (car x)
   'music-description
   (cdr (assq 'description (cdr x
 (let ((lst (cdr x)))
   (set! lst (assoc-set! lst 'name (car x)))
   (set! lst (assq-remove! lst 'description))
   (hashq-set! music-name-to-property-table (car x) lst)
   (cons (car x) lst)))
   folded-music-types))

#(set! music-descriptions
   (append folded-music-types music-descriptions))

#(set! music-descriptions
   (sort music-descriptions alist>

%% works with unfoldRepeats:
\unfoldRepeats \mus

%% not working:
\mus


Cheers,
  Harm

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

Re: Percent repeats in lyrics causes error in 2.18.2

[Thomas Morley]

Am Di., 7. Mai 2019 um 23:00 Uhr schrieb David Kastrup :
>
> David Kastrup  writes:
>
> > Thomas Morley  writes:
> >
> >> Am Di., 7. Mai 2019 um 14:15 Uhr schrieb :
> >
> > [...]
> >
> >> Though, it's the first time ever I've heard somebody wants to use
> >> \repeat percent in Lyrics...
> >
> > It sounded to me like what desired was more like \repeat fold , namely
> > something that doesn't do anything except be subject to \repeat unfold
> > .
>
> More like subject to \unfoldRepeats .  Sorry, got confused.
>
> >
> > Does that seem like a reasonably useful name/request or is that too
> > esoteric?
>
> --
> David Kastrup

You mean something like \repeat volta without repeat-bar-lines or
similar to the visibility of compressed and uncomprssed
MultiMeasureRests?
Sounds nice and "\repeat fold" reasonable, imho.

Cheers,
  Harm

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

Re: Percent repeats in lyrics causes error in 2.18.2

[Thomas Morley]

Am Di., 7. Mai 2019 um 14:15 Uhr schrieb :
>
> I've entered some repeated music and folded it with 'repeat percent' in
> the score.
> However, lyrics doesn't understand the repetition, so adding
> \unfoldRepeats caused messing between music and lyrics.
> I've added same 'repeat percent' to the lyrics pieces then. It works
> perfectly when unfoldRepeats is active!
>
> But happend when I removed 'unfoldRepeats'. Piece of percents
> immediately crashed lilypond internals with error:
>
> Interpreting
> music...[8][16][24][32][40][48][56][64]/usr/share/lilypond/2.18.2/scm/m
> usic-functions.scm:319:21: In procedure car in expression (car durs):
> /usr/share/lilypond/2.18.2/scm/music-functions.scm:319:21: Wrong type
> (expecting pair): ()
>
> Wrong fragment caused error looks like:
> %\lyricmode {
> ...
> \repeat percent 2 { Di -- es, di -- es i -- ræ. }
> ...
> %}
>
> The objective here is that it would be good to have a kind of repeat
> (for lyrics) which just show the content once being 'compressed', but
> repeat it when being unfolded, without any other side effects.
> Volta repeat doesn't work, because it causes repetition marks to be
> injected into the score (yes, even being applied just to the lyrics; it
> is maybe another bug).
> Percent repeat also doesn't work, but causes even worse stopper error,
> then just unusual output.

Hi,

thanks for your report.
Though, it's the first time ever I've heard somebody wants to use
\repeat percent in Lyrics...

Anyway, the error occurs, because `calc-repeat-slash-count´ from
music-functions.scm doesn't listen to LyricEvent.
`calc-repeat-slash-count´ is read then in `lily-imports.cc´.

A fix for the crash would be to add LyricEvent in `calc-repeat-slash-count´.
Ofcourse, the slash wouldn't be printed without consisting the
relevant engravers to Lyrics.

No idea whether we should go for it.
Opinions?

For now a brute-force workaround:

#(define (my-calc-repeat-slash-count music)
  "Given the child-list @var{music} in @code{PercentRepeatMusic},
calculate the number of slashes based on the durations.  Returns @code{0}
if durations in @var{music} vary, allowing slash beats and double-percent
beats to be distinguished."
  (let* ((durs (map duration-of-note
(extract-named-music
  music
  '(EventChord NoteEvent LyricEvent RestEvent SkipEvent
 (first-dur (car durs)))

(if (every (lambda (d) (equal? d first-dur)) durs)
(max (- (ly:duration-log first-dur) 2) 1)
0)))

#(module-set!
  (resolve-module '(lily))
  'calc-repeat-slash-count
  (module-ref (current-module) 'my-calc-repeat-slash-count))

%\unfoldRepeats
<<
  \new Staff { \repeat percent 6 b2 c' }
  \new Lyrics
\with {
  \consists "Percent_repeat_engraver"
  \consists "Double_percent_repeat_engraver"
  \consists "Slash_repeat_engraver"
  \override RepeatSlash.Y-offset = 0.8
}
\lyricmode {
  \repeat percent 6 foo2
  bar
}
>>

Cheers,
  Harm

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

Re: header properties not visible within score

[Thomas Morley]

Am Mi., 1. Mai 2019 um 09:59 Uhr schrieb Markus Rother :
>
> % Embedding \fromproperty in a \score is not working (at least not) for
> header properties.
> % If header scope is hidden by design, how can I achieve the following?
> % Many thanks and best regards, Markus
> \book {
>   \paper {
> indent = 0\mm
> scoreTitleMarkup = \markup {
>   \fromproperty #'header:piece % works as expected
>   \score {
> { s^\markup { "FOO" \fromproperty #'header:piece "BAR" } } %
> property not visible
> \layout {}
>   }
> }
>   }
>   \score {
> { s1 }
> \header {
>   piece = "MENUET"
> }
>   }
>   \score {
> { s1 }
> \header {
>   piece = "RONDEAU"
> }
>   }
> }

Hi Markus,

thanks for your report.

As far as I understand things, \fromproperty can't be used
successfully outside from \paper and/or in common markup.
(score-markup is such a common markup.)

Thus, below fails to print "MY-TITLE"
\header { title = "MY-TITLE" }
\markup { something \fromproperty #'header:title something }

There is
http://lsr.di.unimi.it/LSR/Item?id=467
which has access to $defaultheader, thus below works
\header { title = "MY-TITLE" }
\markup { something \markupWithHeader \fromproperty #'header:title something }
(code for markupWithHeader is not copied here, take it from the linked
LSR-snippet)
As soon as you wrap \book around above it fails again, because \header
in book is not the $defaultheader.
There's a TODO in said snippet:
";; TODO: If we are inside a score, add the score's local header block, too!"
I don't know how, though.

So yes, it would be nice to have a method to access book/score-header
like the LSR-snippet does for $defaultheader.
Not sure if possible at all...

For now, I thought about how to find a work-around for your use-case...
Why do you need a score _in_ scoreTitleMarkup? Likely for a short
excerpt or hints about scordatura or similiar.
But is it really necessary to code the piece-name as a common
TextScript _inside_ this score?
Probably you can do something like below. Yeah, more manual work, I know ...

\book {
  \paper {
indent = 0\mm
scoreTitleMarkup = \markup \column {
  \line { \hspace #20  "FOO" \fromproperty #'header:piece "BAR" }
  \fromproperty #'header:sample
  \fromproperty #'header:piece
}
  }
  \score {
{ s1 }
\header {
  piece = "MENUET"
  sample = \markup \score { cis'1 \layout { indent = 30 } }
}
  }
  \score {
{ s1 }
\header {
  piece = "RONDEAU"
  sample = \markup \score { d'1 \layout { indent = 30 } }
}
  }
}


Cheers,
  Harm

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

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

[Thomas Morley]

Hi Florian,

thanks for your report.

Am So., 28. Apr. 2019 um 17:31 Uhr schrieb Florian :
>
> Hi,
> Third attempt via nabble.com :)

A remark:
Ther are still no _attachments_.
You do all inline, with the consequence making it impossible for me to
simply download the musicxml-file.
In the end I used wget.

> 1. The musicxml file  test.musicxml
> 
> 2. The generated ly file  test.ly
> 
> 3. Screenshot from generated svg :
>
> 
>
> And there’s one more thing (maybe a second bug?) : the first stave seems to
> have a second measure which is not in the musicxml file! Should I post
> another bug report for that?

I can confirm the problem for 2.18.2, but looks fixed for 2.19.82 and
2.21.0 from master.
Thus no further action needed here.

I'd recommend to upgrade to recent devel-version, 2.19.83, it's a
prerelease for the upcoming new stable, 2.20.0, anyway.

Cheers,
  Harm

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

Re: [musicxml2ly] duplicated dynamics and hairpins when using multiple voices

[Thomas Morley]

Am So., 28. Apr. 2019 um 14:39 Uhr schrieb Florian Grundig
:
>
> Hi,
>
> I don’t know why the first time sending files to the mailing list didn’t work 
> - here’e my second attempt - I attached four files:
> 1. The musicxml file
> 2. The generated ly file
> 3,4 The generated svg and pdf file

Still no files.

Neither directly, nor in the archives:
http://lists.gnu.org/archive/html/bug-lilypond/2019-04/msg00039.html
http://lilypond.1069038.n5.nabble.com/musicxml2ly-duplicated-dynamics-and-hairpins-when-using-multiple-voices-td221613.html

Sorry,
  Harm

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

Re: bug-lilypond Digest, Vol 197, Issue 11

[Thomas Morley]

Am Fr., 26. Apr. 2019 um 11:10 Uhr schrieb Thomas Morley
:

> Can't dive deeper into it right now. I'll open a tracker issue in
> order it will not be forgotten.

https://sourceforge.net/p/testlilyissues/issues/5516/

Cheers,
  Harm

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

Re: bug-lilypond Digest, Vol 197, Issue 11

[Thomas Morley]

Am Fr., 26. Apr. 2019 um 10:22 Uhr schrieb David Kastrup :
>
> Federico Bruni  writes:
>
> > Il giorno gio 25 apr 2019 alle 23:40, Thomas Morley
> >  ha scritto:
> >> Probably one could think of making `\tabChordRepeats´ the default
> >> for TabStaff.
> >>
> >> Opinions?
> >
> > I'm in favour  of making it the default for TabStaff.
>
> How?  (Automatic) expansion of q happens at scorification time.  There
> are no contexts at that time and the context definitions may still
> change after scorification.
>
> You'd have to move some of the repeat chord expansion business right
> into iteration and engraving.
>
> --
> David Kastrup

In my naivity I thought adding `\tabChordRepeats´ to TabStaff's layout
would work.
I should have read up how `\tabChordRepeats´ is defined and how it works.
Basically a music-function returning music.
Thus the naive approach will not work.
Can't dive deeper into it right now. I'll open a tracker issue in
order it will not be forgotten.

Cheers,
  Harm

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

Re: bug-lilypond Digest, Vol 197, Issue 11

[Thomas Morley]

Am Do., 25. Apr. 2019 um 22:35 Uhr schrieb Christopher Heckman
:
>
> On Thu, Apr 25, 2019 at 9:05 AM  wrote:
> >
> > Am Mi., 24. Apr. 2019 um 23:24 Uhr schrieb Christopher Heckman
> > :
> > >
> > > I searched for this at the archives, but maybe I didn't look in the right 
> > > place.
> > >
> > > The title is pretty self-expanatory. If the pitch e is normally played
> > > on the 5th string of a guitar (after transposition), then
> > >
> > > \new TabStaff {  q }
> > >
> > > will show e played on the 6th string and then on the 5th string, even
> > > if you put a tie after .
> > >
> > > (This is Lilypond version 2.18.)
> > >
> > > --- Christopher Carl Heckman
> >
> > Hi,
> >
> > thanks for your report, though, see
> > http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#index-_005cchordRepeats-1
> > for
> > \tabChordRepeats
> >
> > Thus no bug.
> >
> >
> > Cheers,
> >   Harm
>
> Fair enough. But shouldn't keeping the fingering information be the
> default? Especially if the chord is an immediate repeat?
>
> --- Christopher Carl Heckman

Well, in general `q´ shouldn't, imho.
Probably one could think of making `\tabChordRepeats´ the default for TabStaff.

Opinions?

Cheers,
  Harm

P.S.
Please always try to reply to the original mail not a digest, it
breaks threads in the archives.
Thanks.

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

Re: Bug: q doesn't keep fingerings in TabStaff context

[Thomas Morley]

Am Mi., 24. Apr. 2019 um 23:24 Uhr schrieb Christopher Heckman
:
>
> I searched for this at the archives, but maybe I didn't look in the right 
> place.
>
> The title is pretty self-expanatory. If the pitch e is normally played
> on the 5th string of a guitar (after transposition), then
>
> \new TabStaff {  q }
>
> will show e played on the 6th string and then on the 5th string, even
> if you put a tie after .
>
> (This is Lilypond version 2.18.)
>
> --- Christopher Carl Heckman

Hi,

thanks for your report, though, see
http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#index-_005cchordRepeats-1
for
\tabChordRepeats

Thus no bug.


Cheers,
  Harm

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

Re: rest + fermata

[Thomas Morley]

Am So., 14. Apr. 2019 um 13:38 Uhr schrieb Martin Tarenskeen
:
>
>
> Hi,
>
> This is strange:
>
> %%% start of tiny example
>
> \version "2.19.83"
> {
>r1\fermata
>R1\fermata
> }
>
> %%% end of tiny example
>
> r1\fermata works fine, R1\fermata doesn't. No fermata sign is printed.
> Is this a bug?

Hi,

see
http://lilypond.org/doc/v2.19/Documentation/notation/writing-rests#index-_005cfermataMarkup-1
leading to:
{
   r1\fermata
   R1\fermataMarkup
}

No bug ;)

Cheers,
  Harm

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

Re: Clarinet fingerings not working

[Thomas Morley]

Am Mi., 10. Apr. 2019 um 19:48 Uhr schrieb Karim Haddad :
>
> Sorry,
>
> Find out the problem...
> First the snippet number (my bad !) is : ttp://lsr.di.unimi.it/LSR/Item?id=615
>
> Well after this, there is a typo error in the core of the define's section :
>
> the define twelfthKey-str should be :
>
> #(define twelfthKey-str (string-append
> " -1.1 0.8 moveto /("
> (ly:font-config-get-font-file "Emmentaler")
> "/) findfont 1 scalefont setfont
> (12) show"))
>
> A missing backslash before the closed parenthesis...
> However, it is strange that this gets through version 2.18 and not the 
> 2.19.83 (and yes i have tested it with this last version).

I changed the snippet following your suggestion. Though, I've no clue
about clarinet ...

However, the not corrected snippet fails with a similar gs-error on my
machine using 2.18.2:
`(gs -q -dSAFER -dDEVICEWIDTHPOINTS=737.01 -dDEVICEHEIGHTPOINTS=226.77
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite
-sOutputFile=./atest-92.pdf -c.setpdfwrite -fatest-92.ps)' failed
(256)

No clue why it works inside LSR. As far as I know LSR is always
running in jail, this may have an impact here.
Or probably: my 2.18.2 uses Ghostscript 8.70 maybe LSR is different...

Cheers,
  Harm

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

Re: Barcheck warning with independent meters and midi

[Thomas Morley]

Am So., 31. März 2019 um 01:06 Uhr schrieb N Trocado :
>
> > You move engravers, this has _no_ impact on midi.
> > So no bug in the source code.
> This is correct. Thank you for your help and sorry for the false bug report.
> NT

You're welcome.
Midi is underrepresented generally. For example, we have the
possibility to code custom-engravers but there is no possibility I
know of to do similar for midi.
And the docs are not very verbose either.

Cheers,
  Harm

P.S.
No need to apologize for sending a bug-report, which turns out to be no bug.
Better than the opposite: When bugs are not reported than a fix is
very unlikely...

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

Re: Barcheck warning with independent meters and midi

[Thomas Morley]

Am Sa., 30. März 2019 um 20:20 Uhr schrieb N Trocado :
>
> The following produces a barcheck warning:
>
> \version "2.19.82"
>
> \layout {
>   \context {
> \Score
> \remove "Timing_translator"
> \remove "Default_bar_line_engraver"
>   }
>   \context {
> \Staff
> \consists "Timing_translator"
> \consists "Default_bar_line_engraver"
>   }
> }
>
> \score {
>   <<
> \new Staff {
>   \time 4/4
>   a1 |
> }
> \new Staff {
>   \time 7/8
>   a4. a4 a |
> }
>   >>
>   \layout { }
>   \midi { }
> }
>
> -> 21:10: warning: barcheck failed at: 1/8
>   a1
>  |
>
> There's no warning if I comment out the midi block.
> Despite the warning, the midi file plays correctly, following the time 
> signature of the lowest staff.
> AFAIK the midi standard may not allow for independent meters in different 
> channels. If this is the reason for the barcheck warning, maybe a more 
> specific (single) message would be appropriate? It took me a long time to 
> find out why the barcheck warnings were being produced...

You move engravers, this has _no_ impact on midi.
Instead you should do:

\score {
  <<
\new Staff {
  \time 4/4
  c'1 |
}
\new Staff {
  \time 7/8
  a4. a4 a |
}
  >>
  \layout {
\context {
  \Score
  \remove "Timing_translator"
  \remove "Default_bar_line_engraver"
}
\context {
  \Staff
  \consists "Timing_translator"
  \consists "Default_bar_line_engraver"
}
  }
  \midi {
\context {
  \Score
  \remove "Timing_translator"
}
\context {
  \Staff
  \consists "Timing_translator"
}
  }
}

So no bug in the source code.
Admittedly midi is highly underdocumented.
Which is the real problem here ...


Cheers,
  Harm

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

Re: Dispositioned notehead in chord when staffsize=14 and clef=bass

[Thomas Morley]

Am So., 24. März 2019 um 14:25 Uhr schrieb Martin Tarenskeen
:
>
>
> Hi,
>
> A bumped into a strange bug with a dispositioned notehead.
>
> See attached example "staffsize14.ly" and "staffsize14.pdf" output.
> Using lilypond 2.19.82 on Linux Fedora.
>
> What's happening here?

Looks like
#5303 layout-set-staff-space confuses chord note head placement in a
certain situation
https://sourceforge.net/p/testlilyissues/issues/5303/

Some discussion here:
http://lists.gnu.org/archive/html/lilypond-user/2016-10/msg00263.html

Sorry to be of not more help,
  Harm

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

Re: Lilypond crash related to tuplets

[Thomas Morley]

Am Sa., 23. März 2019 um 21:41 Uhr schrieb Aaron Hill
:
>
> On 2019-03-23 6:46 am, Andrew Bernard wrote:
> > What calls calc_x_offset for Tuplet Number?
>
> This likely may be coming from Scheme.  If you look at the Internals
> reference, you will see that the X-offset property for TupletNumber is
> by default set to ly:tuplet-number::calc-x-offset.
>
> That means that if you were to call (ly:grob-property grob 'X-offset)
> against a TupletNumber, it will end up consulting the specified
> procedure which is in this case implemented in C++.
>
> > Any assistance would be greatly appreciated. My string quartet is going
> > nowhere but I am learning a lot about debugging lilypond.
>
> Are you able to share your .ly that exhibits this behavior?  Without a
> failing case on my side, I am left to only guess what might be
> triggering the behavior.

I'd like to second.

> That said, I have found a few things in the
> code that *could* be problematic.
>
> For instance, would you try adding this to your project:
>
> 
>\override TupletBracket.X-positions = #(lambda (grob)
>  (let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
>(if (> (car xpos) (cdr xpos))
>  (format #t "\nwarning: Inverted X-positions ~a" xpos))

We have `ordered-cons´ for:

>(cons (min (car xpos) (cdr xpos)) (max (car xpos) (cdr xpos)
> 
>
> This will emit a warning when it detects that the calculated X-positions
> are inverted, but it also patches the issue by making the interval
> valid.
>
> -- Aaron Hill

It's worth checking LigatureBracket as well, they share the same
procedures for stencil/X-offset.
HorizontalBracket probably too (same procedure for
`connect-to-neighbor´), although this is unlikely to trigger the
problem, imho.

Cheers,
  Harm

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

Re: Bug: restarting staff destroys DynamicLineSpanner.staff-padding after line break

[Thomas Morley]

Am Mo., 11. März 2019 um 23:01 Uhr schrieb Trevor Bača :
>
> On Thu, Mar 7, 2019 at 2:14 AM David Kastrup  wrote:

> > It's probably not the only spanner
> > unprepared to span pieces of interrupted staff symbols.
> >
>
> Isn't this still a bug?

In the sense David pointed out.

> Or, rather a gap in system functionality for which
> no workaround exists?

Here an attempt for a workaround.
It's not tested beyond the given example, up to you ;)

\new Staff {
  \override DynamicLineSpanner.after-line-breaking =
#(lambda (grob)
   (let* ((staffs
(filter
  (lambda (e) (grob::has-interface e 'staff-symbol-interface))
  (ly:grob-array->list
(ly:grob-object (ly:grob-parent grob Y) 'elements)

 (for-each
   (lambda (staff) (set! (ly:grob-object grob 'staff-symbol) staff))
   staffs)

 ;(format #t"\nstaff-padding: ~a\nY-offset: ~a\nstaff-symbol ~a\n"
 ;  (ly:grob-property grob 'staff-padding)
 ;  (ly:grob-property grob 'Y-offset)
 ;  (ly:grob-object grob 'staff-symbol))
   ))

\override DynamicLineSpanner.staff-padding = 10
c'1\p\< c'1 c'1
\break

c'1 \stopStaff \startStaff c'1 c'1
\break

c'1 c'1 c'1
\break

c'1 c'1 c'1\f
}

\paper {
indent = 0
ragged-right = ##t
}

Cheers,
  Harm

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

Re: Lilypond 2.19.82 with multiple voices seems to fail

[Thomas Morley]

Am So., 3. März 2019 um 08:18 Uhr schrieb Andrew Bernard
:
>
> HI James,
>
> This elusive defect comes up a lot. See the User archives. I have seen in
> on Linux also,

Yep, me too. Though I'm surprised to see the problem on this fairly short score.

###

Anyway, what _is_ the problem?

As far as I can tell, creating lots and lots of new contexts
overcharges lilypond. With some OS earlier, with Linux obviously
later.
Lots and lots of contexts may be created by excessive use of << \\ >>
or (rarely) by some user-defined procedure.

Look at this short example, where I coded an engraver to display
contexts-info, duplicated contexts are discarded!

#(define (my-engraver ctx)
  (let ((new-contexts '()))
 `(
   (listeners
(AnnounceNewContext
  .
  ,(lambda (engraver event)
(set! new-contexts (cons event new-contexts)
   (finalize
.
,(lambda (trans)
  (let ((ctx-type-id
  (map
(lambda (c)
  (let ((creator (ly:event-property c 'creator)))
(list
  (ly:event-property creator 'type)
  (ly:event-property creator 'id
(delete-duplicates (reverse new-contexts)
  (format #t
"\nInside this score ~a new contexts are created. Type and id are:\n~y"
(length ctx-type-id)
ctx-type-id)))

\score {
  {
<< c''1 \\ c' >>
R1
<< d''1 \\ d' >>
  }
  \layout {
\context {
  \Score
  \consists \my-engraver
}
  }
}

It returns:

Inside this score 6 new contexts are created. Type and id are:
((Staff "")
 (Voice "1")
 (Voice "2")
 (Voice "")
 (Voice "1")
 (Voice "2"))

And this music is close to minimal !!!

Applying the same engraver to the OP's original code returns:

Inside this score 56 new contexts are created. Type and id are:
((PianoStaff "")
 (Staff "upper")
 (Dynamics "dyn")
 (Staff "lower")
 (Voice "")
 (Voice "")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2")
 (Voice "1")
 (Voice "2"))

###

What does the docs say?

From
http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#single_002dstaff-polyphony
"
The double backslash construct

The << {…} \\ {…} >> construct, where the two (or more) expressions
are separated by double backslashes, behaves differently to the
similar construct without the double backslashes: all the expressions
within this construct are assigned to new Voice contexts. These new
Voice contexts are created implicitly and are given the fixed names
"1", "2", etc.
[...]
This syntax can be used where it does not matter that temporary voices
are created and then discarded.
[...]
In all but the simplest works it is advisable to create explicit Voice
contexts as explained in Contexts and engravers and Explicitly
instantiating voices.
"

Imho, it's all there:
<< \\ >> creates _new_ Voices.
Use it where it _does not matter_
Recommended are explicit Voices.

Can it be improved?
Not sure. Opinions?



Suggestions/sollutions

(1) Use explicit Voices, meaning enter the entire music of a Voice in
a (named) Voice, kept alive, and finally join it in a Staff in \score
I'm aware some people want to keep measures (with all Voices)
together, << \\ >> is a bad way to do so, though.
Instead one could use:

(2) \parallelMusic
See:
http://lilypond.org/doc/v2.19/Documentation/notation/multiple-voices#writing-music-in-parallel

(3)
If one really, really wants to keep the << \\ >> construct a method
could be to explicitely create Voices named "1" and "2" and keep them
alive.
In the OP's score that would make for this \score:

\score {
  \new PianoStaff \with { instrumentName = #"Piano" }
  <<
\new Staff = "upper"
<<
\new Voice = "1" { s2.*29 s1*25 }
\new Voice = "2" { s2.*29 s1*25 }
\rhnotes
>>
\new Dynamics = "dyn" \dynam
\new Staff = "lower"
<<
\new Voice = "1"{ s2.*29 s1*25 }
\new Voice = "2"{ s2.*29 s1*25 }
\lhnotes
>>
  >>
  \layout {
\context {
  \Score
  %\consists \my-engraver
}
  }
  \midi { }
}

Applying my engraver returns:
Inside this score 12 new contexts are created. Type and id are:
((PianoStaff "")
 (Staff "upper")
 (Voice "1")
 (Voice "2")
 (Dynamics "dyn")
 (Staff "lower")
 (Voice "1")
 (Voice "2")
 (Voice "")
 

Re: Lilypond 2.19.82 with multiple voices seems to fail

[Thomas Morley]

Am Sa., 2. März 2019 um 23:58 Uhr schrieb DaveAtkinson :
>
> Hi LilyPond folks,
>
> I think I've found a bug in the above version of LilyPond and I can't find
> another report of it, so I thought I'd report it. Apologies if it's a known
> issue.
>
> I'm trying to produce a score of a piano accompaniment in which I'm making
> extensive use of multiple voices in a bar. These seem to work at first but
> then start failing. By failing, I mean lilypond quits after the
> "interpreting music" message with no errors, no log, and no output. The
> score is quite long, so I've uploaded it. The failing lines are commented
> out with the word 'fail' inside the comment (and a line of spaces outside
> the comment to keep the staves lining up). There are 3 examples in the file
> (all in the variable 'lhnotes' which are the notes for the piano left hand
> part). The final line that I've written also fails and is not commented out.
>
> Aria_-_Mon_coeur_s_ouvre_a_ta_voix_-_C.ly
> 
>
> Any thoughts would be appreciated.
>
> Cheers,
> Dave

Works fine here on Ubuntu 18.04 64-bit with lilypond 2.18.2 and 2.19.82

Cheers,
  Harm

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

Re: Rehearsal mark interferes with TupletBracket length

[Thomas Morley]

Am Do., 21. Feb. 2019 um 11:11 Uhr schrieb Andrew Bernard
:
>
> Hi Mark,
>
> No, that's the strange thing.
>
> I can't duplicate it in an MWE.
>
> If's a string quartet by Chris Dench. You can imagine the density and
> subtlety of the scoring. There's two hundred pages - hard to give to others
> to have a look at for debugging!
>
> Andrew
>
>
> On Thu, 21 Feb 2019 at 04:22, Mark Knoop  wrote:
>
> >
> > I can't test this at the moment, but are you anywhere overriding the
> > `extra-spacing-width` of the RehearsalMark grob?

This is
https://sourceforge.net/p/testlilyissues/issues/2362/
"tupletBracket fails with tupletFullLength and a long mark above"

A minimal:
{
  \set tupletFullLength = ##t
  \times 2/3 { c'2 2 2 }
  \mark "123456789"
}
Making the mark even longer will cause the Bracket to disappear and a
plethora of warnings.


You may try
\override TupletBracket.full-length-to-extent = ##f
or
unset tupletFullLength for the moment.

HTH,
  Harm

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

Re: modern-straight and flat- flags too thick and too spaced apart

[Thomas Morley]

Am So., 17. Feb. 2019 um 20:57 Uhr schrieb Carl Sorensen :
>
>
>
> On 2/16/19, 7:22 PM, "edes"  wrote:
>
>
> Hello, list.
>
> Some time ago I reported a bug with modern-straight and flat flags, and it
> was accepted as issue 5412:
>
> https://sourceforge.net/p/testlilyissues/issues/5412/
>
> I only have a very basic knowledge of lilypond, but I assume that this
> problem happens at the font level, and that there is no way to improve the
> output by tweaking the lilypond code?
>
> It turns out that the straight family of  flags is actually implemented in 
> scheme.
>
> The file is scm/flag-styles.scm
>
> The thicknesses are hard-coded at lines 111 (modern-straight-flag), 117 
> (old-straight-flag), and 122 (flat-flag).
>
> The names of the variables (which show up only as numbers in these calls) are 
> found at line 60.
>
> Unfortunately, at this point there does not appear to be any grob property 
> for  the thickness, so there is not a straightforward override.  You'll need 
> to edit the scheme file.  Or, you could define your own straight flag style 
> by copying (and altering) one of the flag definitions.
>
> If you get some better numbers, and especially if you have some evidence from 
> nicely-engraved scores, it's likely that we would replace the defaults.
>
> Thanks,
>
> Carl

Hi Carl,

I'm currently working on it.

Better default values are easy to obtain:

#(define-public (flat-flag grob)
  "Flat flag style.  The angles of the flags are both 0 degrees"
  ((straight-flag 0.48 0.81 0 1.0 0 1.0) grob))


Though, there is a design-decision we need to do.

Currently the straight-flags are modeled like default Flag-glyphs.
This means if there are more than 3 flags the spacing is not adjusted
(like for beams). Furthermore the end of the stem and flag match
exactly, as opposed to beams (at least they should, there's a small
discrepancy, already reported by the OP).
If we keep this thinking, than (flat) straight-flags stay different
compared to Beams.

The OP claims straight-flags, especially flat ones, should behave like
Beams. If we follow, than straight-flags need to adjust according to
the amount of flags, like Beams. Furthermore they should be placed so
that the stem ends in the _middle_ of the first flag, as for beams.
Disadvantage would be that a stem with default flag would often have a
different visible length compared to a stem with straight flags.

Speaking only for myself I think the OP is correct saying flat-flags
should behave like Beams, though I don't agree for
modern/old-straight-flags.


So the question is, which route to follow?


I already have code for the mentioned possibilties, but currently I'm
not able to do one thing for flat-flag and a different for other
straight-flags.
In any case the length of beamed and unbeamed Stems is different in
many cases. One would need to tackle Stem not Flag, so a different
issue, imho.


Cheers,
  Harm

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

Re: Failed assertion in tremolos with beamed notes

[Thomas Morley]

Am Do., 7. Feb. 2019 um 15:37 Uhr schrieb James Lowe :
>
> Hello,
>
>
> On Thu, 7 Feb 2019 10:30:20 +0100, Hendrik Fuß  wrote:
>
> > Hi,
> >
> > attached is a minimal example that causes a crash in lilypond 2.19.82.
> >
> > Output:
> >
> > GNU LilyPond 2.19.82
> > »assertion_test.ly« wird verarbeitet
> > Analysieren...
> > Interpretation der Musik...
> > Vorverarbeitung der grafischen 
> > Elemente.../home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh:227:
> >  failed assertion `!is_empty ()'
> > Abort trap: 6
> >
> > Hope this is helpful.
> >
> > Best
> > Hendrik
>
> Using Ubuntu 16.0.4 with current master - 2.21.0
>
> Same crash.
>
> James

FWIW,

2.10.33 Segmentation fault (core dumped)
2.12.3 Success
2.14.2 Success
2.16.2 Success
2.18.2 Success
2.19.82 Aborted (core dumped) [mainly same message as below]
2.21.0
lilypond: /home/hermann/lilypond-git/flower/include/interval.hh:227: T
Interval_t::center() const [with T = double]: Assertion `!is_empty
()' failed.
Aborted (core dumped)


Running gdb (n.b. my lilydevel is the renamed lilypond-2.19.82):

$ gdb lilydevel/usr/bin/lilydevel
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lilydevel/usr/bin/lilydevel...(no debugging
symbols found)...done.
(gdb) run lilypondH/Test/forum/atest-83.ly
Starting program: /home/hermann/lilydevel/usr/bin/lilydevel
lilypondH/Test/forum/atest-83.ly
warning: File "/home/hermann/lilydevel/usr/lib/libstdc++.so.6.0.20-gdb.py"
auto-loading has been declined by your `auto-load safe-path' set to
"$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path
/home/hermann/lilydevel/usr/lib/libstdc++.so.6.0.20-gdb.py
line to your configuration file "/home/hermann/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/hermann/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU LilyPond 2.19.82
Processing `lilypondH/Test/forum/atest-83.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...lilydevel:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh:227:
T Interval_t::center() const [with T = double]: Assertion
`!is_empty ()' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x75b11801 in __GI_abort () at abort.c:79
#2  0x75b0139a in __assert_fail_base (fmt=0x75c887d8
"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=assertion@entry=0x7960ac "!is_empty ()",
file=file@entry=0x795dc8
"/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh",
line=line@entry=227, function=function@entry=0x7e35a0 "T
Interval_t::center() const [with T = double]") at assert.c:92
#3  0x75b01412 in __GI___assert_fail (assertion=0x7960ac "!is_empty ()",
file=0x795dc8
"/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/include/interval.hh",
line=227,
function=0x7e35a0 "T Interval_t::center() const [with T =
double]") at assert.c:101
#4  0x006e728f in ?? ()
#5  0x77920c7a in scm_dapply () from
/home/hermann/lilydevel/usr/bin/../lib/libguile.so.17
#6  0x0054d4f4 in ?? ()
#7  0x005618eb in ?? ()
#8  0x00468bec in ?? ()
#9  0x77920a83 in scm_dapply () from
/home/hermann/lilydevel/usr/bin/../lib/libguile.so.17
#10 0x0053fc09 in ?? ()
#11 0x00466348 in ?? ()
#12 0x00466975 in ?? ()
#13 0x00467155 in ?? ()
#14 0x00556529 in ?? ()
#15 0x77920c7a in scm_dapply () from
/home/hermann/lilydevel/usr/bin/../lib/libguile.so.17
#16 0x0054d4f4 in ?? ()
#17 0x004493e3 in ?? ()
#18 

programming error/segfault while omitting Fingering.stencil with fingeringOrientations set 'left

[Thomas Morley]

Hi,

the following code is problematic

{
  \set fingeringOrientations = #'(left)
  \override Fingering #'stencil = ##f
%% chord needs two elements to trigger the bug
}

Versions 2.12.3 up to 2.16.2 print correctly, without error

Versions 2.18.2 up to 2.19.82 print correctly, but return:
programming error: Infinity or NaN encountered

Current master does:
Segmentation fault (core dumped)

Cheers,
  Harm

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

Re: Doc-snippet "Two \partcombine pairs on one staff" broken

[Thomas Morley]

Am So., 30. Dez. 2018 um 12:00 Uhr schrieb Thomas Morley
:
>
> Am So., 30. Dez. 2018 um 11:06 Uhr schrieb Thomas Morley
> :
> >
> > Hi,
> >
> > out of 
> > https://lists.gnu.org/archive/html/lilypond-devel/2018-12/msg00178.html
> >
> > The doc-tagged LSR-snippet "Two \partcombine pairs on one staff"
> > http://lsr.di.unimi.it/LSR/Item?id=958
> > is obviously inspired by
> > https://sourceforge.net/p/testlilyissues/issues/1321/?page=1=25#a054
> >
> > While it works with 2.18.2 as described, without error/warning, it does not 
> > with 2.19.82 and recent master.
> > http://lilypond.org/doc/v2.19/Documentation/snippets/simultaneous-notes#simultaneous-notes-two-_005cpartcombine-pairs-on-one-staff
> > Lots of warnings and the pdf is not as wished.
> >
> > Not sure how to fix.
> > Thoughts?
> >
> >
> > Cheers,
> >   Harm
>
> Attached a possible fix. Works with 2.18., 2.19.82 and (after
> convert-ly, i.e. partcombine->partCombine) with recent master.
> If no objections, I'll change the LSR-snippet. It will then be
> available in our docs after next LSR-import.


Done.

Cheers,
  Harm

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

Re: Doc-snippet "Two \partcombine pairs on one staff" broken

[Thomas Morley]

Am So., 30. Dez. 2018 um 11:06 Uhr schrieb Thomas Morley
:
>
> Hi,
>
> out of https://lists.gnu.org/archive/html/lilypond-devel/2018-12/msg00178.html
>
> The doc-tagged LSR-snippet "Two \partcombine pairs on one staff"
> http://lsr.di.unimi.it/LSR/Item?id=958
> is obviously inspired by
> https://sourceforge.net/p/testlilyissues/issues/1321/?page=1=25#a054
>
> While it works with 2.18.2 as described, without error/warning, it does not 
> with 2.19.82 and recent master.
> http://lilypond.org/doc/v2.19/Documentation/snippets/simultaneous-notes#simultaneous-notes-two-_005cpartcombine-pairs-on-one-staff
> Lots of warnings and the pdf is not as wished.
>
> Not sure how to fix.
> Thoughts?
>
>
> Cheers,
>   Harm

Attached a possible fix. Works with 2.18., 2.19.82 and (after
convert-ly, i.e. partcombine->partCombine) with recent master.
If no objections, I'll change the LSR-snippet. It will then be
available in our docs after next LSR-import.


Cheers,
  Harm
\layout {
  \context {
\Staff
\accepts "VoiceBox"
  }
  \context {
\name "VoiceBox"
\type "Engraver_group"
\defaultchild "Voice"
\accepts "Voice"
\accepts "NullVoice"
  }
}

partcombineUplsr =
#(define-music-function (p l partOne partTwo)
  (ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
a @code{VoiceBox} named @q{Up} containing @code{Voice}s
that contain @var{partOne} and @var{partTwo} merged into one
voice where feasible.  This variant sets the default voicing
in the output to use upward stems."
#{
  \new VoiceBox = "Up" <<
\context Voice = "one" { \voiceOne }
\context Voice = "two" { \voiceThree }
\context Voice = "shared" { \voiceOne }
\context Voice = "solo" { \voiceOne }
\context NullVoice = "null" {}
\partcombine #partOne #partTwo
  >>
#})

partcombineDownlsr = #
(define-music-function (p l partOne partTwo)
  (ly:music? ly:music?)
"Take the music in @var{partOne} and @var{partTwo} and return
a @code{VoiceBox} named @q{Down} containing @code{Voice}s
that contain @var{partOne} and @var{partTwo} merged into one
voice where feasible.  This variant sets the default voicing
in the output to use downward stems."
#{
  \new VoiceBox = "Down" <<
\set VoiceBox.soloText = #"Solo III"
\set VoiceBox.soloIIText = #"Solo IV"
\context Voice ="one" { \voiceFour }
\context Voice ="two" { \voiceTwo }
\context Voice ="shared" { \voiceFour }
\context Voice ="solo" { \voiceFour }
\context NullVoice = "null" {}
\partcombine #partOne #partTwo 
  >>
#})

soprano = { d'4 | cis'  b  e'  d'8 cis' | cis'2 b }
alto = { fis4 | e8 fis gis ais b4 b | b ais fis2 }
tenor = { a8 b | cis' dis' e'4 b8 cis' d'4 | gis cis' dis'2 }
bass = { fis8 gis | a4 gis g fis | eis fis b,2 }

\new Staff <<
  \key b\minor
  \clef alto
  \partial 4
  \transpose b b'
  \partcombineUplsr \soprano \alto
  \partcombineDownlsr \tenor \bass
>>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond