Re: [openLilyLib] oll-core incompatible with Guile 2.2

2022-01-18 Thread Valentin Petzel
I have written a message to the list a year ago regarding this. The problem is 
that OLL has a call in oll-core/internal/control.scm:
(use-syntax (ice-9 syncase))
Which does not work anymore in 2.2, neither is it nescessary anymore, as guile 
2 provides R5RS natively.

My fix to this was to include a check for the guile version, like in the 
appended file.

There are a few other problems in certain OLL modules, which can also be 
mitigated.

Cheers,
Valentin

Am Mittwoch, 19. Jänner 2022, 01:45:04 CET schrieb Jean Abou Samra:
> Le 18/01/2022 à 20:43, Simon Albrecht a écrit :
> > Dear list,
> > 
> > I have started using the experimental 2.23.5 build with Guile 2.2 [1]
> > and it turns out to be incompatible with the core of openLilyLib.
> > 
> > Here are the error messages I got—it may be that only the first is
> > relevant:
> > [...]
> 
> Take a look at the attached patch (apply with 'git am').
> For me, it makes the file
> edition-engraver/usage-examples/example-1.ly work. Note,
> however, that ...
> 
> > I would have to delve in order to find the root of the error and solve
> > the problem, which I don’t really have time for, unless I must…
> 
> ... this applies to me as well, so I haven't tested
> anything else and don't intend to delve deeper than
> this for now.
> 
> Best,
> Jean;; control syntax
;;
;; Andrew Bernard 2017


(define-module (oll-core internal control))

(if (< (string->number (car (string-split (version) #\.))) 2)
(use-syntax (ice-9 syncase)))

;; when and unless from R6RS

(define-syntax when
  (syntax-rules ()
((when test result1 result2 ...)
 (if test
	 (begin result1 result2 ...)


(define-syntax unless
  (syntax-rules ()
((unless test result1 result2 ...)
 (if (not test)
	 (begin result1 result2 ...)



signature.asc
Description: This is a digitally signed message part.


Re: [openLilyLib] oll-core incompatible with Guile 2.2

2022-01-18 Thread Jean Abou Samra

Le 19/01/2022 à 01:45, Jean Abou Samra a écrit :

Le 18/01/2022 à 20:43, Simon Albrecht a écrit :

Dear list,

I have started using the experimental 2.23.5 build with Guile 2.2 [1] 
and it turns out to be incompatible with the core of openLilyLib.


Here are the error messages I got—it may be that only the first is 
relevant:

[...]



Take a look at the attached patch (apply with 'git am').
For me, it makes the file
edition-engraver/usage-examples/example-1.ly work. Note,
however, that ...


I would have to delve in order to find the root of the error and 
solve the problem, which I don’t really have time for, unless I must…


... this applies to me as well, so I haven't tested
anything else and don't intend to delve deeper than
this for now.



I forgot something: if you are using 2.23.4 or
higher (as with these experimental binaries), you
also need the attached in the edition-engraver.

Jean
From 12d3e43590cc091ecb1a4f5b8b9d06de5c28121f Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 19 Jan 2022 01:45:50 +0100
Subject: [PATCH] Replace ly:context-now with ly:context-current-moment

ly:context-now was doing exactly the same as ly:context-current-moment
and this duplication was removed in LilyPond 2.23.
---
 engine.scm | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/engine.scm b/engine.scm
index aee8adc..52552eb 100644
--- a/engine.scm
+++ b/engine.scm
@@ -756,7 +756,7 @@ Path: ~a" path)
 (define (start-translation-timestep trans)
   (log-slot "start-translation-timestep")
   (if (or (not start-translation-timestep-moment)
-  (ly:moment

Re: [openLilyLib] oll-core incompatible with Guile 2.2

2022-01-18 Thread Jean Abou Samra

Le 18/01/2022 à 20:43, Simon Albrecht a écrit :

Dear list,

I have started using the experimental 2.23.5 build with Guile 2.2 [1] 
and it turns out to be incompatible with the core of openLilyLib.


Here are the error messages I got—it may be that only the first is 
relevant:

[...]



Take a look at the attached patch (apply with 'git am').
For me, it makes the file
edition-engraver/usage-examples/example-1.ly work. Note,
however, that ...


I would have to delve in order to find the root of the error and solve 
the problem, which I don’t really have time for, unless I must…


... this applies to me as well, so I haven't tested
anything else and don't intend to delve deeper than
this for now.

Best,
Jean
From 84078085af9d83e4f5fa3bfa93f7804e99803698 Mon Sep 17 00:00:00 2001
From: Jean Abou Samra 
Date: Wed, 19 Jan 2022 01:37:41 +0100
Subject: [PATCH] Quick fixes for Guile 2 compatibility

Don't define when and unless in Guile 2, they're already defined and
the functionality of (ice-9 syncase) has been made available by
default, thus removing the module.

Use #f as explicit destination in format calls to silence warning.

Load  as identifier because define-method apparently no longer
accepts it as expression.
---
 internal/control.scm | 28 
 internal/file-handling.scm   |  3 +--
 internal/logging.scm | 10 +-
 internal/named-alists.scm|  3 +--
 internal/options.scm |  2 +-
 internal/os-path.scm |  6 +++---
 load/templates.ily   |  2 +-
 load/tools.ily   |  2 +-
 temp-package-declaration.ily |  6 +++---
 tree.scm | 15 ---
 usage-examples/properties.ly |  4 ++--
 usage-examples/stack.ly  |  6 ++
 util/consist-to-contexts.ily |  3 +--
 util/include-pattern.ily |  2 +-
 14 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/internal/control.scm b/internal/control.scm
index 8a9c0b7..c1d9c19 100644
--- a/internal/control.scm
+++ b/internal/control.scm
@@ -5,20 +5,24 @@
 
 (define-module (oll-core internal control))
 
-(use-syntax (ice-9 syncase))
+(cond-expand
+ (guile-2)
+ (else
+  (use-syntax (ice-9 syncase))
 
-;; when and unless from R6RS
+  ;; when and unless from R6RS
 
-(define-syntax when
-  (syntax-rules ()
-((when test result1 result2 ...)
- (if test
-	 (begin result1 result2 ...)
+  (define-syntax when
+(syntax-rules ()
+  ((when test result1 result2 ...)
+   (if test
+   (begin result1 result2 ...)
 
 
-(define-syntax unless
-  (syntax-rules ()
-((unless test result1 result2 ...)
- (if (not test)
-	 (begin result1 result2 ...)
+  (define-syntax unless
+(syntax-rules ()
+  ((unless test result1 result2 ...)
+   (if (not test)
+   (begin result1 result2 ...)
 
+))
diff --git a/internal/file-handling.scm b/internal/file-handling.scm
index ff5c07b..ff9b75d 100644
--- a/internal/file-handling.scm
+++ b/internal/file-handling.scm
@@ -46,7 +46,7 @@
   (let ((parser (ly:parser-clone)))
 (ly:parser-parse-string parser "\\language \"nederlands\"")
 (ly:parser-parse-string parser
-  (format "\\include \"~a\"" file))
+  (format #f "\\include \"~a\"" file))
 #t)
   #f))
 
@@ -63,4 +63,3 @@
 		(set! lines (cons line lines))
 		(lp (read-line h 'concat))
   #f)))
-
diff --git a/internal/logging.scm b/internal/logging.scm
index 3360287..7de996b 100644
--- a/internal/logging.scm
+++ b/internal/logging.scm
@@ -38,12 +38,12 @@
 
 ; Generic function to consistently format the output for the logging functions
 (define (oll-format-log fmt vals)
-  (apply format (format "\n\n~a\n" fmt) vals))
+  (apply format #f (format "\n\n~a\n" fmt) vals))
 
 ; Open log file
 (define oll-logfile
   (open-output-file
-   (format "~a.oll.log" (ly:parser-output-name (*parser*)
+   (format #f "~a.oll.log" (ly:parser-output-name (*parser*)
 
 ; Generic function to consistently write to log file.
 ;  is a sectioning header in the log file
@@ -57,7 +57,7 @@
  (number->string (cadr (ly:input-file-line-char-column (*location*
 
  "\n~a:\n"
- (apply format fmt vals)
+ (apply format #f fmt vals)
  "\n\n")
 title))
 
@@ -70,7 +70,7 @@
(begin
 ;log-to-file "Error" fmt vals)
 (ly:input-message (*location*)
- (format "Error:~a" (oll-format-log fmt vals)))
+ (format #f "Error:~a" (oll-format-log fmt vals)))
 (ly:error ""
 
 (define (oll:warn fmt . vals)
@@ -99,4 +99,4 @@
 (export oll:error)
 (export oll:warn)
 (export oll:log)
-(export oll:debug)
\ No newline at end of file
+(export oll:debug)
diff --git a/internal/named-alists.scm b/internal/named-alists.scm
index e494e72..147eafb 100644
--- a/internal/named-alists.scm
+++ b/internal/named-alists.scm
@@ -78,7 +78,7 @@ using key '~a' and ~a.  This will create a new alist instead,
 which is probably not intended."
 alst-name funcname key-

Re: Display Question Mark at center of a measure

2022-01-18 Thread Jean Abou Samra

Le 19/01/2022 à 00:40, Rajesh Baskar a écrit :


Hi Jean,

Here is the complete code.




Yes. Here is a simplified example:

\version "2.22.1"

\score {
  {
    \startMeasureCount
    <<
  \hideNotes b'4 a' g' a'
  \new Voice { R1 }
    >>
    \stopMeasureCount
  }
  \midi { }
  \layout { }
}

What's happening here is that you are not
telling LilyPond about the delimitation between
your voices. Since the b'4, a', etc. are not
grouped in any way, they form individual expressions.
In other words, the indentation is misleading and
this is interpreted as

\version "2.22.1"

\score {
  {
    \startMeasureCount
    <<
  \hideNotes
  b'4
  a'
  g'
  a'
  \new Voice { R1 }
    >>
    \stopMeasureCount
  }
  \midi { }
  \layout { }
}

Because there is \startMeasureCount at the
beginning, a new Voice is started. Then you have
this polyphonic construction, which spans a new
Voice for each of the notes and a last one
for the \new Voice { R1 }. This puts all of
the notes in parallel at the same moment.
Because \hideNotes happens in the voice that
is continued from the beginning, it applies
in this voice before the voices for the notes
are branched off, so \hideNotes still affects
them even though the construct is not doing
what you want. The solution is simple: group
the notes with braces. To end the \hideNotes,
either create a new voice explicitly instead
of continuing the main one, so that \hideNotes
will not bleed over the following music, or
insert \unHideNotes at the end.

\version "2.22.1"

\score {
  {
    \startMeasureCount
    <<
  \new Voice { \hideNotes b'4 a' g' a' }
  \new Voice { R1 }
    >>
    \stopMeasureCount
    c'1
  }
  \midi {}
  \layout {}
}

or

\version "2.22.1"

\score {
  {
    \startMeasureCount
    <<
  { \hideNotes b'4 a' g' a' \unHideNotes }
  \new Voice { R1 }
    >>
    \stopMeasureCount
    c'1
  }
  \midi {}
  \layout {}
}

Best,
Jean



Re: Display Question Mark at center of a measure

2022-01-18 Thread Rajesh Baskar

Hi Jean,

Here is the complete code.

\version "2.22.0"
\language english
boxify = #(define-music-function (grob-path) (key-list?)
    (define proc (grob-transformer 'stencil (lambda (grob orig)
    (grob-interpret-markup grob #{ \markup \override #'(box-padding . 
1.25)

    \override #'(thickness . 1) \box \stencil #orig #}
    #{ \override $grob-path . stencil = #proc #})
#(define (center-stencil stil) (ly:stencil-aligned-to
(ly:stencil-aligned-to stil X CENTER) Y CENTER))
questionMarkMultiMeasureRest = { \override MultiMeasureRest.stencil = 
#(grob-transformer 'stencil
(lambda (grob default) (ly:stencil-translate-axis (center-stencil 
(ly:text-interface::print grob))

(interval-center (ly:stencil-extent default X)) X)))
\override MultiMeasureRest.text = "?"
\override MultiMeasureRest.font-size = 7
\override MultiMeasureRest.color = "#6A00F4" }
\header {tagline = "" }
\score {\new Staff {
\override Score.SpacingSpanner.strict-note-spacing = ##t
\set Score.proportionalNotationDuration = #(ly:make-moment 1/4)
\override Staff.MeasureCounter.staff-padding = #4.5
\set Staff.midiInstrument = #"Acoustic Grand Piano"
\key c \major \numericTimeSignature \time 4/4 \clef treble
\startMeasureCount
<< \hideNotes b'4 a' g' a'
\new Voice { \questionMarkMultiMeasureRest R1 }
>>
\unHideNotes c''4 b' g'2 \stopMeasureCount \bar "||"}
\layout { \context { \Staff \consists Measure_counter_engraver
\boxify MeasureCounter } } \midi { \tempo 4 =92} }


On 1/18/2022 10:40 AM, Jean Abou Samra wrote:

Le 18/01/2022 à 19:14, Rajesh Baskar a écrit :


Thanks Lukas and Jean for your help.

There is an issue with the below solution. Whenadding << and >> the 
visual is correct but while playing the score the first measure notes 
all play together. I'm guessing it's because of << >>. Is there a way 
to fix this.


Thanks for all the help.

Raj



I cannot reproduce. Can you paste the complete code that
demonstrates the problem?

Thanks,
Jean


Re: ice-9 i18n string-locale-upcase

2022-01-18 Thread Jean Abou Samra

Le 18/01/2022 à 20:37, Simon Albrecht a écrit :

On 18/01/2022 18:52, Jean Abou Samra wrote:

Because this is documentation for Guile 2
and current releases of LilyPond still have
Guile 1.8.



Thanks for the speedy reply! I wasn’t sure whether the switch to Guile 
2 had already been made. I got it to work with the experimental binary 
you linked to, albeit only after fixing the actual code (see bottom 
for the revised example).



Did you forget that example? Anyway, I guess you wanted

\version "2.23.5"

#(use-modules (ice-9 i18n))

\markup \column {
  #(string-upcase "üß")
  #(string-locale-upcase "üß" (make-locale (list LC_MESSAGES)
   "de_DE"))
}


Backwards compatibility would be great, so I still ask: Do you or does 
anyone know whether similar functionality is available for Guile 1.8? 
Although I’m aware that character handling is a major difference 
between the versions, so I wouldn’t be surprised if not.



Functionality, no. Unicode handling is a feature of
Guile 2 and later (well, and partly a misfeature actually
because it's great to support Unicode, but Guile's string
internals leave to be desired, which make string operations
slow). At best, you can use clumsy workarounds like the
following, with a manually maintained table of replacements ...

\version "2.23.0"

#(define custom-replacements
   '(("ü" . "Ü")
 ("ß" . "SS")
 ("à" . "À")
 ("ê" . "Ê")
 ("ø" . "Ø")
 ;; add entries ...
 ))

#(use-modules (ice-9 match))
#(define upcase-with-clumsy-unicode-workaround
   (let ((table (make-hash-table)))
 (for-each
  (match-lambda
   ((key . value) (hash-set! table key value)))
  custom-replacements)
 (lambda (str)
   (apply string
  (let loop ((chars (string->list str))
 (acc '()))
    (match chars
 (()
  (reverse! acc))
 ((#\303 next . rest)
  (loop rest
    (append (let ((repl (hash-ref table (string 
#\303 next

 (if repl
 (reverse! (string->list repl))
 (list next #\303)))
    acc)))
 ((other . rest)
  (loop rest
    (cons (char-upcase other)
  acc)

\markup \column {
  #(upcase-with-clumsy-unicode-workaround "Je vais à la pêche. üßø")
}


Best,
Jean





Re: ice-9 i18n string-locale-upcase

2022-01-18 Thread Simon Albrecht

On 18/01/2022 18:52, Jean Abou Samra wrote:

Because this is documentation for Guile 2
and current releases of LilyPond still have
Guile 1.8.



Thanks for the speedy reply! I wasn’t sure whether the switch to Guile 2 
had already been made. I got it to work with the experimental binary you 
linked to, albeit only after fixing the actual code (see bottom for the 
revised example).


Backwards compatibility would be great, so I still ask: Do you or does 
anyone know whether similar functionality is available for Guile 1.8? 
Although I’m aware that character handling is a major difference between 
the versions, so I wouldn’t be surprised if not.


Best regards
Simon




Re: optical recognition for input

2022-01-18 Thread Paul Hodges

From:   Valentin Petzel  
 To:
 Cc:   Paul Hodges ,  
 Sent:   18/01/2022 19:30 
 Subject:   Re: optical recognition for input 

But the question is: Would you want that? In situations where this works you  
probably have a high quality scan of a quality score, 


Exactly.  The best success I've had is scanning the Neue Mozart Ausgabe scores 
(the full scores are all on line for free!) of substantial works (a Vespers and 
a Mass) to make instrumental parts.  


Paul

[openLilyLib] oll-core incompatible with Guile 2.2

2022-01-18 Thread Simon Albrecht

Dear list,

I have started using the experimental 2.23.5 build with Guile 2.2 [1] 
and it turns out to be incompatible with the core of openLilyLib.


Here are the error messages I got—it may be that only the first is relevant:

%%
/home/simon/openlilylib/oll-core/internal/init.ily:46:2: error: GUILE 
signaled an error for the expression beginning here

#
 (use-modules
Omitting the destination on a call to format is deprecated.
Pass #f as the destination, before the format string.
Unbound variable: use-syntax
/home/simon/openlilylib/oll-core/internal/init.ily:59:1: error: unknown 
escaped string: `\registerOption'


\registerOption #'(_propsets) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:59:17: error: syntax 
error, unexpected SCM_TOKEN, expecting '.' or '='

\registerOption
    #'(_propsets) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:60:1: error: unknown 
escaped string: `\definePropertySet'


\definePropertySet #'(OLL global) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:60:20: error: syntax 
error, unexpected SCM_TOKEN, expecting '.' or '='

\definePropertySet
   #'(OLL global) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:63:1: error: unknown 
escaped string: `\registerOption'


\registerOption oll-core.root #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:63:17: error: syntax 
error, unexpected SYMBOL, expecting '.' or '='

\registerOption
    oll-core.root #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:63:31: error: syntax 
error, unexpected SCM_TOKEN, expecting '='

\registerOption oll-core.root
  #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:66:1: error: unknown 
escaped string: `\registerOption'


\registerOption loaded-packages #'(oll-core)
/home/simon/openlilylib/oll-core/internal/init.ily:67:1: error: unknown 
escaped string: `\registerOption'


\registerOption loaded-modules.oll-core #'()
/home/simon/openlilylib/oll-core/internal/init.ily:67:41: error: syntax 
error, unexpected SCM_TOKEN, expecting '='

\registerOption loaded-modules.oll-core
    #'()
/home/simon/openlilylib/oll-core/internal/init.ily:79:1: error: unknown 
escaped string: `\setLogLevel'


\setLogLevel log
ERROR: In procedure %resolve-variable:
Unbound variable: getOption
%%

I would have to delve in order to find the root of the error and solve 
the problem, which I don’t really have time for, unless I must…


Can someone help me out?

Best regards
Simon

[1] https://lists.gnu.org/archive/html/lilypond-devel/2021-12/msg7.html




Re: [openLilyLib] oll-core incompatible with Guile 2.2

2022-01-18 Thread Simon Albrecht

https://github.com/openlilylib/oll-core/issues/62

On 18/01/2022 20:43, Simon Albrecht wrote:
I have started using the experimental 2.23.5 build with Guile 2.2 [1] 
and it turns out to be incompatible with the core of openLilyLib.


Here are the error messages I got—it may be that only the first is 
relevant:


%%
/home/simon/openlilylib/oll-core/internal/init.ily:46:2: error: GUILE 
signaled an error for the expression beginning here

#
 (use-modules
Omitting the destination on a call to format is deprecated.
Pass #f as the destination, before the format string.
Unbound variable: use-syntax
/home/simon/openlilylib/oll-core/internal/init.ily:59:1: error: 
unknown escaped string: `\registerOption'


\registerOption #'(_propsets) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:59:17: error: 
syntax error, unexpected SCM_TOKEN, expecting '.' or '='

\registerOption
    #'(_propsets) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:60:1: error: 
unknown escaped string: `\definePropertySet'


\definePropertySet #'(OLL global) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:60:20: error: 
syntax error, unexpected SCM_TOKEN, expecting '.' or '='

\definePropertySet
   #'(OLL global) #'()
/home/simon/openlilylib/oll-core/internal/init.ily:63:1: error: 
unknown escaped string: `\registerOption'


\registerOption oll-core.root #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:63:17: error: 
syntax error, unexpected SYMBOL, expecting '.' or '='

\registerOption
    oll-core.root #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:63:31: error: 
syntax error, unexpected SCM_TOKEN, expecting '='

\registerOption oll-core.root
  #(this-parent)
/home/simon/openlilylib/oll-core/internal/init.ily:66:1: error: 
unknown escaped string: `\registerOption'


\registerOption loaded-packages #'(oll-core)
/home/simon/openlilylib/oll-core/internal/init.ily:67:1: error: 
unknown escaped string: `\registerOption'


\registerOption loaded-modules.oll-core #'()
/home/simon/openlilylib/oll-core/internal/init.ily:67:41: error: 
syntax error, unexpected SCM_TOKEN, expecting '='

\registerOption loaded-modules.oll-core
    #'()
/home/simon/openlilylib/oll-core/internal/init.ily:79:1: error: 
unknown escaped string: `\setLogLevel'


\setLogLevel log
ERROR: In procedure %resolve-variable:
Unbound variable: getOption
%% 




Re: Display Question Mark at center of a measure

2022-01-18 Thread Jean Abou Samra

Le 18/01/2022 à 19:14, Rajesh Baskar a écrit :


Thanks Lukas and Jean for your help.

There is an issue with the below solution. Whenadding <<  and >> the 
visual is correct but while playing the score the first measure notes 
all play together. I'm guessing it's because of << >>. Is there a way 
to fix this.


Thanks for all the help.

Raj



I cannot reproduce. Can you paste the complete code that
demonstrates the problem?

Thanks,
Jean




Re: Display Question Mark at center of a measure

2022-01-18 Thread Rajesh Baskar

Thanks Lukas and Jean for your help.

There is an issue with the below solution. When adding <<  and >> the 
visual is correct but while playing the score the first measure notes 
all play together. I'm guessing it's because of << >>. Is there a way to 
fix this.


Thanks for all the help.

Raj

On 1/14/2022 1:39 AM, Lukas-Fabian Moser wrote:

Hi Rajesh,

Am 14.01.22 um 01:44 schrieb Rajesh Baskar:
I'm tying to display a question mark at the center of the 1st measure 
in a 2 measure score.


I have got this working with hard-coding the offset (3 . 4.5) but 
this will not work when the number of notes in a measure is larger 
than 3. Is there a way to get this to work dynamically where the 
question mark moves to the center of the measure irrespective of the 
length of a measure.


Please try to remove everything in your examples not actually related 
to the problem at hand (here, for example, everything having to do 
with MIDI, proportional notation, boxed measure counters etc.).


What comes to mind is that your question mark is exactly in the 
position where you would normally expect a whole bar rest. So how about:


\version "2.22.0"

#(define (center-stencil stil)
   (ly:stencil-aligned-to
    (ly:stencil-aligned-to stil X CENTER)
    Y CENTER))

questionMarkMultiMeasureRest = {
  \override MultiMeasureRest.stencil =
  #(grob-transformer
    'stencil
    (lambda (grob default)
  (ly:stencil-translate-axis
   (center-stencil (ly:text-interface::print grob))
   (interval-center (ly:stencil-extent default X))
   X)))
  \override MultiMeasureRest.text = "?"
  \override MultiMeasureRest.font-size = 7
  \override MultiMeasureRest.color = "#6A00F4"
}

\new Staff {
  \clef bass
  <<
    { \hideNotes b2 c }
    \new Voice {
  \questionMarkMultiMeasureRest
  R1
    }
  >>
  \unHideNotes a2 c'4 g
}

One could of course wrap the simultaenous addition of the tweaked full 
bar rest in a music function.


The reason I'm using such a comparatively complex stencil override is 
that the default positioning of the MultiMeasureRest (which is what we 
want here) is handled in the default stencil; if we overwrite that 
function completely, we don't get the nice centered alignment we want.


Lukas


Re: ice-9 i18n string-locale-upcase

2022-01-18 Thread Jean Abou Samra

Le 18/01/2022 à 18:01, Simon Albrecht a écrit :

Hi everyone,

I wanted to set up some customisable headings using #(string-upcase 
"string"), but it doesn’t work on German umlauts, so I came upon 
string-locale-upcase on this page:


https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Character-Case-Mapping.html#Character-Case-Mapping 



However, I can’t get it to work. To this example file:


\version "2.23.5"
#(use-modules (ice-9 i18n))
\markup \column {
  #(string-upcase "üß")
  #(string-locale-upcase "üß" "de_DE")
}


Guile says: “no code for module (ice-9 i18n)”.

Why? Can I load the module another way? Will it do what I want? Should 
I use another tool? ;-)



Because this is documentation for Guile 2
and current releases of LilyPond still have
Guile 1.8. Try Jonas' latest *experimental*
binaries using Guile 2:

https://lists.gnu.org/archive/html/lilypond-devel/2021-12/msg7.html
or rather 
https://lists.gnu.org/archive/html/lilypond-devel/2021-12/msg00078.html

if you are using Windows.

Best,
Jean




ice-9 i18n string-locale-upcase

2022-01-18 Thread Simon Albrecht

Hi everyone,

I wanted to set up some customisable headings using #(string-upcase 
"string"), but it doesn’t work on German umlauts, so I came upon 
string-locale-upcase on this page:


https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Character-Case-Mapping.html#Character-Case-Mapping

However, I can’t get it to work. To this example file:


\version "2.23.5"
#(use-modules (ice-9 i18n))
\markup \column {
  #(string-upcase "üß")
  #(string-locale-upcase "üß" "de_DE")
}


Guile says: “no code for module (ice-9 i18n)”.

Why? Can I load the module another way? Will it do what I want? Should I 
use another tool? ;-)


Thanks in advance,
Simon




Re: optical recognition for input

2022-01-18 Thread Paul Hodges

From:   Vincent Gay  

By curiosity I tried it with a score produced by Lilypond, the result is  
not very satisfactory. As it is, it seems to me that it is quicker to  
enter everything on the keyboard than to correct what the software has  
recognized.

I've not tried Audiveris; but this is my impression from the Music OCR programs 
I've tried.  I found PhotoScore (which came with Sibelius) essentially useless.


I do use SharpEye (http://www.visiv.co.uk/) sometimes, on a clean score, but 
only some very specific styles of music make it worth it.  The ability to edit 
on the spot, with the original in view is handy - except that the editor is 
extremely strange and hard to use.  The current version is fifteen years old...


Paul

Re: optical recognition for input

2022-01-18 Thread Vincent Gay

Le 18/01/2022 à 02:19, Josiah Boothby a écrit :
he instructions for building for source specify three dependencies: 
git, gradle, and JDK 11.


Audiveris can be installed in Archlinux without any problem (AUR 
repository). It is indeed the version 11 of the JDK which is installed 
as a dependence.


By curiosity I tried it with a score produced by Lilypond, the result is 
not very satisfactory. As it is, it seems to me that it is quicker to 
enter everything on the keyboard than to correct what the software has 
recognized. Maybe with future versions...


--
Vincent Gay
Envoyé depuis mon saxo-phone :)
https://myrealbook.vintherine.org/ - http://photos.vintherine.org/