Re: TimeSignature with note in denominator

[Jean Abou Samra]

Le 12/11/2021 à 16:41, Kieren MacMillan a écrit :
> Hi all,
>
> I’m not sure whether I’m waiting for others to move this discussion forward…?
>
> Assuming I’m not:
>
> 1. In *my* mind, the optimal situation *from the user/UI perspective* would be 
> to have a single public interface
>
>     \time BLAH FOO BAR etc.
>
> which would gracefully and transparently handle all possible time signature 
> demands: simple and compound sigs, all possible “denominator” representations, 
> beat structures, etc. My first question in this regard: Am I wrong [from the 
> user/UI perspective]? I totally get that it may be unadvisable from the 
> programmers’ perspective (and for sure from backwards-compatibility 
> perspective, etc.) — my question here is more one of Lilypond programming 
> philosophy.


I concur with David on this. The programmers' perspective
is quite related to the users'. A unified \time command is
not trivial to achieve from a parsing perspective. If the
syntax of the argument is "4/4.", there is work to be done
in the parser to let it accept it. "4 4." is feasible with
a separate function, but I am pretty sure it isn't with
a unified music function. Again, fiddling with the parser
would be required.

In general, the more input is recognized by shape rather
than by explicit hints from the user, the more it becomes
tricky to add new styles without breaking existing ones.
(Note that parsers of the kind GNU Bison creates are
limited in the amount of “look-ahead” you are allowed
before making a decision, which means that not every
syntax you might like will be possible to implement.
I am a newbie to parser.yy, but I understand enough of
it to see how complex it is.)


> 2. Regardless of the more general philosophical state… What’s my next move on 
> this patch? It sounded to my [dev-]noob ears like a number of people out there 
> (Dan, Werner, etc.) had concerns about my idea to “bunt” by just adding a new 
> denominator style to the TimeSignature grob. Do I wait for more input? Please 
> let me know the protocol — I have lots of ideas I’d like to turn into patches, 
> but I’m still at the bottom of the “process and culture” learning curve.

Freestyle protocol. Basically, I think it's helpful
if you prepare a patch and post it, either on the
mailing list in an attachment, or on GitLab (marking
the merge request as draft, just start the title with
"Draft:" for that). That makes it easier to discuss
the specifics.

As always, feel free to ask for help.

Cheers,
Jean