Re: LSR down?
> The LSR looks like it's down. I don't know who is responsible for > it so I thought I'd just post here. Thanks. I've written an e-mail to Sebastiano. Werner
LSR down?
The LSR looks like it's down. I don't know who is responsible for it so I thought I'd just post here. -- Knute Snortum
Re: Graphical markup between objects?
Am So., 23. Juni 2024 um 19:48 Uhr schrieb Fennel :
>
>
> Wondering if it's possible to override the behavior of the glide line such
> that the glide will draw to the next fingering regardless of what the second
> number is.
>
> - Fennel
It's not possible. Think of chords with multiple fingerings, how to decide?
But you can fake it:
{
b1-\glide -1 b'-\tweak text "2" -1
}
Cheers,
Harm
Re: Graphical markup between objects?
Wondering if it's possible to override the behavior of the glide line such that the glide will draw to the next fingering regardless of what the second number is. - Fennel On Thursday, May 30th, 2024 at 12:28 AM, Werner LEMBERG wrote: > > > > I was looking for something like "shift line" or "line between > > fingerings", the latter of which seems to point to the correct page. > > > https://gitlab.com/lilypond/lilypond/-/merge_requests/2357 > > > Werner
Re: need help building a Scheme function
Hi Lukas!
Thanks for the patient and helpful tutorial(s). :)
> The last "m" in your innermost (if ...) is unnecessary: As with the
> difference between "for" and "map" in plain Scheme, the return value of the
> lambda function in for-some-music gets discarded ("for" functions are
> supposed to _do_ something, not _return_ something). So your branch stating
> "... else return m" can be omitted.
Excellent.
> Next, as you already hinted: If you use the same expression more than once
> (here (ly:music-property m 'pitch)), it is usually reasonably to store it in
> a variable, i.e. use (let ...).
Why wouldn’t I use let* here? I read
https://extending-lilypond.gitlab.io/en/scheme/local-variables.html#let-syntax,
and unless there’s some big-ticket efficiency problem under the hood, I don’t
see why anyone would use let instead of let*.
> Also some food for thought, if I may:
> - What if I want to replace each b by the c _above_ it?
Yes, you are thinking what I’m thinking, for the final version. :)
> we rather want a list of pairs (old-pitch . new-pitch)
That’s the interface I was thinking of.
> In order to construct such a list of pairs from two music inputs as above,
> (map ...) provides a very elegant way.
In the case of a simple scale,
\adjustPitches scaleIn scaleOut
and then post-processing into lists, etc., makes some sense. But what about
sending in pairs instead? e.g.
\adjustPitches ((ces c) (c b') (e g))
There would be the question of whether the user wants to process each pair
consecutively (e.g., all ces become c, then all c [including the old ces]
become b', etc.)… Maybe both options made available, with either a switch or
optional parameter(s)?
Cheers,
Kieren.
__
My work day may look different than your work day. Please do not feel obligated
to read or respond to this email outside of your normal working hours.
Re: need help building a Scheme function
The last "m" in your innermost (if ...) is unnecessary: As with the
difference between "for" and "map" in plain Scheme, the return value of
the lambda function in for-some-music gets discarded ("for" functions
are supposed to _do_ something, not _return_ something).
No, it doesn't. It is a boolean that determines whether to recurse (#f)
or not (everything else).
Of course you're right, my bad. To be more precise:
- Plain Scheme (for ...) is indeed not supposed to return something but
rather do something.
- LilyPond's (for-some-music ...) is intended to i) do something, ii)
return a boolean indicating whether the recursion should continue (kind
of "is my work done in this branch of music?").
Of course that's what you explained, I just wanted to point out the
comparison with standard "for".
So @Kieren: In your example you should take care to control the return
value of your lambda (in particular, also in the else-branches of your
if's.)
Lukas
Re: need help building a Scheme function
Hi David, If you don't want to call upon undocumented internals of LilyPond (the (@@ (lily) ...) bit), you can just use [with-output-to-string] Wow, thanks! I hadn't encountered this possibility yet. Also thanks for pointing out the possibility of in-place modification. Lukas
Re: need help building a Scheme function
Hi Kieren,
for-some-music does not return music. It works on music in-place. So
the last thing in your music function must not be for-some-music but
rather the music that you have been working on.
So…
%%% SNIPPET BEGINS
adjustPitch =
#(define-music-function (pitchIn pitchOut music) (ly:pitch? ly:pitch? ly:music?)
(for-some-music
(lambda (m)
(if (music-is-of-type? m 'note-event)
(if (and (= (ly:pitch-notename (ly:music-property m 'pitch))
(ly:pitch-notename pitchIn))
(= (ly:pitch-alteration (ly:music-property m
'pitch)) (ly:pitch-alteration pitchIn)))
(ly:music-set-property! m 'pitch
(ly:make-pitch
(ly:pitch-octave (ly:music-property m
'pitch))
(ly:pitch-notename pitchOut)
(ly:pitch-alteration pitchOut)))
m)
#f))
music)
music)
testmusic = \fixed c' { c4 d es e f g c' es' eis }
{ \testmusic }
{ \adjustPitch ees e \testmusic }
%%% SNIPPET ENDS
??
The last "m" in your innermost (if ...) is unnecessary: As with the
difference between "for" and "map" in plain Scheme, the return value of
the lambda function in for-some-music gets discarded ("for" functions
are supposed to _do_ something, not _return_ something). So your branch
stating "... else return m" can be omitted.
Next, as you already hinted: If you use the same expression more than
once (here (ly:music-property m 'pitch)), it is usually reasonably to
store it in a variable, i.e. use (let ...).
Also some food for thought, if I may:
- What if I want to replace each b by the c _above_ it?
- I've been thinking about a conventient user interface. If I understand
you correctly, you aim for something like a list of input-pitches and a
list of output-pitches, both preferably given as music, so we can do
\adjustPitch { c d e } { fis e d } \music
meaning: turn c into fis, d into e, and e into d. If I'm right, you'll
probably be able to make good use of (music-pitches ...). Also, for
search-and-replace tasks in Scheme, using an association list (alist) as
a dictionary is often convenient. This would mean we rather want a list
of pairs (old-pitch . new-pitch). In order to construct such a list of
pairs from two music inputs as above, (map ...) provides a very elegant way.
See also:
https://www.gnu.org/software/guile/manual/html_node/Association-Lists.html
https://www.gnu.org/software/guile/manual/html_node/List-Mapping.html
Lukas
