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
