[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TimeSignature with note in denominator

From: Jean Abou Samra
Subject: Re: TimeSignature with note in denominator
Date: Mon, 15 Nov 2021 19:54:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

Le 13/11/2021 à 04:21, Flaming Hakama by Elaine a écrit :
So, I guess for me this is a 2- or 3-part trick question.

The first is, how is the usage of \time different in lyrics than anywhere

Frankly, I was not aware that using \time inside lyrics was a thing.
What is the reason to use \time inside lyrics?
It is a suggested practice, is it the only way of doing certain things?

If it is interpreted differently in lyrics than elsewhere,
is that a pattern that we want to keep?

Or should we fix it so that it behaves the same in both contexts?

The second has to do with the example syntax.
I don't suppose it will change your use case,
but just to be clear, I was proposing it might be possible
to distinguish a number from a duration by using {}

So, for one thing, you used it in the numerator
where I was suspecting it would only ever appear in the denominator,
so it would be more like;

\lyrics { \time 4/4 + 4/{8} }

But really, that was just for doing a shorthand notation, I was not
formally proposing that syntax.

Rather, I was rather suggesting that it be used in the syntax of

\lyrics { \compoundTime #{{4 4) (4 {8})) }

I suspect that using {} to distinguish number from duration is still not
going to cut it in this usage, either.

But I suspect that there could be some other kind of way to modify either
the data type (number vs string?) of that denominator argument so that it
was clear which representation was intended.


I'm sorry if it came across as a 'trick question'.
It was certainly not meant such.

My point was merely that -- independently of the
specific case at hand here -- there are technicalities
that cannot be avoided. So I was trying to explain
why LilyPond developers may make decisions of
syntax that sometimes even them would like to see
differently if only considering the intuitiveness, and
not the special cases, the programmability, the
possibility/ease of writing good error messages
for invalid input, the flexibility of the parser
tooling, etc.

I don't have much to add, and the discussion is
already well-furnished, so I won't comment
further on the specific topic for now.

Kind regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]