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
