lilypond x64 and arm64 for macOS users in homebrew
Dear developers, We have been working the last few days on homemade formulas for TeXLive ( https://github.com/Homebrew/homebrew-core/pull/83738) and Lilypond ( https://github.com/Homebrew/homebrew-core/pull / 85024) . The Lilypond formula relies on the TeXLive formula to build, which is practically ready to be merged. With that, Lilypond 2.22 will have binary distributions for macOS Catalina or higher, with x86_64 (Intel) or arm64 (M1) processors, available with command `brew install lilypond`. The problem is that homebrew core maintainers do not agree to use the old and obsolete Guile 1.8 to build and run Lilypond, so the version we are using in the formula is 2.2 (which exists in homebrew). I know guile 2 is not officially supported by Lilypond, but we did a lot of testing and compiled a lot of scores, with no errors. I just noticed that compilation time is a little slow with Guile 2. Therefore, I would like your opinion if we can continue with Guile 2, even if this homebrew distribution is not an official distribution, or if you could demonstrate, with examples, known issues in compiling sheet music with Guile 2. Thanks! -- --- Jefferson dos Santos Felix
Re: Broken make info dependencies
David Kastrup writes: > make info > > Oops, half of the images in Documentation/out-www/lilypond-changes.info > are just [Image of music] text tags. > > make doc > > 45 minutes later: > > make info > > Still half of the images in Documentation/out-www/lilypond-changes.info > are just [Image of music] text tags. > > make info-clean > > That target does not exist. > > make doc-clean > > make doc > > Wasting another 45 minutes > > make info > > Using just a script rather than a Makefile would have taken half as long > as this series of broken makes. And having to build the HTML > documentation of all languages when the Info files only need the images > from the English version is not exactly rewarding either. Now everything in Documentation/out-www/lilypond-changes.info is [Image of Music] WTF? -- David Kastrup
Broken make info dependencies
make info Oops, half of the images in Documentation/out-www/lilypond-changes.info are just [Image of music] text tags. make doc 45 minutes later: make info Still half of the images in Documentation/out-www/lilypond-changes.info are just [Image of music] text tags. make info-clean That target does not exist. make doc-clean make doc Wasting another 45 minutes make info Using just a script rather than a Makefile would have taken half as long as this series of broken makes. And having to build the HTML documentation of all languages when the Info files only need the images from the English version is not exactly rewarding either. -- David Kastrup
Re: Question on commit c478396f Move all doc building logic to Documentation/GNUmakefile
On 9/30/2021 1:17 AM, Jean Abou Samra wrote: Le 30/09/2021 à 05:38, John Wheeler a écrit : In jest I add: reading the code is a lot of fun, but I miss the programmer's guide to the lilypond language and it's libraries. Do you think there is enough interest in programming in lilypond in the community to create one? Maybe even just a complete introduction to the concepts and program flow with pointers to the rest of the documentation for the details? I am motivated to offer my help. I did write this thing a while ago: https://extending-lilypond.readthedocs.io/ Hope that helps, Jean Wonderful! Thank you for sharing it. Your work is at the top of my reading list. John
Re: Scheme performers/translators
Han-Wen Nienhuys writes: > On Thu, Sep 30, 2021 at 12:24 AM David Kastrup wrote: >> >> Well, this is not as much supporting the MIDI layer as it is >> employing the translator level for messing with music during >> iteration. It's sort of annoying that it doesn't work by default. > > It doesn't work by default because we never bothered to invest time in > improving it. You are changing the topic. It's sort of annoying that employing the translator level for messing with music during iteration doesn't work by default since all that is required for that is not deleting the already instantiated translator from the respective lists. > It's not obvious to me that a principled approach to MIDI rendering > would use a broadcast/acknowledge type architecture like the > typography part does. Not relevant at all to this patch. -- David Kastrup
Re: Shortcut for \repeat unfold
Dan Eble writes: >> On Sep 24, 2021, at 19:32, Jean Abou Samra wrote: >> >> - "\rep n music", not as self-telling (and I think Lukas >> only calls his shortcut \rep because redefining \repeat >> is not syntactically valid); > > What about killing two birds with two stones? > > 1. convert-ly \times A/B into \tuplet B/A We do that already in the 2.17.11 conversion rule. It remains mainly for backward compatibility. I think I remember that some people liked it for some purpose, however. Uses the same convention as \scaleDurations or so. > 2. times = \repeat unfold \etc When I was just occasionally using LilyPond, at some time when \tuplet did not exist, I tended to be fuzzy about \time, \times, \tempo . I am familiar enough these days that this is a mere anecdotal data point: I have no idea how it would affect newcomers. -- David Kastrup
Better method for inputting alists?
LilyPond makes it easy to define a top-level alist and extend it with
new keys:
\version "2.22.0"
foo.one = 1
foo.two = "2"
foo.nested.red = 3,4
foo.nested.blue = ##t
\void \displayScheme \foo.nested.red
This pattern works well enough. However, especially when nested more
deeply, it does result in redundant and error-prone typing as each new
entry must specify the full path of keys.
Borrowing syntax for context mods, one can get an improved approach:
\version "2.22.0"
alist =
#(define-scheme-function (with) (ly:context-mod?)
(define (assign? mod) (eq? 'assign (car mod)))
(define (assign->pair mod) (cons (cadr mod) (caddr mod)))
(map assign->pair (filter assign? (ly:get-context-mods with
foo = \alist \with {
one = 1
two = "2"
nested = \alist \with {
red = 3,4
blue = ##t
}
}
\void \displayScheme \foo.nested.red
The above technique admittedly abuses the \with construct, so would it
make sense for the parser to support alists directly? Not sure what the
syntax should be; but here's a possibility prepending a colon to the
brace:
foo = :{ one = 1 two = "2" nested = :{ red = 3,4 blue = ##t } }
Functions could take advantage of such abbreviated syntax to support
named arguments without having to resort to the same \with hack. The
\override markup command in particular would become nicer-looking:
\markup \override :{ offset = 15 thickness = 3 } \undertie "lorem ipsum"
-- Aaron Hill
PATCHES - Countdown for September 30th
Hello,
Here is the current patch countdown list. The next countdown will be on
October 2nd.
***
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!931 ci: Define tag to use custom runners - Jonas Hahnfeld
https://gitlab.com/lilypond/lilypond/-/merge_requests/931
!927 Clean up Drul_array initialization and assignment - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/927
Countdown:
!935 Make -dcrop generate .cropped.xxx files again - Jean Abou Samra
https://gitlab.com/lilypond/lilypond/-/merge_requests/935
!934 Support tail \alternative inside \repeat { } - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/934
!932 Allow partial \repeat commands without \alternative - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/932
!930 fix \book pagesize regression in lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/930
!929 lilypond-book: New options `paper-width` and `paper-height` -
Werner Lemberg
https://gitlab.com/lilypond/lilypond/-/merge_requests/929
!921 Draft: Add \lyricSkip and \lyricSkips $n. - Lukas-Fabian Moser
https://gitlab.com/lilypond/lilypond/-/merge_requests/921
Review:
!939 Allow creating Scheme translators working in `\midi` - David Kastrup
https://gitlab.com/lilypond/lilypond/-/merge_requests/939
!938 DocBook: output the raw LilyPond code at the right place - Thibaut
Cuvelier
https://gitlab.com/lilypond/lilypond/-/merge_requests/938
!937 Draft: \repeat unfold shorthand - Dan Eble
https://gitlab.com/lilypond/lilypond/-/merge_requests/937
!936 DocBook: support tag attributes with a single quote - Thibaut Cuvelier
https://gitlab.com/lilypond/lilypond/-/merge_requests/936
!933 Introduce the \after command - Lukas-Fabian Moser
https://gitlab.com/lilypond/lilypond/-/merge_requests/933
!897 support cairo backend in lilypond-book - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/897
New:
!920 Robustness fix for ly:engraver-announce-end-grob - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/920
Waiting:
!913 release: binaries with cairo - Han-Wen Nienhuys
https://gitlab.com/lilypond/lilypond/-/merge_requests/913
--
Regards
James
OpenPGP_0xAAC8D177A7F5A364.asc
Description: OpenPGP public key
Re: recognizing "pedal" in musicxml harmony, along with modifying Ignatzek exceptions
Hello Leonard,
On 29/09/2021 21:56, leonardlthomp...@gmail.com wrote:
Hello!
Many of us who use chord symbols in our scores find value in having 'pedal'
as a chord symbol type, which is simply a single unison pitch given by the
chord's root. Both Finale and Musescore successfully export 'pedal' as a
data type of a element in musicxml files.
The chordkind_dict variable in the musicxml2ly in my Lilypond installation
file has the 'pedal' entry commented out, which I modified to what the
commented out line basically hints at:
'pedal': ':1'
That modification, along with modifying ignatzekExceptionMusic in the
chord-modifiers-init file to include
-\markup \super {Pedal} has given me added functionally in both
recognizing a 'pedal' chord type when importing musicxml , and in having
'pedal' available in the Chordnames context. Would anyone see value in
having this reflected in the main repository?
best,
Leonard
Thanks for the input. We always appreciate this.
I have no experience to be able to add to this discussion, but you might
get more (better) initial feed back from the developer list and/or even
the 'user' list than the bug list.
That is not to say you would never get a reply but that not everyone in
our dev team looks at the bug list. I'll cc the dev list anyway in case
you are on that too.
--
Regards
James
Re: Scheme performers/translators
On Thu, Sep 30, 2021 at 12:24 AM David Kastrup wrote: > > Aaron Hill writes: > > > On 2021-09-29 12:39 pm, David Kastrup wrote: > >> The question is whether we should do something like this as default, > >> possibly conditioned on whether any acknowledgers are present? Because > >> even if we cannot react to Midi data structures (since they are not > >> Scheme-accessible for now), sometimes a translator may be enough to do > >> the trick. > > > > You say "for now" above, so is allowing Scheme to interact directly > > with the MIDI stream something that is planned? > > I have no idea what you call "planned". It is a deficiency that one > cannot use LilyPond in anything but a hardwired manner for creating > Midi. That does not mean that I know this to be in anybody's personal > work queue. At the current point of time, the Midi data structures are > not even in the Scheme memory management. I think most of them just > stick around without ever getting deleted. Audio elements get deleted in Performance::~Performance, and I'd be surprised if the MIDI stuff gets leaked. MIDI didn't show up the memory leak hunt Jonas and I did about 9 months ago. File a bug if you can repro a leak? > > Between what you have just shown and the work that already occurs in > > articulate.ly, it seems a lot of practical manipulation is possible > > without going down to the MIDI layer. So, your little patch to enable > > wider use of Scheme translators seems quite useful. At the very > > least, the more folks build on this and start playing around with the > > music, the more we would understand what a potential full Scheme > > performer support would entail. > > Well, this is not as much supporting the MIDI layer as it is employing > the translator level for messing with music during iteration. It's sort > of annoying that it doesn't work by default. It doesn't work by default because we never bothered to invest time in improving it. It's not obvious to me that a principled approach to MIDI rendering would use a broadcast/acknowledge type architecture like the typography part does. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Why doesn't the build fail for anybody else, including the bots?
Am Donnerstag, dem 30.09.2021 um 00:25 +0200 schrieb David Kastrup: > Jean Abou Samra writes: > > > > > > Why does nobody else get this? > > > > Possibly you are missing a "make doc-clean" as with > > https://lists.gnu.org/archive/html/bug-lilypond/2021-09/msg00024.html? > > make doc-clean does not affect the info file generation that make all > does. So, obviously you need "make -C Documentation clean" to affect the info file generation. > Our dependencies are nothing short of annoying. If one can only > reliably build after make *-clean there is no point in using Make. Improvements welcome, I would say. The auto-generated stuff is a mess, and it has always been at least for the last two years that I'm contributing to LilyPond. signature.asc Description: This is a digitally signed message part
Re: Question on commit c478396f Move all doc building logic to Documentation/GNUmakefile
Le 30/09/2021 à 05:38, John Wheeler a écrit : In jest I add: reading the code is a lot of fun, but I miss the programmer's guide to the lilypond language and it's libraries. Do you think there is enough interest in programming in lilypond in the community to create one? Maybe even just a complete introduction to the concepts and program flow with pointers to the rest of the documentation for the details? I am motivated to offer my help. I did write this thing a while ago: https://extending-lilypond.readthedocs.io/ Hope that helps, Jean
Re: Why doesn't the build fail for anybody else, including the bots?
> Our dependencies are nothing short of annoying. If one can only > reliably build after make *-clean there is no point in using Make. +1 In case it is too complicated to get complete dependencies (I think this was the argument then when it was simplified by Han-Wen) maybe we can get a new target make generated-files that takes care of those files that are not handled in a standard `make all` or `make doc` call. Werner
