Change chord type input and chord name output
Hello, I have few questions about the \chordmode *Questions* - How can I change the name for the c:aug7 from C7#5 to Co7 for all augmented seventh chords, not only for specific pitches in the chordNameExceptions list? - Similarly, how can I change the name for the half-diminished seventh c:m7.5- from Cø to Cø7 for all half-diminished seventh chords? - How can I define an alias for the c:m7.5- to be c:hdim7? I tried with a variable, but it does not work *Example* hdim7 = m7.5- % does not work chSeq = \chordmode { c1 c:m c:aug c:dim \break c1:maj7 c:m7 c:aug7 c:dim7 c:7 c:m7.5- c:hdim7 % does not work } << \new Staff = chStaff \chSeq \new ChordNames = chNames \chSeq >> [image: image.png] Thank you, Vlad
-dcompile-scheme-code on Windows
Hi Abraham et al., I'm starting a new thread about the fact that -dcompile-scheme-code is apparently not working for you (https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00307.html). This option is new in 2.23.14 and makes for better error messages when something goes wrong in Scheme code. I used it for developing the lyrics respacing code, then just left it at the end. I wonder if -dcompile-scheme-code is broken for everyone on Windows or just for some. (If it's broken for everyone, I'm surprised that this is only noticed now ...) Can a few people on Windows please try compiling this and report back: \version "2.23.81" #(ly:set-option 'compile-scheme-code) #(debug-enable 'backtrace) #(display (+ 2 2)) #(use-modules (ice-9 match) (ice-9 hash-table) (oop goops)) Knowing if this works on macOS would be helpful too. Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: -dcompile-scheme-code on Windows
On 20.11.2022 13:37, Jean Abou Samra wrote: I wonder if -dcompile-scheme-code is broken for everyone on Windows or just for some. (If it's broken for everyone, I'm surprised that this is only noticed now ...) Can a few people on Windows please try compiling this and report back: See attached log. Cheers, Robin GNU LilyPond 2.23.81 (running Guile 2.2) Processing `1.ly' Parsing... 1.ly:5:2: error: Guile signaled an error for the expression beginning here # (debug-enable 'backtrace) In procedure bytevector-u64-set!: Value out of range: -149659645 1.ly:7:2: error: Guile signaled an error for the expression beginning here # (display (+ 2 2)) In procedure bytevector-u64-set!: Value out of range: -149659645 1.ly:8:2: error: Guile signaled an error for the expression beginning here # (use-modules (ice-9 match) In procedure bytevector-u64-set!: Value out of range: -149659645 Success: compilation successfully completed
Re: -dcompile-scheme-code on Windows
Le 20/11/2022 à 13:53, Robin Bannister a écrit : On 20.11.2022 13:37, Jean Abou Samra wrote: I wonder if -dcompile-scheme-code is broken for everyone on Windows or just for some. (If it's broken for everyone, I'm surprised that this is only noticed now ...) Can a few people on Windows please try compiling this and report back: See attached log. Ah, sorry, the snippet was silly. Please use this one instead: \version "2.23.81" #(debug-enable 'backtrace) #(ly:set-option 'compile-scheme-code) #(display (+ 2 2)) #(use-modules (ice-9 match) (ice-9 hash-table) (oop goops)) Namely, put #(debug-enable 'backtrace) before #(ly:set-option 'scheme-code). Thanks, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: -dcompile-scheme-code on Windows
On 20.11.2022 13:56, Jean Abou Samra wrote: Ah, sorry, the snippet was silly. Please use this one instead: \version "2.23.81" #(debug-enable 'backtrace) #(ly:set-option 'compile-scheme-code) #(display (+ 2 2)) #(use-modules (ice-9 match) (ice-9 hash-table) (oop goops)) Says successful, but doesn't look it. Cheers, Robin GNU LilyPond 2.23.81 (running Guile 2.2) Processing `1.ly' Parsing... 1.ly:6:2: error: Guile signaled an error for the expression beginning here # (display (+ 2 2)) 16 (apply-smob/1 #) In /home/lily/lilypond-2.23.81/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm: 876:16 15 (lilypond-main _) 905:4 14 (lilypond-all _) In srfi/srfi-1.scm: 640:9 13 (for-each # ) In /home/lily/lilypond-2.23.81/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm: 915:9 12 (_ "1.ly") In ice-9/boot-9.scm: 829:9 11 (catch ly-file-failed # ) In unknown file: 10 (ly:parse-file "1.ly") 9 (apply-smob/1 #) In system/base/compile.scm: 255:6 8 (compile _ #:from _ #:to _ #:env _ #:opts _) 183:32 7 (compile-fold _ (display (+ 2 2)) # ) In language/cps/compile-bytecode.scm: 591:12 6 (emit-bytecode _ # _) In system/vm/assembler.scm: 2614:12 5 (link-assembly #< buf: #u32(2097437 573 0 577 513 > ) 2587:22 4 (link-objects #< buf: #u32(2097437 573 0 577 513 2 >) 1857:9 3 (link-dynamic-section #< buf: #u32(2097437 573 0 > ) In unknown file: 2 (bytevector-u64-set! #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 ) ) In ice-9/boot-9.scm: 751:25 1 (dispatch-exception 0 out-of-range ("bytevector-u64- " )) In unknown file: 0 (apply-smob/1 # out-of-range "b " ) In procedure bytevector-u64-set!: Value out of range: -149659645 1.ly:7:2: error: Guile signaled an error for the expression beginning here # (use-modules (ice-9 match) 16 (apply-smob/1 #) In /home/lily/lilypond-2.23.81/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm: 876:16 15 (lilypond-main _) 905:4 14 (lilypond-all _) In srfi/srfi-1.scm: 640:9 13 (for-each # ) In /home/lily/lilypond-2.23.81/release/binaries/lilypond/build/out/share/lilypond/current/scm/lily/lily.scm: 915:9 12 (_ "1.ly") In ice-9/boot-9.scm: 829:9 11 (catch ly-file-failed # ) In unknown file: 10 (ly:parse-file "1.ly") 9 (apply-smob/1 #) In system/base/compile.scm: 255:6 8 (compile _ #:from _ #:to _ #:env _ #:opts _) 183:32 7 (compile-fold _ (use-modules (ice-9 match) (ice-9 #) #) ) In language/cps/compile-bytecode.scm: 591:12 6 (emit-bytecode _ # _) In system/vm/assembler.scm: 2614:12 5 (link-assembly #< buf: #u32(3146013 836 0 0 0 1 3 > ) 2587:22 4 (link-objects #< buf: #u32(3146013 836 0 0 0 1 314 >) 1857:9 3 (link-dynamic-section #< buf: #u32(3146013 836 0 > ) In unknown file: 2 (bytevector-u64-set! #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 ) ) In ice-9/boot-9.scm: 751:25 1 (dispatch-exception 0 out-of-range ("bytevector-u64- " )) In unknown file: 0 (apply-smob/1 # out-of-range "b " ) In procedure bytevector-u64-set!: Value out of range: -149659645 Success: compilation successfully completed
Re: Change chord type input and chord name output
Hello, Le 20/11/2022 à 10:27, Volodymyr Prokopyuk a écrit : * How can I change the name for the c:aug7 from C7#5 to Co7 for all augmented seventh chords, not only for specific pitches in the chordNameExceptions list? * Similarly, how can I change the name for the half-diminished seventh c:m7.5- from Cøto Cø7for all half-diminished seventh chords? You don't need to do anything special. The exceptions defined with chordNameExceptions are given for one "example" tonality, but they work for any transposition of the chord. * How can I define an alias for the c:m7.5- to be c:hdim7? I tried with a variable, but it does not work The syntax is not that straightforward and you need a bit of Scheme code, but it can be done, see below. \version "2.23.81" myChordExceptions = { -\markup { \super "○7" } -\markup { \super "ø7" } } \layout { \context { \ChordNames chordNameExceptions = #(append (sequential-music-to-chord-exceptions myChordExceptions #t) ignatzekExceptions) } } % adapted from chord-ignatzek-names.scm #(define (replace-step repl pitches) (map (lambda (pitch) (if (eqv? (ly:pitch-steps pitch) (ly:pitch-steps repl)) repl pitch)) pitches)) chordmodifiers.hdim = #(lambda (pitches) (replace-step #{ ees' #} (replace-step #{ ges' #} pitches))) mus = \chordmode { c1:aug7 d:aug7 c:m7.5- d:m7.5- c:hdim7 d:hdim7 } << \new Staff \mus \new ChordNames \mus >> Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Bar line at beginning of piece
Hi, is there an "idiomatic" way of forcing LilyPond to print a bar line "|" at the beginning of the piece other than doing the hack of adding \grace s1 \bar "|" before the music? My problem is that I need to do this programmatically with a large number of short scores. If any of those starts with a time signature, e.g. \time 3/4, then the result will be the usual issue #34 problem of C | 3/4 Now, obviously I could write a function that extracts an initial time signature from a music variable and moves it in front of the \grace s1 bit, which amounts to more hacking in order to gloss over the problems of the initial hack :-). Hence my question: Is there a mechanism for allowing a barline at the beginning of the piece not involving grace notes? (If not, I _think_ that the behaviour of not printing any bar lines at the beginning should be made an overridable default, so I'd add this to my already over-long list of "things I'd like to add to core LilyPond as soon as I have time".) Lukas
Re: Bar line at beginning of piece
Le 20/11/2022 à 14:51, Lukas-Fabian Moser a écrit : Hi, is there an "idiomatic" way of forcing LilyPond to print a bar line "|" at the beginning of the piece other than doing the hack of adding \grace s1 \bar "|" before the music? [...] Hm. \version "2.23.81" { \once \set Timing.measureStartNow = ##t \once \set Timing.measureBarType = "|-s" c'1 \break c'1 } What is amusing is that measureStartNow is unset at the start of the piece, but both Multi_measure_rest_engraver and Measure_counter_engraver "or" it with a boolean that is true in the first time step. Only Bar_engraver uses its value unchanged without doing something special at the first time step. It could be wise to make measureStartNow set to #t at the beginning of the piece, and change Bar_engraver to "and" it with "not the start of the piece". (Actually, I was already surprised by this some time ago, https://gitlab.com/lilypond/lilypond/-/issues/6126.) Cheers, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: -dcompile-scheme-code on Windows
Hello Jean, Le dim. 20 nov. 2022 à 13:38, Jean Abou Samra a écrit : > \version "2.23.81" > > #(ly:set-option 'compile-scheme-code) > #(debug-enable 'backtrace) > > #(display (+ 2 2)) > #(use-modules (ice-9 match) >(ice-9 hash-table) >(oop goops)) > > > Knowing if this works on macOS would be helpful too. > It's working fine for me on macOS with the latest 2.23.81 with both places of #(debug-enable 'backtrace) By the way, is it expected that the «lilypond git repository» link is pointed toward savannah rather than gitlab on the https://lilypond.org/development.html page ? Cheers, -- JJ Fleck Physique et Informatique PCSI1 Lycée Kléber
Re: Bar line at beginning of piece
Hi Jean, Hm. \version "2.23.81" { \once \set Timing.measureStartNow = ##t \once \set Timing.measureBarType = "|-s" c'1 \break c'1 } Thank you very much - this works from 2.23.8 on, I assume because of Dan's additions. Great! I still have to read up on the bar type definition codes which I never actually managed to understand. For example, in scm/bar-line.scm, I read: ;; predefined bar lines ;; ;; definition of bar lines goes as follows: ;; ;; (define-bar-line "mid-line bar[-annotation]" ;; "end-of-line bar[-annotation]" ;; "beginning-of-line bar[-annotation]" ;; "span bar") ;; ;; Each argument must be a string or #f. The string "" calls for a ;; zero-width stencil. The string "x" or the value #f call for no ;; stencil. "x" may be annotated, unlike #f. From this explanation, it find it hard to understand the the "mid-line" bar is taken as kind of an "identifier", which becomes clear only after reading (define-public (define-bar-line bar-glyph eol-glyph bol-glyph span-glyph) "Define a bar glyph @var{bar-glyph} and its substitutes at the end of a line (@var{eol-glyph}), at the beginning of a line (@var{bol-glyph}) and as a span bar (@var{span-glyph}). The substitute glyphs may be either strings or booleans: @code{#t} calls for the same value as @var{bar-glyph} and @code{#f} calls for no glyph." Also, "each argument must be a string or #f" seems strange when reading (define-bar-line "|" #t #f #t) So probably the comments on predefined bar lines don't reflect very faithfully what's actually happening? Lukas
Re: Flexible lyric alignment
Hi Jean, > This is a vast refinement of the initial \autoMove function I love that you generate “magic” solutions with such facility, and that you still care enough to respect existing parameters (e.g., minimum-distance) and include new useful ones (e.g., details.strength). > - As said in a previous message, this is the other extreme compared > to what LilyPond does by default: lyrics are not taken into account > *at all* into note spacing. In your algorithm, is there a way to turn off the feature on a per-syllable basis? e.g., in the example you included, can we (e.g.) force the first word [“Would”] to be considered in note spacing but not any of the other syllables? Thanks again for this incredible tool! Kieren.
Re: -dcompile-scheme-code on Windows
Le 20/11/2022 à 16:08, Jean-Julien Fleck a écrit : It's working fine for me on macOS with the latest 2.23.81 with both places of #(debug-enable 'backtrace) Thanks for testing. By the way, is it expected that the «lilypond git repository» link is pointed toward savannah rather than gitlab on the https://lilypond.org/development.html page ? Yes, Savannah is still the official repository because LilyPond is a GNU project. The development repository on GitLab is mirrorred to Savannah. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Bar line at beginning of piece
Le 20/11/2022 à 16:11, Lukas-Fabian Moser a écrit : Thank you very much - this works from 2.23.8 on, I assume because of Dan's additions. Great! There have been so many changes to bar lines that I have stopped tracking which happened in which version :-) I still have to read up on the bar type definition codes which I never actually managed to understand. For example, in scm/bar-line.scm, I read: ;; predefined bar lines ;; ;; definition of bar lines goes as follows: ;; ;; (define-bar-line "mid-line bar[-annotation]" ;; "end-of-line bar[-annotation]" ;; "beginning-of-line bar[-annotation]" ;; "span bar") ;; ;; Each argument must be a string or #f. The string "" calls for a ;; zero-width stencil. The string "x" or the value #f call for no ;; stencil. "x" may be annotated, unlike #f. From this explanation, it find it hard to understand the the "mid-line" bar is taken as kind of an "identifier", which becomes clear only after reading (define-public (define-bar-line bar-glyph eol-glyph bol-glyph span-glyph) "Define a bar glyph @var{bar-glyph} and its substitutes at the end of a line (@var{eol-glyph}), at the beginning of a line (@var{bol-glyph}) and as a span bar (@var{span-glyph}). The substitute glyphs may be either strings or booleans: @code{#t} calls for the same value as @var{bar-glyph} and @code{#f} calls for no glyph." Yes, the bar line system is slightly surprising: the "mid-line" part is used both as the argument to \bar and as the source for the mid-line glyph. Also, "each argument must be a string or #f" seems strange when reading (define-bar-line "|" #t #f #t) So probably the comments on predefined bar lines don't reflect very faithfully what's actually happening? This one looks like an oversight in commit 66c0227700. Cheers, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Change chord type input and chord name output
Outstanding! Thank you very much! I'm impressed with the flexibility of LilyPond! However, less verbose scripting could be a huge plus to LilyPond. Thank you, Vlad On Sun, Nov 20, 2022 at 2:46 PM Jean Abou Samra wrote: > Hello, > > Le 20/11/2022 à 10:27, Volodymyr Prokopyuk a écrit : > > > > * How can I change the name for the c:aug7 from C7#5 to Co7 for all > > augmented seventh chords, not only for specific pitches in the > > chordNameExceptions list? > > * Similarly, how can I change the name for the half-diminished > > seventh c:m7.5- from Cøto Cø7for all half-diminished seventh chords? > > > > > > > You don't need to do anything special. The exceptions > defined with chordNameExceptions are given for one > "example" tonality, but they work for any transposition > of the chord. > > > > > * How can I define an alias for the c:m7.5- to be c:hdim7? I tried > > with a variable, but it does not work > > > > > > > > The syntax is not that straightforward and you need a bit > of Scheme code, but it can be done, see below. > > > \version "2.23.81" > > myChordExceptions = { >-\markup { \super "○7" } >-\markup { \super "ø7" } > } > > \layout { >\context { > \ChordNames > chordNameExceptions = >#(append > (sequential-music-to-chord-exceptions myChordExceptions #t) > ignatzekExceptions) >} > } > > % adapted from chord-ignatzek-names.scm > #(define (replace-step repl pitches) > (map (lambda (pitch) >(if (eqv? (ly:pitch-steps pitch) > (ly:pitch-steps repl)) >repl >pitch)) > pitches)) > > chordmodifiers.hdim = >#(lambda (pitches) > (replace-step #{ ees' #} (replace-step #{ ges' #} pitches))) > > mus = \chordmode { >c1:aug7 d:aug7 >c:m7.5- d:m7.5- >c:hdim7 d:hdim7 > } > > << >\new Staff \mus >\new ChordNames \mus > >> > > > > Best, > Jean > >
Re: -dcompile-scheme-code on Windows
This is now https://gitlab.com/lilypond/lilypond/-/issues/6474 Thanks everyone, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Change chord type input and chord name output
Le 20/11/2022 à 17:30, Volodymyr Prokopyuk a écrit : However, less verbose scripting could be a huge plus to LilyPond. Well, LilyPond has convenient syntax for most "scripting" use cases. It's just that defining custom chord modifiers is pretty unusual, so it doesn't benefit from a syntax as simple as the one you imagined. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Flexible lyric alignment,Re: Flexible lyric alignment
Hi all, > Kieren, you've got to try this out! It will blow your mind! I just took Jean’s example, and compared the output with and without the \include step… Truly astonishing. (I haven’t tried it with my Real World Scores™, but can’t wait to do so!) > Jean, seriously, this is amazing! Agreed. > This has turned a so-so day into an amazing one! Between this and \alignTo, the last couple of days has advanced (accelerated, simplified, etc.) my Lilypond workflow to an almost unimaginable extent. > P.S. I hope my enthusiasm for this fix doesn't eclipse my sincere > appreciation for all the amazing work done by the regular developers past and > present. I've had lots of generous help over the years from many developers > and other users here. So grateful to you all for creating a truly awesome > tool and helping me and so many others! We are blessed here in the ’Pond. Kieren.