Re: Different default arpeggio positions

[Jean Abou Samra]

Le 01/12/2022 à 07:08, Abraham Lee a écrit :

Happy Holidays!

A number of versions ago, I created the following function to extend 
the top and bottom ends of the Arpeggio grob, which I find more 
aesthetically pleasing (generally), though I know it's not perfect:


\override Arpeggio.after-line-breaking =
 #(lambda (grob)
    (let* ((pos (ly:grob-property grob 'positions))
           (p1 (car pos))
           (p2 (cdr pos))
           (btm (- p1 1.0))
           (top (+ p2 0.5))
           )
      (ly:grob-set-property! grob 'positions (cons btm top))
    ))

It used to work perfectly (that I can remember), but now using either 
after-line-breaking or before-line-breaking, I can't get it to work 
correctly, especially when I need to use


\set PianoStaff.connectArpeggios = ##t.

Any thoughts as to why it no longer works and/or what I should be 
doing differently? Ideally, I'd like to use different values depending 
on if the associated note is in a space (like 1.0 space) or on a staff 
line (like 0.5 space), but I'd be happy with a single solution to 
start with like I have above.


Here's a small snippet showing the current default arpeggio in both 
single staff usage and cross-staff usage, another with my function 
used with before-line-breaking, and then finally the same function but 
with after-line-breaking. It almost works with before-line-breaking, 
but not the cross-staff one.





Hi Abraham,

This is a widespread but bad coding pattern that I regularly advise
against on this list :-)

It seems that when people notice they can set grob properties
in after-line-breaking, they start using after-line-breaking
for anything and everything, while that is not its purpose.

The problem here is that after-line-breaking is run *just* after
line breaking. It happens before LilyPond has done page spacing,
i.e., layout out systems and staves vertically. For a cross-staff
arpeggio, the positions depend on the distance between the
two staves, so you are requesting 'positions earlier than LilyPond
can provide it to you.

In general, cross-staff objects are treated specially. For
a normal arpeggio, LilyPond will request the arpeggio's
stencil, to build the staff's skylines, and stencil will
read positions. For a cross-staff arpeggio, which LilyPond
recognizes by its cross-staff property set to #t, LilyPond
refrains from reading the stencil before page layout is done,
knowing that it needs to depend on page layout.

The proper solution is to stop assuming that positions is
available at a specific point, and instead write a callback
that computes it as soon as it is asked for:

\version "2.23.82"

\score {
  <<
    \new PianoStaff <<
  \new Staff = "pianoRH" \pianoRH
  \new Staff = "pianoLH" \pianoLH
    >>
  >>
  \layout {
    #(use-modules (ice-9 match))
    \context {
  \Score
  \override Arpeggio.positions =
    #(grob-transformer
  'positions
  (lambda (grob original)
    (match original
  ((a . b) (cons (- a 0.5) (+ b 1.0)))
  (x x
    }
  }
}



Best,
Jean




OpenPGP_signature
Description: OpenPGP digital signature

Re: Different default arpeggio positions

[Mark Knoop]

At 23:08 on 30 Nov 2022, Abraham Lee wrote:
> Happy Holidays!

> A number of versions ago, I created the following function to extend
> the top and bottom ends of the Arpeggio grob, which I find more
> aesthetically pleasing (generally), though I know it's not perfect:

Can you not just use \offset?

https://lilypond.org/doc/v2.23/Documentation/notation/the-offset-command

--
Mark Knoop

Re: Different default arpeggio positions

[Thomas Morley]

Hi Jean,

Am Do., 1. Dez. 2022 um 09:48 Uhr schrieb Jean Abou Samra :

> This is a widespread but bad coding pattern that I regularly advise
> against on this list :-)

you'll find a plethora of snippets in the archives using
after-line-breaking authored by me.
Likely starting in 2.12.3.

> It seems that when people notice they can set grob properties
> in after-line-breaking, they start using after-line-breaking
> for anything and everything, while that is not its purpose.

Well, the purpose of after-line-breaking was not well documented back
those days.
And in 2.23. IR still reads:
"Dummy property, used to trigger callback for after-line-breaking."
This is a collection of words making little sense, at least without
further explanations.

> The problem here is that after-line-breaking is run *just* after
> line breaking. It happens before LilyPond has done page spacing,
> i.e., layout out systems and staves vertically.

This is not documented afaik.

> For a cross-staff
> arpeggio, the positions depend on the distance between the
> two staves, so you are requesting 'positions earlier than LilyPond
> can provide it to you.
>
> In general, cross-staff objects are treated specially. For
> a normal arpeggio, LilyPond will request the arpeggio's
> stencil, to build the staff's skylines, and stencil will
> read positions. For a cross-staff arpeggio, which LilyPond
> recognizes by its cross-staff property set to #t, LilyPond
> refrains from reading the stencil before page layout is done,
> knowing that it needs to depend on page layout.
>
> The proper solution is to stop assuming that positions is
> available at a specific point, and instead write a callback
> that computes it as soon as it is asked for:
>
> \version "2.23.82"
>
> \score {
><<
>  \new PianoStaff <<
>\new Staff = "pianoRH" \pianoRH
>\new Staff = "pianoLH" \pianoLH
>  >>
>>>
>\layout {
>  #(use-modules (ice-9 match))
>  \context {
>\Score
>\override Arpeggio.positions =

Furthermore, grob-transformer is not very old
In older versions one had to code far more complex
or
use after-line-breaking - with its limitations.

>  #(grob-transformer
>'positions
>(lambda (grob original)
>  (match original
>((a . b) (cons (- a 0.5) (+ b 1.0)))
>(x x
>  }
>}
> }
>
>
>
> Best,
> Jean
>
>

Ofcourse you're right advertising  not to use after-line-breaking for
all and everything.
Though, I do understand why it's still in use.

Just my 2 cents,
  Harm

Re: Different default arpeggio positions

[Jean Abou Samra]

Le 01/12/2022 à 10:09, Thomas Morley a écrit :

Ofcourse you're right advertising  not to use after-line-breaking for
all and everything.
Though, I do understand why it's still in use.




Yes, sure. My point was to advise against it, not to rebuke people who
have used / are using it.

Indeed, before we had grob-transformer, it was more necessary than
it is today.

Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Spacing between stanzas

[revneu]

Hi all:

I used 

\addlyrics {

\override VerticalAxisGroup.nonstaff-nonstaff-spacing.basic-distance = #4
and achieved the effect I wanted. But only for the last line of music. The
other lines were unaffected.

 

Is there a way I can get the spacing for each line of music?

 

Re: Different default arpeggio positions

[Abraham Lee]

On Thu, Dec 1, 2022 at 2:13 AM Jean Abou Samra  wrote:

> Le 01/12/2022 à 10:09, Thomas Morley a écrit :
> > Ofcourse you're right advertising  not to use after-line-breaking for
> > all and everything.
> > Though, I do understand why it's still in use.
>
>
>
> Yes, sure. My point was to advise against it, not to rebuke people who
> have used / are using it.
>
> Indeed, before we had grob-transformer, it was more necessary than
> it is today.
>
> Best,
> Jean


Thank you, again, Jean. I appreciate the feedback and will test out your
code when I have a chance tonight.

Best,
Abraham

>

Re: Adding text to chord names or note names (replies to discussion)

[kbvw]

Hello Jean, Elaine,

> Amusingly, I found this post from 2001: 
> https://lists.gnu.org/archive/html/gnu-music-discuss/2001-03/msg00327.html
>
> (The thread continues here: 
> https://lists.gnu.org/archive/html/gnu-music-discuss/2001-04/msg0.html)

​
Ha, that's funny indeed. I'd say I completely agree with him there on the topic 
of the chords (leaving the strongly-worded statements about development aside).

His analogy with TeX and mathematics is a nice one I think: although a proof is 
a proof of course, the way we think about math/notation evolves, and we don't 
need TeX to reason about it: we just use it to write it down. And then music 
theory is a lot less "stable" by comparison: it changes all the time, even the 
"classical" bit.

(It was also suggested later in that thread to use lyrics mode: makes sense 
actually, except for the transposition functionality. I would probably use 
lyrics mode for Roman numerals or anything relative.)

Regarding the different use cases of input modes, chord symbols, etc., I guess 
one would have to disentangle two underlying concepts commonly addressed by the 
word "chord", like Elaine mentioned as well. One would be a collection of 
simultaneous (concrete/instantiated) pitches; let's call it a "voicing". The 
other would be a sort of specified "harmonic background" (I would say "context" 
but this might be confused with a LilyPond context), somewhat more related to 
(abstract) pitch classes. Either for analysis or as a specification of what to 
play.

In the former view, it makes total sense to have the pitches internally, and I 
can see many use cases, for automatic analysis, easier input of voicings, etc. 
In the latter view, if the harmonic background is something that you are 
specifying and reasoning from (as it often is in improvised music), and if 
that's what you want on the page, a calculating layer seems more redundant. 
Maybe it doesn't get in the way now or you can solve it, but it might get in 
the way with something new you come up with tomorrow?

@Jean:
Thanks for the alternative function for "enharmonicizing" the chords.

@Elaine:
I found it quite interesting reading your replies, as it seems to me that we 
agree on almost all of the premises: "we only need to transpose root and slash 
bass", "chords are often enharmonically ambiguous and one could argue for a 
sharp or a flat", "theoretical concepts are of lesser importance when 
specifying a chord to an improviser, and simple spellings are easier to read". 
Yet, we seem to reason from there in opposite directions somehow.

> If your only issue is "specifying the pitches every time" then it seems that 
> you are not aware of the chord input syntax, and are instead using pitches.
>
> Perhaps you should invest in learning the chordmode syntax?

​
I did learn the chord mode syntax; it's quite intuitive. And I found your list 
of chord exceptions (posted to this list in the past) helpful, so thanks for 
that! I should clarify that the "mode" was just some example, as was the "6-9". 
These things are rather well defined. It was more of an argument of being 
limited unnecessarily.

Silly new example: suppose I'd want to specify to "tonicize F" for a few 
measures by McCoy-Tyner-style smashing it as a pedal and playing very freely 
over it: f^"tyner"? Or I'd want to specify a tonal feeling of D but I'd rather 
say which pitches not to play. I'm not saying I would actually write those 
things, but if the specified harmony "is" the composition, why limit yourself?

Besides that, your example of writing out the modes doesn't solve my initial 
(quite concrete) problem of transposition: if I take your C phrygian and 
transpose to A-flat, I get a bunch of double flats. (I know you could transpose 
to G-sharp in that case, but I have many chords in a piece and instruments in 
several keys: I'd rather just transpose the piece once as a whole.)

The workarounds you present afterwards seem like quite a bit of effort to me. 
Don't get me wrong: whatever works, and I thank you for the carefully 
worked-out suggestions! I'd just rather not find individual solutions for 
individual chords/parts.

All the best,
Koen

Re: Adding text to chord names or note names (solution)

[Koen van Walstijn]

Hello,

(Separately reply follows to some of the specific things that were written.)

In case there is interest, what I did now was tweaking the 
Current_chord_text_engraver from scheme_engravers.scm. It simply takes the 
first pitch specified in a chord as the root, takes the first one with property 
"bass" as the bass, and it additionally listens to text-script-events from 
which it takes the first specified one as the suffix. I use that in a custom 
context called "HarmonicBackground" for lack of something better, same as 
ChordNames but with this engraver instead of the original one. For the input I 
just use relative mode.

An example of how I specify the chord symbols now:

chords = \relative {

^"7"
des^"lyd"

}

\new HarmonicBackground {
\chords}

Code can be found here: 
https://gitlab.com/kbvw/lilypond-tweaks/-/blob/master/harmonic-background.ly

It's probably not foolproof; I'm a novice with both LilyPond and Scheme. 
Currently the text-script is hard-coded to go in the superscript of the chord, 
before the slash separator. Perhaps it would be nicer to look if the 
text-script is entered with ^ or _, and even nicer would be to use shorthands 
in an input mode such as the chord mode, but I didn't look at any of the 
input/parser code yet.

For myself that suffices for now; it looks good to me on the page and it's 
easy/flexible to enter.

If anyone more knowledgeable thinks it's worth continuing with, I'd be happy to 
discuss/help! (I can see several advantages and disadvantages.)

All the best, and thanks for the help,
Koen

Re: Adding text to chord names or note names (solution)

[Jean Abou Samra]

Le 01/12/2022 à 19:04, Koen van Walstijn a écrit :

Hello,

(Separately reply follows to some of the specific things that were 
written.)


In case there is interest, what I did now was tweaking the 
Current_chord_text_engraver from scheme_engravers.scm. It simply takes 
the first pitch specified in a chord as the root, takes the first one 
with property "bass" as the bass, and it additionally listens to 
text-script-events from which it takes the first specified one as the 
suffix. I use that in a custom context called "HarmonicBackground" for 
lack of something better, same as ChordNames but with this engraver 
instead of the original one. For the input I just use relative mode.


An example of how I specify the chord symbols now:

chords = \relative {
   ^"7"
des^"lyd"
}

\new HarmonicBackground {
    \chords
}

Code can be found here: 
https://gitlab.com/kbvw/lilypond-tweaks/-/blob/master/harmonic-background.ly


It's probably not foolproof; I'm a novice with both LilyPond and 
Scheme. Currently the text-script is hard-coded to go in the 
superscript of the chord, before the slash separator. Perhaps it would 
be nicer to look if the text-script is entered with ^ or _, and even 
nicer would be to use shorthands in an input mode such as the chord 
mode, but I didn't look at any of the input/parser code yet.


For myself that suffices for now; it looks good to me on the page and 
it's easy/flexible to enter.


If anyone more knowledgeable thinks it's worth continuing with, I'd be 
happy to discuss/help! (I can see several advantages and disadvantages.)


All the best, and thanks for the help,
Koen




I think that at this point we have largely stepped beyond the scope of 
this mailing list. I suggest that you open an issue at


https://gitlab.com/lilypond/lilypond/-/issues

to suggest the feature (linking to the discussion). Then we can discuss 
the details there.


Best,
Jean



OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding text to chord names or note names (solution)

[Jean Abou Samra]

Le 01/12/2022 à 19:04, Koen van Walstijn a écrit :
Code can be found here: 
https://gitlab.com/kbvw/lilypond-tweaks/-/blob/master/harmonic-background.ly



By the way: if you want to made a piece of code available that you think 
someone might want to reuse for LilyPond, you need to put it under 
GPLv3+, not GPLv3. (I would envision a somewhat different implementation 
anyway, but I figured this may be useful to know.)





OpenPGP_signature
Description: OpenPGP digital signature

Re: Adding text to chord names or note names (solution)

[Koen van Walstijn]

Hi Jean,

Thanks, indeed that's useful to know. (Still learning.) Sorry about that: I'll 
change it to GPLv3+ and open the issue on Gitlab.

Cheers,
Koen

--- Original Message ---
On Thursday, December 1st, 2022 at 8:31 PM, Jean Abou Samra 
 wrote:


> Le 01/12/2022 à 19:04, Koen van Walstijn a écrit :
> 
> > Code can be found here:
> > https://gitlab.com/kbvw/lilypond-tweaks/-/blob/master/harmonic-background.ly
> 
> 
> 
> By the way: if you want to made a piece of code available that you think
> someone might want to reuse for LilyPond, you need to put it under
> GPLv3+, not GPLv3. (I would envision a somewhat different implementation
> anyway, but I figured this may be useful to know.)

lilypond-book -> latex

[Carlos Knauer]

Hi.
Carlos, from Brazil.
I need package "lilypond-book->latex". How can I download it ?
Thanks

Re: Different default arpeggio positions

[Abraham Lee]

On Thu, Dec 1, 2022 at 1:49 AM Mark Knoop  wrote:

>
> At 23:08 on 30 Nov 2022, Abraham Lee wrote:
> > Happy Holidays!
>
> > A number of versions ago, I created the following function to extend
> > the top and bottom ends of the Arpeggio grob, which I find more
> > aesthetically pleasing (generally), though I know it's not perfect:
>
> Can you not just use \offset?
>
> https://lilypond.org/doc/v2.23/Documentation/notation/the-offset-command
>
> --
> Mark Knoop
>

Thanks so much for that, Mark!

I didn't realize that command was a thing. Might do just what I need (for a
single default pair of values). And if I need to do something more
conditional, it's nice to know there's Jean's solution for that, too.

Best,
Abraham

Frescobaldi on Hi-res monitors

[Abraham Lee]

I apologize for the semi-off-topic, but is anyone who uses a hi-res monitor
(i.e., 4K+) having the Music View display properly? For some reason, mine
renders the page scaled down vertically about 25% shorter than it should
be. It's tolerable, but annoying. Makes the normal PDF viewer look really
weird (even though it's correct) when I see it.

Anyone else experiencing this? Anyone have an idea of how to fix it?
Figured this was a safe group to ask.

Thanks,
Abraham

"loco" after ottava

[Joel C. Salomon]

Piece of music I have in front of me puts the text "loco." above the
first note after an ottava.  See also the attached example, from
.

The code below does not work, which makes me suspect I do not in fact
understand the spanner interface. (I tried to adapt the example from
crescendo spanners.)  The less-elegant solution of "just use
`\textMark` on the next note" works fine, but it feels like I'm
missing something obvious.

--Joel

\version "2.23.80"

{
  r4
  \override Staff.OttavaBracket.bound-details.right.text = "loco."
  \ottava 1
  c''' d''' e''' |
  \ottava 0
  r \textMark \markup\italic "kluge" e' d' c'
}

Re: Different default arpeggio positions

[Abraham Lee]

On Thu, Dec 1, 2022 at 8:53 AM Abraham Lee 
wrote:

>
>
> On Thu, Dec 1, 2022 at 2:13 AM Jean Abou Samra  wrote:
>
>> Le 01/12/2022 à 10:09, Thomas Morley a écrit :
>> > Ofcourse you're right advertising  not to use after-line-breaking for
>> > all and everything.
>> > Though, I do understand why it's still in use.
>>
>>
>>
>> Yes, sure. My point was to advise against it, not to rebuke people who
>> have used / are using it.
>>
>> Indeed, before we had grob-transformer, it was more necessary than
>> it is today.
>>
>> Best,
>> Jean
>
>
> Thank you, again, Jean. I appreciate the feedback and will test out your
> code when I have a chance tonight.
>
> Best,
> Abraham
>

Code works perfectly, Jean, though what it's doing is a bit of a mystery.
You've been very kind to provide a solution and I don't want to take more
of your time on the subject, but is there some documentation somewhere that
explains that commands you've used so I can figure out what's going on for
myself? Or if the explanation is simple, I'd greatly appreciate it so I can
stop using before/after-line-breaking since I used to use it a lot (as
Thomas has hinted at).

Thanks,
Abraham

Re: lilypond-book -> latex

[Werner LEMBERG]

> I need package "lilypond-book->latex". How can I download it ?

If you have downloaded or installed LilyPond, you should already have
the `lilypond-book` script.  On the command line, say

```
lilypond-book --help
```

for a first overview of the available options; you need to add
`--format=latex` to make the script handle LaTeX input files.

Assuming that you are using the latest stable release (2.22.2), the
complete documentation of `lilypond-book` is available online as

  https://lilypond.org/doc/v2.22/Documentation/usage/lilypond_002dbook


Werner

Re: Frescobaldi on Hi-res monitors

[Andrew Bernard]

Frescobaldi works fine for me on a 5K2K (5120x2160) 34 inch screen, in 
both Windows 11 and Linux in VM's.


What OS are you using?

Andrew


On 2/12/2022 11:52 am, Abraham Lee wrote:
I apologize for the semi-off-topic, but is anyone who uses a hi-res 
monitor (i.e., 4K+) having the Music View display properly? For some 
reason, mine renders the page scaled down vertically about 25% shorter 
than it should be. It's tolerable, but annoying. Makes the normal PDF 
viewer look really weird (even though it's correct) when I see it