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.
