[Top][All Lists]

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

Re: TimeSignature with note in denominator

From: Carl Sorensen
Subject: Re: TimeSignature with note in denominator
Date: Sat, 13 Nov 2021 19:50:08 +0000
User-agent: Microsoft-MacOutlook/10.10.1b.201012

I have not been a strong contributor to this thread.   And I have not been a 
strong advocate for the time signatures with a notehead in the denominator.  I 
think all of those time signatures can be expressed just as well as a compound 


In looking at this, is seems the lexer (and the propery timeSignatureFraction) 
are not semantically correct.

Although the time signature looks like a fraction, it is not.  A fraction has 
numbers in the denominator and the numerator (and strictly speaking, a fraction 
properly has integers in the numerator and denominator -- if they are not 
integers, it's a quotient, not a fraction, IIUC).  And the time signature has 
an integer in the "numerator" and a duration in the "denominator".

I'm not sure it is worth the work to get semantically correct, but 
semantically, \time 4/4 should not be a fraction of two integers; it should be 
a pair of a count and a duration.

And if we had semantically correct time signature entry, Kieren's wish for a 
different display for the duration would be relatively straightforward, 
although we would potentially have an "isoduration" problem that is analogous 
to the "chord name semantics" problem -- there is no difference in duration 
between 4~4 and 2, so we couldn't preserve 4~4.  Similarly, we could not tell 
the difference between 8.~8 and 8~8., although I can't imagine how the 
difference between these two representations would be important; both represent 
a duration of 5 eighth-notes.

Anyway, like I said earlier, I'm not sure that it's worth changing the 
internals since they work so well for the lilypond core functionality 
(traditional western music), but I noticed the semantic error as I read this 


reply via email to

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