Re: Different default arpeggio positions
Am Sa., 3. Dez. 2022 um 16:35 Uhr schrieb Jean Abou Samra : > > Le 03/12/2022 à 15:58, Thomas Morley a écrit : > > Ofcourse. Though, it's another thing a (probably new) user has to > > learn, maybe scaring him/her away. > > > For someone coming from a language like Haskell, Rust, > OCaml or now even Python, pattern matching will feel > already familiar. > > Someone new to Scheme programming might be glad to discover a > construct that is easier to remember than functions with cryptic > names like "car", "cdr" and "cadadr". > > It's a matter of point of view ... Yep, my point of view is highly influenced by my own history: Before I started with LilyPond I had no programming knowledge. No Haskell, Perl, Python or whatever. I started to learn scheme because LilyPond not always did what I wanted her to do... There may be more users out there with zero programming experience. My whole point is to not increase the hurdles for them. Other users are experienced programmers. As always we need to strike a balance between all of them. Best, Harm
Re: Different default arpeggio positions
Le 03/12/2022 à 15:58, Thomas Morley a écrit : Ofcourse. Though, it's another thing a (probably new) user has to learn, maybe scaring him/her away. For someone coming from a language like Haskell, Rust, OCaml or now even Python, pattern matching will feel already familiar. Someone new to Scheme programming might be glad to discover a construct that is easier to remember than functions with cryptic names like "car", "cdr" and "cadadr". It's a matter of point of view ... Iiuc, than (x x) is a second pattern (and return value), triggered if the first one, a pair like (a . b), doesn't match. Yup. Jean. OpenPGP_signature Description: OpenPGP digital signature
Re: Different default arpeggio positions
Am Sa., 3. Dez. 2022 um 13:41 Uhr schrieb Jean Abou Samra : > > Le 02/12/2022 à 23:47, Thomas Morley a écrit : > > I know you like pattern matching, though imho it makes things not > > always easier for users. > > > > Yes, I like pattern matching. No, I'm not going to stop using it :-) I don't intend to advertise you shouldn't use it, but I wanted to mention my concerns, see below > Sure, you have to learn it, like every construct, Ofcourse. Though, it's another thing a (probably new) user has to learn, maybe scaring him/her away. Therefore I usually code using only simple features from default guile, using more "fancy" modules only if really neccessary. Looks this opinion is not very wide spread. I had a similar discussion with a guile-dev some time ago, LOL > but it improves code clarity IMHO (especially in complex code). > > > > Even for me - I don't understand that (x x)-line: > > > > \override Arpeggio.positions = > > #(grob-transformer > > 'positions > > (lambda (grob original) > > (match original > > ((a . b) (cons (- a 5.0) (+ b 5.0))) > > (x x ;; <== > > > > > This was me being too lazy to look up whether > original might be something other than a pair, > like #f, '() or *unspecified*, especially if > the grob suicided itself inside the positions > callback. In such a case, this code would have > returned original unchanged, as > > (if (pair? original) > (cons (- (car original) 5.0) (+ (cdr original) 5.0)) > original) > > This case appears not to occur, though, so that precaution > was unnecessary. > > Best, > Jean > Thanks for the explanation. Iiuc, than (x x) is a second pattern (and return value), triggered if the first one, a pair like (a . b), doesn't match. Thanks, Harm
Re: Different default arpeggio positions
Le 02/12/2022 à 23:47, Thomas Morley a écrit : I know you like pattern matching, though imho it makes things not always easier for users. Yes, I like pattern matching. No, I'm not going to stop using it :-) Sure, you have to learn it, like every construct, but it improves code clarity IMHO (especially in complex code). Even for me - I don't understand that (x x)-line: \override Arpeggio.positions = #(grob-transformer 'positions (lambda (grob original) (match original ((a . b) (cons (- a 5.0) (+ b 5.0))) (x x ;; <== This was me being too lazy to look up whether original might be something other than a pair, like #f, '() or *unspecified*, especially if the grob suicided itself inside the positions callback. In such a case, this code would have returned original unchanged, as (if (pair? original) (cons (- (car original) 5.0) (+ (cdr original) 5.0)) original) This case appears not to occur, though, so that precaution was unnecessary. Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Different default arpeggio positions
Hi Harm, hi Jean, Le ven. 2 déc. 2022 à 23:49, Thomas Morley a écrit : ... > Even for me - I don't understand that (x x)-line: > ... +1, thanks for asking! Cheers, Pierre
Re: Different default arpeggio positions
Am Fr., 2. Dez. 2022 um 11:46 Uhr schrieb Jean Abou Samra : > > Le 02/12/2022 à 05:16, Abraham Lee a écrit : > > 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). > > > Try reading this, and feel free to ask again if this doesn't clarify it > for you: > > https://extending-lilypond.readthedocs.io/en/latest/backend.html#properties-and-callbacks > > Best, > Jean > Hi Jean, we have a very short section about grob-transformer in the Extending Manual. Probably too concise. Your text is more clear. Many thanks again for the entire text! I know you like pattern matching, though imho it makes things not always easier for users. Even for me - I don't understand that (x x)-line: \override Arpeggio.positions = #(grob-transformer 'positions (lambda (grob original) (match original ((a . b) (cons (- a 5.0) (+ b 5.0))) (x x ;; <== I'd likely code it like: \override Arpeggio.positions = #(grob-transformer 'positions (lambda (grob original) (cons (- (car original) 5.0) (+ (cdr original) 5.0 Best, Harm
Re: Different default arpeggio positions
Le 02/12/2022 à 05:16, Abraham Lee a écrit : 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). Try reading this, and feel free to ask again if this doesn't clarify it for you: https://extending-lilypond.readthedocs.io/en/latest/backend.html#properties-and-callbacks Best, Jean OpenPGP_signature Description: OpenPGP digital signature
Re: Different default arpeggio positions
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: Different default arpeggio positions
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
Re: Different default arpeggio positions
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: Different default arpeggio positions
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
Re: Different default arpeggio positions
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
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
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
