Re: suppressing implicit TabStaff

[Jeff Olson]

On 6/26/2024 12:45 AM, Xavier Scheuer wrote:

This works: \new TabStaff \with { \tabFullNotation } { \mus }


Thanks, Xavier.  The NR example, that I now see, also works:

   \new TabStaff { \tabFullNotation \mus }

All is good!

Jeff

Re: suppressing implicit TabStaff

[Jeff Olson]

On 6/25/2024 11:45 PM, David Kastrup wrote:

Have you tried just writing \set Staff.minimumFret instead?  TabStaff
listens to the alias Staff as well as its germane TabStaff.


Thanks, David!

That works even for the case where there is no explicit Staff (just a 
bare TabStaff).  Excellent!


But I still had to remove my \tabFullNotation command to avoid an 
implicit TabStaff.


Is there an alternative place (outside the music code) to put 
\tabFullNotation?  Perhaps as a context setting for the explicit TabStaff?


Jeff

suppressing implicit TabStaff

[Jeff Olson]

Sometimes guitarists want the same piece two ways: with an added 
TabStaff while learning and without the TabStaff when performing (for 
brevity).  But the code needed to tailor the tab generation also screws 
up the notation when you don't want tab.


My music code has extensive use of "\set TabStaff.minimumFret" which 
works fine when generating an explicit TabStaff.


But attempts to generate only an ordinary Staff from the same music code 
are garbled by the automatic TabStaff that gets generated from all the 
TabStaff settings embedded in that code.


MWE-TabStaff.ly is attached, and here is its output showing scores with 
and without an explicit TabStaff


MWE-TabStaff.png

Commenting out the "\set TabStaff.minimumFret" works (no TabStaff 
shown), but that also alters the explicit TabStaff and is not an option.


What's the easiest way to suppress the implicit TabStaff while 
maintaining common code for both with/without tab?


Tags come to mind but I don't like the clutter or the hassle.

I'm hoping for a context setting that I could add somewhere (like in 
\layout) to make an explicitly declared TabStaff produce no output.


I looked at TabStaff in the IR but didn't find anything at that level to 
silence the whole thing.  Also looked at Keeping contexts alive in the 
NR for clues on how to suppress it.


How can I keep all my embedded TabStaff settings without showing an 
implicit TabStaff?


TIA,
Jeff
\version "2.24.3"

\header { tagline = ##f }
#(ly:set-option 'tall-page-formats 'png)
#(ly:set-option 'use-paper-size-for-page #f)

mus = { \set TabStaff.minimumFret = #5
a b c' }

\score {
  \new StaffGroup <<
\new Staff { \clef "treble_8" \mus }
\new TabStaff { \mus }
  >>
}


\score {
\new Staff { \clef "treble_8" \mus }
}

Re: Circular staves

[Jeff Olson]

Valentin,

How about modifying it so it's readable on a large circular table, i.e., 
so that the segment closest to you (at the current bottom of the score) 
is right-side-up.


Then imagine placing the large score on a rotating server (Lazy Susan 
<https://en.wikipedia.org/wiki/Lazy_Susan>) so that N people around the 
table could sing an N-part round by rotating the score clockwise.


Perhaps a new "spin" on the four-part tablebook format used by Dowland?

Or has Lazy Susan format already been done?

Jeff

On 3/16/2024 10:29 AM, Leo Correia de Verdier wrote:

Wow!

That was truly amazing!

/Leo


16 mars 2024 kl. 16:46 skrev Valentin Petzel:

Some time ago Jean posted this lovely proof of concept to the list for
circular staves. I’ve revised this to handle stuff like multiple Staves,
Spanners and Beams and such stuff. The result looks quite stunning in my
opinion. Also the way the code now works each bit essentially only requires
the a translation and orientation depending on the source position. In the
next step I’ll try to change the interface so that System provides not an
angle and a radius, but a procedures that takes any coordinate and returns a
target coordinate as well as an orientation. This way this implementation
should work as well for arbitary changes of coordinates.

A problem with this implementation is that we need a sufficiently wide paper for
rendering the origin staff. This is usually much wider than what is required to
fit the result. I’ve thought about doing the classic web designer trick and use
negative page margins, but Lilypond does not think that this is a reasonable
thing to do ...

Cheers,
Valentin

Am Sonntag, 23. April 2023, 22:09:22 CET schrieb Jean Abou Samra:

Le dimanche 23 avril 2023 à 12:37 +1000, Andrew Bernard a écrit :
Just checking - you can't make circular staves with notes in lilypond,
can you? I know you can do nice circle of fifths diagrams as per an LSR
example, but circular staves are way out of scope, aren't they?

This came up in the Dorico forum and several users assert with no
evidence or examples that lilypond can, so I wanted to check my view.

What exactly makes you think it is not possible, given the control LilyPond
gives you on the notation via Scheme?

Attached is an include file showing that you can do basic circular scores in
<100 lines of straightforward Scheme code. This is a quickly coded demo, it
would need a bit of love to gracefully print beams or ledger lines. (I
won't invest that effort if the person is staying on Dorico and not
actually using it, though.)






--
  
      o_ Jeff Olson

 (\___\/_/)   jjocanoe
~ ~ ~ / ~ ~ ~ ~  @gmail.com

Re: accessing current file name in markup function

[Jeff Olson]

On 12/7/2023 12:21 PM, Jean Abou Samra wrote:


Documentation question from trying to understand *location* in 
David's solution:




Guessing, is sip a stream input pointer? _Where would I look to find 
the definition/example of sip?_






 *location* doesn't return a string but a special type of 
location/input object.


The name "sip" is a bit weird; looking in the commit that added the 
code 19 years ago, it looks like it was meant as "smob input" (where 
smob = Scheme object = LilyPond C++ object made available to Scheme).


Thanks for the explanation, Jean.

The technical glossary 
(https://lilypond.org/doc/v2.24/Documentation/notation/technical-glossary) 
does include smob but not sip.


And I had misinterpreted *location* as either an attempt at emphasis in 
email and/or short for insert-your-location-here rather than literally 
executable scheme code.


Is that construct (*location*) a general scheme syntax (so that some 
*foo* could be also be meaningful), or perhaps is it a reserved word?


My attempts to search the Lilypond index for *location* seemed to ignore 
the asterisks or take them as wild-cards.  Ditto when trying the sphinx 
search icon in your https://extending-lilypond.gitlab.io/en/scheme/.


Not to snark, but perhaps I should cease my hunting of the elusive *sip* 
for fear that it is a boojum, causing me to softly and suddenly vanish away.


Thanks,
Je...

Re: accessing current file name in markup function

[Jeff Olson]

On 12/6/2023 3:48 PM, David Kastrup wrote:

\version "2.24.2"

locationOf =
#(define-scheme-function () ()
(apply format #f "~a:~a:~a:~a" (ly:input-file-line-char-column 
(*location*


\markup { \locationOf }


Documentation question from trying to understand *location* in David's 
solution:


I found that function in the IR documentation[1], but I could not find 
the definition of a /_sip_/:


   _Function:_*|ly:input-file-line-char-column|*/sip/

   Return input location insipas|(file-name line char column)|.

Guessing, is sip a stream input pointer? _Where would I look to find the 
definition/example of sip?_


Or, David, does *location* mean a string literal containing the name of 
the file like "eso.ly"?


[1] 
https://lilypond.org/doc/v2.24/Documentation/internals/scheme-functions#index-ly_003ainput_002dfile_002dline_002dchar_002dcolumn


TIA,
Jeff

Re: petrucci style notehead for MetronomeMark, plus Piae Cantiones style G clef and time signature

[Jeff Olson]

Sorry it's taken a couple of days to answer.

On 11/12/2023 7:23 PM, Jon Arnold wrote:

I'm into this!
Cool!  Have you done Gaudete?  If so, where did you get the music for 
the verses?  I wound up writing my own in Dorian to match the chorus, 
but Steeleye Span (https://www.youtube.com/watch?v=EDc2FD-vy8M) did 
theirs in Aeolian (with a flatted sixth), if I'm not mistaken.  
Wikipedia (https://en.wikipedia.org/wiki/Gaudete) says "the standard 
tune comes from older liturgical books" but gives no reference and I 
haven't found any other PD sources (the two on 
https://imslp.org/wiki/Gaudete%2C_Christus_est_natus_(Anonymous) are 
both SA and not authoritative, and also Aeolian).




1) Not sure on this one- you need to override the notehead in a \note 
{2} markup somehow since there's not a dedicated glyph for that.
May study this more.  For now I'm using \tempo 2.=72 to help indicate 
what gets one beat.  I also use modern dotted halves in the music rather 
than expecting my modern readers to understand imperfection and 
alteration implicit in the original.


2) I think that's as close as you get with Emmantaler. You can see the 
list of clefs here: 
https://lilypond.org/doc/v2.24/Documentation/notation/clef-style
That's what I feared.  I'd never seen a petrucci-g clef before, so I 
even tried the more common petrucci-c1 and moved it down to modern 
middle C, but now I'm back to petrucci-g.  I'm still hoping I can 
simulate the G clef symbol in Piae Cantiones.  Have you seen petrucci-g 
clefs in real music?



3) \override Staff.TimeSignature.style = #'single-digit
Didn't like this look (it's modern, not mensural).   Instead I omit the 
time signature altogether.




Hope I don't annoy you by adding other things but:

Not at all!  Thanks.

1) there are two semibreve (quarter note in your edition) rests at the 
beginning of the line if you haven't seen them
Thank you for mentioning that!  I totally misinterpreted those marks as 
modifiers of the time signature.  I have now included quarter rests in 
mensural style, as it helps the reader understand that the first note is 
not on the downbeat but is a pickup.


2) consider adding the custos engraver to your staff context like you 
did with the ambitus: \consists "Custos_engraver" \override 
Custos.style = #'mensural
Considered it already but didn't want to stress my modern readers with 
an unfamiliar benefit.




On Sun, Nov 12, 2023 at 5:24 PM Jeff Olson  wrote:

My questions ...

1)  How to get petrucci style note head in the tempo indication?

2)  Where to get the G clef as used in Piae Cantiones?

3)  How to get the time signature as used in Piae Cantiones?


Thanks again, Jon!

Jeff

petrucci style notehead for MetronomeMark, plus Piae Cantiones style G clef and time signature

[Jeff Olson]

This is my first time using quasi-mensural notation for modern notation 
readers (going for medieval look, not historical accuracy).


If you haven't gagged at that, I'd like some help on a few items.

Here's how the original starts ... (IMSLP260656 p48)

InDulciJubilo1910

And this is my approximation so far (using more familiar note durations) ...

MWE-mensural.png

My MWE-mensural.ly so far ... (constrained to overrides in my Voice 
variable vs new MensuralStaff)


\version "2.24.0"
vexDUMa = \transpose c c' {
  \tempo 2=100
  \time 6/8
  \override Staff.TimeSignature.style = #'mensural
  \clef "petrucci-g"
  \override NoteHead.style = #'petrucci
  \override Staff.MetronomeMark.style = #'petrucci
  \override Staff.AmbitusNoteHead.style = #'petrucci
  \cadenzaOn
  c4\(  c2 c4 e2 f4   g2 a4 g2\) \bar "," %1
  g4\(  c2 c4 e2 f4   g2 a4 g2.\) \breathe \bar "," %2
  \bar "||"
}
\score {
  { \vexDUMa }
  \layout { \context { \Staff \consists "Ambitus_engraver" }}
}

My questions ...

1)  How to get petrucci style note head in the tempo indication?

2)  Where to get the G clef as used in Piae Cantiones?

3)  How to get the time signature as used in Piae Cantiones?

TIA,
Jeff


\version "2.24.0"
vexDUMa = \transpose c c' {
  \tempo 2=100
  \time 6/8
  \override Staff.TimeSignature.style = #'mensural
  \clef "petrucci-g"
  \override NoteHead.style = #'petrucci
  \override Staff.MetronomeMark.style = #'petrucci
  \override Staff.AmbitusNoteHead.style = #'petrucci
  \cadenzaOn
  c4\(  c2 c4 e2 f4   g2 a4 g2\) \bar "," %1
  g4\(  c2 c4 e2 f4   g2 a4 g2.\) \breathe \bar "," %2
  \bar "||"
}
\score { 
  { \vexDUMa }
  \layout { \context { \Staff \consists "Ambitus_engraver" }}
}

Re: Show TacetStaff when StaffGroup empty

[Jeff Olson]

On 11/1/2023 6:37 AM, David Kastrup wrote:




Thanks, David. Now I'm really smiling to have learned something new! 
Your knowledge is more encyclopedic than Wikipedia.


I once mail-ordered a fretted u-bass but exchanged it for the fretless 
style, which I find easier to play (lighter touch) and more expressive.  
Intonation can even be better on fretless as the strings can develop 
nonuniformities in density. Wonder if that's why those fretted basses 
from the 1770's died out?


Thanks again!
Jeff

Re: Show TacetStaff when StaffGroup empty

[Jeff Olson]

On 10/31/2023 4:23 PM, David Kastrup wrote:

Jean Abou Samra  writes:


Le mardi 31 octobre 2023 à 20:40 +0100, David Kastrup a écrit :

Given that I was way less comfortable with English at the time
than I am today, it is possible that I fell into the trap of a
false cognate: the French "cordes frottées" sounds similar to
"fretted strings" but in fact means "bowed strings".

Well, maybe I had the wrong reading of the posts here.  Hopefully not
the wrong writing.




Thank you, David, for your prompt action, and Jean for that humorous story.

The only reason I cc'd Harm was that he was one of five listed under 
Documentation in http://lilypond.org/authors.html, and in previous posts 
he had identified himself as a [fellow] classical guitarist.  So I 
imagined he might smile, as I did, at seeing the double bass listed 
among fretted instruments.


And thanks, Michael, for your pointer to that documentation in your 
response to the OP.  I try to follow such links when they're from 
someone who apparently knows more about the topic than I do. It is, 
indeed, an excellent read.


I hope everyone is now smiling.

Jeff

P.S. What's the best way to alert somebody whenever I see a small nit 
like this in the documentation?  I don't have an account on gitlab, nor 
do I subscribe to the bugs or developers lists.

Re: Show TacetStaff when StaffGroup empty

[Jeff Olson]

On 10/31/2023 1:40 PM, David Kastrup wrote:

Nothing to fret about, unless you're in documentation, eh Harm?

I know Harm as a pretty good fretted string instrument player.  Probably
this should just be "strings" which it typically associated with the
kind of instruments listed there and has the advantage that you don't
get into trouble for a) pizzicato (which is weird for "bowed strings")
or b) viol (which is both bowed and fretted and may be used in a string
section for nostalgically informed practice).


Agreed, on both counts.

No blame; just raising awareness to  documenters.

Jeff

Re: Show TacetStaff when StaffGroup empty

[Jeff Olson]

On 10/30/2023 11:27 AM, Michael Werner wrote:
This is based on 
http://lilypond.org/doc/v2.25/Documentation/notation/hiding-staves


I'm not the OP but that is excellent documentation, save for one word:

   "In the following example, staves devoted to wind instruments are
   removed in the second system; however, the double bass is not,
   because it is part of the larger group of *fretted* strings, which
   is playing."

That larger group in the example consists of Violin I, Violin II, Alto, 
Cello, Double bass.


Nothing to fret about, unless you're in documentation, eh Harm?

Jeff

Re: lilypond-user Digest, Vol 246, Issue 40

[Jeff Olson]

On 5/13/2023 5:49 PM, Jean Abou Samra wrote:


PS. In fact it's better like this (to avoid influencing other balloons 
at the same moment):


|\version "2.24.1" \layout { \context { \Voice \consists 
Balloon_engraver } } circleB = \tweak layer -1 \tweak 
annotation-balloon ##f \balloonText #'(0 . 0) \markup \with-color 
"#fcc" \draw-circle #3.5 #0.1 ##t {  a d'  b' 
e'' } |


Excellent!  How would you similarly circle a rest (both r and f''\rest)?

Jeff

Re: lilypond-user Digest, Vol 246, Issue 40

[Jeff Olson]

On 5/13/2023 2:07 PM, lilypond-user-requ...@gnu.org wrote:

Il 13/05/23 15:47, Jean Abou Samra ha scritto:

[...]
|\version "2.24.1" circleB = \once \override NoteHead.stencil = 
#(grob-transformer 'stencil (lambda (grob original) 
(grob-interpret-markup grob #{ \markup \with-outline \stencil 
#original \overlay { \stencil #original \align-on-other #X #CENTER 
\stencil #original #CENTER \draw-circle #1.5 #0.1 ##f } #}))) { 
\circleB c'' \circleB c'' \circleB c''2 \circleB c''1 \circleB c''8 
\circleB a'8 \circleB b'16 \circleB c''16 \circleB b'16 \circleB a'16 
\circleB f'2 } |


You can then add |\with-color "red"| before |\draw-circle| or do 
other transformations.


Jean


Jean,

I tried adapting your circleB with a fill to do something like 
staffHighlight but with a more focused spotlight effect, especially for 
notes outside the staff on ledger lines where staffHighlight ordinarily 
doesn't go.    Here's my adaptation (with the original stencil last, so 
the note itself is not obliterated by the fill):


\version "2.24.1"
circleB =
\once \override NoteHead.stencil =
#(grob-transformer
  'stencil
  (lambda (grob original)
    (grob-interpret-markup
 grob
 #{
    \markup \with-outline \stencil #original
    \overlay {
  \align-on-other #X
    #CENTER \stencil #original
    #CENTER \with-color "#fcc" \draw-circle #3.5 #0.1 ##t
  \stencil #original
  }
 #})))

{  \circleB e a d' \circleB g' b' e'' }


But filling the circle obscures the staff and ledger lines (unlike the 
staffHighlight effect) making the circled note ambiguous (see first 
staff in image below).


The only workaround I know is to do an overlay of the whole score with 
its un-decorated self, like this (second staff in image below).


\markup { \overlay {
  \score {  \new Voice { \circleB e a d' \circleB g' b' e'' } }
  \score {  \new Voice { e a d'  g'  b' e'' } }
} }


Here's the image of the two results.  The circle highlight obliterates 
the ledger and staff lines:


two results

I see the circle also has no extent so it gets clipped in the png.  That 
I can workaround.


But how can I get the circle placed behind the staff (as in the second 
result) without doing an unwieldy overlay of the whole score?


Jeff

Re: help with Wrong type of argument

[Jeff Olson]

On 5/1/2023 4:52 AM, Lukas-Fabian Moser wrote:


#`((lineto 0 ,hgt) (closepath))

is the a list with two elements, namely
- the 3-element list containing 'lineto, 0 and the value of the 
variable hgt

- the 1-element list containing the symbol 'closepath.

This may also be written as:

#(list (list 'lineto 0 hgt) (list 'closepath))

or, mixing the two styles,

#(list (list 'lineto 0 hgt) '(closepath))


Thanks, Lucas.  That helps too!

--
  
  o_ Jeff Olson

 (\___\/_/)   jjocanoe
~ ~ ~ / ~ ~ ~ ~  @gmail.com

Re: help with Wrong type of argument

[Jeff Olson]

On 5/1/2023 12:20 AM, Michael Werner wrote:


#`((lineto 0 ,hgt)


Thank you so much for your quick fix and very patient explanation, Michael!

I had noticed the quote (') and figured that an unquote (,) would be 
needed but forgot that it required changing the quote to a quasiquote (`).



All the gory details can be found at:

https://extending-lilypond.gitlab.io/en/scheme/quoting.html


Thanks again!  I had read that article about quoting when Jean first 
advertised it but quasiquoting didn't sink in.  Re-reading it now, it 
seems more complete than I recall and all makes sense. It's an excellent 
explanation (thanks Jean!).


--
  
  o_ Jeff Olson

 (\___\/_/)   jjocanoe
~ ~ ~ / ~ ~ ~ ~  @gmail.com

help with Wrong type of argument

[Jeff Olson]

I'm starting to translate some of my \postscript markups into lilypond 
in order to use cairo, and it seems I always stub my toe when trying to 
use a variable in a substitution function.


In this example I'm trying to do (lineto 0 hgt) which fails with "In 
procedure *: Wrong type argument in position 1: hgt".


But it works if I replace hgt with a constant: (lineto 0 2).

My cargo cult thinking was that this lineto command was in a scheme 
expression so I shouldn't use a # or $ before the hgt variable to 
reference it (like the xtip and ytip inside the cons).


I'd welcome a quick syntax fix or a reference to what I should have read 
before asking.


TIA,
Jeff

Here's my code (small if not minimal):

\version "2.24.0"

#(define-markup-command (dopath layout props xtip ytip hgt wid txt rot)
  (number? number? number? number? string? number?)
  (let (
 (a (* wid 0.4))
 )
  (interpret-markup layout props
    #{\markup \translate #(cons xtip ytip) \rotate #rot \path #0.25
  #'((lineto 0 hgt)
 (closepath))
  #})))

\markup \dopath #10 #0 #2 #1 "D" #-5

Re: trouble putting \book block in a scheme function

[Jeff Olson]

On 4/5/2023 2:37 PM, Jean Abou Samra wrote:


Le mercredi 05 avril 2023 à 14:30 -0600, Jeff Olson a écrit :


The conclusion of [1], on how to put nicely cropped png or svg images
into individual files with specified file names, was to wrap each score
in a \book block with an individual \bookOutputName, as shown in that
message.

Since I have 1000+ such scores, each conveniently created by a scheme
function, it should be easy to just add the book wrapper inside that
function.  The first step was beginning like this MWE:

\version "2.24.1"
scr =
#(define-scheme-function (mus) (ly:music?)
 #{
   %\book {
 \score { #mus }
   %}
 #} )
\scr { c'' }

But un-commenting the two lines above generates "error: bad expression
type".

Adding -lDEBUG didn't explain more.  Does that error mean \book is
forbidden here?

How can I include a \book wrapper (and \bookOutputName) in my score
function?


Yeah... there are known syntax quirks in that area. This works though:

|\version "2.24.1" scr = #(define-void-function (mus) (ly:music?) 
(print-book-with-defaults #{ \book { \score { #mus } } #})) \scr { c'' }|

Thanks, Jean!  I never would have guessed.  I'll give it a try.

trouble putting \book block in a scheme function

[Jeff Olson]

The conclusion of [1], on how to put nicely cropped png or svg images 
into individual files with specified file names, was to wrap each score 
in a \book block with an individual \bookOutputName, as shown in that 
message.


Since I have 1000+ such scores, each conveniently created by a scheme 
function, it should be easy to just add the book wrapper inside that 
function.  The first step was beginning like this MWE:


\version "2.24.1"
scr =
#(define-scheme-function (mus) (ly:music?)
    #{
  %\book {
    \score { #mus }
  %}
    #} )
\scr { c'' }

But un-commenting the two lines above generates "error: bad expression 
type".


Adding -lDEBUG didn't explain more.  Does that error mean \book is 
forbidden here?


How can I include a \book wrapper (and \bookOutputName) in my score 
function?


Thx,
Jeff

[1] https://lists.gnu.org/archive/html/lilypond-user/2023-03/msg00417.html

Re: bookOutputName still gets "-1" suffix added to SVG file names

[Jeff Olson]

On 3/30/2023 7:05 PM, Jean Abou Samra wrote:

I don't understand the problem you're having. Is my suggestion of
using -dtall-page-formats not sufficient for your use case?

If you expect a 1-to-1 mapping between SVG files and MIDI files,
you can just put each piece into its own \book, with the
\bookOutputName of your choice, and compile it with
-dtall-page-formats=svg, and that should give you your desired
output files without suffixes.


Thanks, Jean.

That indeed does produce 1-to-1 mappings without suffices:

\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'tall-page-formats 'png,svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\book {
  \bookOutputName  "Foo"
  \score { { f' } \layout { } \midi { } }
}
\book {
  \bookOutputName  "Abc"
  \score { { a' } \layout { } \midi { } }
}
\book {
  \bookOutputName  "Bar"
  \score { { b' } \layout { } \midi { } }
}

Each book has a layout and a midi, with the layout rendered both
as png and svg, properly cropped and with no -1 suffix in any file names:

-rwxrwxrwx+ 1 J None 451 Mar 30 21:37 MWE-SVG-tall.ly
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37  Foo.mid
-rwxrwxrwx+ 1 J None    6498 Mar 30 21:37  Foo.svg
-rwxrwxrwx+ 1 J None    2421 Mar 30 21:37  Foo.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37  Abc.mid
-rwxrwxrwx+ 1 J None    6490 Mar 30 21:37  Abc.svg
-rwxrwxrwx+ 1 J None    2401 Mar 30 21:37  Abc.png
-rwxrwxrwx+ 1 J None 119 Mar 30 21:37  Bar.mid
-rwxrwxrwx+ 1 J None    6530 Mar 30 21:37  Bar.svg
-rwxrwxrwx+ 1 J None    2377 Mar 30 21:37  Bar.png

Here is Bar.svg

Bar.svg

and Bar.png (at default low resolution of 101)

Bar.png

Both are properly cropped, as opposed to whole (tall?) pages.


I think what threw me off using tall-page-formats were conclusions on

https://lists.gnu.org/archive/html/lilypond-user/2023-03/msg00029.html
https://lists.gnu.org/archive/html/lilypond-user/2023-02/msg00070.html
https://gitlab.com/lilypond/lilypond/-/issues/6235

saying "this combination of options appears to produce cropped output"
   #(ly:set-option 'separate-page-formats 'eps,png,pdf)
   #(ly:set-option 'use-paper-size-for-page #f)

Going back to the manuals didn't help explain tall-page-formats:

The 2.24 usage manual defines tall-page-formats as
   "Comma-separated list of formats (svg, pdf, png, or eps)
   to use for the ‘tall page’ image in lilypond-book."

But I couldn't find "tall page" in the usage pages for lilypond-book
nor in the LilyPond index for either the usage manual or NR.

I did find this oblique mention near the end of the 2.24 Changes doc
(in the Miscellaneous Improvements section) regarding "the default of
the aux-files program option changed to #f" (I never use that option):

   "The formats for lilypond-book images can be set separately for
   the tall page image (typically PNG for HTML output) and per-system
   images (typically, EPS or PDF for printed output) with the -d
   sub-options -dtall-page-formats and -dseparate-page-formats 
respectively."


Based on these limited descriptions and discussions, and my requirement
for properly cropped multi-system scores in separate image files, as
opposed to un-cropped whole pages (tall pages?), I'd still think
separate-page-formats should work.

Maybe the documentation of separate- and tall-page-formats
should elaborate more.

Or am I still missing the one place where that explanation is provided?

Thanks for your patience!

Jeff

Re: bookOutputName still gets "-1" suffix added to SVG file names

[Jeff Olson]

On 3/30/2023 10:11 AM, David Wright wrote:

    32 -rwxrwxrwx+ 1 J None   32199 Mar 29 22:25  Foo-1.svg*
    32 -rwxrwxrwx+ 1 J None   32190 Mar 29 22:25  Abc-1.svg*
    32 -rwxrwxrwx+ 1 J None   32231 Mar 29 22:25  Bar-1.svg*

That looks like a linux platform.

But it's Windows 10 running the cygwin.dll
(see http://cygwin.com/ and https://en.wikipedia.org/wiki/Cygwin)



If the thousand-odd files are in a single directory, and you like
visual interfaces, renaming them is very simple in a TUI-style
file manager like Midnight Commander (mc). You'd rename (called
Move) from *-1.svg to *.svg after selecting all the files with
the * keystroke.

If you prefer a CLI, then it's as simple as:

   $ cd directory-containing-files
   $ rename 's/-1\.svg$/.svg/' *.svg

except for the complication of which version of rename you have
installed on your system. I prefer the version that uses a Perl
expression, and it's set up as the default on my system for the
"rename" command, but can also be invoked as prename or file-rename.

Where files are scattered amongst directories, the CLI rename command
can be invoked from a find command, which searches directory trees for
suitable filenames to rename.

Cheers,
David.


Thanks for your detailed assistance, David!

The rename command in my cygwin doesn't look like it takes Perl REs,
which I'd prefer instead:

$ rename -V
rename from util-linux 2.33.1

SYNOPSIS
   rename [options] expression replacement file...

DESCRIPTION
   rename will rename the specified files by replacing the first 
occurrence

   of expression in their name by replacement.

But as this is part of my process going forward, I'll probably use
bash pattern matching or write a Perl script.

If it's just removing the "-1" it's easy, as you indicate.
But the MidiMismatch example that I showed Jean would be more difficult.

Still holding out hope that ly developers may take the suggestion
I made to Jean, which would allow everything to be resolved inside ly.

Thx again,
Jeff

Re: bookOutputName still gets "-1" suffix added to SVG file names

[Jeff Olson]

On 3/29/2023 11:57 PM, Jean Abou Samra wrote:


These "-1" suffices are messing with my URLs for the SVG files,
so I'd appreciate any ideas on how to get rid of them.  Thx.

They are there for good reason. If any of your |\book|s got output on 
multiple pages, there would indeed be multiple files output.


Understood, but, like midi, the first file could (should) still have 
been un-suffixed.


And the current mismatch between layout files and midi files is a good 
reason for the opposite:


Consider this MWE named MidiMismatch.ly that generates pairs of svg and 
midi files:


\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'separate-page-formats 'svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\header { tagline = ##f }
\paper { print-page-number = ##f }
\score { { f' } \layout { } \midi { } }
\pageBreak
\score { { a' } \layout { } \midi { } }
\pageBreak
\score { { b' } \layout { } \midi { } }

The suffices of its generated svg files are **off by one** from the midi 
files:


   1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15  MidiMismatch.mid*
   1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-1.mid*
   1 -rwxrwxrwx+ 1 J None 119 Mar 30 17:15 MidiMismatch-2.mid*
   8 -rwxrwxrwx+ 1 J None    6496 Mar 30 17:15 MidiMismatch-1.svg*
   8 -rwxrwxrwx+ 1 J None    6502 Mar 30 17:15 MidiMismatch-2.svg*
   8 -rwxrwxrwx+ 1 J None    6510 Mar 30 17:15 MidiMismatch-3.svg*



By the way, in addition to simplifying automation (like lilypond-book),

The above example shows how this creates an automation nightmare.


having |-1.svg| even on the first page makes it possible to use both 
|separate-page-formats| and |tall-page-formats| at the same time.



So I added "#(ly:set-option 'tall-page-formats 'svg)" to the example above
and it produced MidiMismatch.svg (with three scores) which is what I 
assume you mean.

It had no effect on the off-by-one between midi and svg, of course.

Nevertheless, couldn't the suffixing algorithm in all cases still start with
the un-suffixed named and add suffices only to resolve actual collisions?

Removing the tall-page-formats line would then have begun with 
MidiMismatch.svg
matching MidiMismatch.mid (the note f') and all subsequent files would 
also match.


And that would also have enabled bookOutputName in my original example 
to have

complete control over the whole file name (with only one file per book).

As it stands, it seems I'd have to use techniques outside of lilypond,
as David W suggests, in order to correct the filenames.  Is that what 
you're implying?


Thx,
Jeff

bookOutputName still gets "-1" suffix added to SVG file names

[Jeff Olson]

I've got to generate a thousand+ cropped SVG files with specified file names
from one lilypond compilation, so I'm wrapping each score in a \book with
its own \bookOutputName as in this MWE:

\version "2.24.1"
#(ly:set-option 'backend 'cairo)
#(ly:set-option 'separate-page-formats 'svg)
#(ly:set-option 'use-paper-size-for-page #f)
#(ly:set-option 'point-and-click #f)
\book {
  \bookOutputName  "Foo"
  { f' }
}
\book {
  \bookOutputName  "Abc"
  { a' }
}
\book {
  \bookOutputName  "Bar"
  { b' }
}

But the SVG files all have the extra -1 suffix as though there were additional
files from the same book that would collide:

  32 -rwxrwxrwx+ 1 J None   32199 Mar 29 22:25  Foo-1.svg*
  32 -rwxrwxrwx+ 1 J None   32190 Mar 29 22:25  Abc-1.svg*
  32 -rwxrwxrwx+ 1 J None   32231 Mar 29 22:25  Bar-1.svg*

My MIDI files don't have this problem since they only add a suffix on
**subsequent** files with the same base name, and there's only one per book.

These "-1" suffices are messing with my URLs for the SVG files,
so I'd appreciate any ideas on how to get rid of them.  Thx.

P.S. I get the same thing using 'backend 'svg
P.P.S  I'm using Windows 10 Pro with Cygnus bash and Frescobaldi 3.1.1

Jeff

Re: Installing 2.24.1

[Jeff Olson]

On 3/13/2023 7:06 AM, Werner LEMBERG wrote:

https://gitlab.com/lilypond/lilypond/-/merge_requests/1869


Wow! That was fast work, Werner!  Thanks for finding a way to include
the extra steps to "Run as administrator".

Jeff

Re: RE: Installing 2.24.1

[Jeff Olson]

On 3/11/2023 10:37 PM, Mark Stephen Mrotek wrote:

My experience installing Lilypond is with the Windows Installer.

I know what a Zip file is yet I have never used one to install a
program.  Is there some more detailed instructions than what is
provided in The Graphical Setup for Windows?


Quoting the Graphical setup under Windows:
http://lilypond.org/doc/v2.24/Documentation/learning/graphical-setup-under-windows

  "The file will a ZIP archive called ‘lilypond-x.y.z-mingw-x86_64.zip’
  (where “mingw” means it’s for Windows). Extract this in the file explorer.
  Place the resulting directory lilypond-x.y.z-mingw-x86_64 in a permanent
  location; the actual folder doesn’t matter, you just need to put it somewhere
  you won’t move it afterwards. For example, you could choose your home folder."
 
Actually, on Windows the folder *does* matter.


Depending upon where you want the installed location to be, you may
need to do some extra steps to overtly "run as administrator".  Previous
releases of LilyPond used the Windows installer to handle this aspect
for you (the familiar "Do you want to allow this program to make changes
on your computer?").  But the extract step in the 2.24 instructions fails
if you choose the typical (protected) Windows place under Program Files.

Here are "some more detailed instructions" (Win 10) for that case:

1) Download lilypond-2.24.1-mingw-x86_64.zip 
fromhttps://lilypond.org/download.html
2) Click the Windows "Start" icon in lower left
3) Scroll way down to see WinZip (alternatively File Manager)
4) Right click WinZip and select More > Run as administrator
5) Answer "Yes" to allow this program to make changes
6) Select the icon for Open WinZip File
7) Browse to where you put the download in step 1)
8) See prompt "Would you like to unzip the contents of this Zip file now?"
9) Select "Yes, unzip the files to a folder I choose"
10) Navigate to e.g. C:\Program Files\LilyPond and unzip

This produces C:\Program Files\LilyPond\lilypond-2.24.1 with the .exe
at C:\Program Files\LilyPond\lilypond-2.24.1\bin\lilypond.exe
This .exe location is what you specify in Frescobaldi.

If you're a tinkerer and might make changes to some of the LilyPond
script files, you would be better off choosing a location under your
home directory, as the instructions suggest.  The complication of
running as administrator is only needed if you want to protect the
installed files from inadvertent modification.

HTH
Jeff

Re: how would one cross-reference two [or more] books?

[Jeff Olson]

On 1/13/2023 1:27 PM, Jean Abou Samra wrote:

LilyPond 2.24.1 is planned for the end of January or early February. Whether it 
includes this mostly depends on whether Ivan Maidanski has released BDWGC 8.2.3 
by then.


Thanks for the update, Jean!  Could you also help me understand what was 
happening with \page-ref in my original post?  E.g., ...


What causes \page-ref to fail for labels outside of the current \book?

Can the caller of \page-ref predict when it would fail, so as to avoid 
calling it if it would fail?


Or if you have to let it fail, can the last arg (default) be replaced 
with a callback that would undo the conversion of a label into a 
stencil?  I considered checking the output stencil of \page-ref, but 
doesn't that have specific position info included that would make it 
difficult to match against?


Why does the "Sav0" invocation of \save-page-refs behave as though it is 
being called after the "Sav1" and "Sav2" invocations, while, in 
contrast, the four invocations of \indexItem ("Top", "No.1", "No.2" and 
"No.3") leave side effects in the index showing their results in the 
order of appearance?


Clearly Lilypond isn't just "executing" commands to completion in order 
of appearance or the ordinary table-of-contents at the beginning of a 
document wouldn't work. Maybe that's just old imperative thinking vs 
functional thinking, but some of these temporal issues make it look 
dysfunctional at times.


What's the right way to think about these issues?

Jeff

Re: how would one cross-reference two [or more] books?

[Jeff Olson]

(including lilypond-user)

On 1/12/2023 7:01 AM, Kieren MacMillan wrote:


Hi all,

A very large part of my composition [and thus Lilypond engraving] 
career is concerned with very large, multi-format musical dramas 
(operas, musicals, plays-with-music, dramatic song cycles, etc.). A 
typical set of outputs might be:


– full orchestra/band score
– individual orchestra/band parts
– Piano/Conductor score (reduction/arrangement)
– Piano/Vocal score (a *different* reduction/arrangement)
– Vocal/Choral score (reduction/arrangement)
– libretto

I would *love* to be able to have a note in the (e.g.) P/C score that 
says “This song is found on pg. 12 of the Vocal/Choral score” — at the 
very least at the song level, but optimally at any arbitrary point in 
the score (e.g., top of every page, beginning of a given section of a 
song, etc.).


1. What mechanism(s) would be best used to accomplish this?

2. Can it be done [relatively easily] if each of the outputs are 
driven from an individual .ly file, or would it really require all 
outputs to be coded in the same .ly file [with separate \book blocks]?


Thanks!
Kieren.

Hi Kieren,

IIUC, this sounds like the same problem as how to make an index of items 
across multiple books.


Back in 2.22 where I was running out of 32-bit memory, I was forced to 
try dividing my 500+ page compilation (logically one book) into multiple 
books in order stay under the memory limit.  I'm guessing the end of a 
\book throws out all of its grobs while keeping its stencils, and that 
releases a lot of memory.


But in my work, having an index at the end was absolutely essential, and 
it had to cover everything as though it had been multiple \bookparts 
instead of multiple \books.


The problem was that \page-refs into other \books always failed (they 
fell back to the default arg).


The solution was to save the \page-ref output as stencils at the end of 
each \book, i.e. to resolve the \labels while you still have them.


In my case, there was an index data structure that was designed to save 
\labels, which ordinarily would be converted into markup stencils when 
the index was being printed at the very end.


What I did was make a function that would re-scan that index structure, 
resolving any stored \labels into stencils, if that hadn't already been 
done (i.e. if they weren't already stencils, resolve them to stencils).  
When it was time to print the final index, you'd test the supposed 
\label values to see if they were already stencils: (if (ly:stencil? 
label) (markup #:stencil label) (markup #:page-ref label "XXX" "?"))).


Look in the attached dual-index-dev.ily (where dual meant something 
else: a sorted index plus a simultaneously kept unsorted index). See "% 
save-page-refs command" and "% index command" for the relevant code.


Where things got beyond my abilities was for the parts of document that 
were before my explicit \books.  This is demonstrated by the simple file 
MWEindex.ly.  It has two books, labeled No.1 and No.2., with the 
non-book stuff before them named "Top" and the stuff after named No.3.  
It makes a simple index showing those four items, along with their page 
numbers, which did get correctly resolved outside of the two books:


Exercise 0 . . . . . Top . . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . . . . . . .Sav1
Exercise 1 . . . . . No.1 . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . . . . . . . . 101
Exercise 2 . . . . . No.2 . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . . . . . . . . 201
Exercise 3 . . . . . No.3 . . . . . . . . . . . . . . . . . . . . . . . 
. . . . . . . . . . . . . . . . . . . . 1


No.1 does start on page 101 and No.2 does start on 201, and No.3 is 
technically correct as page 1.  But I could not get items from Top to 
resolve also to page 1.  Instead, it is replaced by the default value 
supplied as the tag argument to save-page-ref, so I could tell which 
invocation of save-page-refs was clobbering things.


It might help to note which pdf outputs contain which parts:

    "Number 1" is in MWEindex.pdf
    "Number 2" is in MWEindex-1.pdf
    "Top Level", "Number 3" and the "Exercise Index" are in 
MWEindex-2.pdf (the last to print)


Apparently the page-refs from Top are indeed added to the index data 
first, even though that part of the document is the last to be printed. 
(Expected)


What was unexpected was that the \save-page-refs tagged "Sav0" was 
executed (or whatever the non-imperative term is) last.  This left the 
item labeled "Top" in the index where it was found during book 1 (by the 
save-page-refs tagged "Sav1") which couldn't resolve it because that 
label was not in book 1.


I didn't know how to overcome this peculiarity, other than by not 
indexing any items in the Top section.  And I lost interest when I 
learned that 2.23 was 64-bit and shouldn't need division into books to 
keep memory in bounds.  Turns out, ironically, 

Re: HTH w RTFM (Reading The Full Manual)

[Jeff Olson]

On 1/5/2023 6:26 AM, David Kastrup wrote:

I wonder whether something like this might help motivate work on lagging
translations?


Hmm, lags over what kind of time scale?

I've only been comparing major releases, 2.24.0 vs 2.22.2.
Did translations for 2.24.0 features not make it into that release?

Or is the issue one of tracking the lag between en and lang deliveries
on a finer scale, during the development release?

And in either case, would translators just look at the en Section Changes
to see what's new/ripe for translation.  Or do they need diffs between
en and lang that show they've actually changed the corresponding lang sections?

Some of that may be better suited to a tool that looks at unpublished source.

Jeff

Re: HTH w RTFM (Reading The Full Manual)

[Jeff Olson]

On 1/5/2023 3:24 PM, Jeff Olson wrote:

But there is one for the Contributor's Guide, which I'll send separately due to 
size.


And here it is.  In this one, the Old/Obsolete sections reveal that most of the 
old
administrative policies have been thrown out.  Also the Bug Squad and Meisters.

   - ContributorsGuide24-SectionChanges.html

Jeff
Title: Contributor's Guide — Section Changes




<< Back to Documentation Index
 LilyPond — Contributor’s Guide  v2.24.0 (stable-branch). 



  1. Introduction to contributing
  
1.1 Help us
1.2 Overview of work flow
1.3 Summary for experienced developers
1.4 Mentors
  
  2. Quick start
  
2.1 LilyDev

  Installing LilyDev in VirtualBox
  Configuring LilyDev in VirtualBox

2.2 Compiling with LilyDev
2.3 Now start work!
  
  3. Working with source code
  
3.1 Setting up

  3.1.1 Installing Git
  3.1.2 Creating a GitLab account and setting up SSH
  3.1.3 Cloning and forking the repository
  3.1.4 Configuring Git

3.2 Git cheat sheet

  Pulling recent changes
  Viewing the history
  Switching branches
  Listing branches
  Staging and committing files
  Amending and reverting changes
  Uploading your branch for review
  Deleting branches

3.3 Lifecycle of a merge request

  3.3.1 Uploading a patch for review
  3.3.2 Automated testing
  3.3.3 Patch countdown
  3.3.4 Merging to master
  3.3.5 Abandoned patches

3.4 Writing good commit messages
3.5 Commit access
3.6 Further Git documentation resources
3.7 Repository directory structure
  
  4. Compiling
  
4.1 Overview of compiling
4.2 Requirements

  4.2.1 Requirements for running LilyPond
  4.2.2 Requirements for compiling LilyPond
  
Fedora
Linux Mint
OpenSUSE
Ubuntu
Other
  
  4.2.3 Requirements for building documentation

4.3 Getting the source code
4.4 Configuring make

  4.4.1 Build modes
  4.4.2 Running autogen.sh
  4.4.3 Running configure
  
Configuration options
Checking build dependencies
Configuring target directories
  


4.5 Compiling LilyPond

  4.5.1 Using make
  4.5.2 Saving time with the ‘-j’ option
  4.5.3 Useful make variables

4.6 Post-compilation options

  4.6.1 Installing LilyPond from a local build
  4.6.2 Generating documentation
  
Documentation editor’s edit/compile cycle
Building documentation
Building a single document
Saving time with CPU_COUNT
Installing documentation
Building documentation without compiling
  
  4.6.3 Testing LilyPond binary

4.7 Problems

  Compiling on MacOS X
  FreeBSD
  International fonts
  Using lilypond python libraries

4.8 Concurrent stable and development versions
4.9 Build system
  
  5. Documentation work
  
5.1 Introduction to documentation work
5.2 \version in documentation files
5.3 Documentation suggestions
5.4 Texinfo introduction and usage policy

  5.4.1 Texinfo introduction
  5.4.2 Documentation files
  5.4.3 Sectioning commands
  5.4.4 LilyPond formatting
  5.4.5 Text formatting
  5.4.6 Syntax survey
  
Comments
Cross references
External links
Fixed-width font
Indexing
Lists
Special characters
Miscellany
  
  5.4.7 Other text concerns

5.5 Documentation policy

  5.5.1 Books
  5.5.2 Section organization
  5.5.3 Checking cross-references
  5.5.4 General writing
  5.5.5 Technical writing style

5.6 Tips for writing docs
5.7 Scripts to ease doc work

  5.7.1 Scripts to test the documentation
  
Building only one section of the documentation
  
  5.7.2 Scripts to create documentation
  
Regenerating menus
Updating doc with convert-ly
  


5.8 Docstrings in scheme
5.9 Translating the documentation

  5.9.1 Getting started with documentation translation
  
Translation requirements
Which documentation can be translated
Starting translation in a new language
  
  5.9.2 Documentation translation details
  
Files to be translated
Translating the Web site and other Texinfo documentation
Adding a Texinfo manual
  
  5.9.3 Documentation translation maintenance
  
Check state of translation
Updating documentation translation
Updating translation committishes
Maintaining without updating transl

comparing crashes in 2.23.81 with 2.23.14 and 2.22.1

[Jeff Olson]

The attached score generator hints that the crashes in these three 
releases may be different manifestations of the same 32-bit address limit.


A previous thread 
(https://lists.gnu.org/archive/html/lilypond-user/2022-11/msg00189.html) 
indicated a fixed was being worked for "exited with return code 
-1073741819" in 2.23.14 and that 2.23.81 was "better in this respect, 
although the problem remains in very intensive situations".


Since this is a blocking issue for my large projects, I used a 
light-weight score generator (see attached tst22381.ly and 
gen-scores.ily) that simulates my projects to test the breaking points 
of these three releases.  All you do to run it is change the version 
number and set the number of scores.  It then generates a simple but 
large document with the specified number of scores where the scores vary 
pseudo-randomly in size, to simulate the variations in my project.  I've 
been running it from Frescobaldi 3.1.1 on Windows 10, increasing the 
number of scores until it crashes.  Takes about 1'14" per run on 2.23.81.


Here are the repeatable results for these releases:

2.22.1 runs up to 625 scores, whereupon lilypond reaches the 32-bit 
address limit (~2G on my 64-bit Windows 10) and gets bad-alloc.


2.23.14 runs up to 413 scores, beyond which it returns 1073741819.

2.23.81 runs up to 418 scores, beyond which it returns 1073741819.

Coincidentally (?) all of these failures are at about the same memory 
usage (~2G) as measured in Task Manager. Of course 2.22.1 being 32-bit 
has a hard limit, but the 2.23 releases should be able to cruise past 
that limit.


The theory that unites these is that the segmentation fault implied by 
1073741819, so I hear, is typically due to a bad pointer leading outside 
the boundaries of the process's memory segment.  Perhaps after the 
porting 2.23.x to 64-bits, there remains a pointer variable somewhere 
that is still typed for 32 bits.  So when the number of scores pushes 
memory consumption above the 32-bit size and the code with the 32-bit 
wide pointer eventually gets executed, bang, you get a 1073741819.  Or 
something like that.  Just an amateur guess.


My projects have about 1200 scores, hence my interest in helping however 
I can, as a user not a developer. Perhaps real developers may be able to 
use this score generator to prove in the fix.


HTH,
Jeff
\version "2.23.81"

% number of score to generate
#(define numscors 418)

\header {
  title = \markup { "Version " #(lilypond-version)" with " #(number->string numscors) " scores" }
  tagline = ##f
}
\paper  {
  #(set-paper-size "letter")
  indent = 7\mm
  top-margin = 15\mm
  bottom-margin = 15\mm
  left-margin = 15\mm
  right-margin = 15\mm
  ragged-last-bottom = ##t
  page-breaking = #ly:page-turn-breaking
}

\include "gen-scores.ily"

$@(scors numscors)

% final values
#(format #t "exn=~d  i=~d  mincat=~d  maxcat=~d~%" exn i mincat maxcat)



%{
convert-ly.py (GNU LilyPond) 2.23.14  convert-ly.py: Processing `'...
Applying conversion: 2.23.1, 2.23.2, 2.23.3, 2.23.4, 2.23.5, 2.23.6,
2.23.7, 2.23.8, 2.23.9, 2.23.10, 2.23.11, 2.23.12, 2.23.13, 2.23.14
%}


%{
convert-ly.py (GNU LilyPond) 2.23.81  convert-ly.py: Processing `'...
Applying conversion: The document has not been changed.
%}
\version "2.23.81"

% some sequential music objects (fragments to be concatenated by gen-music 
function)
xa = { g'4. a'8 g'4 f' e' f' g'2 d'4 e' f'2 e'4 f' g'2 g' a'4 g'8 f' e'4 f' g'2 
}
xb = { d'4 e' f'4 e' f' g'8 f' e'4 f'8 g' a'4 c'' e''4 d''8 c'' b'4 cis'' d''2 }
xc = { a'4 b' c''4 b' c'' d''8 c'' b'4 c''8 d'' e''2~ e''4 d''8 c'' b'4 cis'' 
d''2 }
xd = { a'4 b' c''4 b' c'' d''8 c'' b'4 g'8 f' e'4 d' cis'4 a'8 g' a'4 cis'' 
d''2 }
xe = { d''4 c'' b'4 g'8 f' g'4 b' c''4 d'' e''2 d''4 c''8 b' a'4 b' c''2 }
xf = { g'4 a' bes'4 a' bes' c''8 bes' a'2 b' c''4 b' c'' d''8 c'' b'4 a' bes'2 
a'4 g'8 f' e'4 fis' g'2 }
xg = { d'4 e' f'4 e' f' g'8 f' e'4 c''8 b' a'4 g' fis'4 d''8 c'' d''4 fis' g'2 }
xh = { g'4 f' e'4 c''8 bes' c''4 e' f'4 a'8 g' f'4 e' d'2 g' e'4 c' }

% list of sequential music objects
smolist = #(list xa xb xc xd xe xf xg xh)

% to get a scheme list of music elements from a music object
#(define (get-elements mus) (ly:music-property mus 'elements))

% list of element-lists
elists = #(map get-elements smolist)
enum = #(length elists)

% recursively concatenate a range of elists (0 <= m <= n, possibly > enum)
#(define (cat-elists m n)
   (let ((elist-m (list-ref elists (modulo m enum
 (if (< m n) (append elist-m (cat-elists (1+ m) n)) elist-m )))

% force a fixed seed (pseudo-random)
#(set! *random-state* (seed->random-state 42))

% generate music by concatenating contiguous members from list.
% i mod enum is the starting position in the list for the next gen-music.
% mincat is the minimum number of concatenations (mincat >= 0)
% maxcat is the max number of concatenations (maxcat >= mincat)
% actual number of cats is random between mincat and maxcat.
i = 0
mincat = 2
maxcat 

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/14/2022 1:53 PM, Jean Abou Samra wrote:
Meanwhile I've got to get back to making an MWE to explore why 
2.23.14 (but not 2.22.1) is crashing with a segmentation fault when I 
put too many scores in a bookpart (clearly another thread).

If it is something like "exited with return code -1073741819",
that is already in the process of being fixed. Otherwise, yes,
please write about this ASAP.


That's it exactly!  What a relief to know a fix is coming.

Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/13/2022 1:24 PM, Jean Abou Samra wrote:

[Self-promotion:] Have you tried to read this?

https://scheme-tutorial.readthedocs.io

(It originates in a presentation that some people found clear, which 
is the reason why I wrote it down.)


Yes!  It is excellent and I highly recommend it.  Especially after you 
incorporated my 7/12/2022 off-list suggestions concerning named let and 
various presentation formatting issues (self-promotion )!


I also recommend your 
https://extending-lilypond.readthedocs.io/en/latest/ and am reading 
Abelson and Sussman as recommended by Andrew 
(https://lists.gnu.org/archive/html/lilypond-user/2022-07/msg00388.html). 
All these help.


It seems my issues are not so much with Scheme as they are with the 
multi-pass, delayed-effect subtleties inherent in the complex issues 
lilypond addresses, which continue to surprise me when I try to  make a 
substitution function work.  But that's a whole 'nother thread.


Meanwhile I've got to get back to making an MWE to explore why 2.23.14 
(but not 2.22.1) is crashing with a segmentation fault when I put too 
many scores in a bookpart (clearly another thread).


Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/10/2022 4:50 AM, Jean Abou Samra wrote:
For your information, I have submitted a merge request to mention this 
change in LilyPond's Changes document 
(https://gitlab.com/lilypond/lilypond/-/merge_requests/1719).


Also, the red herring in init.ly is now tracked in 
https://gitlab.com/lilypond/lilypond/-/issues/6459 


Thanks, Jean.

While we're at it, there are two other changes that I don't see listed 
in https://lilypond.org/doc/v2.23/Documentation/changes-big-page.html


 * -dbackend=cairo
 o Jonas invited users to try this out in the announcement for 2.23.12
   https://lists.gnu.org/archive/html/lilypond-user/2022-08/msg00364.html
   but cairo isn't mentioned at all in the changes doc.
 * \bar ".|:-|"
 o This is what convert-ly did to my 2.22 instances of \bar ".|:" ,
   which isn't even in the 2.23 NR.
 o It's especially curious since the 2.23 changes doc uses the 2.22
   form unchanged elsewhere:
 + "The solution is to place \bar inside the music for each
   staff, as is usual with most commands.
   <<
  \new Staff { \bar ".|:" c' }
  \new Staff { \bar ".|:" c' }
>>

Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/12/2022 1:51 AM, Hans Åberg wrote:

On 12 Nov 2022, at 05:27, Jeff Olson  wrote:

On 11/7/2022 6:58 AM, Hans Åberg wrote:

In 2.22 you successfully get "Hello, World!" at top of page.


This example works in LilyPond 2.23.80 (MacPorts), on MacOS 13.0.

Interesting.  This must mean that Helvetica-Bold is available as a system font 
on MacOS, so even our stripped down ghostscript can find it there.  Not so on 
my Windows 10.

Indeed, there is a TrueType Collection Helvetica.ttc, that also contains the 
bold font.

This link say you can download it.
https://en.wikipedia.org/wiki/Helvetica


Thanks, Hans,

That info was for a Helvetica derivative called "Neue Haas Grotesk", and 
the mentioned package, "Pan-European Supplemental Fonts", is no longer 
available for Windows 10.


But even buying real Helvetica properly might not work because the 
ghostscript in 2.23.14 fails to find find fonts that already *are* 
system fonts on my Windows 10, namely "Times New Roman", which is 
present in various faces via these Windows font files:


   $ ls /c/Windows/Fonts/times*
   /c/Windows/Fonts/times.ttf  /c/Windows/Fonts/timesbd.ttf
   /c/Windows/Fonts/timesbi.ttf  /c/Windows/Fonts/timesi.ttf

But my MWE continues to fail with all these attempts to reference the 
old "/Times" and "/Times-Bold" that used to work in 2.22.1's ghostscript:


   \markup { \postscript #"
    %/Times findfont
    %/Times-Bold findfont
    %/TimesNewRoman findfont
    %/Times-New-Roman findfont
    %/Times-Regular findfont
    %/Times-Roman findfont
    %/TimesNewRoman-Regular findfont
    /TimesNewRoman-Bold findfont
    4 scalefont setfont
    (ABCDEFG#b) show "}





So, Jean,

The 2.23 ghostscript appears to find system fonts on MacOS (/Helvetica) 
but not on Windows (/Times).  Is that the kind of failure that Jonas was 
referring to in the developer thread?


   https://lists.gnu.org/archive/html/lilypond-devel/2022-04/msg00018.html
   If system fonts don't work anymore via LilyPond, that would be worth of
   a bug report.

I've done #(ly:font-config-display-fonts) as directed in the 2.23 NR 
(thanks for adding that), and it lists


   family Times New Roman
 Times New Roman:style=Bold,Negreta, ...

But the MWE above with all those variations still fails even after 
trying all of these overrides


   %\markup \override #'(font-name . "Times") "ABCDEFG#b"
   %\markup \override #'(font-name . "Times Bold") "ABCDEFG#b"
   %\markup \override #'(font-name . "Times New Roman") "ABCDEFG#b"
   \markup \override #'(font-name . "Times New Roman Bold") "ABCDEFG#b"

This isn't blocking me since you showed me the workaround using "C059".  
I only raise this issue in case the stripped down ghostscript isn't 
working with system fonts the way Jonas and the developers intended.


If this is just a matter of finding the right way to name the font 
within \postscript, then perhaps some warning should be added to the 
2.23 changes about this issue.


Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/7/2022 11:58 PM, Jean Abou Samra wrote:

By the way, what are you using PostScript code for more precisely?
It is not possible for you to switch to regular markup? (If
it's lots of paths, for example, that could be partly automated.)


Jean,

I did most of this 5+ years ago in 2.18.2 before I knew any scheme, and 
my scheme attempts since then have not built my confidence.


The main purpose of my postscript code is generating a wide variety of 
fretboard and keyboard diagrams, so it's more of a programming 
environment where the elements are postscript procedures that can 
substituted easily for other procedures to allow lots of options.


It's also heavy on data structures (two dimensional arrays of property 
lists) where each cell (finger position) on the fretboard is described 
by its own property list.  Cells have type, so they can even refer to 
abstractions outside the fretboard such as labels for open string 
tunings and Roman numerals for neck positions.  Other properties 
identify the cell's position (string, fret), its pitch (midi) and other 
info whose length varies with the cell's type (e.g. text, font and fill 
color for a typical cell).


Building a specific fretboard starts with a variety of geometry options 
(including size, proportions and instrument type) and computing the 
frets and string crossings accordingly (in another data structure).  
Then computing the cell properties mentioned earlier according to 
various options the user has specified.  Some fretboards can be split 
lengthwise (at the tuning discontinuity between strings 2 and 3) or 
shown in reverse (as though you're seeing through the back of the neck, 
like Gaspar Sanz's tablature orientation).  Cells can optionally be 
rendered with rounded edges, like "chicklet" keyboard buttons.  Frets 
can be shown (or not) in a variety of metallic colors.  Yada, yada, ...  
A ton of capabilities, most of which I'm not using in these first few books.


So it's not a lot of painstakingly hard-coded paths that I could 
transform with a perl script.  It's a lot of imperative, stateful, 
global-memory programming expressed in a ton of stack operations 
(natural to me, since I wrote a light-weight OS in Forth fifty years 
ago).  I'd really have to have a lot more confidence in my 
scheme/functional programming before trying to do it in markup.


Maybe I'll send you a sample off-list to see what an expert would consider.

Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/7/2022 11:58 PM, Jean Abou Samra wrote:

Surprises (2)-(4) happen because font-name is meant to be a
sledgehammer that overrides all font selection logic. In
particular, it makes \bold and \italic have no effect.
You have to use font-style instead.


On 11/8/2022 12:07 AM, Jean Abou Samra wrote:

Sorry, I was misremembering, font-style doesn't exist.
The solution is more like:

\version "2.23.80"

\paper {
  fonts =
    #(set-global-fonts
  #:roman "C059"
  #:sans "Nimbus Sans"
  #:typewriter "Nimbus Mono PS")
}

\markup \bold \sans "abcde"


Nimbus Sans is the default for #:sans, but you could
replace it with Nimbus Sans L.

Alternatively:

\version "2.23.80"

\markup \override #'(font-name . "Nimbus Sans Bold") "abcde" 


Jean,

Thanks for the examples.

This is what I'm using so far at the end of my main ly file to get the 
fonts loaded:


   \markup \override #'(font-name . "Nimbus Sans Bold") "ABCDEFG#b in
   /NimbusSans-Bold ~/Helvetica-Bold"
   \markup \override #'(font-name . "C059 Bold") "ABCDEFG#b in
   /C059-Bold ~/Times-Bold"
   \markup \override #'(font-name . "C059") "ABCDEFG#b in /C059-Roman
   ~/Times"
   \markup \override #'(font-name . "Emmentaler-20") "ABCDEFG#b in
   Emmentaler-20

I'll translate it to hide the output, but I'll probably have to put it 
inside an explicit bookpart since it forces the title/composer like on 
the front page.


Would be nice if lilypond had a way to load a resource into the 
postscript file without having to produce this extra output, or sledge 
hammer the bold/italic styles.


So does this sort of code have to be at the end because you can't 
un-break the damage from the sledge hammer?


Jeff

--
  
  o_ Jeff Olson

 (\___\/_/)   jjocanoe
~ ~ ~ / ~ ~ ~ ~  @gmail.com

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/7/2022 6:58 AM, Hans Åberg wrote:

In 2.22 you successfully get "Hello, World!" at top of page.

This example works in LilyPond 2.23.80 (MacPorts), on MacOS 13.0.


Interesting.  This must mean that Helvetica-Bold is available as a 
system font on MacOS, so even our stripped down ghostscript can find it 
there.  Not so on my Windows 10.


Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/7/2022 6:46 AM, Timothy Lanfear wrote:
Could it be sufficient to install the full Ghostscript and set the 
environment variable GS_FONTPATH to point to that Ghostscript 
version's font directory? (e.g. export GS_FONTPATH=/usr/share/fonts). 
The LilyPond Ghostscript will then search that directory.


Love the creativity on this list!  I was wondering about using the full 
Ghostscript executable but never thought of just using its fonts.  
Thanks for the idea, Timothy.


Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/7/2022 12:02 AM, Jean Abou Samra wrote:


\version "2.23.80"

\markup {
\postscript "
    /NimbusSans-Regular findfont
    4 scalefont setfont
    (Hello, World!) show
    "
}

\markup
\override #'(font-name . "Nimbus Sans")
\translate #'(100 . 0)
"abcxyz"

...

N.B. The way I found "NimbusSans-Regular" was by running
LilyPond with --ps and looking at the generated PostScript
code (search for BeginResource in it). 



Excellent!  Thank you three times for your examples and patient 
explanations!


So part of the trick is discovering which lilypond font-name to specify 
in order to embed the desired font in lilypond's postscript.


My target is /Helvetica-Bold in postscript, and the wikipedia article on 
Ghostscript indicates that "Nimbus Sans L" is the proper substitute for 
Helvetica.   So I followed your pattern and used font-name "Nimbus Sans 
L", but (surprise 1) the generated postscript font  was 
/TeXGyreHeros-Regular.   The Hello World output looked like Helvetica 
but was not bold, so I specified \bold "abcxyz", but (surprise 2) that 
didn't change abcxyz to bold and still used font /TeXGyreHeros-Regular.  
So font-name "Nimbus Sans L" does not appear to have a bold type?


Similar thing (surprise 3) with font-name "Nimbus Sans": adding \bold 
had no effect on abcxyz and the postscript font was still 
/NimbusSans-Regular.  Here's the code I used:


\markup
\override #'(font-name . "Nimbus Sans")
\abs-fontsize #20
\bold
"abcxyz"

Not knowing how to guess the right font-name, I removed the override and 
just did \sans \bold:


\markup
\abs-fontsize #20
\sans \bold
"ABCDEFG#b in ly \sans \bold"

That of course produced output in sans bold and the postscript font it 
embedded was /NimbusSans-Bold.  I guess surprise 4 is that lilypond 
knows about postscript font /NimbusSans-Bold but won't generate it when 
\bold is specified with font-name  "Nimbus Sans".


As a check, removing the \bold and doing just \sans does indeed revert 
to /NimbusSans-Regular (no surprise).


So I can get my postscript to run with /NimbusSans-Bold instead of 
/Helvetica-Bold.  I just have to let lilypond pick the specific font 
family for abcxyz based on the generic family.  It works, but I'd feel 
more confident if I knew the right font-name to cause /NimbusSans-Bold 
to be loaded.


Am I still doing something wrong? (wouldn't be a surprise)

Jeff

Re: ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

On 11/6/2022 1:05 AM, Jean Abou Samra wrote:


Can someone explain (a) why Helvetical is no longer in 2.23.14's gs 
and (b) the syntax for specifying Nimbus Sans L properly in my MWE?


Thanks for wading through all this with me.  I've been on a very big 
lilypond project for 6 years now, and it is so big I have to use the 
64-bit version in 2.23 due to memory usage.  But the project also 
contains 2500+ lines of postscript code for essential diagrams (like 
guitar fretboards and piano keyboards) so right now I'm still stuck.  
Really need Helvetica-Bold or its metrical equivalent to work in 2.23


This was discussed a few times, last time here: 
https://lists.gnu.org/archive/html/lilypond-devel/2022-10/msg00065.html




Jean, please help me understand what this implies.  The above 
lilypond-devel thread basically ends with Harm's statement that


   It is no longer possible to specify fonts like above.
   https://lists.gnu.org/archive/html/lilypond-devel/2022-04/msg00018.html

The font specification he says is "no longer possible" is exactly like 
my case: \postscript "/Arial-Bold findfont", so he suggests not using 
\postscript.   And the thread he references ends with Jonas' reply about 
how lilypond's ghostscript is different than others:


   Not quite, our Ghostscript is stripped down to not include unnecessary
   stuff and that is not prepared for users doing stuff with \postscript.

Do the above responses mean there's no way to use fonts within 
lilypond's \postscript feature anymore?


That would be a drastic change affecting users who have developed an 
embedded base of postscript code within lilypond.  I've been searching 
the v2.23 changes 
(https://lilypond.org/doc/v2.23/Documentation/changes-big-page.html) and 
there's no mention at all of "postscript" or "Ghostscript" or the need 
to migrate from using \postscript to \markup the way that Harm suggested.


There's only this oblique mention of fonts in the section that aimed at 
enthusiasts compiling LilyPond from source and packagers preparing 
LilyPond for distribution ("If you are not part of either group, you can 
skip over this section").  It says:


   Starting with this stable release, LilyPond’s build system does not
   install text fonts anymore. Please provide them as separate packages
   while paying attention to the fonts’ license and notice files.

I'm hoping the lack of a specific change notice means there's still a 
way to use fonts within \postscript, but the replies from Harm and Jonas 
suggest otherwise.


Please clarify.  For example,

 * Is \postscript inside lilypond deprecated or no longer supported?
 * Is the use of "findfont" within \postscript no longer supported?
 * Or are there some fonts on which findfont is still usable?
 * E.g., should findfont still work on the font families listed in
   https://lilypond.org/doc/v2.23/Documentation/notation/fonts#font-families?
 * Or is there a way a font-name override declared outside of
   \postscript can be referenced by findfont inside a \postscript block?

In other words, perhaps, what's the verdict on \postscript in lilypond?

Jeff

ghostscript 9.56.1 in lilypond 2.23.14 no longer finds font Helvetica-Bold, but gs in 2.22.1 did

[Jeff Olson]

This MWE works in 2.22.1 but fails in 2.23.14 (running via Frescobaldi 
3.1.1 on up-to-date Windows 10):


   \version "2.22.1"
   \markup {
  \postscript #"
    /Helvetica-Bold findfont
    4 scalefont setfont
    (Hello, World!) show
    "
   }

In 2.22 you successfully get "Hello, World!" at top of page.

In 2.23 you get a warning that gs failed, along with a red herring about 
(let ((book-handler ... yada yada.  See attachment 
Helvetica-error-Frescobaldi.txt.


To see why gs failed, I used a cygwin window to run the gs that is 
packaged with 2.23.14 ('/c/Program 
Files/LilyPond/lilypond-2.23.14/libexec/gs.exe') and added the -dDEBUG 
option to the options that lilypond supplied.


The specific gs failure is

   Error: /invalidfont in findfont
   Operand stack:
   Helvetica-Bold

See attachment Helvetical-error-Ghostscript.txt for the full gs command 
and its output.


Interestingly, saving the postscript intermediate file from 2.22.1 
(where Helvetica works) and running the gs from 2.23.14 also failed with 
the same gs error.


Following advice from the NR on Fonts, I ran font-config-display-fonts 
in both 2.22.1 and 2.23.14 and neither output mentioned Helvetica. So 
that isn't how Helvetica was found in 2.22.1.


And Helvetica is not a system font in Window 10 (not in 
C:\Windows\Fonts) so I can't follow the NR to do 
#(ly:font-config-add-font "path/to/font-file").


The only way that Helvetica was found in 2.21.1 must be that it was 
supplied in the ghostscript.


Indeed, even the ghostscript docs 
(https://ghostscript.readthedocs.io/en/latest/Fonts.html) say it 
includes "Times, Helvetica, Courier, Symbol, etc."


So, the gs packaged with 2.21.1 includes Helvetica but the gs packaged 
with 2.23.14 apparently does not.


Wikipedia says that font "Nimbus Sans L" is a metrical equivalent to 
Helvetica-Bold (per 
https://en.wikipedia.org/wiki/Nimbus_Sans#Nimbus_Sans_L) and is also 
included in Ghostscript:


   "Although the characters are not exactly the same, Nimbus Sans L has
   metrics almost identical to Helvetica and Arial. Nimbus Sans L is
   one of the Ghostscript fonts, a set of free alternatives to the 35
   basic PostScript fonts (which include Helvetica)."

And Nimbus Sans L is also listed in our NY as part of our "sans" family.

But I have not found a way to specify Nimbus Sans L (or other Nimbus San 
variations) in my postscript findfont in my MWE.


Can someone explain (a) why Helvetical is no longer in 2.23.14's gs and 
(b) the syntax for specifying Nimbus Sans L properly in my MWE?


Thanks for wading through all this with me.  I've been on a very big 
lilypond project for 6 years now, and it is so big I have to use the 
64-bit version in 2.23 due to memory usage.  But the project also 
contains 2500+ lines of postscript code for essential diagrams (like 
guitar fretboards and piano keyboards) so right now I'm still stuck.  
Really need Helvetica-Bold or its metrical equivalent to work in 2.23


Jeff
\version "2.23.14"
\markup {
  \postscript #"
/Helvetica-Bold findfont
4 scalefont setfont
(Hello, World!) show
"
}Starting lilypond.exe 2.23.14 [MWE-Helvetica.ly]...
Processing `M:/music/postscript/MWE-Helvetica.ly'
Parsing...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `MWE-Helvetica.pdf'...
warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH 
-dAutoRotatePages=/None -dPrinted=false ./lilypond-tmp-6034027)' failed (1)

C:/Program 
Files/LilyPond/lilypond-2.23.14/share/lilypond/2.23.14/ly/init.ly:65:2: error: 
Guile signaled an error for the expression beginning here
#
 (let ((book-handler (if (defined? 'default-toplevel-book-handler)
Throw to key `ly-file-failed' with args `()'.
Exited with return code 1.
$ '/c/Program Files/LilyPond/lilypond-2.23.14/libexec/gs.exe' -dDEBUG -q 
-dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH -dAutoRotatePages=/None -dPrinted=false 
./lilypond-tmp-6034027
START 0 1470560 172535 1310592 29508 true 575 3 <0>
END PROCS 2 1519392 220962 1330792 35420 true 684 3 <0>
END FONTDIR/ENCS 3 1548024 250403 1330792 37900 true 694 3 <0>
END DEVS 4 1549952 21 1330792 37900 true 698 3 <0>
END STATD 5 1570152 271911 1330792 40780 true 703 3 <0>
END GS_FONTS 7 1620504 333597 1330792 40780 true 732 3 <0>
END BASIC COLOR 8 1669336 358866 1330792 40780 true 748 3 <0>
END IMAGE 10 1669336 366518 1330792 40780 true 753 3 <0>
BEGIN RESOURCES 14 2451856 1108435 1435896 146580 true 774 4 <0>
END CATEGORY 17 2451856 1112362 1435896 146868 true 775 5 <0>
END GENERIC 18 2482008 1136102 1435896 146868 true 777 4 <0>
END FIXED 19 2502208 1153328 1435896 146868 true 777 4 <0>
END MISC 20 2502208 1164912 1435896 146868 true 777 4 <0>
END ENCODING 22 2522408 1183946 1435896 150498 true 777 4 <0>
Extend MacRomanEncodingForTrueType for TrueType: insert /apple @ 240
Extend MacRomanEncodingForTrueType for TrueType: insert /approxequal @ 197
Extend MacRomanEncodingForTrueType for TrueType: insert 

Re: ChoirStaff with spanning bar lines at breaks

[Jeff Olson]

On 10/18/2022 5:30 AM, Lukas-Fabian Moser wrote:

\version "2.22.1"

\layout {
  \context {
    \ChoirStaff
    \consists Span_bar_engraver
    \override SpanBar.break-visibility = ##(#t #f #f)
  }
}


... or, if you want to have the illusion of being able to talk to 
LilyPond in English, equivalently:


\layout {
  \context {
    \ChoirStaff
    \consists Span_bar_engraver
    \override SpanBar.break-visibility = #end-of-line-visible
  }
}
On 10/18/2022 8:24 AM, Kieren MacMillan wrote:

Lukas,


... or, if you want to have the illusion of being able to talk to LilyPond in 
English

BWAHAHAHAHA!
Kieren


Perfect!  Thank you, all!

I got as close as the Span_bar_engraver in Internals but figured 
ChoirStaff had to suppress it.  Now it looks obvious.


BTW, the source was "Still, Still, Still" in the book "Alte deutsche 
Volkslieder" by Hans Müller published in 1916 by Germanistische Presse, 
New York.  All 99 songs in the book follow this convention.


Jeff

ChoirStaff with spanning bar lines at breaks

[Jeff Olson]

I'm transcribing an SA-TB piece with lyrics between the two staves and 
using a ChoirStaff so there are no spanning bar lines between the staves 
that would interfere with the lyrics.  But my source does add spanning 
bar lines at the end of each system.


How can I get bar lines in a ChoirStaff to span staves only at the end 
of each system?


See attached MWE-ChoirStaff-end-bars.ly

Jeff
\version "2.22.1"

\header {
  tagline = ##f
}

global = {
  \key c \major
  \time 4/4
}

soprano = {
  a'1 b'
  \bar "|."
}

alto = \relative {
  \global
  % Music follows here.
  
}

tenor = {
  f1 g
  
}

bass = \relative {
  \global
  % Music follows here.
  
}

verse = \lyricmode {
  A -- men
  
}

\score {
  \new ChoirStaff <<
\new Staff  <<
  \new Voice = "soprano" { \voiceOne \soprano }
>>
\new Lyrics \with {
  \override VerticalAxisGroup #'staff-affinity = #CENTER
} \lyricsto "soprano" \verse
\new Staff  <<
  \clef bass
  \new Voice = "tenor" { \voiceOne \tenor }
>>
  >>
  \layout { }
}

Re: Barre grob - appearance

[Jeff Olson]

On 8/27/2022 5:36 AM, Thomas Morley wrote:

Ofcourse, one can find several
codings here on the list, in LSR, I have some own as well. All are
(ab)using spanners like TextSpanner or hijacking other grobs like
Arpeggio.


As an old amateur guitarist, I'm looking forward to a better barre 
solution.  Thank you, Harm, for taking this on!


In the mean time there are existing solutions that are NOT based on 
spanners.


The system I've been using for years is based on the similarities of 
barres and position indicators.  Both are indicators for overall 
placement of the hand along the neck.  Both typically use Roman 
numerals.  Both occupy the same visual space above the staff, and hence 
both are read by the eye like the different words in the same sentence 
about "Where do I put my hand?".  The more detailed question of "Where 
do I put my fingers?" is handled as a separate issue using Arabic 
numerals within the staff.


The system is easily described, as in this footnote to the reader:

    Roman numerals above the staff indicate hand positions on the 
fretboard and remain in effect until the
    next such indication.  A barre is indicated by prefixing the Roman 
numeral with a small “b_” for a small

    barre or a large “B_” for a large barre at that position.

Admittedly, this system alone isn't going to express all the nuances in 
your inner barre examples, but my arrangements are for intermediate 
guitarists, and they seem to catch on to it quickly (and most, like me, 
can scarcely do an inner barre).


Implementation in lilypond is trivial, by including definitions like these:

% guitar neck position indicators
pI    = ^\markup { "I" }
pII   = ^\markup { "II" }
pIII  = ^\markup { "III" }
pIV   = ^\markup { "IV" }

% large barre
BpI    = ^\markup { "B_I" }
BpII   = ^\markup { "B_II" }
BpIII  = ^\markup { "B_III" }
BpIV   = ^\markup { "B_IV" }

% small barre
bpI    = ^\markup { "b_I" }
bpII   = ^\markup { "b_II" }
bpIII  = ^\markup { "b_III" }
bpIV   = ^\markup { "b_IV" }

The resulting code is very compact and stands out nicely in 
Frescobaldi's color highlighting, as shown in the attached image 
alt-barre-frescobaldi.png.


The output appearance from this same example is shown in the attached 
alt-barre-appearance.png.  This is from a lengthy arrangement for two 
guitars I published five years ago, which is why it was intentionally 
crowded to reduce the page count.  In some of the cases shown, I had to 
cheat on the placement of the position indicators, e.g. in m44.


I'm hoping that whatever solution you create will play well with other 
grobs in crowded situations.  As you mentioned two weeks ago, "Notation 
of classical guitar is one of the most complex ones". There's already a 
lot of other important visual clutter, even in the simple example I've 
attached (e.g. slurs and beams on the same notes under the barre).  
Reminds me of Alice's Restaurant 
 "... with circles 
and arrows and a paragraph on the back ... explaining what each one was 
...".  We just don't want our creations "... to be used as evidence 
against us".  :-)


Jeff

Re: is "pure positioning" done per score or per bookpart?

[Jeff Olson]

On 6/16/2022 3:01 PM, Jean Abou Samra wrote:



Le 16/06/2022 à 01:35, Jeff Olson a écrit :

Jean,

I'm studying your "Overview of LilyPond’s inner workings" 
(https://extending-lilypond.readthedocs.io/en/latest/intro.html#overview-of-lilypond-s-inner-workings-and-how-you-might-hook-in-them) 
and trying to correlate the processing steps you describe with the 
INFO level output that I can see in the log.


Knowing my piece, I can discern in the log what's done e.g. for every 
score from things that are done for each bookpart:


   per compile:   "Parsing..."
   per score: "Interpreting music...[8][16][24][32][40][48]"
   per score: "Preprocessing graphical objects..."
   per bookpart:  "Finding the ideal number of pages..."
   per bookpart:  "Fitting music on 39 or 40 pages..."
   per bookpart:  "Drawing systems..."
   per compile:   "Converting to .pdf"

But what is not self-evident is whether the stage you label as "Pure 
Positioning" is done per score in "Preprocessing graphical 
objects..." or per bookpart in "Finding the ideal number of pages...".


Since pure positioning is done a priori, before breaks are decided, 
it could be per score.  But the word "ideal" in the log might 
alternatively match with "pure".


This off-by-one ambiguity cascades through the subsequent stages and 
their correlation with log messages, but surprisingly both 
possibilities arguably line up with the log.


I guess I could equivalently ask whether the stage "Writing Output" 
is done for each bookpart or once for the whole compilation.


If you're still taking suggestions re 
extending-lilypond.readthedocs.io, it might help others if each of 
the processing stages listed in the Overview explicitly said how they 
appear in the log, since those phrases are often familiar even to 
Frescobaldi users.




Good question! It happens mostly in the "Preprocessing graphical
objects..." step. The truth, however, is that this "phase" is a
simplified view, which I gave to make the whole thing a little
more approachable. Unlike, for example, conversion from PS to PDF,
there isn't really a point of the compilation where LilyPond
thinks "OK, at this stage the next thing I need to do is pure
positioning". All properties in the backend use a lazy model,
which is explained in more detail in the "Backend programming"
part of extending-lilypond.readthedocs.io. Basically, grobs
contain specifications of how to compute their properties, whether
pure or not, and when something somewhere needs a property,
the computation is triggered. The flow is:

- Parsing,

- Interpreting,

- "Preprocessing graphical objects": at this point, the game
  is to find out horizontal spacing. This requires knowing a bit
  about the height of some grobs, like stems, so you know what
  distance there must be between two notes to avoid any collision.
  This is where LilyPond uses a lot of pure estimations, since
  exact info is in many cases not available at that point (a stem
  might be part of a beam, which will not be able to determine
  its slope before it knows the distance between its endpoints,
  which needs horizontal spacing, and you're precisely trying
  to determine horizontal spacing). Similarly, it figures out
  the approximate (pure) height of various parts of the score
  so that the page breaking algorithm can know how many systems
  it is good to put on a page.

  As you can see, this is the phase where pure info is really
  useful. Nothing prevents from using it elsewhere, though.
  This is actually done a little bit in "Drawing systems" too.

- Then you have "Finding the ideal number of pages" and "Fitting
  music on x pages", corresponding to page breaking and line breaking.

- "Drawing systems" is the real ("unpure") positioning and final
  computation of all stencils and offsets.

- "Converting to file.pdf" is the conversion from PS to PDF
  by GhostScript.

I'll try to clarify that, and it's a good idea to include the
log messages. Thanks for your feedback.

Cheers,
Jean

PS:

I guess I could equivalently ask whether the stage "Writing Output" 
is done for each bookpart or once for the whole compilation.



"Writing output" is a very simple stage: take the PS file, convert
it to PDF format. It's just a format conversion, so it happens
per book. Several \book blocks lead to several output PDF files
and consequently trigger this several times. It's just happening
once per output .pdf.


Thanks as always for your detailed explanations, Jean.

My interest stems from trying to understand memory usage at various 
stages and whether there's anything I can do to conserve memory, like 
perhaps inserting my own \breaks, but that's a whole 'nother thread.


Jeff

is "pure positioning" done per score or per bookpart?

[Jeff Olson]

Jean,

I'm studying your "Overview of LilyPond’s inner workings" 
(https://extending-lilypond.readthedocs.io/en/latest/intro.html#overview-of-lilypond-s-inner-workings-and-how-you-might-hook-in-them) 
and trying to correlate the processing steps you describe with the INFO 
level output that I can see in the log.


Knowing my piece, I can discern in the log what's done e.g. for every 
score from things that are done for each bookpart:


   per compile:   "Parsing..."
   per score: "Interpreting music...[8][16][24][32][40][48]"
   per score: "Preprocessing graphical objects..."
   per bookpart:  "Finding the ideal number of pages..."
   per bookpart:  "Fitting music on 39 or 40 pages..."
   per bookpart:  "Drawing systems..."
   per compile:   "Converting to .pdf"

But what is not self-evident is whether the stage you label as "Pure 
Positioning" is done per score in "Preprocessing graphical objects..." 
or per bookpart in "Finding the ideal number of pages...".


Since pure positioning is done a priori, before breaks are decided, it 
could be per score.  But the word "ideal" in the log might alternatively 
match with "pure".


This off-by-one ambiguity cascades through the subsequent stages and 
their correlation with log messages, but surprisingly both possibilities 
arguably line up with the log.


I guess I could equivalently ask whether the stage "Writing Output" is 
done for each bookpart or once for the whole compilation.


If you're still taking suggestions re extending-lilypond.readthedocs.io, 
it might help others if each of the processing stages listed in the 
Overview explicitly said how they appear in the log, since those phrases 
are often familiar even to Frescobaldi users.


Thanks,
Jeff

Re: phrase marks ending on tied notes: first vs last?

[Jeff Olson]

On 5/4/2022 5:58 PM, Brian Barker wrote:

At 17:30 04/05/2022 -0600, Jeff Olson wrote:

What would Elaine Gould do?


"When a final pitch is extended by a series of tied notes, it is 
acceptable (and a convention) to end the slur with the first whole-bar 
duration; alternatively, in cramped conditions, with the first tied note.


So she would accept both examples in your first staff, as well as the 
first example in your second staff - but the second example your 
second staff only "in cramped conditions". 


Thanks, Brian!  I shall continue to follow The Goulden Rule, now that I 
know what it is.


Jeff

phrase marks ending on tied notes: first vs last?

[Jeff Olson]

Just curious whether other users have wrestled with this choice or have 
strong preferences.


At the recommendation of my reviewer, I'm adding phrase marks \(...\) to 
hundreds of simple sight reading exercises, to make them more readable.  
While doing so, I caught myself sometimes ending the phrase on the first 
note of a tied pair, and at other times going all the way to the last 
note of the tie.  My reviewer had no preference, but in the interest of 
uniformity I went back and started doing them all the same way (phrasing 
to the last of the tied notes).  But I didn't always like the results.


The attached example (MWE-phrasing-to-ties.png) shows excerpts from two 
cases where my eye preferred doing it differently (first staff).  The 
second staff shows the opposite in each case, which I don't prefer.  
(The excerpts are from Olcott: My Wild Irish Rose and Waldteufel: España 
Waltz, but the originals are generally unhelpful re phrase marks: I'm 
making exercises, not urtexts, after all).


Perhaps my issue is the visual interference between the phrase curve and 
the tie curve when they're both on top.  It just looks more busy, more 
complicated in such cases. I know I can force them to avoid each other 
(one up, one down, or more space), but I'd like to use the same simple 
source again in another octave, where the collisions could be 
different.  And I've got hundreds to do, so it has to be easy.


I can imagine that the target instrument might influence this choice.  A 
guitarist might prefer ending on the first, since they have little 
influence after the note is played; while a clarinetist or vocalist 
might prefer ending on the last, since they can't breathe until it's 
done.  My work is currently for guitar, and there are no lyrics involved.


So do people have rigid rules on phrasing, or just play it by ear?  What 
would Elaine Gould do?


Discussion is invited.

Jeff

\version "2.22.1"

\transpose c c' {
  \time 3/4
  e'2.\( | %1
  e'2 d'4 | %2
  c'2.~\) | %3
  c'2 r4 | %4
  \bar "||"
  c4\( e g | %5
  b8 r \tuplet 3/2 { a8 b a } g4~ | %6
  g4\) r %7
  \bar "|."
}

\transpose c c' {
  \time 3/4
  e'2.\( | %1
  e'2 d'4 | %2
  c'2.~ | %3
  c'2\) r4 | %4
  \bar "||"
  c4\( e g | %5
  b8 r \tuplet 3/2 { a8 b a } g4~\) | %6
  g4 r %17
  \bar "|."
}

Re: how to repeat a scheme function that creates a Score

[Jeff Olson]

On 4/6/2022 12:35 AM, Jean Abou Samra wrote:
The attached MWE file has lots of my failed attempts commented out 
(I'm at a teachable moment if someone has a moment to teach).  Or 
just point me to the right manual page(s).



Here is a piece of code that works:


$@(map (lambda (i) (scr)) (iota 10))


Now let's go through your attempt to see why they are failing. 


This is an amazing user group! Thank you times three to Aaron, Valentin 
and Jean for your immediate and expert responses!


And special thanks to you, Jean, for giving me a full course explaining 
why all my previous attempts had failed.  That was a very valuable 
learning experience!


The code I'm using now is:


% scors generates a specified number of scores
% e.g. invoke $@(scors 10) from lilypond to generate ten scores
#(define (scors num) (map (lambda (i) (scr)) (iota num)))


This works nicely as I can make a series of invocations in different 
bookparts (simulating separate chapters) while preserving the overall 
sequence of piece numbers.


I'd like you to check my learning on "$@" ...

Per the ER section 1.2.1, "There are also ‘list splicing’ operators |$@| 
and |#@| that insert all elements of a list in the surrounding context."


So it's not part of scheme but part of lilypond, as a bridge between 
scheme and lilypond.


And that it tells lilypond to preserve all the elements of scheme list 
value as a sequence of expressions/values to be parsed/interpreted by 
lilypond, as opposed to getting just the value of the last element of 
the list.


And so it is analogous (at least mnemonically) to the meaning of "$%" in 
bash (if I remember correctly), which preserves a sequence of command 
line arguments as separate values rather than combining them as one 
argument.


But may I ask, why are "$@" and "#@" called 'list splicing' operators?  
The same terminology is used in Perl for what appears to me to be very 
different behaviors (list editing, insertion and removal), so I'd 
appreciate learning why 'splicing' is considered descriptive in lilypond.


Jeff

Re: how to repeat a scheme function that creates a Score

[Jeff Olson]

On 4/5/2022 11:58 PM, Aaron Hill wrote:

On 2022-04-05 10:40 pm, Jeff Olson wrote:

Question (b):

My secondary question is very simple.  How do you set the seed for
scheme's "random" function (used in my gen-music.ily).  I'd like to
get the repeatability of a pseudo-random number generator.



(set! *random-state* (seed->random-state 42))


Review the Guile documentation [1]:

[1]: 
https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Random.html#Random



-- Aaron Hill


Thanks, Aaron, for answering the ultimate question [2].

[2] https://en.wikipedia.org/wiki/42_(number)

Jeff

how to repeat a scheme function that creates a Score

[Jeff Olson]

Two questions below re: (a) looping and (b) random seed.


In order to investigate some other problems I'm having in a large 
project (pagination, memory usage) I learned enough scheme (barely) to 
define a function that generates a new score with each invocation:


--

\version "2.22.0"

\include "gen-music.ily"

% each invocation of scr generates a new score of different length
pcn = 0
scr = #(define-scheme-function () ()
   (set! pcn (1+ pcn))
   #{
 \score {
   \header { piece = \markup{ "Piece " #(number->string pcn) } }
   { \gen-music \bar "|."} }
   #} )

--

(The include file, gen-music.ily, is attached, and the above ~MWE is 
also attached as MWE-do-scr.ly.)


Question (a):

My main question is how to write a scheme function that will invoke my 
scr function N times, where N could be a number like 1000.


So far the only way I know how to do multiple invocations is by 
explicitly hard-coding "\scr \scr ..." in blocks and copy/pasting those 
blocks.


Looking for a better way, I realized I don't even know how to get one 
line of scheme to do 2 invocations (needed for tail recursion 
approach).  I can make them execute, in some cases, but not to produce 
pdf output (never gets to "Interpreting music...").  Part of this may be 
#(scr) vs $(scr).  The attached MWE file has lots of my failed attempts 
commented out (I'm at a teachable moment if someone has a moment to 
teach).  Or just point me to the right manual page(s).


Question (b):

My secondary question is very simple.  How do you set the seed for 
scheme's "random" function (used in my gen-music.ily).  I'd like to get 
the repeatability of a pseudo-random number generator.


TIA,
Jeff

P.S. May you smile when you see the generated music.
\version "2.22.0"

\include "gen-music.ily"

% each invocation of scr generates a new score of different length
pcn = 0
scr = #(define-scheme-function () ()
   (set! pcn (1+ pcn))
   #{
 \score { 
   \header { piece = \markup{ "Piece " #(number->string pcn) } } 
   { \gen-music \bar "|."} }
   #} )

% only way I know to repeat so far
\scr \scr \scr \scr \scr \scr \scr \scr \scr \scr % 10
%\scr \scr \scr \scr \scr \scr \scr \scr \scr \scr % 20

%#(scr)  % runs but generates no output
%$(scr)  % works for one invocation


% guessing at recursive repeat
%#(define scors (lambda (n) (if (= n 1) (scr) ((scr) (scors (- n 1) )
%#(scors 2)

% guessing at for-each repeat
%#(for-each (lambda (ignore) (scr)) '(1 2 3 4 5))

% never does "Interpreting music..." (no output)
%#(begin (scr) (scr) (scr))

% does "Interpreting music...[8]" but only outputs "Piece 3"
%$(begin (scr) (scr) (scr))

%#(define mine (list (scr) (scr) (scr)))
%#@mine % error: bad expression type
%#mine   % (no output)
%$(make-sequential-music mine) % Wrong type argument in position 1 (expecting Prob): #
%$mine  % error: bad expression type
%$(mine)% GUILE signaled an error for the expression beginning here
%$(list mine)   % error: bad expression type
\version "2.22.0"

% some sequential music objects (to be concatenated with variation by gen-music 
function)
xa = { g'4. a'8 g'4 f' e' f' g'2 d'4 e' f'2 e'4 f' g'2 g' a'4 g'8 f' e'4 f' g'2 
}
xb = { d'4 e' f'4 e' f' g'8 f' e'4 f'8 g' a'4 c'' e''4 d''8 c'' b'4 cis'' d''2 }
xc = { a'4 b' c''4 b' c'' d''8 c'' b'4 c''8 d'' e''2~ e''4 d''8 c'' b'4 cis'' 
d''2 }
xd = { a'4 b' c''4 b' c'' d''8 c'' b'4 g'8 f' e'4 d' cis'4 a'8 g' a'4 cis'' 
d''2 }
xe = { d''4 c'' b'4 g'8 f' g'4 b' c''4 d'' e''2 d''4 c''8 b' a'4 b' c''2 }
xf = { g'4 a' bes'4 a' bes' c''8 bes' a'2 b' c''4 b' c'' d''8 c'' b'4 a' bes'2 
a'4 g'8 f' e'4 fis' g'2 }
xg = { d'4 e' f'4 e' f' g'8 f' e'4 c''8 b' a'4 g' fis'4 d''8 c'' d''4 fis' g'2 }
xh = { g'4 f' e'4 c''8 bes' c''4 e' f'4 a'8 g' f'4 e' d'2 g' e'4 c' }

% list of sequential music objects
smolist = #(list xa xb xc xd xe xf xg xh)

% to get a scheme list of music elements from a music object
#(define (get-elements mus) (ly:music-property mus 'elements))

% list of element-lists
elists = #(map get-elements smolist)
enum = #(length elists)

% recursively concatenate a range of elists (0 <= m <= n, possibly > enum)
#(define (cat-elists m n)
   (let ((elist-m (list-ref elists (modulo m enum
 (if (< m n) (append elist-m (cat-elists (1+ m) n)) elist-m )))

% generate music by concatenating contiguous members from list.
% i mod enum is the starting position in the list for the next gen-music.
% mincat is the minimum number of concatenations (mincat >= 0)
% maxcat is the max number of concatenations (maxcat >= mincat)
% actual number of cats is random between mincat and maxcat.
i = 0
mincat = 0
maxcat = 9
gen-music = #(define-music-function () ()
  (let* ((m i) (n (+ m (+ mincat (random (1+ (- maxcat mincat)))
(set! i (1+ n))
(make-sequential-music (cat-elists m n

Re: Ambitus_engraver causes ghost laissezVibrer ties on first note of Voice

[Jeff Olson]

On 3/23/2022 5:18 AM, Valentin Petzel wrote:

I have nothing against ghosts, just against this type of ghost.

This is the user mailing list. For requests like "please fix this" you might
also send this to the bug mailing list. If you need a quick fix: Adding an
empty grace column \grace{ s } before the first note will fix this, as will
putting the whole thing into a single note chord . I suppose
that the Ambitus_engraver creates the Ambitus Note Heads in the same timestep
as the first Note Column, which results in them being acknowledged by the
engravers for semi-ties.

Cheers,
Valentin


Thanks, Valentin.  Your quick(!) fixes should be all I need.

Jeff

Ambitus_engraver causes ghost laissezVibrer ties on first note of Voice

[Jeff Olson]

Do you like ghosts?

Putting an LV tie on the first note of a Voice in which there is an 
ambitus generates two unwelcome "ghost" LV ties floating unattached 
above and below the note, in addition to the desired single LV tie that 
is properly attached to the note.  Here is the MWE (see also attached 
image Ambitus-LV-ghosts.png):


\version "2.22.0"
\new Voice \with { \consists "Ambitus_engraver" } {
  a'\laissezVibrer c'' c'
}

In this example, the c'' and c' are necessary to establish a range for 
the ambitus to display that is distinct from the note with the proper LV 
tie.  By experimenting with these notes (or simply by visual inspection 
of the output) you see that the two floating ghost LV ties are at 
vertical positions within the first note column that match the two 
extrema of the ambitus.  They are the same LV ties that would be 
properly expected had the ambitus extrema been included as notes in a 
chard with the first note, like this:


\laissezVibrer

So the vertical position of the ghosts is determined by the ambitus even 
though their horizontal position is in the first note column.


This behavior exists at least in 2.22.1 and 2.18.2.  Log files are clean.

The ghosts disappear when the LV tie is not on the first note (e.g. just 
add initial g'):


\new Voice \with { \consists "Ambitus_engraver" } {
  g' a'\laissezVibrer c'' c'
}

The ghosts also disappear if the ambitus belongs to the Staff context 
(just change Voice to Staff):


\new Staff \with { \consists "Ambitus_engraver" } {
  a'\laissezVibrer c'' c'
}

I don't like ghosts.  Please fix.

Jeff

Re: how to reference paper variables in a music function

[Jeff Olson]

Thanks, David, for your prompt reply. Unfortunately I do not have the 
ability to alter the source in any way (including commenting out lines) 
once the source has been submitted to Mutopia.  Their process is to 
specify the paper size on the lilypond command line; any code like those 
set-paper-size commands that would interfere has to be commented out.  I 
think Harm's solution would help lots of frustrated Mutopia people who 
tear their hair out over trying to make the exact same source file 
generate satisfactory output on two different paper sizes.


Thx again,
Jeff



On 11/29/2018 9:26 AM, David Wright wrote:

On Wed 28 Nov 2018 at 23:12:20 (-0700), Jeff Olson wrote:

I have a complex Mutopia submission that requires different formatting
for A4 and Letter sized paper (it's too tight on the page to trust
lilypond's spacing algorithms on the same source without paper
specific tweaks).

So I'd like to define a music function (see "ifLetter" below) that can
sense the paper choice and select either of two music definitions
accordingly.

In the demo below, I'd like to switch output between music-one (one
system) and music-two (two systems) depending upon which paper size is
set.  But I'm just guessing about how to reference the documented
variable "paper-width" to compare to the value 8.5\in.  In the attempt
below, the condition always evaluates to ##f and produces two systems
on letter size paper (I want music-one for letter paper).

I'd prefer testing a variable whose value was "letter" (rather than
8.5 inches) but I couldn't find such a variable documented
(paper-size?, default-paper-size?).

I've seen ly:output-def-lookup, but that requires a props or layout
that is not obvious how to access within a music function.

The code below produces the expected results when the condition (eqv?
'paper:paper-width (* 8.5 25.4))is rewritten as(eqv? 1 1) or (eqv? 1
2).

BTW, documented spacing examples suggest that the construct (* 8.5 in)
should be effective in scheme, but I get a compile error indicating
that "in" is unbound, so I've written in 25.4 as a literal.

BTW2, I've similarly been unable to access the paper variable
page-count within a music function.
\paper{
   page-count = #1
   %#(set-paper-size "a4")  %uncomment to test specific paper size
   #(set-paper-size "letter")  %uncomment to test specific paper size
}
ifLetter =
#(define-music-function (parser location musL musE) (ly:music? ly:music?)
    (if (eqv? 'paper:paper-width (* 8.5 25.4)) musL musE )
    )

\score { \ifLetter \music-one \music-two }

You're editing one % character to switch between paper sizes, so why not:

% ifLetter =  \paper { #(set-paper-size "a4") } % 
uncomment for A4
  ifLetter =  \paper { #(set-paper-size "letter") } % 
uncomment for Letter

Cheers,
David.


--
  
  o_ Jeff Olson

 (\___\/_/)   jjocanoe
~ ~ ~ / ~ ~ ~ ~  @gmail.com

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

how to reference paper variables in a music function

[Jeff Olson]

I have a complex Mutopia submission that requires different formatting 
for A4 and Letter sized paper (it's too tight on the page to trust 
lilypond's spacing algorithms on the same source without paper specific 
tweaks).


So I'd like to define a music function (see "ifLetter" below) that can 
sense the paper choice and select either of two music definitions 
accordingly.


In the demo below, I'd like to switch output between music-one (one 
system) and music-two (two systems) depending upon which paper size is 
set.  But I'm just guessing about how to reference the documented 
variable "paper-width" to compare to the value 8.5\in.  In the attempt 
below, the condition always evaluates to ##f and produces two systems on 
letter size paper (I want music-one for letter paper).


I'd prefer testing a variable whose value was "letter" (rather than 8.5 
inches) but I couldn't find such a variable documented (paper-size?, 
default-paper-size?).


I've seen ly:output-def-lookup, but that requires a props or layout that 
is not obvious how to access within a music function.


The code below produces the expected results when the condition (eqv? 
'paper:paper-width (* 8.5 25.4))is rewritten as(eqv? 1 1) or (eqv? 1 2).


BTW, documented spacing examples suggest that the construct (* 8.5 in) 
should be effective in scheme, but I get a compile error indicating that 
"in" is unbound, so I've written in 25.4 as a literal.


BTW2, I've similarly been unable to access the paper variable page-count 
within a music function.


Thx,
Jeff
--
\version "2.18.2"

\paper{
  page-count = #1
  %#(set-paper-size "a4")  %uncomment to test specific paper size
  #(set-paper-size "letter")  %uncomment to test specific paper size
}

music-one = { a b c d e f g }
music-two = { a b c d \break e f g }

ifLetter =
#(define-music-function (parser location musL musE) (ly:music? ly:music?)
   (if (eqv? 'paper:paper-width (* 8.5 25.4)) musL musE )
   )

\score { \ifLetter \music-one \music-two }

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Choice of pitch input mode

[Jeff Olson]

On 4/29/2016 4:56 PM, Jeff Olson wrote:

< 41312

41340


Okay, now I know what you mean by the > problem and I've modified my
ways and the script (to insert a couple of leading blanks) to show e.g.

  < 41312
  > 41340

HTH,
Jeff
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Choice of pitch input mode

[Jeff Olson]

On 4/29/2016 5:58 AM, Matt Hood wrote:

What does everyone prefer? Relative, absolute, or a mix of both?


Summary: For my work, a perl script confimed my choice of absolute
 mode in conjunction with judicious use of \transpose,
 but for other people it suggests relative is better.

Details:
I started with relative, to conserve line width and minimize input effort,
but soon realized that was a premature optimization.

In my transcriptions of Beethoven and Bach for guitar duos, most of the
input effort and line width is attributable to chords, fingerings, string
indications and other annotations.

And for the limited range of a guitar (3.5 octaves) I can \transpose c c'
to minimize the number of octave marks in absolute mode (so range is e, to b'').
Thus I never encounter long high runs of 32nds above c'''.

I also found that, for the limited range of the guitar, it was easier to think
in absolute (you're always aware of your octave on a guitar) than in relative
(especially in the frequent case where a pitch and its octave are in the same
chord or arpeggio, yet with identical pitch symbols).  Doing global replacements
in vi is also a bit easier in absolute than in relative.

To satisfy my curiousity about the "relative frequency" of octave marks,
both between files in relative vs files in absolute mode, and compared to
other annotations that seem to overwhelm octave marks, I wrote a little
perl script (included below) to count selected characters in ly files.

The script confirmed my intial impression that (a) octave marks are a trivial
contributor to line width (in my work) but also suprised me that (b) using
absolute mode on average only added one more octave mark per measure than
using relative mode (probably because I used \transpose to simplify input).

For fun, here are some specific test runs.

The first example is from when I used only relative mode.  FYI, I habitually
use measure marks (|) and try for one measure per line.  I also use lots
of abbreviations to shorten things where I can (see large number of "=" signs).

The results below for relative mode show only about 1 octave mark per measure
for a typical piece of about 6 pages:

$ ly-chars mypubs/pathetique-2-guitar-duo-2064/pathetique-2-guitar-duo.ly
In a file of 214 measure marks, 710 lines, 26458 characters and 3 \relatives ...
octave marks (,') are 1.0 per measure mark, 0.3 per line, 0.8 percent of file.

Here's a count of selected characters (X represents all others):
' 68
) 78
( 78
^ 121
# 124
_ 138
, 142
= 156
{ 204
} 204
| 214
[ 215
] 216
% 256
\ 735
< 940

940

- 998
X 20631
$


The second example is from recent one-page piece in absolute mode.
The surprise here is that there are only about 2 octave marks per measure.
While that's twice as many as for relative, it's still only one extra character
per measure:

$ ly-chars mypubs/lagrima-duo-2103/lagrima-duo.ly
In a file of 55 measure marks, 338 lines, 10634 characters and 0 \relatives ...
octave marks (,') are 2.1 per measure mark, 0.3 per line, 1.1 percent of file.

Here's a count of selected characters (X represents all others):
, 32
[ 33
] 33
_ 35
) 49
( 49
| 55
^ 63
' 85
# 86
% 89
{ 123
} 123
< 130

130

= 156
- 176
\ 351
X 8836
$

So that's just for my work.  To see an average over other people's work,
here are analogous runs over all the 455 Beethoven files in mutopia, first
on the ones that use relative (at least once) and then those that don't.

$ cd /f/MutopiaProject/ftp/BeethovenLv
$ ly-chars `find -type f -name '*.ly' -exec grep -q relative '{}' \; -print `
In 99 files of 11756 measure marks, 28834 lines, 752704 characters and 158 
\relatives ...
octave marks (,') are 1.6 per measure mark, 0.7 per line, 2.6 percent of file.

Here's a count of selected characters (X represents all others):
^ 841
= 1296
_ 1863
# 2374
{ 3327
} 3327
[ 4839
] 4842
) 8804
( 8805
% 8853
' 9625
, 9675
| 11756

11848

< 11890
- 14235
\ 18339
X 616165
$
$ ly-chars `find -type f -name '*.ly' ! -exec grep -q relative '{}' \; -print `
In 356 files of 1350 measure marks, 33854 lines, 2139195 characters and 0 
\relatives ...
octave marks (,') are 205.5 per measure mark, 8.2 per line, 13.0 percent of 
file.

Here's a count of selected characters (X represents all others):
| 1350
% 2059
^ 2288
_ 2703
# 3533
- 4021
= 4519
{ 12864
} 12864
[ 15002
] 15033
) 16376
( 16406
, 25594
< 41312

41340

\ 69817
' 251807
X 1600307


Contrary to my personal experience, the above results show a 5 fold increase
in octave marks for absolute files (13.0 percent) vs relative (2.6 percent).
The authors using absolute are also much less likely to use measure marks
so ignore that number.  And who knows about one measure per line.

Perhaps the huge number of octave marks in the absolute files could be
reduced by judicious local use of \transpose.

Since I've already taken up so much space, I may as well include perl script:
$ cat ly-chars.pl
   $relatives = 0;
   $files = @ARGV;
   while (<>) {
  #/\|/ or