Re: shiftDurations and tempo

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Jean Abou Samra <jean@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.

To wit:

>From 56869db10837eac331e89d074efa5952116ce3d6 Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@gnu.org>
Date: Tue, 28 Jun 2022 00:06:17 +0200
Subject: [PATCH] Allow \tempo #<Duration> = ... for tempo specifications

What doesn't work is specifying \tempo "text" #<Duration> = ...
because its implementation would lead to parser conflicts.
---
 lily/parser.yy | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lily/parser.yy b/lily/parser.yy
index 9207e479c8..7fff2fd019 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -1403,6 +1403,16 @@ tempo_event:
        TEMPO steno_duration '=' tempo_range    {
                $$ = MAKE_SYNTAX (tempo, @$, SCM_EOL, $2, $4);
        }
+       | TEMPO embedded_scm_bare '=' tempo_range {
+               if (unsmob<Duration> ($2))
+               {
+                       $$ = MAKE_SYNTAX (tempo, @$, SCM_EOL, $2, $4);
+               } else {
+                       parser->parser_error (@2, _("duration expected"));
+                       $$ = MAKE_SYNTAX (tempo, @$,
+                                         SCM_EOL, Duration (2, 0).smobbed_copy 
(), $4);
+               }
+       }
        | TEMPO text steno_duration '=' tempo_range     {
                $$ = MAKE_SYNTAX (tempo, @$, $2, $3, $5);
        }
-- 
2.34.1

It's debatable whether this partial ability to specify the duration as
#... but not in the long form including text is worth the confusion.
Anyone who wants to tackle the resulting parser conflicts is welcome to
try: Bison appears to do a pretty good job these days proposing
productions that may trigger the problem when giving the right options.

-- 
David Kastrup