Fw: [gnu-soc] GNU accepted in GSOC 2023

We should now revise our GSoC page... Werner --- Begin Message --- Hello people! The GNU Project has been accepted as a mentoring organization in the Google Summer of Code program, 2023. This is what we have to do now: - If your GNU program wants to participate, please send project idea

Re: Ghostscript and new PDF interpreter

Six weeks ago I wrote about a very unpleasant size increase of `notation.pdf` from 8MByte to 27MByte with the new PDF engine of `gs`: >>> I'll soon file a bug report for GS regarding the size issue. >> >> This is now >> >> https://bugs.ghostscript.com/show_bug.cgi?id=706316 > > The GS peopl

convert-ly warnings too global

If I do ``` convert-ly en/notation/rhythms.itely > /dev/null ``` I get the following two warnings. ``` Not smart enough to convert music following \fine. Warning: \fine no longer enforces the end of the music. If your piece has music following \fine that you want to exclude when it is unfol

Re: convert-ly warnings too global

>> If I do >> >> ``` >> convert-ly en/notation/rhythms.itely > /dev/null >> ``` >> >> I get the following two warnings. >> >> >> ``` >> Not smart enough to convert music following \fine. >> >> Warning: \fine no longer enforces the end of the music.  If your piece >> has music following \fine t

Re: RFC: stop doing "grand replace" updates to copyright years

> I have uploaded a draft for my currently preferred approach to a > branch on my GitLab fork. Thanks for working on this! > and copyright headers like this: [...] > > + This file was mainly authored by: > + David Nalesnik > + Thomas Morley > + Dan Eble > + Jonas

removing `--show-rules` option of `convert-ly`?

Folks, who has ever used option `--show-rules` of `convert-ly`, except for being curious what this option does? In https://gitlab.com/lilypond/lilypond/-/merge_requests/1854 we are discussing whether it would make sense to remove it. Please comment. Werner

Running `convert-ly` under Windows

Right now I'm updating chapter 2 of the Usage manual (handling `convert-ly`). In section 2.4 I find the following. When running `convert-ly` in a command prompt window under Windows on a file that has spaces in the filename or in the path to it, it is necessary to surround the entire inpu

Re: Lilypond for Apple Processor

> Well, what I was trying to say, and what I probably should have made > more explicit, is that "official" binaries from our side require a > bit of work. In fact, the support in our scripts needs to be dealt > with in advance, so "patches welcome" *hint, hint*. Apple wants that binaries for Ap

Re: Lilypond for Apple Processor

> Apple wants that binaries for Apple machines are built on Apple > hardware. What about cross-compiling M1 stuff on a non-M1 system? > Would this be a possible solution? I mean a non-M1 macOS system. Werner

Make gitlab automatically add MR ID to commit message(s)?

I think it would be beneficial if the original MR ID gets added to the commit message(s). Is this possible? In many cases there is some useful discussion that might help better understand code issues. Ideally, the 'merge request' button would do that. Werner

Differences in `web.html`

Comparing http://lilypond.org/web.html with a self-compiled .../out-www/offline-root/Documentation/web/web.html I see the attached difference. Is it an oversight that `scripts/build/fix-docsize.sh` is not executed while building the website on 'lilypond.org'? Werner PS: That we no

Re: Differences in `web.html`

Jonas wrote: >> I see the attached difference.  Is it an oversight that >> `scripts/build/fix-docsize.sh` is not executed while building the >> website on 'lilypond.org'? > > Yes, intentionally so: "make website" does not execute it because it > doesn't have access to the linked manuals and cann

Re: Make gitlab automatically add MR ID to commit message(s)?

> The method I use is to go to > [https://gitlab.com/lilypond/lilypond/-/commits/master](https://gitlab.com/lilypond/lilypond/-/commits/master) > and search for the commit's title line using the search box in the > top right. For example, OK, thanks! Werner

Re: Strange difference between release and self-compiled binary on "2" glyph

> This is the output of > \markup \number 2 > using the official 2.25.2 Linux binaries on the one hand, and a > self-compiled build made on the v2.25.2 tag from a clean directory > on the other hand (PS backend in both cases). My self-compiled LilyPond produces the 'other' glyph version (i.e., no

Re: Musings on the font-encoding property

> 1. Look up `font-family`. If it's `music`, then use the music font, >otherwise use a text font as appropriate for the `font-family`. I'm all for your changes. AFAICS, the only limitation is that an ordinary text font with a family name 'music' cannot be used. I think we can live with tha

Re: Musings on the font-encoding property

> >>  AFAICS, the only limitation is that an ordinary text font with a >> family name 'music' cannot be used. > > No :-) unlike what its name suggests, the `font-family` property is > a family symbol, not a font string (yes, it's another misnamed thing > in font handling). The `font-family` valu

some objects not clickable

Please have a look at the attached snippet. Neither the `Divisio` nor the `VaticanaLigature` grob is clickable. What can be the reason for that? Werner \version "2.24" \pointAndClickOff \include "gregorian.ly" #(use-modules (ice-9 match)) #(define notation-format (match (ly:version

Re: some objects not clickable

> The ligature is apparently not printed by a `VaticanaLigature` but > by a `NoteHead` (try `\override NoteHead.color = blue`). A bit > disconcerting. Interestingly, adding ``` \addLink NoteHead "writing-pitches" ``` doesn't help for `VaticanaLigature` (but works for normal note heads). This

Re: some objects not clickable

> It's the same problem as for `Divisio`, and the same workaround > applies: [...] Again, thanks a lot! Werner

Re: music-font-encodings option

> Would anyone be able to explain me what the purpose of the > music-font-encodings option is? I'm trying to understand how the > generation of the Emmentaler font works. I see that there is quite > a bit of infrastructure for this option, which is used in > `--pspdfopt`, but it's not clear to

Re: music-font-encodings option

>>> Essentially, this option switches between the `show` and `glyphshow` >>> PostScript operators to access Emmentaler glyphs. The former is >>> considered the 'standard' method for accessing glyphs in a PS file >>> (according to the GS developers); however, it needs properly set up >>> encoding

convert-ly doesn't catch `make-pango-font-tree`

[0cb681106e53c50d53a35304df639ad8a2a88cbc] In my source file I have ``` \version "2.24" \paper { fonts = #(make-pango-font-tree "Linux Libertine O" "Linux Biolinum O" "Ubuntu Mono" (/ (* staff-height pt) 2.5)) } ``` `convert-ly` of current gi

Re: convert-ly doesn't catch `make-pango-font-tree`

>> In my source file I have >> >> ``` >> \version "2.24" >> >> \paper { >>   fonts = #(make-pango-font-tree >>     "Linux Libertine O" >>     "Linux Biolinum O" >>     "Ubuntu Mono" >>     (/ (* staff-height pt) 2.5)) >> } >> ``` >> >> `convert-ly` of current git

Re: Add definition for mensural-f3 clef

Hello Kim, welcome to LilyPond. > I’m not sure of the current way to suggest a change to lilypond source > but I just have a simple, 1-line change to propose. Thanks, but it's more than that, because... > It would be useful to have a mensural F clef that is on staff line 3 > for a baritone cl

Heads-up: gs 10.02 needed for `make doc`

Due to https://bugs.ghostscript.com/show_bug.cgi?id=706552 which was fixed today it is necessary to use the forthcoming gs version 10.02 for successful LilyPond documentation builds (using `extractpdfmark`) with the new PDF engine of GhostScript. Without this patch, many text accents in Lily

Re: Lilypond SMuFL Integration

Hello Konrad, I've forwarded your question to the right mailing list. Please subscribe! > I've been using Lilypond for awhile and am wondering how I might be > able to get involved with developing the SMuFL integration with > Lilypond and including more glyphs into Lilypond's repertoire. I >

Re: Bar lines in mensural notation (request for interpretation)

> [...] This is what I've drawn out: When notating a chant, anyone who > places full-height single or double lines anywhere but the end of a > phrase is a sheep, a klutz, and an ignoramus. :-) > My main doubt is whether this restriction is limited to church > music. I hope to understand whethe

Re: Glyph extents

> ``` > Box > Open_type_font::get_indexed_char_dimensions (size_t signed_idx) const > { > const size_t len = 256; > char name[len]; > FT_Error code > = FT_Get_Glyph_Name (face_, FT_UInt (signed_idx), name, FT_UInt (len)); > if (code) > warning (_f ("FT_Get_Glyph_Name () Freetype e

Re: Glyph extents

> However, much faster to compute is the control box ('cbox'), which > consists of the minimum and maximum values of all points all > contours of a glyph. This should be However, much faster to compute is the control box ('cbox'), which consists of the minimum and maximum values of all point

Re: Glyph extents

>> For LilyPond, the term 'bbox' means something completely different: >> It is an artificial box suited for LilyPond's needs but *completely >> decoupled* from the actual glyph dimensions.  For a glyph's width, >> breapth, height, and depth, the OpenType SFNT tables only deliver >> 'width'. >> >>

Re: What music font packaging/selection experience do we want?

> Now to the second approach, which I prefer. [...] Me too. All your suggestions are sound, thanks. Werner

LSR #983 produces strange result

Please have a look at https://lsr.di.unimi.it/LSR/Item?id=983 This code has obviously worked some time before, but it no longer doesn't. Is this a problem with the code or a bug? Werner

Re: LSR #983 produces strange result

>> > This code has obviously worked some time before, but it no longer >> > doesn't. Is this a problem with the code or a bug? >> >> Fixed inside LSR by replacing >> \once\omit Staff.BarLine >> by >> \once\hide Staff.BarLine Thanks! > I think it may be a bug. Consider: > > { > \textLengthOn

No writable cache directories

Compiling and installing lilypond from today's git repository, without changing anything else in my font configuration, I get a Fontconfig error (I've inserted some empty lines for better visibility). ``` Creating font configuration... Adding fontconfig configuration file: /usr/local/share/lily

Re: No writable cache directories

> Compiling and installing lilypond from today's git repository, > without changing anything else in my font configuration, I get a > Fontconfig error (I've inserted some empty lines for better > visibility). Forgot to mention this is with fontconfig 2.14.1. Werner

Re: No writable cache directories

>> This looks fishy... > > This has come up > before. > https://gitlab.com/extending-lilypond/extending-lilypond.gitlab.io/-/issues/2 > > Can you try with FC_DEBUG=272 ? This doesn't give any more detailed information. However, adding `strace` gives more insights. Attached is the output of

Re: Next releases

> LilyPond 2.25.5 will happen on the weekend of the 20th/21st (unless I > get too bored this next weekend...). I'm planning version 2.25.6 for > the second weekend of June (10th/11th) or the one after (17th/18th). +1 > I also think it might be a good idea to have another bugfix release > of sta

strange volta bracket example in LSR

The snippet 'Adding volta brackets to additional staves' https://lsr.di.unimi.it/LSR/Item?id=427 doesn't seem to do what the description says. Honestly, I have no idea what this snippet actually wants to demonstrate at all... Werner

Re: strange volta bracket example in LSR

>> The snippet 'Adding volta brackets to additional staves' >> >> https://lsr.di.unimi.it/LSR/Item?id=427 >> >> doesn't seem to do what the description says. Honestly, I have no >> idea what this snippet actually wants to demonstrate at all... > > https://gitlab.com/lilypond/lilypond/-/issues/6

Re: Fix Lilypond Beaming GSOC Project

>> One thing that concerns me is that generating tests takes a long >> time (`make test`). Besides using option `-jX` from make, I also suggest that you use 'ccache' to speed up the C++ compiler. https://ccache.dev/ This doesn't directly help with 'make test', though. Werner

Re: Fix Lilypond Beaming GSOC Project

>>> One thing that concerns me is that generating tests takes a long >>> time (`make test`). > > Besides using option `-jX` from make, [...] Ah, and also look into the environment variable `CPU_COUNT` used by LilyPond's build system. For example, I usually do a documentation build with ``` make

Re: Future of the font-name property

> What should we do here? > > A. Keep it supported indefinitely. Reduce its existence in the >documentation to a footnote. > B. Remove it. Make convert-ly emit a “not smart” message and write >clear instructions to convert files. > C. Deprecate it now, remove it in 2.28. I favour (A),

Re: Assigning issues

> The other important consideration is that people in this group > commonly have the temperament of an artist and the verbal filter of > an engineer. Hehehehe :-) > Therefore, my advice is not to assign an issue to another > contributor lightly; but if you understand the practical impact and >

Re: Variation fonts again

> On master, compiling the code > > ``` > \version "2.25.6" > > \paper { > property-defaults.fonts.serif = "Noto Serif" > } > > \markup \bold "abc" > ``` > > I get > > ``` > warning: font index 393216 too large for font > `/usr/share/fonts/google-noto-vf/NotoSerif[wght].ttf', usin

Re: Variation fonts again

>> So yes, please open an issue. > > https://gitlab.com/lilypond/lilypond/-/issues/6613 Thanks! Werner

Re: Clef, key, and time-signature changes

>> Time signatures are printed at the beginning of a piece >> and whenever the time signature changes. > > That is true, but incomplete: time signatures are also printed when > the time signature hasn't changed -- and it has been that way for > years. Interesting. > I haven't tested key signat

Re: Time-signature cancellation

>>> Has anyone here ever used or seen the time-signature cancellation >>> sign shown in MR 2029, or anything like it? >>> https://gitlab.com/lilypond/lilypond/-/merge_requests/2029 >> >> Never. >> Kieren. > > Now I'm starting to doubt that I should bother with it. Maybe asking on 'lilypond-user'

Re: LilyPond Visual Index for forthcoming version 2.26

> I have two minor points of feedback on the second page: There should > IMO be some padding between the boxed (magenta) headings, and they > should always be in the order *Score, *Staff, *Voice, *Lyrics. Thanks, I have fixed this in my source code. Werner

Re: Plan for LilyPond 2.24.2

> after the unstable release 2.25.6 is out and the included update of > bdwgc seems to resolve the rare crashes on Windows (not backported > yet), I would like to go ahead with the stable version 2.24.2. Thanks in advance for doing that! Werner

Re: Posts duplicated

> Since yesterday, I've been receiving all posts twice, from all > gnu.org mailing lists (lilypond-{devel,user,user-fr}). Is this only > happening to me? Yes. > (I did fiddle with my mailing list subscriber account recently in > order to investigate a problem someone else had, but at least not

`make bytecode && make doc` broken

[b30a94a7f8da18a8b08d3c4f11bb95c278a83c57] Currently, `make bytecode && make doc` is broken: ``` Command '/home/wl/build-lilypond/out/bin/lilypond [...] \ ".../out/lybook-db/snippet-names-c727b9067d4d978254fae040dfb82c3e.ly"' returned non-zero exit status 1. ``` In `snippet-nam

Re: No applicable method for #< - (4)> in call

> For the record, there is now a patch > at https://gitlab.com/lilypond/lilypond/-/merge_requests/2057 > > It LGTM. What do you think of fast-tracking it, to unbreak the > build for everyone? +1 Werner

Re: Suggestion: Hooks for formatting titling fields

> In my opinion it would not affect the complexity of Lilypond much to > add such hooks to all common markup fields, and it would make > tweaking specific fields much easier. I like your idea, thanks! What about preparing a MR so that everything is formalized? I can imagine that your idea (hav

Re: Flex on macOS

> Apart from that, even though it took me a lot of time due to having > to set up all the VMs etc., the release went quite smoothly. Thank > you Jonas for thoroughly documenting the release procedure in the > CG. Thanks to both of you! Werner

Re: PATCHES - Countdown to September 1

> Countdown: > > !2089 Draft: Generate HTML documentation with texi2any - Jonas Hahnfeld > https://gitlab.com/lilypond/lilypond/-/merge_requests/2089 Colin, something that starts with 'Draft:' in the description should be omitted from the normal review cycle. So: MR 2089 is *not* on countdo

Re: PATCHES - Countdown to September 1

>> Colin, something that starts with 'Draft:' in the description >> should be omitted from the normal review cycle. So: MR 2089 is >> *not* on countdown. Please adjust the tag accordingly. > > Thanks for the clarification, Werner. I've set it back to Needs_work, > as that was the last status y

default values in documntation strings?

Folks, consider the following ``` partCombine = #(define-music-function (chord-range part1 part2) ((number-pair? '(0 . 8)) ly:music? ly:music?) (_i "... The default value of @var{chord-range} is @code{(0. 8)}. ...") ... ``` Is there a standardized way to mention the default value of

Re: [RFC] HTML documentation with texi2any

> after some more work, I think I have resolved most details for > generating LilyPond's HTML documentation with texi2any. [...] Thanks again. > For a possible timeline, we could wait for the release of LilyPond > 2.25.8 (probably September 16/17 because I'm travelling next > weekend, unless J

LilyPond Visual Index

Folks, I've just submitted a Merge Request for a new version of the LilyPond Visual Index, to be added to LilyPond's documentation. https://gitlab.com/lilypond/lilypond/-/merge_requests/2107 Please comment! Werner

Re: Add a property `jianpuBeaming` needed to support Jianpu (numbered musical notation).

> These two patches introduce a boolean context property called > jianpuBeaming, which enables a relatively straightforward 'beamify' > behavior: when stems point downward (so beams being positioned > beneath the note heads), each beamlet covers the width of the > corresponding group of note head

Re: Add a property `jianpuBeaming` needed to support Jianpu (numbered musical notation).

> Attached is a sample of Jianpu notation. The two patches I submitted > are necessary for the underlines to function correctly here. Thanks, but please give a real example, say, an excerpt from 'Two springs in Moon Light' (二泉映月), both from a reference (which you would consider as good typography

Cairo_outputter::textedit_link

Is there ever a situation where `Cairo_outputter::textedit_link` is called? I've set a breakpoint on this function and run over all files in `input/regression`, but there wasn't a single hit... Werner

Re: Cairo_outputter::textedit_link

>> Is there ever a situation where `Cairo_outputter::textedit_link` is >> called?  I've set a breakpoint on this function and run over all >> files in `input/regression`, but there wasn't a single hit... > > Point-and-click. OK, thanks, but it would be great to have some actual LilyPond input co

Re: Cairo_outputter::textedit_link

> If you use the PS backend like in the command above, you > have no chance of triggering functions in the Cairo backend :P D'oh :-) Thanks! Werner

Fw: LilyPond support for `festival`

I accidentally selected the wrong mailing list, so Milan's reply doesn't appear here. If you reply, please don't send messages to 'freetype-devel' :-) Werner --- Begin Message --- >>>>> "WL" == Werner LEMBERG writes: WL> I wonde

'ledger-line-thickness' paper variable

The 'ledger-line-thickness' paper variable is set in `paper.scm`. It isn't used for anything, AFAICS, and it looks like a historical oversight that it wasn't removed. What shall we do with it? Werner

Re: 'ledger-line-thickness' paper variable

>> The 'ledger-line-thickness' paper variable is set in `paper.scm`. >> It isn't used for anything, AFAICS, and it looks like a historical >> oversight that it wasn't removed. > > Yes, that's correct. It doesn't serve a purpose anymore. > >> What shall we do with it? > > You have already drawn

Re: LilyPond support for `festival`

>WL> I wonder what we should do with the 'festival' and 'lilysong' >WL> files (and related stuff) in LilyPond. Please have a look at >WL> >WL> https://gitlab.com/lilypond/lilypond/-/issues/1245 >WL> >WL> This stuff is completely undocumented... > > if this is the only bug filed about this stuff

unnecessary line in `define-context-properties.scm`?

I wonder whether line 35 in file `define-context-properties.scm` is necessary. AFAICS, the `map` call in functions `all-user-translation-properties` and `all-internal-translation-properties`, together with the following ``` (define-public all-translation-properties (append all-user-translatio

Re: How some "Joe Users" perceive LilyPond installation

> Below is the copy of a discussion on the LilyPond Facebook group > that I found interesting. Just food for thought. [...] Thanks, Jean. I was almost tempted to answer on Facebook some hours ago, but I refrained because my answer would not have being useful in any way :-) Let's just conclude

Windows locale support

Folks, does localization of, say, `lilypond --help` work on Windows? I've tested LilyPond 2.25.9 within `cmd.exe` of a US version of Windows 10 (i.e., the standard language and region setup is for the USA), and I can't make it output anything else but US English. It doesn't react to setting a

Re: Windows locale support

> Le dimanche 15 octobre 2023 à 18:39 +0000, Werner LEMBERG a écrit : > >> does localization of, say, `lilypond --help` work on Windows? I've >> tested LilyPond 2.25.9 within `cmd.exe` of a US version of >> Windows 10 (i.e., the standard language and region setup is

horizontal vs. vertical padding

I try to provide a patch for issue #2185. The given solution simply reduces `Fingering.padding` from 0.5 to 0.3. However, this affects both horizontal and vertical padding, which is not what I want. I only want to change the horizontal padding, but it seems that we don't have a property for th

bizarre behaviour of `output-filename`

Consider this input file called `c.ly`: ``` output-filename = "foo" output-suffix = "bar" \book { \paper { output-suffix = "baz" } { c' } } \book { { c' } } \book { { c' } } ``` The created output files are foo-baz.pdf c-bar.pdf c-bar-1.pdf I consider it bizarre that th

Re: bizarre behaviour of `output-filename`

> I consider it bizarre that the top-level variable `output-filename` > is only considered in a `\book` block where the paper variable > `output-suffix` is also set, contrary to `output-suffix`. Why is > `output-filename` considered at all? Where in the code is this > read? AFAIK, top-level va

Scheme: Using brackets in addition to parentheses

As I've just discovered, brackets work the same as parentheses in Scheme expressions: ``` #[set-global-staff-size 26] { c' } ``` Guile allows this by default; the read option `square-brackets` is active for compatibility with R6RS. Shall we use and advertise this? Some user Scheme code could

Re: bizarre behaviour of `output-filename`

>> Some debugging shows it seems to be the latter: All top-level >> definitions are available as paper variables within a book's paper >> block, together with all paper variables of the top-level paper >> block: >> >> Is this really intentional? > > https://gitlab.com/lilypond/lilypond/-/issues

Re: Multiple clefs in one Staff

> Inspired by > > > Should we be offering something like that? What exactly do you mean with 'offering'? Having this functionality is certainly useful for Piano music. However, it's quite ra

Re: Multiple clefs in one Staff

>> Having this functionality is certainly useful for Piano music. >> However, it's quite rare, and an LSR snippet should be sufficient >> (possibly integrated into LilyPond's documentation). > > I see that you have shown an example that repeats the clef for every > measure. If that's the conven

`set-global-staff-size` fails within `\book`

Consider this snippet. ``` \book { #(set-global-staff-size 20) { c' } } \book { #(set-global-staff-size 10) { c' } } ``` Section 'Setting the staff size' in the NR says To set the staff size globally for all scores in a file (or in a \book block, to be precise), use set-global-sta

Re: [RFC] Transition to Guile 3.0

>> Please let me know of your comments! > > I'm very happy that you got Guile 3.0 working on Windows. Kudos for > that (and I guess we need to send big thanks to Mike Gran too). +1 > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. [...] I th

Re: Plan for LilyPond 2.24.3 and Transition to Guile 3.0

>> Step 1: Officially support Guile 3.0 and add optional CI testing I >> opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 >> to add some compatibility with earlier versions of Guile 3.0 and >> then implement detection support in configure. It also creates >> Docker images and adds

Make `Beam.positions = #beam::slope-like-broken-parts` the default?

The positioning of broken beams becomes so much better IMHO if `Beam.positions = #beam::slope-like-broken-parts` gets used (of course this is undocumented...) Have a look at the images from the regtest `beam-broken-classic.ly`. Is there any reason to not make this the default? Werner

Re: Make `Beam.positions = #beam::slope-like-broken-parts` the default?

>> The positioning of broken beams becomes so much better IMHO if >> `Beam.positions = #beam::slope-like-broken-parts` gets used (of >> course this is undocumented...) >> >> Have a look at the images from the regtest >> `beam-broken-classic.ly`. Is there any reason to not make this the >> defaul

clefs, time signatures, and key signatures

Folks, please have a look at Merge Request 2188 and comment there on how to proceed with the new distances between clefs and time signatures, together with the new distances between clefs and key signatures. https://gitlab.com/lilypond/lilypond/-/merge_requests/2188 The question is whether

Re: [RFC] Transition to Guile 3.0

>> then remove automatic detection of Guile 2.2 from configure. > > I did not yet upload a merge request to make Guile 3.0 the default > for all builds: After more thought, I believe it's better to do this > together with the removal of automatic configure support for Guile > 2.2, to avoid the s

Re: clefs, time signatures, and key signatures

> please have a look at Merge Request 2188 and comment there on how to > proceed with the new distances between clefs and time signatures, > together with the new distances between clefs and key signatures. > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2188 > > The question is whe

Re: clefs, time signatures, and key signatures

>> please have a look at Merge Request 2188 and comment there on how >> to proceed with the new distances between clefs and time >> signatures, together with the new distances between clefs and key >> signatures. >> >> https://gitlab.com/lilypond/lilypond/-/merge_requests/2188 >> >> The quest

Re: clefs, time signatures, and key signatures

> I’ve just looked at the images and especially w/r to the Alto clef I > strongly prefer the new spacing. For the others there are spots > where I’m not sure it is too tight but overall the new spacing > appears to be more balanced. > > I thus think the new spacing is better overall. Thanks, bu

Re: clefs, time signatures, and key signatures

> I think that the distances between the clef and the sigs are improved Thanks, but which variant do you prefer? The first image or the second image in https://gitlab.com/lilypond/lilypond/-/merge_requests/2188 ? Werner

Re: `set-global-staff-size` fails within `\book`

Six weeks ago I asked the following, without getting a response: > Consider this snippet. > > ``` > \book { > #(set-global-staff-size 20) > { c' } > } > > \book { > #(set-global-staff-size 10) > { c' } > } > ``` > > Section 'Setting the staff size' in the NR says > > To set the sta

Re: `set-global-staff-size` fails within `\book`

>> Consider this snippet. >> >> ``` >> \book { >> #(set-global-staff-size 20) >> { c' } >> } >> >> \book { >> #(set-global-staff-size 10) >> { c' } >> } >> ``` I played a bit more with this, and I've found that `set-global-staff-size` affects the *next* book block, which is, well, unexpe

Re: `set-global-staff-size` fails within `\book`

> IMHO the documentation is wrong. Everything's in the name. > set-global-staff-size sets the *global* staff size. Per-\book is not > global. Thanks to all who answered. I've submitted an MR to improve the documentation. https://gitlab.com/lilypond/lilypond/-/merge_requests/2200 Werner

Can't automatically merge

It seems that merging is currently not working; gitlab reports fatal: unable to access 'https://gitlab.com/lilypond/lilypond.git/': SSL certificate problem: self-signed certificate in certificate chain Do we have to do something? Werner

Re: Can't automatically merge

> Looks like it was fixed? > https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 Yep, thanks. Werner

Re: Can't automatically merge

>> Looks like it was fixed? >> https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 > > Yep, thanks. I spoke too early – it's still not working properly. Werner

Re: Can't automatically merge

>>> Looks like it was fixed? >>> https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 >> >> Yep, thanks. > > I spoke too early – it's still not working properly. On this page I read: For self-hosted runners, the previous workaround may need to be re-applied as we have updated G

Re: Can't automatically merge

> (In cases like these, please cc me directly; then the email will > land in my inbox and I may react faster...) OK, thanks. > I disabled Dan's and Karlin's runner. Can you please restart it and > then ping me so I can re-enable? If possible, maybe also update the > runner version... The firs

Re: clefs, time signatures, and key signatures

>>> please have a look at Merge Request 2188 and comment there on how >>> to proceed with the new distances between clefs and time >>> signatures, together with the new distances between clefs and key >>> signatures. >>> >>> https://gitlab.com/lilypond/lilypond/-/merge_requests/2188 >>> >>> The

numbers

This works: ``` { \ottava -1 c } ``` while this fails: ``` { \ottava +1 c'' } ``` Is there a technical reason for it? Werner

<    8   9   10   11   12   13   14   15   16   17   >