Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)
> Can't reproduce this here on x86_64, Ubuntu 22.04. > I did 100 subsequent runs without a single failure. > > Jean, which system are you on? Fedora 40, x86_64. > If you can reproduce this often enough, could you share a core dump? Well, I've been testing it with the official released binaries of 2.25.16, which are stripped, so no stack trace (I don't even have LilyPond's development dependencies installed right now). Since this looks almost certainly GC-related, it may even depend on the compiler optimization level / LTO used in the build. signature.asc Description: This is a digitally signed message part
Re: 2.25.15: Interpreting music: infinite loop (fatal error: intlog2 with negative argument: 0)
On my Linux machine with 2.25.16, that file nondeterministically compiles, segfaults, or triggers a floating point exception. No time to investigate more, though. signature.asc Description: This is a digitally signed message part
Re: Intermittent core dumps with 2.25.8 under Ubuntu 22.04.3
> Le 1 juin 2024 à 00:40, Trevor Bača a écrit : > > QUESTION: if Lily does core dump during one of the runs, what is the exact > path to the core file? (I'm using something like /tmp/lilypond-2.25.15 for > Lily's install directory.) See https://github.com/itamarst/gha-upload-cores
Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.
> In contrast to Jean, I have a different point of view. I think it
> would be *very* valuable to have documentation strings of *all*
> functions that might be useful in the long run
Oh, that's also my point of view — it *would* be very valuable.
Just... IMO not realistic. It already took me weeks to write
the extending-lilypond guide (not counting the effort to understand
the code base in the first place). "rg '```\{func\}' | wc -l" tells
me that currently 76 functions are documented in the guide, so the
multiplier to get more usable documentation for all functions that
are already documented is already ~10, and there are the undocumented
ones also.
signature.asc
Description: This is a digitally signed message part
Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.
> Thank you so much, that did the trick. > > The naming of lilypond scheme functions can be really unintuitive > sometimes. At the very least, the internals reference could use > some major extensions making clear what the functions do and how, > with examples. Via [1], it would have been impossible for me to > understand what scorify-music does or that I need this function > over ly:make-score. Am I missing some other place where this is > already documented in more detail? > > If not, I'd be happy to start investing my time to contribute to > the Internals reference documentation, especially Section 4 "Scheme > functions". In addition to better explanatory texts this section > could benefit from more crosslinks and examples - or maybe the > examples should be in a different (new) section to keep this > reference concise. I'd be happy to discuss this further. Not that improvements like this are not welcome, but if you want my honest opinion, documenting public functions to the degree that one could use them just from the manual is a lost cause. There are way too many of them (740 functions in the current Internals Reference, but many more exist which are undocumented). I think we just have to accept that, these functions being largely the deep guts of LilyPond exposed for anyone to use, you have to be a bit familiar with the source code in order to use them correctly. I think the best we can do is high-level extending documentation — like what I've tried to do in https://extending-lilypond.gitlab.io — supplemented by a dose of "read the source code" for advanced usage. Note that I didn't know about scorify-music before you sent this bug report. I just knew that chord repeats are expanded by a music function in toplevel-music-functions, and I did a bit of grepping in order to find the call site. Best, Jean signature.asc Description: This is a digitally signed message part
Re: Bug: Repeated chords (via "q") are not rendered when using ly:book-process.
Le samedi 30 mars 2024 à 16:47 +, Lovis B. Suchmann a écrit :
> \version "2.24.3"
>
> % Repeated chords (via "q") are not rendered when using ly:book-process.
>
> test = { r4 r q | }
>
> \book { \score { \test \layout {} } }
>
> #(ly:book-process (ly:make-book $defaultpaper
> #f
> (ly:make-score test))
> $defaultpaper
> $defaultlayout
> (string-append (ly:parser-output-name) "-1"))
This isn't a bug. You probably want to use scorify-music instead of
the low-level function ly:make-score.
signature.asc
Description: This is a digitally signed message part
Re: Chord names collide with span bar
Le mercredi 20 mars 2024 à 15:56 +0100, Jean Abou Samra a écrit : > Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > > Your solution requires version 2.22 and I'm using 2.24 > > (with the \alternative command so it's not easy to change) > > The old \alternative syntax is still supported in 2.24. Ah, sorry. Somehow, I “autocorrected” your reply as “Your solution requires version 2.24 and I'm on 2.22”. Forget about it. signature.asc Description: This is a digitally signed message part
Re: Chord names collide with span bar
Le mercredi 20 mars 2024 à 07:51 -0700, Knute Snortum a écrit : > Your solution requires version 2.22 and I'm using 2.24 > (with the \alternative command so it's not easy to change) The old \alternative syntax is still supported in 2.24. signature.asc Description: This is a digitally signed message part
Re: \alternative fails if \repeat unfold proceeds it
Le samedi 24 février 2024 à 11:05 -0800, Knute Snortum a écrit :
> I've run into something that I think is a bug -- or I'm not understanding
> something. It happens when you are in a \repeat volta section and use a
> \repeat unfold just before the \alternative section.
>
> \version "2.25.13"
>
> \relative {
> c''4 c c c |
> \repeat volta 2 {
> \repeat unfold 2 { d4 d d d }
> % d4 d d d % uncomment me and everything's fine
That's legacy \alternative syntax kicking in for backwards compatibility.
The \alternative gets attached to \repeat unfold. Try inserting {} here.
> \alternative {
> \volta 1 { e4 e e e }
> \volta 2 { f4 f f f }
> }
> }
> g4 g g g
> }
>
> The work around is to have one line of non-repeated notes just before the
> \alternative section.
signature.asc
Description: This is a digitally signed message part
Re: Imprecise font scaling
> Perhaps it might be worth clarifying what sort of "pt" does LilyPond use. Or > did I just overlook this information? IMHO, this also falls in the "not worth documenting" category. But yes, lily/include/dimensions.hh contains const Real INCH_TO_PT = 72.270; signature.asc Description: This is a digitally signed message part
Re: Imprecise font scaling
> Shall we document this somehow? Not everything is necessarily worth documenting. signature.asc Description: This is a digitally signed message part
Re: Imprecise font scaling
Sorry, my mail client changed the formatting in a way I didn't expect.
Resending.
> I'm running the following code
>
> \version "2.25.12"
> \markup { LOL }
> \markup { \magnify #2.0 LOL }
>
> and the results are not really precise. When producing --eps, the relevant
> output lines are
>
> /C059-Roman 3.86523438 output-scale div selectfont
> /C059-Roman 7.73242188 output-scale div selectfont
>
> However, 2 * 3.86523438 = 7.73046876 != 7.73242188. Basically the same
> behaviour
> can be observed when using Cairo (both for EPS and SVG).
> (Producing SVG without Cairo is pretty disastrous in this regard, but
> that doesn't bother me too much at the moment.)
I'm quite sure this is because of
int pango_size = static_cast (
std::lround (static_cast (requested_size) * PANGO_SCALE));
in lily/font-select.cc, which we cannot really do anything about, because
the Pango API
https://docs.gtk.org/Pango/method.FontDescription.set_size.html
expects an integer size scaled by PANGO_SCALE, which is 1024. That is, we are
limited to a precision of 1/1024 points on the font size.
signature.asc
Description: This is a digitally signed message part
Re: Imprecise font scaling
I'm running the following code
\version "2.25.12"
\markup { LOL }
\markup { \magnify #2.0 LOL }
and the results are not really precise. When producing --eps, the relevant
output lines are
/C059-Roman 3.86523438 output-scale div selectfont
/C059-Roman 7.73242188 output-scale div selectfont
However, 2 * 3.86523438 = 7.73046876 != 7.73242188. Basically the same
behaviour can be observed when using Cairo (both for EPS and SVG).
> (Producing SVG without Cairo is pretty disastrous in this regard, but
> that doesn't bother me too much at the moment.)
I'm quite sure this is because of
int pango_size = static_cast (
std::lround (static_cast (requested_size) * PANGO_SCALE));
in lily/font-select.cc, which we cannot really do anything about, because
the Pango API
https://docs.gtk.org/Pango/method.FontDescription.set_size.html
expects an integer size scaled by PANGO_SCALE, which is 1024. That is, we are
limited to a precision of 1/1024 points on the font size.
signature.asc
Description: This is a digitally signed message part
Re: bug-reporting instructions need clarification
> Follow-up replies, on the other hand, come > through without further moderation – at least I think this is the > case, but I'm not sure. When approving a message, the moderator can optionally choose to add the sender to a whitelist of automatically approved addresses. I usually do this on bug-lilypond (though not on lilypond-user). signature.asc Description: This is a digitally signed message part
Re: Lilypond installation
Hi, Le mardi 16 janvier 2024 à 01:19 -0700, Mike Raevsky a écrit : > I'm in the middle of a clean installation on a mac with Sonoma 14.1.2 with > an M2 chip. The instructions have been incomplete and have varied > significantly from the screenshots on the website. After I gave up with the > tarball, I installed MacPorts which had some issues (beyond your control) > to use that installer, and it appears I've finished, but the list of notes > is extensive and I thought I'd share that with you. As of now, I'll be > going through these to figure out which are important and which are just > notes. Can you share the issues you've had with the official installation instructions please? The MacPorts package is not only out of our control, but also broken (it's missing fonts), and they haven't fixed it in almost a year (sigh). If you want to use a package manager to install LilyPond, I'd recommend Homebrew. signature.asc Description: This is a digitally signed message part
Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info
> I don't have the time to check this but is there not a way to simply write > bytes to (current-error-port) in Guile? Like scm_c_write < https://www.gnu.org/software/guile/manual/html_node/Using-Ports-from-C.html > ? signature.asc Description: This is a digitally signed message part
Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info
Le vendredi 12 janvier 2024 à 06:08 +, Werner LEMBERG a écrit : > How shall we proceed? I don't have the time to check this but is there not a way to simply write bytes to (current-error-port) in Guile? IIRC, all Guile ports can be used in both binary and text ways. Also, I'm pretty sure that the intent of FcChar8* in Fontconfig is to represent UTF-8 so this is probably worthy of a bug report to the Fontconfig people? signature.asc Description: This is a digitally signed message part
Re: Using -dshow-available-fonts with LilyPond v2.25.12 throws error with non–UTF-8 encoded font info
Le mardi 09 janvier 2024 à 12:43 -0500, Nate Whetsell a écrit : > I’m starting to think this may be a bug in Guile. Well, Guile's encoding handling is quite bug-ridden. signature.asc Description: This is a digitally signed message part
Re: Minimum tie length not honored after a break
It's just a separate property. Try setting minimum-length-after-break.
Re: offset and TupletNumbers
> Is this bug #6618? Yes. signature.asc Description: This is a digitally signed message part
Re: floating point exception (core dumped)
Thanks for the report, but can you include an example, please? Just something that sometimes crashes or at some point used to crash, even if not reliably. Someone else reported a similar bug not long ago, but without an example, making it impossible right now for a developer to investigate the problem. Thanks, Jean signature.asc Description: This is a digitally signed message part
Re: Intermittent core dumps with 2.25.8 under Ubuntu 22.04.3
Le mardi 19 septembre 2023 à 15:58 -0400, Trevor Bača a écrit : > Happy to try to help, if anyone can offer guidance on how to better report > the problem, Having the files would obviously help a lot, if you can share them. If this reproducibly crashes on Linux outside of GitHub actions then it will be enough. Otherwise we'll need a core dump. See https://github.com/itamarst/gha-upload-cores/blob/main/.github/workflows/build.yml for an example. signature.asc Description: This is a digitally signed message part
Re: Lilypond only respects override of Score.SpacingSpanner.strict-grace-spacing at the beginning of the score
Le dimanche 24 septembre 2023 à 09:21 +, Ole V. Villumsen via bug-lilypond a
écrit :
> \version "2.24.2"
>
> \relative {
> g'1 |
> % The following has no effect.
> \override Score.SpacingSpanner.strict-grace-spacing = ##t
> \grace { a4 } g1 |
> }
>
> \relative {
> % This works.
> \override Score.SpacingSpanner.strict-grace-spacing = ##t
> g'1 |
> \grace { a4 } g1 |
> }
>
> As a consequence we cannot change this property dynamically in the course of
> the score.
This is expected. The \newSpacingSection command can be used to start a new
SpacingSpanner that will respond to the current active spacing settings.
signature.asc
Description: This is a digitally signed message part
Re: Core dump in version 2.25.7 (regression)
Opened https://gitlab.com/lilypond/lilypond/-/issues/6654 . Thanks, Jean signature.asc Description: This is a digitally signed message part
Re: SVG output: Bad \smallCaps kerning
Adding back the list. Le dimanche 27 août 2023 à 19:30 -0400, Kevin Cole a écrit : > Mixed results... So, this is a "thanks, but..." > > The Frescobaldi .deb suggested by those instructions is 3.2. The Flatpak is > 3.3. > > Using the Flatpak Frescobaldi, clicking the pull-down menu "Lilypond -> > Engrave (Custom)" and explicitly selecting SVG is ignored. Frescobaldi > produces a PDF. (Maybe there's some non-obvious way to use the pull-down > menu?) It works for me. To be sure, you're engraving each time from this "custom" menu, right? This menu is *not* a set of options that are used every time you compile in the "normal" way. If you want to make Frescobaldi compile all files into SVGs, you should set that in Edit > Preferences > LilyPond Preferences > Default Output Format. > The instructions for installing the command-line version offers a tarball that > lives in a vacuum: Rather than integrating with /usr, /usr/local or ~/.local/ > the attitude appears to be "Screw that. I'm fiercely independent, and you'll > need to go through additional, unnecessary hoops to get me to play nicely with > all of the other children, fussing with new paths, aliases, or whatever." But why do you want to fuss with anything? Why not just run LilyPond as "~/.../bin/lilypond" ? Zero setup required. > Among the questionable choices is assuming I need yet another version of > Python (I already have 3.10) -- though LilyPond wouldn't be the first to do > that. Call it questionable or not, but it's not really a choice. These binaries do what's necessary to be able to run on about any reasonably recent Linux distro (namely only requiring a reasonably recent version of the fundamental system library, glibc). We can't assume that Python is installed, much less that the version we want is installed, and there's the "python3" vs "python" problem too. > That said, running LilyPond from the command line did produce the correct > output when asked, and it kerned properly. So, really, thanks for that. Good. > Is there a place to file feature requests like "Integrate with the operating > system?" Maybe a Bash script that moves everything to the appropriate > /usr/local/ or ~/.local/ subdirectories? That's exactly what was done in LilyPond ≤ 2.23.6. The result? I've helped people who had gotten utterly confused because they removed the ~/lilypond directory (or whichever it was) but did not remove the symlinks or wrappers (I don't remember) in ~/bin, and thought LilyPond was still installed because of these, or got them to mix up with a different installation, etc. etc. This list is the right channel for feature requests, but I suspect we would not implement this particular request. On the other hand, it's noteworthy that the (not yet released) master branch of Frescobaldi implements automatic installation of LilyPond (in a directory internal to Frescobaldi, for use inside Frescobaldi, not on the command line). IMHO, auto-management of LilyPond versions is more in scope for Frescobaldi than LilyPond itself. Jean signature.asc Description: This is a digitally signed message part
Re: SVG output: Bad \smallCaps kerning
> Le 27 août 2023 à 21:52, Kevin Cole a écrit : > > That just leads to: > > fatal error: compiled without CAIRO_BACKEND > > which means I will have to install and keep track of yet another version of > LilyPond -- this one compiled from scratch... Compiling from scratch is (of course) not needed -- just follow https://lilypond.org/doc/v2.24/Documentation/learning/installing to get the official binaries. (The error means your LilyPond distro package doesn't compile with Cairo, which was still possible for 2.24 though not really recommended.) > (I begin to understand why there needs to be 15 versions of documentation > now.) ? There is no separate version of the documentation for Cairo support.
Re: SVG output: Bad \smallCaps kerning
Try the Cairo backend, adding -dbackend=cairo on the command line or #(ly:set-option 'backend 'cairo) in the file. It is partly because of font issues like this that the legacy SVG backend is usually inferior to the new Cairo backend.
Re: Ugly multiple slurs over line break
Le vendredi 04 août 2023 à 20:38 +, Ole V. Villumsen via bug-lilypond a
écrit :
> % Multiple slurs in a Voice work nicely on one staff, as described in NR.
> %
> https://lilypond.org/doc/v2.24/Documentation/notation/expressive-marks-as-curves#slurs
> % Multiple slurs crossing over a line break are ugly and collide easily.
>
> % I suppose modifying the shapes could be a workaround (I have not tried).
> %
> https://lilypond.org/doc/v2.24/Documentation/notation/modifying-shapes#modifying-ties-and-slurs
>
> \version "2.24.1"
>
> \layout {
> ragged-right = ##t
> }
>
> \relative {
>
> \break }
Wheew, that's hideous. Thank you for this example, which I've added
to https://gitlab.com/lilypond/lilypond/-/issues/5616
signature.asc
Description: This is a digitally signed message part
Re: convert-ly.py in 2.25.7 "broken"
Le mercredi 02 août 2023 à 21:01 +0200, Craig Fearing a écrit : > > OK thanks for the info. > > Out of curiosity, are you the "Jean" in that first line in the file? > > #!/home/jean/repos/lilypond/release/binaries/dependencies/install/Python- > 3.10.8/bin/python3.10 Yes. That line is called a "shebang" and is in fact irrelevant on Windows (it is relevant on Linux, macOS and other UNIX systems), but the build process happens to generate it nevertheless. Best, Jean > signature.asc Description: This is a digitally signed message part
Re: convert-ly.py in 2.25.7 "broken"
Le mardi 01 août 2023 à 23:36 +0200, Craig Fearing a écrit : > If I use Frescobaldi's "Update..." tool, files with version numbers less > than 2.25.6 get updated to 2.25.6 and those already at 2.25.6 are not > touched. > > If I compare the convert-ly files in 2.25.5 and 2.25.6 I see they are > almost identical except for version number. That is not true, however, > when comparing 2.25.7, starting from the first line! > > (Win-64 build) That is intentional. convert-ly (from any version) will only update the \version statement to the latest version for which it actually made changes to your file, the idea being that if no changes were required to go from 2.25.6 to 2.25.7, then the file is considered compatible with 2.25.6 just as well as with 2.25.7. signature.asc Description: This is a digitally signed message part
Re: Faulty extra beam with manual beam and cross-staff stems
Le mardi 01 août 2023 à 20:35 +, Ole V. Villumsen a écrit : > Finally a warning message from Lilypond would be nice when I do it wrong so > that I don’t start suspecting a bug. Explanatory and with suggestion how to > fix if possible. If anybody is going to invest work into this, I think it would be more sensible to just try to obviate it altogether. signature.asc Description: This is a digitally signed message part
Re: Faulty extra beam with manual beam and cross-staff stems
Le mardi 01 août 2023 à 18:34 +, Ole V. Villumsen via bug-lilypond a écrit :
> % Manual beams and cross-staff stems don’t seem to work together.
> % Expected result: Shared stems across staves; beams above notes in upper
> staff only.
>
> % I have tried all possible combinations of specifying beams and \crossStaff
> in the
> % upper staff, the lower one and both. I always get unwanted beams in the
> lower staff.
You should add \autoBeamOff in the lower staff, and remove the manual beams
there.
\version "2.25.7"
\layout {
\context {
\PianoStaff
\consists "Span_stem_engraver"
}
}
\new PianoStaff <<
\new Staff \relative {
r8 e'[ e] r
r e e r |
r e[ e] r
r e[ e] r |
r e e r
r e[ e] r |
r e[ e] r
r e e r |
r e[ e] r
r2 |
}
\new Staff \relative {
\clef bass
\stemUp
\autoBeamOff
\crossStaff {
r8 g g r
r g g r |
r g g r
r g g r |
r g g r
r g g r |
r g g r
r g g r |
r g g r
r2 |
}
}
>>
\crossStaff requires an explicit \autoBeamOff. I'm not saying that this is
the perfect user interface, but there is no bug here.
Jean
signature.asc
Description: This is a digitally signed message part
Re: markLengthOn leads to excessively wide MMRs
Le lundi 10 juillet 2023 à 13:06 -0700, Saul Tobin a écrit :
> \layout {
> \context {
> \Score
> skipBars = ##t
> \markLengthOn
> }
> }
>
> {
> \tempo "Tempo" 4=120
> R1*4
> \mark\default
> }
>
> The MMR should only stretch to the minimum length necessary to
> accommodate the MetronomeMark. This leads to very ugly results with long
> MetronomeMarks, including sometimes stretching measures beyond the page
> margins (even if the text itself fits within the margins). It also leads to
> ugly results when a system contains multiple MMRs, as one is too wide and
> the other too narrow.
>
> I have not found an obvious way to tweak this behavior.
Sounds reasonable.
What about creating the issue yourself? The reason for asking to report on bug-
lilypond is to filter out reports that aren't actual bugs, and make sure the
necessary info is there before filing an issue. All bug reports I've seen from
you so far I've just pasted as-is into the tracker, so...
Best,
Jean
signature.asc
Description: This is a digitally signed message part
Re: Compilation Issue
Le lundi 03 juillet 2023 à 21:38 -0500, Zvony Nagy a écrit : > warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH - > dAutoRotatePages=/None -dPrinted=false > /var/folders/j0/jbxtm1xs4hq32jrg2x_m_lgwgq/T//lilypond-tmp-1525935)' > failed (256) > > /usr/local/Cellar/lilypond/2.24.1/share/lilypond/2.24.1/ly/init.ly:65:2 <0>: > error: Guile signaled an error for the expression beginning here > # > (let ((book-handler (if (defined? 'default-toplevel-book-handler) > Throw to key `ly-file-failed' with args `()'. > Exited with return code 1. Someone else experienced the same issue with Homebrew recently: https://lists.gnu.org/archive/html/lilypond-user/2023-06/msg00138.html Apparently, there is a problem with the Ghostscript Homebrew package. Maybe report a bug to them. The official binaries from lilypond.org are not know to have any such issues. Best, Jean signature.asc Description: This is a digitally signed message part
Re: Shifting ottavation spanner to voice context breaks clef change in 2.24.0 and higher
Le samedi 03 juin 2023 à 00:15 +0200, Heiko Schill a écrit : > Good evening everyone, > > when compiling the attached document, in the first staff the clef change is > ignored for the lower voice after moving the ottavation spanner to the > voice context as suggested in the snippets-document. This seems to happen > only if one or more notes are located between the "\ottava 0" and the > "\clef bass" command (see the third staff which compiles correctly). > > In the default setup (second staff), the ottavation and clef change work > correctly, but the ottavation is applied to all voices in the staff (as by > design, but not intended here). > > The usage of several voices is not necessary: In a single voice example, > the bug manifests irrespective of the presence of extra notes between the > \ottava and \clef commands (see staffs 4 and 5). > > I noticed this behavior with version 2.24.0, but it is the same with > version 2.24.1 and 2.25.5. Thanks for the detailed report, and sorry for the delay in handling it. I've opened https://gitlab.com/lilypond/lilypond/-/issues/6633 signature.asc Description: This is a digitally signed message part
Re: convert-ly No module named 'convertrules'
Le jeudi 15 juin 2023 à 09:41 -0400, Pierre-Luc Gauthier a écrit : > I hope I'm not necroposting here. > > I naively tried to move it to /usr/local/bin but still : > > Traceback (most recent call last): > File "/usr/local/bin/convert-ly", line 82, in > import convertrules > ModuleNotFoundError: No module named 'convertrules' > > For the record there is : > https://aur.archlinux.org/packages/lilypond-git#comment-915688 Moving into /usr/local/ isn't expected to help; ether LilyPond is installed into /usr/ (normally by a package manager, like you are using), or into /usr/local/ (normally by "sudo make install"), but not both. Do other scripts, such as musicxml2ly, work? There should be a "/usr/share/lilypond//python/" directory (where = 2.25.x or = current). Is that the case? signature.asc Description: This is a digitally signed message part
Re: Barline doesn't whiteout stave lines sometimes
Le jeudi 08 juin 2023 à 22:14 -0400, William Rehwinkel via bug-lilypond a écrit
:
> Dear list,
>
> In the following example, the stave lines overlap the barlines at the
> end of the bottom two staves (the expected behavior would have been for
> the stave lines to be interrupted by the bar lines like the others).
I don't think it's a bug.
By default, StaffSymbol and BarLine have the same layer value (see
[StaffSymbol](https://lilypond.org/doc/v2.25/Documentation/internals/staffsymbol)
and [BarLine](https://lilypond.org/doc/v2.25/Documentation/internals/barline)
in the Internals Reference), so the order in which they are drawn is arbitrary.
Of course, you could argue that the order should always be well-defined. That
would require giving a layer to every single grob, which would not necessarily
scale (are you prepared to make a decision on what the layer of each of the 163
grob types should be?).
IMHO, if you have an order that you want to be followed, you should just set
the layer yourself, as in
```
\layout {
\context {
\Staff
\override BarLine.color = #red
\override BarLine.layer = 1
}
}
```
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mardi 30 mai 2023 à 22:40 +0200, Jean Abou Samra a écrit : > Le dimanche 28 mai 2023 à 14:37 +0200, Jean Abou Samra a écrit : > > > > One thing I will try when I can is building in a Kubuntu VM. So far, I used > > a VM with the default Ubuntu variant, with GNOME. That would normally not > > matter, but since the desktop environments are > > different, maybe Kubuntu has different font configuration settings. > > > Ha! It reproduces in a fresh Kubuntu VM. > > I'll create a ticket now that we know it's not just a problem on your system. https://gitlab.com/lilypond/lilypond/-/issues/6620 signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le dimanche 28 mai 2023 à 14:37 +0200, Jean Abou Samra a écrit : > > One thing I will try when I can is building in a Kubuntu VM. So far, I used a > VM with the default Ubuntu variant, with GNOME. That would normally not > matter, but since the desktop environments are > different, maybe Kubuntu has different font configuration settings. Ha! It reproduces in a fresh Kubuntu VM. I'll create a ticket now that we know it's not just a problem on your system. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
> Le 28 mai 2023 à 05:29, Colin Campbell a écrit : > > Just in case it might help, I uninstalled the font, and reran the test file, > successfully. Logs attached to compare against failed run. These logs sound like I was wrong to blame Pango. Apparently, the introduction of emoji configuration happens when LilyPond applies the system font configuration to the font pattern. One thing I will try when I can is building in a Kubuntu VM. So far, I used a VM with the default Ubuntu variant, with GNOME. That would normally not matter, but since the desktop environments are different, maybe Kubuntu has different font configuration settings. > I have no idea where that font file came from, as I have no use at all for > coloured emojis. I see it was provided by Google, which makes me wonder about > an update to Vivaldi or Chromium. Anyway, it's late, and I've taken topo much > of your time already. Helping me understand a bug I've introduced is not a waste of my time.
Re: Crash in 2.25.4
Le dimanche 28 mai 2023 à 00:38 +0200, Jean Abou Samra a écrit : > Le samedi 27 mai 2023 à 16:31 -0600, Colin Campbell a écrit : > > I generally keep my system current, and libpango is at 1.0-0 already. > The "1.0" version number denotes an ABI compatibility promise as far as I > understand; current versions of Pango are actually around 1.50. (1.0.0 is > from around 2002.) > So, just to confirm, "sudo apt upgrade libpango1.0-0" said Pango was already > the latest version? Oh, and also check "sudo apt upgrade fontconfig" signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le samedi 27 mai 2023 à 16:31 -0600, Colin Campbell a écrit : > I generally keep my system current, and libpango is at 1.0-0 already. The "1.0" version number denotes an ABI compatibility promise as far as I understand; current versions of Pango are actually around 1.50. (1.0.0 is from around 2002.) So, just to confirm, "sudo apt upgrade libpango1.0-0" said Pango was already the latest version? > Just as a reminder: the error is reliably reproducible on my system, so the > challenge seems to be isolating the difference between yours and mine. Yes. Unfortunately, if it's an uninitialized variable or such, it might be near impossible — such things can depend on totally random parameters. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le dimanche 28 mai 2023 à 00:05 +0200, Jean Abou Samra a écrit : > If Pango fails to correctly substitute values in the FcConfig, it could > potentially mean that it's passed with some fields uninitialized to > Fontconfig. That could explain why the error is not > reproducible; the value of "color" could be a random uninitialized boolean > variable. But I'm not sure yet. Colin, is your Ubuntu system up-to-date ? Who knows, if the bug's in Pango, it might already have been fixed. Try "sudo apt upgrade libpango1.0-0". signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le samedi 27 mai 2023 à 07:50 +0200, Jean Abou Samra a écrit :
> > With lilypond 2.25.6 and your second patch applied, here are 2 .PDFs:
> > first is without the offending font installed, the second is the temporary
> > file produced when the font is present.
>
>
> Thanks, but I am more interested in the log than the PDF for this one.
[Colin's answer, which had attachments too big for the list; I saw it in the
moderation interface]
Ran the test as FC_DEBUG=2025 ./out/bin/lilypond /Work/Non-Musical.ly >
fclog.log 2> lilylog.log and I hope that's what you meant. Running
without FC_DEBUG produced a log of zero bytes.
Resulting files attached.
Cheers,
Colin
[my answer]
It's quite strange that fclog.log is empty without FC_DEBUG (note that for now
I don't need FC_DEBUG anymore). Since the FcPatternPrint calls were put in
```
static void
substitute_with_lily_config (FcPattern *pat, void *config)
{
FcConfig *fcconfig = static_cast (config);
FcConfigSubstitute (fcconfig, pat, FcMatchPattern);
}
```
which is registered as
```
// Before searching a font pattern with Fontconfig, FcConfigSubstitute
should
// be called on the pattern with the appropriate FcConfig so that the
// configuration can define transformations to be applied on the pattern.
// LilyPond does this to define font aliases. Unfortunately, Pango has a
bug
// with this when using custom FcConfigs: it calls FcConfigSubstitute with
the
// global, default FcConfig instead of the font map's FcConfig. This is
// https://gitlab.gnome.org/GNOME/pango/-/issues/743 . Work around it by
// adding an extra function to transform the pattern, calling
// FcConfigSubstitute with the right FcConfig.
// pango_ft2_font_map_set_default_substitute is deprecated as of Pango 1.46
in
// favor of pango_fc_font_map_set_default_substitute, but we still support
// 1.44.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
pango_ft2_font_map_set_default_substitute (res, substitute_with_lily_config,
font_config_.get (), nullptr);
#pragma GCC diagnostic pop
```
it looks like Pango did not call the default substitute function.
I'm not yet sure how that could happen.
If Pango fails to correctly substitute values in the FcConfig, it could
potentially mean that it's passed with some fields uninitialized to Fontconfig.
That could explain why the error is not reproducible; the value of "color"
could be a random uninitialized boolean variable. But I'm not sure yet.
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
> > With lilypond 2.25.6 and your second patch applied, here are 2 .PDFs: first > is without the offending font installed, the second is the temporary file > produced when the font is present. > Thanks, but I am more interested in the log than the PDF for this one.
Re: Crash in 2.25.4
Le jeudi 25 mai 2023 à 19:06 -0600, Colin Campbell a écrit : > I believe we now have a Bingo! > > I d/l and built lilypond 2.25.5 from the website, and ran it against the > test file; it ran successfully. > > I re-installed the fonts-noto-color-emoji package, and ran lilypond > 2.25.5 again, which gave the error. > > I also ran 2.25.6 against the test file and it also broke. I've attached > the temporary .PDF which it tried to complete. > > I ran the test with your earlier FC_DEBUG=2025 ./out/bin/lilypond > --verbose --ps /Work/Non-Musical.ly > fclog.log 2> lilylog.log > > Archived files attached. > > Being cynical, I again removed the noto font, and lilypond 2.25.6 now > runs the test file without error. > > Clearly, there is some thing in that font file which doesn't agree with > lilypond's recent versions. Good that you can reproduce again. Now, can you try the patch with FcPatternPrint and send the log? (No need for FC_DEBUG or --verbose or --ps this time.) signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mercredi 24 mai 2023 à 20:31 -0600, Colin Campbell a écrit : > Applied this on top of your previous patch; let me know if you want it > done differently. > > Again, no problems applying, compiling lilypond, nor compiling the test > file. > > Resulting .PDF attached Sorry for not being clear: I would like you to apply this patch *on top of a configuration that fails*. I suppose you need to reinstall the fonts-noto-color-emoji package. (Same for the other patch, but this one is more important.) signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mercredi 24 mai 2023 à 09:08 +, Werner LEMBERG a écrit : > > So Pango is apparently requesting a font with colored glyphs from > > Fontconfig... > > A bug? Probably. So far, I've been unable to understand where this happens; "git grep FC_COLOR" yields no results in the Pango source code. signature.asc Description: This is a digitally signed message part
Re: repeat percent interferes with inline clef
Le dimanche 21 mai 2023 à 22:38 +0200, Peter Häring a écrit :
> % percent sign interferes with inline clef.
> % There is extra space for the clef,
> % but the percent sign is centered .
> % It should be positioned with the same padding
> % to the left bar line as the others.
> % Or: it should be centered in the space left of the clef.
>
> \version "2.23.3"
> {
> \clef violin
> \repeat percent 4 a'1
> \clef bass
> a,1
> }
>
Thanks, added as https://gitlab.com/lilypond/lilypond/-/issues/6614
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mardi 23 mai 2023 à 22:08 +0200, Jean Abou Samra a écrit :
> So Pango is apparently requesting a font with colored glyphs from
> Fontconfig...
Speaking of which, I would also be interested in the output with
```
diff --git a/lily/all-font-metrics.cc b/lily/all-font-metrics.cc
index dd8cfaa8f3..0a8efa4433 100644
--- a/lily/all-font-metrics.cc
+++ b/lily/all-font-metrics.cc
@@ -52,7 +52,9 @@ static void
substitute_with_lily_config (FcPattern *pat, void *config)
{
FcConfig *fcconfig = static_cast (config);
+ FcPatternPrint (pat);
FcConfigSubstitute (fcconfig, pat, FcMatchPattern);
+ FcPatternPrint (pat);
}
All_font_metrics::All_font_metrics (File_path search_path,
```
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mardi 23 mai 2023 à 21:15 +0200, Jean Abou Samra a écrit : > Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit : > > > Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it > > is a LilyPond or a Pango issue). > > I'm rather sure it's a Pango or Fontconfig issue. Ok, here's some progress. In Colin's fclog.log file, I read ``` Match Pattern has 29 elts (size 32) family: "C059"(s) "Century SchoolBook URW"(s) "C059"(s) "Century Schoolbook L"(s) "C059"(s) "TeX Gyre Schola"(s) "C059"(s) "DejaVu Serif"(s) [lots and lots of families trimmed ...] familylang: "en"(s) "en-us"(w) stylelang: "en"(s) "en-us"(w) fullnamelang: "en"(s) "en-us"(w) slant: 0(i)(s) weight: 80(f)(s) width: 100(i)(s) size: 3.86619(f)(s) pixelsize: 64.4365(f)(s) antialias: True(w) True(w) hintstyle: 1(i)(w) 1(i)(w) hinting: True(s) verticallayout: False(s) autohint: False(s) globaladvance: True(s) dpi: 1200(f)(w) rgba: 1(i)(w) 1(i)(w) lang: "und-zsye"(w) "en-us"(s) "en"(w) fontversion: 2147483647(i)(s) embeddedbitmap: True(s) decorative: False(s) lcdfilter: 1(i)(w) 1(i)(w) namelang: "en"(s) prgname: "lilypond"(s) color: True(w) <<<<<<<< ^^ symbol: False(s) variable: DontCare(s) order: 0(i)(s) pangoversion: 15012(i)(s) ``` So Pango is apparently requesting a font with colored glyphs from Fontconfig... signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mardi 23 mai 2023 à 21:15 +0200, Jean Abou Samra a écrit :
> Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit :
>
> > Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it
> > is a LilyPond or a Pango issue).
>
> I'm rather sure it's a Pango or Fontconfig issue.
Colin: it's really hard to debug this remotely (we might have to resort to VNC
or such, I'm afraid...) but there is one simple thing I would be interested in:
if you apply this patch, recompile LilyPond and redo the test, what happens?
```
diff --git a/lily/pango-font.cc b/lily/pango-font.cc
index 7fc7c35207..8f0750c463 100644
--- a/lily/pango-font.cc
+++ b/lily/pango-font.cc
@@ -523,7 +523,7 @@ Pango_font::text_stencil (Output_def * /* state */, const
std::string ,
= pango_attr_font_features_new (features_str.c_str ());
pango_attr_list_insert (list, features_attr);
}
- if (music_string)
+ if (true)
{
// For music fonts, falling back to text fonts is surprising.
PangoAttribute *fallback_attr = pango_attr_fallback_new (false);
```
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le lundi 22 mai 2023 à 08:07 +, Werner LEMBERG a écrit :
> Regarding (2) I'm not sure where exactly the problem lies (i.e., whether it
> is a LilyPond or a Pango issue).
I'm rather sure it's a Pango or Fontconfig issue.
Based on the fact that we use Pango's FreeType backend, which is not the focus
for Pango maintainers, I would not be surprised if this were an issue specific
to this part of Pango, in the same vein as
https://gitlab.gnome.org/GNOME/pango/-/issues/743
Our tagline is defined as
```
tagline = \markup {
\pad-to-box #'(0 . 0) #'(0 . 3)
{ \with-url
"https://lilypond.org/;
\line {
%% 2014 = em dash.
#(format #f "Music engraving by LilyPond ~a~awww.lilypond.org"
(lilypond-version)
(ly:wide-char->utf-8 #x2014)
)
}
}
}
```
The tagline text is one string, so we're text-layouting all in one call to
Pango. I see zero reason for Pango to split out the digits into separate items
with different fonts, since all the glyphs are in the requested C059 font.
Unfortunately, even with the fonts-noto-color-emoji package installed, I still
cannot reproduce this problem in an Ubuntu 23.04 VM.
signature.asc
Description: This is a digitally signed message part
Re: Crash in 2.25.4
(Adding back the bug list) Le samedi 20 mai 2023 à 17:51 -0600, Colin Campbell a écrit : > > I redid git bisect today, doing everything on the command line (I used > Frescobaldi last night). Each time, I ran " > > ``` > colin@Calvin:/Work/lilypond/lilypond$ cd build > colin@Calvin:/Work/lilypond/lilypond/build$ make SILENT=1 -j9 && make > bytecode > colin@Calvin:/Work/lilypond/lilypond/build$ ./out/bin/lilypond > /Work/Non-Musical.ly > ``` > > The result was > > > ## > > ``` > 18e26fa65af11ec236338e43cfe7c4968f087d7f is the first bad commit > commit 18e26fa65af11ec236338e43cfe7c4968f087d7f > Author: Jean Abou Samra [](mailto:j...@abou-samra.fr) > Date: Wed Apr 12 22:30:44 2023 +0200 > > Don't make our FcConfig the global one > ``` > > ### > > I gather, then, that a1b35793415e45f95a447184fac049fb1df15b73] > font-config.cc: Add comment > was the commit that git bisect applied last, and it produced expected output > from the command line, and also using Frescobaldi as a front end. > > I'm not sure this helps in any useful way; it seems unlikely that I would be > the only one affected if it were a problematic commit. Well, this stuff is closely tied to the font libraries LilyPond uses (Pango + HarfBuzz + FreeType + Fontconfig + Cairo) and the system font configuration, so it's something that definitely can get broken for some people while still working for others. > Unless you have other advice, I'm guessing that it would be simpler for me to > clean all trace of lilypond off my machine (I've probably got bits and pieces > of several prior installations, both from packages and locally compiled from > git), and start from a fresh, clean install. I've taken up more than enough > of your time, for which I'm most grateful, but your rather astonishing mind > is best employed on more important tasks. > > All this comes about as I'm thinking of getting back to some documentation > work, and wanted to compile docs locally. I'll still keep that goal in mind. If you can still reproduce the problem after this cleaning, could you run ``` FC_DEBUG=2025 build/out/bin/lilypond --verbose --ps test_file.ly > fclog.log 2> lilylog.log ``` and send the three resulting files, `test_file.ps`, `fclog.log` and `lilylog.log`? signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le vendredi 19 mai 2023 à 23:00 -0600, Colin Campbell a écrit : > The result of git bisect: > > 1db87a2537d6d5ef6631cfbda63954c0a6ee095 is the first bad commit > commit d1db87a2537d6d5ef6631cfbda63954c0a6ee095 > Author: Jonas Hahnfeld > Date: Mon Apr 3 22:57:26 2023 +0200 > > Doc: Avoid full stop in node names > > This propagates the changes from commit c245707e4f to the translations. > > Documentation/ca/learning/common-notation.itely | 2 +- > Documentation/de/learning/common-notation.itely | 2 +- > Documentation/es/learning/common-notation.itely | 2 +- > Documentation/it/learning/common-notation.itely | 2 +- > Documentation/ja/learning/common-notation.itely | 2 +- > 5 files changed, 5 insertions(+), 5 deletions(-) Uh, that does not make a lot of sense. This is purely a doc patch, it can't have caused a bug in LilyPond itself. Either the failure is flaky (but it didn't seem to be), or something is wrong in the way you bisected. In particular, are you sure that the commit you passed to "git bisect good" was a commit old enough to *not* reproduce the bug? Did you remember to call "make" at each iteration to recompile the C++ code? (Sorry if that's obvious.) signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le vendredi 19 mai 2023 à 21:00 +0200, Jean Abou Samra a écrit : > Can you try to find which commit introduced the problem for you, using 'git > bisect'? Alternatively: what's your Ubuntu version? I just installed a fresh Ubuntu 23.04 VM and compiled LilyPond in it but I cannot reproduce the problem. signature.asc Description: This is a digitally signed message part
Re: Issue with emacs 29
Thanks, filed as https://gitlab.com/lilypond/lilypond/-/issues/6609 Best Jean signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le vendredi 19 mai 2023 à 12:26 -0600, Colin Campbell a écrit : > > On 2023-05-19 11:03, Jean Abou Samra wrote: > > \version "2.25.5" > > > > #(define-markup-command (db layout props arg) (markup?) > > (let ((stil (interpret-markup layout props arg))) > > (pretty-print (ly:stencil-expr stil)) > > stil)) > > > > \markup \db abc > > Terminal output: > > ### > > colin@Calvin:/Work$ lilypond BugTest.ly > GNU LilyPond 2.25.5 (running Guile 2.2) > Processing `BugTest.ly' > Parsing...(utf-8-string > "LilyPond Serif 3.8662109375" > "abc" > (translate-stencil > (0.0 . 0.0) > (glyph-string > # > "C059-Roman" > 3.865234375 > #f > ((1.2291590551181102 > (-0.03300964259350393 . 1.0582424612450787) > 0.0 > 0.0 > 66 > "a") > (1.2291590551181102 > (-0.03300964259350393 . 1.6214403128075787) > 0.0 > 0.0 > 67 > "b") > (0.990155905511811 > (-0.03300964259350393 . 1.0582424612450787) > 0.0 > 0.0 > 68 > "c")) > "/usr/share/fonts/opentype/urw-base35/C059-Roman.otf" > 0 > "abc" > ((1 . 1) (1 . 1) (1 . 1) > > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > Converting to `BugTest.pdf'... > warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH > -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-9236892)' > failed (256) > > /usr/local/share/lilypond/2.25.5/ly/init.ly:66:2: error: Guile signaled > an error for the expression beginning here > # > (let ((book-handler (if (defined? 'default-toplevel-book-handler) > Throw to key `ly-file-failed' with args `()'. > > # > > No PDF produced. In the verbose log you sent initially, I see Initializing embedded CFF font list. Found file in search path: /usr/share/fonts/opentype/urw-base35/C059-Roman.otf -> /usr/share/fonts/opentype/urw-base35/C059-Roman.otf Embedding CFF font `C059-Roman'. [/usr/share/fonts/opentype/urw-base35/C059-Roman.otf] Found file in search path: /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf -> /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf [/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf] Right now, I have no idea why LilyPond is looking for the NotoColorEmoji font... Can you try to find which commit introduced the problem for you, using 'git bisect'? Thanks. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le vendredi 19 mai 2023 à 09:43 -0600, Colin Campbell a écrit : > > Of all the errors you posted, which one is it now? > ``` > colin@Calvin:/Work$ lilypond Non-Musical.ly > GNU LilyPond 2.25.5 (running Guile 2.2) > Processing `Non-Musical.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects... > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > Converting to `Non-Musical.pdf'... > warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH > -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-7461402)' failed > (256) > > /usr/local/share/lilypond/2.25.5/ly/init.ly:66:2: error: Guile signaled an > error for the expression beginning here > # > (let ((book-handler (if (defined? 'default-toplevel-book-handler) > Throw to key `ly-file-failed' with args `()'. > ``` Could you compile this and tell about the result, i.e., does it produce a PDF and what does it print in the log? ``` \version "2.25.5" #(define-markup-command (db layout props arg) (markup?) (let ((stil (interpret-markup layout props arg))) (pretty-print (ly:stencil-expr stil)) stil)) \markup \db abc ``` Thanks. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
> Thanks, Werner, for the suggestion. I just tried it, and lilypond still > errors as before. Of all the errors you posted, which one is it now?
Re: Crash in 2.25.4
Le jeudi 18 mai 2023 à 11:27 +0200, Jean Abou Samra a écrit : > Gwyn, is it convenient for you to test patches? I think I see what this is > caused by, but I cannot reproduce the bug in a local build (knowing what > exact compiler flags are used in Fedora's builds > might help). > I'd like to know if this fixes it: > [...] > > Thank you. Thanks for the info you provided privately. The fix https://gitlab.com/lilypond/lilypond/-/merge_requests/2007 has been merged. LilyPond 2.25.5 is planned for this weekend. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Gwyn, is it convenient for you to test patches? I think I see what this is caused by, but I cannot reproduce the bug in a local build (knowing what exact compiler flags are used in Fedora's builds might help). I'd like to know if this fixes it: ``` diff --git a/lily/all-font-metrics-scheme.cc b/lily/all-font-metrics-scheme.cc index 9a36407993..77fabc666b 100644 --- a/lily/all-font-metrics-scheme.cc +++ b/lily/all-font-metrics-scheme.cc @@ -24,7 +24,7 @@ All_font_metrics *all_fonts_global = nullptr; // GC-protects the all_fonts_global object. -SCM all_fonts_global_scm = SCM_UNDEFINED; +volatile SCM all_fonts_global_scm = SCM_UNDEFINED; LY_DEFINE (ly_reset_all_fonts, "ly:reset-all-fonts", 0, 0, 0, (), R"( ``` Thank you. signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
> I'm going nuclear tomorrow: delete my clone, and start over. No need to be *that* nuclear, you can just remove the build directory and start a fresh build.
Re: Crash in 2.25.4
> Le 18 mai 2023 à 05:49, Colin Campbell a écrit : > > Attached console output. I'll do a git pull and recompile a bit later, and > report what happens. Note that the same test file when compiled using > Frescobaldi as a front end, produces the following output: > > > Starting lilypond 2.25.5 [Non-Musical.ly]... > > programming error: unknown context mod tag > > continuing, cross fingers > > Processing `/Work/Non-Musical.ly' > > Parsing... > > Interpreting music... > > fatal error: No grob definition found for `NonMusicalPaperColumn'. > > Exited with return code 1. > > Same test file, same lilypond binary, different error message from running > lilypond on the command line. The only sane explanation I can think of for these errors is that you forgot to recompile LilyPond after a 'git pull'. In other words, you are running a version of the C++ code that is out of sync with the Scheme code.
Re: Crash in 2.25.4
Le mercredi 17 mai 2023 à 17:48 -0600, Colin Campbell a écrit : > Happens to me on Ubuntu as well: I don't think that's the same bug. Regarding this: > Fontconfig error: No writable cache directories This error popped up at some point during the current cycle before being fixed shortly thereafter. Maybe you compiled and installed LilyPond before the merge of https://gitlab.com/lilypond/lilypond/-/merge_requests/1978 ? > Processing `Non-Musical.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects... > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > Converting to `Non-Musical.pdf'... > warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH > -dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-4728954)' > failed (256) Could you please run with `lilypond --verbose` and send the output? Thanks, Jean signature.asc Description: This is a digitally signed message part
Re: Crash in 2.25.4
Le mercredi 17 mai 2023 à 20:02 +, Gwyn Ciesla via bug-lilypond a écrit : > Attaching reproducer. > > From Fedora bug: > > When I attempt to build a score using a PianoStaff or GrandStaff (which > contains more than one sub-staff), lilypond crashes. > > Reproducible: Always > > Steps to Reproduce: > 1. Attempt to build a minimal reproducer (which I will attach) with > lilypond-2.25.4 > Actual Results: > Slightly varying modes of crashing. > > #1) Without dumping core: > > --- 8< --- > nils@makake:~/music> lilypond minimal.ly > > GNU LilyPond 2.25.4 (running Guile 2.2) > Processing `minimal.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects... > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > /usr/share/lilypond/2.25.4/ly/init.ly:64:2: error: Guile signaled an error > for the expression beginning here > # > (let ((book-handler (if (defined? 'default-toplevel-book-handler) > In procedure scm_hash_fn_create_handle_x: Error while printing exception. > --- >8 --- > > #2) With dumping core: > > --- 8< --- > nils@makake:~/music> lilypond minimal.ly > > GNU LilyPond 2.25.4 (running Guile 2.2) > Processing `minimal.ly' > Parsing... > Interpreting music... > Preprocessing graphical objects... > Finding the ideal number of pages... > Fitting music on 1 page... > Drawing systems... > /usr/share/lilypond/2.25.4/ly/init.ly:64:2: error: Guile signaled an error > for the expression beginning here > # > (let ((book-handler (if (defined? 'default-toplevel-book-handler) > In procedure scm_hash_fn_create_handle_x: Wrong type argument in position 1 > (expecting hash-table): Segmentation fault (core dumped) > --- >8 --- > > Expected Results: > It builds a PDF from the score. > > - I get the same behavior on Fedora 38 and Rawhide. > - Using the lilypond-2.25.3 Fedora package _or_ the 2.25.4 binary from > upstream doesn’t exhibit the issue. Thank you for forwarding the report. I can reproduce it on my Fedora system. Apparently we're crashing while looking up the font for the system start brace, but I don't understand why yet. It's quite strange that this doesn't reproduce with the official binaries or local builds. Judging from the backtraces, there might be a memory corruption somewhere, but I have to find out. signature.asc Description: This is a digitally signed message part
Re: Unpredictable insertions of superfluous extra space between lines of lyrics
Le lundi 01 mai 2023 à 20:19 -0400, Connor Harris a écrit :
> I've discovered a bizarre bug (originally in LilyPond 2.22.1, confirmed in
> all versions up through 2.23.13 with reason to suspect that the underlying
> issue may still exist in later versions) with vertical spacing of lyrics.
> Under very specific, seemingly unpredictable conditions, LilyPond inserts
> several lines of extra space between two lines of lyrics attached to the
> same staff. See the below example, which (for reasons I'll discuss later)
> is about as minimal as I can get it. It's edited down from an engraving of
> the German folk song "Hoch auf dem gelben Wagen" that I was working on when
> I discovered it:
>
> ```
> \version "2.22.1"
>
> #(set-global-staff-size 18)
>
> music = \relative c' {
> \key f \major
> \time 4/4
> c4 f8 g a4 c | a4( g) f r |
> c4 f8 g a4 g | f2. r4 |
> c4 f8 g a4 c8 c | \break a4( g) f4 r4
> }
>
> verseOne = \lyricmode {
> Hoch auf dem gel -- ben Wa -- gen
> sitz’ ich beim Schwa -- ger vorn.
> Vor -- wärts die Ros -- se _ tra -- ben;
> }
>
> verseTwo = \lyricmode {
> Po -- stil -- lion an der Schen -- ke
> füt -- tert die Ros -- se~im Flug.
> Schäu -- men -- de Ger -- sten -- ge -- trän -- ke
> }
>
> \score {
> \new Staff { \music }
> \addlyrics {\verseOne}
> \addlyrics {\verseTwo}
> }
> ```
>
> What makes this bug bizarre, and why this example had to be so long, is
> that any number of tweaks, some of them only affecting a single note or
> character in the lyrics, will eliminate the excessive vertical spacing (but
> seemingly similar-looking tweaks won't). For instance, these changes fix
> the lyrics spacing:
>
> - Eliminating the forced break after measure 5. (This is where a line break
> naturally fell in my first engraving of the whole song, and why I
> discovered the bug in the first place.)
> - Adding another forced break anywhere before bar 5.
> - Changing the time signature to 2/4, leaving the note durations unchanged.
> - Changing the H in "Hoch", or the S in "Schenke" and "Schäumende", to
> lowercase (but not the P in "Postillion" or the W in "Wagen").
> - Changing the elision in "Ros -- se~im" to one word: "Ros -- seim"
> - Eliminating the curved apostrophe after "sitz"
> - Changing the g in "gelben" to uppercase (but not the first letters of
> several other lowercase words, such as "füttert"
> - Changing "dem", the third word in the first verse, to "den"
> - Changing the last note of the first measure (C5) to anything on or below
> the third line (that is, B4 or below). Raising instead of lowering that
> note leaves the space unaffected, as does changing other notes: for
> instance, changing that C5 to D5, or changing the preceding A4 to G4, leave
> the extra space unaffected
>
> I've tried to replicate this bug with several LilyPond versions and
> produced it in all versions up to 2.23.13; it doesn't seem to affect
> 2.23.14 and beyond. I considered it worth reporting nevertheless, because
> it seems so exquisitely context-dependent that even if my example doesn't
> exhibit it in later LilyPond versions, this may be due to other changes in
> LilyPond internals, not because the underlying problem in lyric spacing has
> been fixed.
>
> One final comment: I initially discovered this bug with three lines of
> lyrics, and it only affected the spacing between the second and the third;
> the first and second lines were spaced as they should be.
>
Thank you for the detailed and informative bug report.
The problem looks a lot like [issue
#6432](https://gitlab.com/lilypond/lilypond/-/issues/6432) to me. It has
therefore been fixed (didn't just disappear by accident) in version 2.23.14.
Best,
Jean
signature.asc
Description: This is a digitally signed message part
Re: convert-ly 2.25.3 problem
Le jeudi 13 avril 2023 à 20:30 +0200, Craig Fearing a écrit :
> In the attached, fairly minimized file:
>
> \version "2.18.2"
>
> \layout {
> \context { \Lyrics \override LyricText #'font-size = #1.8 }
> }
>
> If I try to update to 2.25.*3* (using the tool in Frescobaldi 3.1.3) I
> get a "not changed" response.
>
> If I change to 2.25.*2* I get the expected result, except that the
> version is set to 2.25.*1*
>
> I tried once more with 2.23.82 which set the version number to 2.23.*14
> *but I didn't go further.
>
> I have attached text files showing the results.
>
> My system is Win10 last updated yesterday.
Thanks for reporting. Werner, can you take a look please? It appears that
4494a12ec8d3408981b26f4dc4040e2f985da06f breaks `convert-ly -` to read stdin
(on Windows).
signature.asc
Description: This is a digitally signed message part
Re: convert-ly No module named 'convertrules'
Le samedi 08 avril 2023 à 11:30 -0400, Pierre-Luc Gauthier a écrit : > I've just compiled 3123dcf1 and I running /usr/bin/convert-ly returns : > > Traceback (most recent call last): > File "/usr/bin/convert-ly", line 82, in > import convertrules > ModuleNotFoundError: No module named 'convertrules' > > Thought I'd mention it. :-) How did you install your self-compiled LilyPond? I would expect `make install` to install into `/usr/local/bin/`, not into `/usr/bin/`. > P.S.: Nice work Jean on d36bb95 ! This is awesome ! Thanks :) That was a lot of work... signature.asc Description: This is a digitally signed message part
Re: \autoChange behaves inconsistently when rests are present
Le samedi 08 avril 2023 à 18:39 +0100, Gilberto Agostinho via bug-lilypond a écrit : > Hi all, > > I've came across a strange bug with \autoChange which was not present in > version 2.22.2 but is present in version 2.24.1 (and was probably > introduced somewhere in between these two versions). That looks problematic indeed. I've filed an issue: [https://gitlab.com/lilypond/lilypond/-/issues/6575](https://gitlab.com/lilypond/lilypond/-/issues/6575) Thank you for the detailed bug report, which I could paste almost as-is into the issue description. signature.asc Description: This is a digitally signed message part
Re: "\version outdated" makes little sense for internal files
[https://gitlab.com/lilypond/lilypond/-/issues/6565](https://gitlab.com/lilypond/lilypond/-/issues/6565) signature.asc Description: This is a digitally signed message part
Re: "\version outdated" makes little sense for internal files
Le lundi 03 avril 2023 à 21:32 +0200, David Kastrup a écrit :
>
> dak@lola:/usr/local/tmp/lilypond$ lilypond scheme-sandbox
> GNU LilyPond 2.25.0 (running Guile 2.2)
> Processing `/usr/local/share/lilypond/2.25.0/ly/scheme-sandbox.ly'
> Parsing...
> GNU Guile 2.2.7
> Copyright (C) 1995-2019 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(#{ g217}#)> #{ - #}
>
> :1:3: error: syntax error, unexpected end of input, expecting \etc
> -
>
> /usr/local/share/lilypond/2.25.0/ly/scheme-sandbox.ly:34:2: error: error in
> #{ ... #}
> #
> (cond-expand
> scheme@(#{ g217}#)>
>
>
> Note: compilation failed and \version outdated, did you
> update input syntax with convert-ly?
>
>
> [https://lilypond.org/doc/v2.25/Documentation/usage/updating-files-with-convert_002dly](https://lilypond.org/doc/v2.25/Documentation/usage/updating-files-with-convert_002dly)
>
> fatal error: failed files: "scheme-sandbox"
Well, “Success: compilation successfully completed” at the end of a
scheme-sandbox run does not make a whole lot of sense either. Perhaps we should
reimplement "lilypond scheme-sandbox" in a way that does not use a
scheme-sandbox.ly file.
signature.asc
Description: This is a digitally signed message part
Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)
Le mercredi 29 mars 2023 à 07:18 +1100, Grant Diffey a écrit :
> To clarify I'm transcribing vaticana using a 'modern' staff and beaming for
> melisma none of the staff types support modern beamed 8th notes. this is the
> convention in the church music I'm scoring (vaticana original) + modern
> transcription using beaming to 'replicate' numesin fact a common structure
> for this is a combined staff which I've been unable to replicate in lilypond
> so far.{
> vaticana
> lyrics
> accompaniment with melody replicating the numes using 8th note beaming
> }
> (in fact this is the score of the chant in front of me for palm sunday)
This sounds like a question for the user list (lilypond-u...@gnu.org) more than
like a bug report.
signature.asc
Description: This is a digitally signed message part
Re: Auto-beaming issues
(CCing Jason Yip, who may be interested in this as part of this GSoC
application on the auto-beaming project.)
Le mardi 28 mars 2023 à 14:50 +0200, Mats Bengtsson a écrit :
> Hi,
>
> I know that there are several old bug reports on auto-beaming, but I've
> come across a couple of problems that are not necessarily covered by
> the existing reports.
>
> Problem 1: Automatic beaming doesn't always work if a voice context
> ends in the wrong place. This might be closely related to #4690, but
> I'm not sure. Example:
>
> \version "2.24.0"
> \score{
> \new Voice \fixed c' {
> << { e8 f } \\ c4 >> g2. | % Autobeaming fails!
> << { e8 f g f } \\ c2 >> g2 | % Autobeaming successful!
> << { e8 f g f e f } \\ c2. >> g4 | % Autobeaming fails!
> << { e8 f g f e f g f } \\ c1 >> | % Autobeaming successful!
> }
> }
The `<< \\ >>` create new voice, and each Voice context has its own beaming
engravers. It works if you make one of the Voice contexts continue from the
polyphonic passage into the monophonic one.
```
\version "2.24.1"
\new Voice \fixed c' {
<<
{ \voiceOne e8 f } %% no \new Voice !
\new Voice { \voiceTwo c4 }
>>
\oneVoice
g2.
}
```
I don't think it's possible to make your input "just work" because
```
\version "2.24.1"
\new Voice \fixed c' {
<<
{ e8 8 8 }
\\
{ c8 8 8 }
>>
d
}
```
does not tell if it should be engraved as
```
\version "2.24.1"
\new Voice \fixed c' {
<<
{ \voiceOne e8 8 8 }
\new Voice { \voiceTwo c8 8 8 }
>>
\oneVoice
d
}
```
or
```
\new Voice \fixed c' {
<<
\new Voice { \voiceOne e8 8 8 }
{ \voiceTwo c8 8 8 }
>>
\oneVoice
d
}
```
So, no bug here from my point of view.
>
> Another example of the same problem is
> \version "2.24.0"
> \score{
> \fixed c' { \partial 4 e8 | f e f g f e f \fine }
> }
Not sure if this one is already registered in the tracker, there are many
beaming issues...
> Problem 2: The current logic which only provides rules on when a beam
> should be ended, obviously provides limited possibilities to express
> the beaming patterns. I was recently typesetting some 18th century
> music where I wanted to imitate the original beaming patterns, where in
> 4/4, 16th triplets and 32nd notes were beamed in half beats, but where
> patterns like 8. 32 32 were beamed together. Unfortunately that cannot
> be handled by the current logic, but the following example is extra
> ugly since also the two eighth notes in the first beat don't get any
> beam:
>
> \version "2.24.0"
> \score{
> \fixed c' {
> a8 g f8.-\trill ( e32 f ) e32 f g f e f g f e4 |
> }
> \layout{
> \context {
> \Score{
> \overrideTimeSignatureSettings
> 4/4 % timeSignatureFraction
> 1/4 % baseMomentFraction
> 1,1,1,1 % beatStructure
> #'((end . ((1/8 . (4 4)) ; 1/8 notes half measure
> (1/12 . (3 3 3 3)) ; triplets and shorter by beat
> (1/24 . (3 3 3 3 3 3 3 3 )) ; 16th triplets and
> shorter by half beats
> )))
> }
> }
> }
> }
>
> Fortunately, in this specific example, it's actually enough to manually
> beam the second beat, in order to get an automatic beam on the first
> beat:
> a8 g f8.-\trill [ ( e32 f ) ] e32 f g f e f g f e4 |
>
> Feature request: It would of course be desirable to have more rich
> possibilities to express beaming patterns, where I for example would be
> able to express beaming patterns so that the previous example
> automatically gives the same as
>
> \score{
> \fixed c' {
> a8 [ g ] f8.-\trill [ ( e32 f ) ] e32 [ f g f ] e [ f g f ] e4 |
> }
> }
Sounds interesting. You understand more about this topic than I do, maybe
create the tracker issue yourself?
signature.asc
Description: This is a digitally signed message part
Re: Gregorian.ly bar forms being converted to wrong glyph (regression between 2.22 and 2.24)
Le mardi 28 mars 2023 à 12:54 +1100, Grant Diffey a écrit :
> The following example:
>
> \include "gregorian.ly"
> { c' \divisioMaior d' \finalis }
>
> Renders 'correctly' in 2.22 (using hacklily)
> and incorrectly on my debian machine with Lilypond 2.24
Dan?
signature.asc
Description: This is a digitally signed message part
Re: Apply @code{} to two instances of `\book` in NR
Jason,
Le lundi 27 mars 2023 à 22:35 -0500, Jason Yip via bug-lilypond a écrit :
> In NR 3.2.1 "Structure of a score", 2 references to the `\book` command
> are not in a `@code{}` command in the 2nd last paragraph.
>
>
> diff --git a/Documentation/en/notation/input.itely
> b/Documentation/en/notation/input.itely
> index f7a6ea6..9e7bfd3 100644
> --- a/Documentation/en/notation/input.itely
> +++ b/Documentation/en/notation/input.itely
> @@ -235,7 +235,7 @@ block, and inside or outside the single music
> expression within a
> @code{\score} block.
>
> Remember that even in a file containing only a @code{\score} block, it
> -is implicitly enclosed in a \book block. A \book block in a source
> +is implicitly enclosed in a @code{\book} block. A @code{\book} block
> in a source
> file produces at least one output file, and by default the name of the
> output file produced is derived from the name of the input file, so
> @file{fandangoforelephants.ly} will produce
The (old) instructions given in the Contributor's Guide are intended to make it
easy for non-technical people to contribute to the documentation.
If you are comfortable with GitLab, it is much simpler to submit a merge
request.
Best,
Jean
signature.asc
Description: This is a digitally signed message part
Re: I would like to fix some documentation issues
Le lundi 27 mars 2023 à 18:06 -0500, Jason Yip via bug-lilypond a écrit : > Hi, I'm following the steps listed at > [https://lilypond.org/doc/v2.25/Documentation/contributor/introduction-to-issues](https://lilypond.org/doc/v2.25/Documentation/contributor/introduction-to-issues) > > to get started. > > My gitlab id: ljyip Good idea. However, I suggest to post this to lilypond-devel; some developers don't monitor the bug list. signature.asc Description: This is a digitally signed message part
Re: Documentation Clarification
Le dimanche 05 mars 2023 à 23:38 -0700, Alexandre Loomis a écrit : > In Notation Reference 5.3.4 - the \tweak command, the sentence > > "Tweaking a whole chord *does not do anything *since its music event only > acts as a container, and all layout objects are created from events inside > of the EventChord:" > > is misleading or incorrect. In the example directly following the sentence, > it does do something, it affects the entire chord. A possible change to the > phrasing would be > > "Tweaking a whole chord *may not have the expected effect* since its music > event only acts as a container, and all layout objects are created from > events inside of the EventChord:" Thank you, I submitted https://gitlab.com/lilypond/lilypond/-/merge_requests/1880 to fix this. signature.asc Description: This is a digitally signed message part
Re: Melody_engraver and tied notes
Le mardi 28 février 2023 à 12:41 +0100, Simon Albrecht a écrit :
> Hello everyone,
>
> Melody_engraver readily sets different stem directions either side of a
> tie. I don’t think it should do that.
>
> %
> \version "2.25.2"
>
> \layout {
> \context {
> \Voice
> \remove Note_heads_engraver
> \consists Completion_heads_engraver
> \consists Melody_engraver
> }
> }
> \relative {
> d''2. b4~ 4 g2 b2 d2.
> }
> %%
>
> Technically, not a minimal example, since Completion_heads_engraver
> isn’t really related. I just figured I include it to be safe, in case
> behaviour differs in any way with regard to potential fixes.
Thanks, https://gitlab.com/lilypond/lilypond/-/issues/6553
signature.asc
Description: This is a digitally signed message part
Re: Figured bass brackets under figures instead of around them when not within a FiguredBass context
Le lundi 27 février 2023 à 15:25 +0200, Valter Maasalo a écrit :
> Figured bass brackets should go around the figures, not below them. This
> happens when the figures are not on their own line in a FiguredBass context,
> but in a Staff.
>
>
>
>
> \version "2.25.1"
> \figuremode {
> <[6] 5>
> }
Thank you, opened https://gitlab.com/lilypond/lilypond/-/issues/6552
signature.asc
Description: This is a digitally signed message part
Re: Cross staff Glissando or VoiceFollower over page break messes up staff spacing
Le vendredi 10 février 2023 à 16:16 -0800, Saul Tobin a écrit : > Just want to follow up — is there an issue tracked for this one? Thanks Sorry for the long delay. I just did a round of issue-opening, this one is now https://gitlab.com/lilypond/lilypond/-/issues/6551 signature.asc Description: This is a digitally signed message part
Re: Bug report (slur positions in a magnifyStaff situation)
Le mardi 29 novembre 2022 à 23:42 +, Dominic Irving a écrit :
> %{
> The positions property of the slur is in units of staff-spaces,
> but this calculation should be scaled according to the current
> 'magnifyStaff' value.
>
> Expected behaviour: the scores all look identical, except rendered at
> different sizes.
> Actual behaviour: the slurs are in different places
> %}
>
> \version "2.23.80"
> music = { c'' \tweak positions #'(3 . 4) ( ees'') }
> \score { \new Staff \music }
> \score { \new Staff \with { \magnifyStaff #1/2 } \music }
> \score { \new Staff \with { \magnifyStaff #2/1 } \music }
Sorry for the very long delay, I think your bug report was just forgotten. I
have opened https://gitlab.com/lilypond/lilypond/-/issues/6549 for this.
signature.asc
Description: This is a digitally signed message part
Re: Custos_engraver crash with no explicit pitches
Le vendredi 17 mars 2023 à 16:12 +0100, Simon Albrecht a écrit :
> Hello everyone,
>
> found this while creating a minimal example. The following code crashes
> on both 2.24.0 and 2.25.2:
>
>
> \version "2.24.0"
>
> \new Staff \with {
> \consists Custos_engraver
> } { 1 \break r1 1 }
>
>
> Not sure it’s ever going to trigger in real-life situations, but it’s a
> crash without error handling. “Output code 11.”
Thanks, but you already reported that bug about a year ago. See
[https://lists.gnu.org/archive/html/bug-lilypond/2022-04/msg00021.html](https://lists.gnu.org/archive/html/bug-lilypond/2022-04/msg00021.html)
and [issue 6327](https://gitlab.com/lilypond/lilypond/-/issues/6327).
signature.asc
Description: This is a digitally signed message part
Re: Standard paper size too big
> Le 3 mars 2023 à 11:45, Jean Abou Samra a écrit : > > >> >> Le vendredi 03 mars 2023 à 11:26 +0100, Ruben du Pon a écrit : >> >> That may be the case, but as I said when I print straight from Frescobaldi >> the score doesn't fit the page (the bottom staff is mostly missing) and when >> I open it in acrobat reader it fits at 89%, so something is off about the >> paper size. >> > I don't think so. Try printing any A4 document from Acrobat or Frescobaldi > and seeing if you get the same behavior. Pretty sure you will. Then you > should either find the proper settings in Acrobat (I don't have it), or in > Frescobaldi, or write a bug report to Frescobaldi. From LilyPond's point of > view, I don't see anything wrong here. > Also, make sure your are printing to A4 paper. US letter paper is about 2cm less than A4 in height, so if your printer dialog is trying to fit A4 into US letter, that could indeed crop the bottom.
Re: Standard paper size too big
Le vendredi 03 mars 2023 à 11:26 +0100, Ruben du Pon a écrit : > That may be the case, but as I said when I print straight from Frescobaldi > the score doesn't fit the page (the bottom staff is mostly missing) and when > I open it in acrobat reader it fits at 89%, so something is off about the > paper size. I don't think so. Try printing any A4 document from Acrobat or Frescobaldi and seeing if you get the same behavior. Pretty sure you will. Then you should either find the proper settings in Acrobat (I don't have it), or in Frescobaldi, or write a bug report to Frescobaldi. From LilyPond's point of view, I don't see anything wrong here. signature.asc Description: This is a digitally signed message part
Re: Standard paper size too big
(Please keep the list CCed) Le vendredi 03 mars 2023 à 11:08 +0100, Ruben du Pon a écrit : > I am using Frescobaldi. If I print straight from there the score doesn't fit > the paper. If I open the pdf in Acrobat Reader and print with the 'fitting' > setting it adjusts to 89%. If I print at 100% it doesn't fit the page. > I will attach the .ly and .pdf files in case that helps anything. If I open your PDF file in Evince, it says “A4, portrait (210 × 297 mm)” in the document properties. signature.asc Description: This is a digitally signed message part
Re: Standard paper size too big
Le vendredi 03 mars 2023 à 10:31 +0100, Ruben du Pon a écrit : > Hi! > I just made a score using Lilypond. > However, when printing I need to print the pdf at 90% scale to fit it to > standard A4 paper. > According to the documentation A4 should be the standard paper size, and I > did not change any defaults. Most likely, the software you're using to print the score is enforcing certain margins without accounting for the existing that the document already has. I cannot really think of any other sane explanation, A4 definitely is LilyPond's default paper size. signature.asc Description: This is a digitally signed message part
Re: 2.25.1 bug
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. signature.asc Description: This is a digitally signed message part
Re: Cross staff Glissando or VoiceFollower over page break messes up staff spacing
On 05/02/2023 22:13, Saul Tobin wrote:
> \version "2.24.0"
>
> \paper {
> ragged-bottom = ##t
> }
>
> \layout {
> \context {
> \Score
> \override Glissando.breakable = ##t
> \override Glissando.after-line-breaking = ##t
> }
> }
>
> global = {
> s1
> \pageBreak
> s1
> }
>
> music = \relative c, {
> \clef bass
> f1\glissando |
> \change Staff = "RH"
> f'''1 |
> }
>
> <<
> \new Staff \global
> \new PianoStaff <<
> \new Staff = "RH" \global
> \new Staff = "LH" << \global \music >>
> >>
> \new Staff \global
>>>
>
> Same behavior with VoiceFollower as with Glisssando
Gosh. That is
commit f511d98c65e46aa30dbd27c0d93cde1d24b974f9 (HEAD)
Author: Jean Abou Samra
Date: Sun Jul 17 19:27:10 2022 +0200
Fix page references to labels straddling at a page break
They were handled inconsistently when the book contained several
bookparts because the whole alist was reversed instead of just the
part for the local bookpart, leading to several reversals for the same
alist part. Merge the two loops, addressing a TODO and incidentally
leading to nothing special needing to be done for ensuring a
consistent order.
Fixes #6301
I'll check how to fix this later.
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: Error in Extending Lilypond example
On 01/02/2023 11:12, Jean Abou Samra wrote: > Saul, > > >> Le 1 févr. 2023 à 04:16, Saul Tobin a écrit : >> >> 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): (). > > > Thanks for the report. I suppose you did not realize that this “Extending > LilyPond” resource is not part of the official documentation, it’s something > I wrote up and maintain externally (unlike the official Extending Manual, > which lives at > https://lilypond.org/doc/v2.24/Documentation/extending/index.html > <https://lilypond.org/doc/v2.24/Documentation/extending/index.html>). Thus, > any feedback you have should be sent to me privately, not to the bug list. Should be fixed now. OpenPGP_signature Description: OpenPGP digital signature
Re: Error in Extending Lilypond example
> Le 1 févr. 2023 à 11:23, Thomas Morley a écrit : > > 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, It’s this: https://gitlab.com/lilypond/lilypond/-/commit/7a09ffee2c69ab9617289afd21dae1b9198a9fee Perfectly intentional. Also, reading it in initialize was a bad idea in 2.22 in the first place. That creates a dependency on the order in which engravers are \consists-ed between your engraver and Paper_column_engraver. I’ll fix it by doing it in the first run of process-music. It should have been like that in the first place.
Re: Error in Extending Lilypond example
Saul, > Le 1 févr. 2023 à 04:16, Saul Tobin a écrit : > > 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): (). Thanks for the report. I suppose you did not realize that this “Extending LilyPond” resource is not part of the official documentation, it’s something I wrote up and maintain externally (unlike the official Extending Manual, which lives at https://lilypond.org/doc/v2.24/Documentation/extending/index.html). Thus, any feedback you have should be sent to me privately, not to the bug list. Best, Jean
Re: bogus warning with defineBarLine
On 30/01/2023 05:36, David Zelinsky wrote: > Is there any benefit in adding a regression test? It compiles > correctly, it's just the warning that is bogus. Is this detected in > regressing testing? Yes, the log is captured for each test. If the log differs in a "make check" run, it will be shown with a diff, just like a change in the images displays an "image diff". If the test is really intended to check that there are no warnings, you can put #(ly:set-option 'warning-as-error) at the beginning, to ensure it errors out (thus failing the make check run entirely) if there is a warning. Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Interaction of slurs and bar checks
On 25/01/2023 15:10, Michael Käppler wrote:
> Hi all,
> I'm posting to bug-lilypond instead of opening an issue in the tracker,
> because
> I'm not sure if the behaviour is somehow intended or a bug.
> Consider the following example:
>
> \version "2.24.0"
> {
> \time 2/4
> d''8 r e''4 |
> ( cis''16 ) cis'' d'' d''
> }
>
> It gives a warning "Unattached SlurEvent" and does not print a slur.
>
> Removing the bar check gives the correct rendition.
>
> What also works is:
>
> \version "2.24.0"
> {
> \time 2/4
> d''8 r e''4 ( |
> cis''16 ) cis'' d'' d''
> }
>
> i.e. moving the opening parenthesis before the bar check.
>
> This behaviour is not new, 2.20.0 behaves exactly the same.
> At least NR 1.2.5 does not mention such a kind of interaction.
> Am I missing something?
Why do you expect the first one to work... ?
A slur is a post-event. It attaches to a note. A bar check is not a post-event.
The first example is trying to attach a slur to a bar check. The failure seems
quite logical to me.
Best,
Jean
OpenPGP_signature
Description: OpenPGP digital signature
Re: \key\default crashes midi output
Le 15/01/2023 à 05:47, Saul Tobin a écrit :
\version "2.24.0"
\score {
\new Staff {
\key f \major
c'1
\key \default
c'1
}
\midi {}
}
This crashes with "In procedure cdar: Wrong type (expecting pair): ()" as
far back as 2.14.2.
Thanks, this is now
https://gitlab.com/lilypond/lilypond/-/issues/6522
OpenPGP_signature
Description: OpenPGP digital signature
Re: Ottavation marks incorrect using \set Staff.ottavationMarkups = #ottavation-ordinals
Le 15/01/2023 à 11:30, Heiko Schill a écrit : Hi all, when using "\set Staff.ottavationMarkups = #ottavation-ordinals", the ottavation bracket marks read 8va/15ma/etc. for the negative ottavation. When using " \set Staff.ottavationMarkups = #ottavation-simple-ordinals" everything is engraved correctly. This is working as expected. Please see https://lists.gnu.org/archive/html/bug-lilypond/2022-04/msg00034.html Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: defineBarLine truncates bartype when span is #f
[Forgot the list, apologies!]
Le 14/01/2023 à 00:52, David Zelinsky a écrit :
In { \defineBarLine bartype #'(end begin span) }
when `span' is `#f', only the first character of `bartype' is used.
Here is an example:
-
\version "2.24.0"
{
\defineBarLine ";|" #'(#t #t #f)
a'1 \bar ";|" b'1 \bar
}
-
This produces a single dotted barline, rather than a dotted-solid
combination as expected.
The explanation is in the definition of bar-line::compound-bar-line on
line 710 of bar-line.scm (the version in 2.24.0, though the current
version in git repository has the same feature). In the initializations:
(let* ...
(span-glyph (get-span-glyph bar-glyph))
(span-glyph-list (string->string-list span-glyph))
when span-glyph is #f, string->string-list returns '(""), a list of
length one. Then further down, the for-each loops over the pair
bar-glyph-list span-glyph-list
and so does just one pass.
A reasonable fix seems to be to add these two lines to the definition of
get-span-glyph, right before the existing "if" statement (line 59 in
version 2.24.0):
(if (and (boolean? span-glyph) (not span-glyph))
(set! span-glyph ""))
[Maybe there's a better way to test if span-glyph is #f --- my knowledge
of scheme is pretty rudimentary!]
Then when span is #f, get-span-glyph will return a list of spaces of
length equal to the length of bar-glyph, which will do the right thing.
This doesn't have any effect on span-bar::compound-bar-line, which does
not use get-span-glyph, but calls
(assoc-get bar-glyph span-bar-glyph-alist)
directly.
Thanks, added as https://gitlab.com/lilypond/lilypond/-/issues/6521
By the way, would you be willing to submit the fix yourself? Read
https://lilypond.org/doc/v2.25/Documentation/contributor/working-with-source-code
on how to proceed.
OpenPGP_signature
Description: OpenPGP digital signature
Re: music2xml script, musicexp.py, self.short_indent/char_per_cm, and a division by zero
Le 30/12/2022 à 15:09, James Wilkinson a écrit : Hello everyone, Firstly, thank you for all your work on Lilypond, and a very Happy New Year! I hope this is the right place to report bugs with musicxml2ly (version 2.23.82, from Fedora). In musicexp.py, in class Paper, def print_ly(self, printer), there is this snippet: char_per_cm = (len(self.get_longest_instrument_name()) * 13) / self.page_width if self.indent != 0: self.print_length_field(printer, "indent", self.indent/char_per_cm) if self.short_indent != 0: self.print_length_field( printer, "short-indent", self.short_indent/char_per_cm) It’s possible for there not to be a longest instrument name, char_per_cm to be zero, self.short_indent not to be zero, and the final division to raise a divide-by-zero error. A very minimal “fix” of if self.short_indent != 0 and char_per_cm != 0: enabled me to run the conversion. The error message from the original version was this: $ musicxml2ly Good_Christian_Men.mxl musicxml2ly: Reading MusicXML from Good_Christian_Men.mxl ... musicxml2ly: Input file Good_Christian_Men.mxl is compressed, extracting raw MusicXML data musicxml2ly: Converting to LilyPond expressions... musicxml2ly: Converting to LilyPond expressions... musicxml2ly: Converting to LilyPond expressions... musicxml2ly: Converting to LilyPond expressions... musicxml2ly: Output to `Good_Christian_Men.ly' Traceback (most recent call last): File "/usr/bin/musicxml2ly", line 3482, in main() File "/usr/bin/musicxml2ly", line 3475, in main voices = convert(filename, options) ^^ File "/usr/bin/musicxml2ly", line 3372, in convert paper_information.print_ly(printer) File "/usr/share/lilypond/2.23.82/python/musicexp.py", line 1026, in print_ly printer, "short-indent", self.short_indent/char_per_cm) ~^~~~ ZeroDivisionError: float division by zero The file is available at https://www.cpdl.org/wiki/images/f/f9/Good_Christian_Men.mxl . Thanks for your time, and hope this helps, Thanks, this is now https://gitlab.com/lilypond/lilypond/-/issues/6518 Since the fix looks quite simple, would you be willing to submit the corresponding patch yourself? Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: MMRs + system breaks + keepAliveInterfaces
Le 13/01/2023 à 23:59, Jean Abou Samra a écrit : Thanks, this is now https://gitlab.com/lilypond/lilypond/-/issues/6518 Sorry, wrong link: https://gitlab.com/lilypond/lilypond/-/issues/6519 OpenPGP_signature Description: OpenPGP digital signature
Re: MMRs + system breaks + keepAliveInterfaces
Le 09/01/2023 à 17:29, Saul Tobin a écrit :
Setting keepAliveInterfaces at the beginning or end of a system with an MMR
immediately preceding or following "bleeds over" into the wrong system if
rests were considered "worth living" on either side.
\layout {
\context {
\Score
keepAliveInterfaces = #'(stem-interface
note-head-interface
rest-interface
)
}
}
% Ex 1
\new Staff \with {
\override VerticalAxisGroup.remove-empty = ##t
\override VerticalAxisGroup.remove-first = ##t
} {
R1
\set Staff.keepAliveInterfaces = #'()
\break
c'1
}
% Ex 2
\new Staff \with {
\override VerticalAxisGroup.remove-empty = ##t
\override VerticalAxisGroup.remove-first = ##t
} {
\set Staff.keepAliveInterfaces = #'()
c'1
\unset Staff.keepAliveInterfaces
\break
R1
}
Thanks, this is now https://gitlab.com/lilypond/lilypond/-/issues/6518
OpenPGP_signature
Description: OpenPGP digital signature
