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.
