Change chord type input and chord name output

2022-11-20 Thread Volodymyr Prokopyuk
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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Robin Bannister

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

2022-11-20 Thread Jean Abou Samra



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

2022-11-20 Thread Robin Bannister

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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Lukas-Fabian Moser

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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Jean-Julien Fleck
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

2022-11-20 Thread Lukas-Fabian Moser

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

2022-11-20 Thread Kieren MacMillan
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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Volodymyr Prokopyuk
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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Jean Abou Samra

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

2022-11-20 Thread Kieren MacMillan
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.