Jean Abou Samra <j...@abou-samra.fr> writes: > Le 27/06/2022 à 20:10, Simon Albrecht a écrit : >> Hello everyone, >> >> I’m trying to encode a piece such that I can switch whether or not >> durations will be shifted (note values >> halved/doubled). Unfortunately \tempo isn’t affected by >> \shiftDurations (that would be a sensible feature request, right?), > > Go open an issue. > > >> so I tried this: >> %%%%%%%%%%%%%%%%%%%%%%%%%%% >> \version "2.23.9" >> >> durationShiftOne = #-1 >> { >> \tempo #(ly:make-duration (+ 3 durationShiftOne)) = 152 >> \shiftDurations \durationShiftOne #0 { 8 } >> } >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> but unfortunately Lily won’t accept that Scheme expression instead >> of the normal duration. >> >> Can I make that work some other way? >> >> Should the parser be able to take that Scheme expression there? > > > \version "2.23.9" > > durationShiftOne = #-1 > { > \tempo $(ly:make-duration (+ 3 durationShiftOne)) = 152 > \shiftDurations \durationShiftOne #0 { 8 } > } > > > You just need to use $ instead of #. See these pages about the difference: > > https://lilypond.org/doc/v2.23/Documentation/extending/lilypond-scheme-syntax.html > https://extending-lilypond.readthedocs.io/en/latest/lily-and-scheme.html#hash-vs-dollar > > The problem is that \tempo has multiple syntaxes (\tempo <markup>, > \tempo <duration> = <bpm> and \tempo <markup> <duration> = <bpm>), > which makes it impossible to accept # here because early evaluation > is needed to disambiguate, I think. I'm no expert of the parser > though.
It's sort of like that. Before looking for a possible following `=` LilyPond has to have made a decision what type the token/expression coming before that has. It cannot look at the type of a #... expression before deciding to look for `=` but it can (and will) look at the type of a $... expression. Now syntax errors are comparatively unhelpful, so one could try to tentatively accept an #... = ... expression anyway and then barf if the expression type does not support it. The result would likely not be worse for the user. -- David Kastrup