Re: TimeSignature with note in denominator

[David Kastrup]

Flaming Hakama by Elaine <elaine@flaminghakama.com> writes:

> From: David Kastrup <dak@gnu.org>

>> Kieren MacMillan <kieren@kierenmacmillan.info> writes:
>> > The time signature “9/8” does *not* (as you imply) actually convey
>> > *any* information about the number of “beats” — the *convention* does
>> > that.
>>
>> I am certain you will be able to provide a definite quote where I
>> "imply" any such thing.
>>
>
> So, are you claiming that this is a misquote?
>
> [David K:]
>> 8/20 does not specify more than the basic
>> subdivision for expressing beats (not necessarily identical with the
>> number of beats as signatures like 9/8 show)

I have problems imagining how myself quoting an example of a signature
with different conventions than derived from the raw fraction is proof
that I imply that the raw fraction carries all the information.

Seriously.

> The feature request is to render 9/8 with an 8th note instead of the
> numeral 8 as the denominator.

The discussion long ago stopped being about the printed result and
rather focused on the internals of time signature representation.

> The feature request is to render 8/20 with a 16th note quintuplet note
> instead of the numeral 20 as the denominator.

No, it never was that.  I quoted the 8/20 signature mention in
LilyPond's code as an example where there _is_ no unique graphic
representation of the composers intent possible just given the
information of 8/20 because it could be equally well intended to express
the basic duration to use as quintuplet or as 10-tuplet.

> Why is the subdivision of the measure relevant?

Because there are different print forms for various ways of expressing
1/20 and the composer might not even have wanted to be definitive in
choosing one.

Not everyone picking 6/8 unambigulously wants to see this interpreted as
2 notes of 4. duration.  So forcing a particular duration expressing a
length not inherently specified is putting words in the composer's
mouth.

>> > I suppose Carl and my surprise (revelation?) is that Lilypond has
>> > *never* handled time signatures correctly (where “correct” means
>> > “according to the accepted definition of 'time signature'”).
>>
>> Nor has his ever handled durations correctly according to your
>> definition of "duration".  Which means you should get a grip on what
>> LilyPond calls a duration before proposing to use it.
>
> So, are you defending incorrect semantics?

Tuplet _notation_ is "incorrect semantics" according to your
classification.  In the end, LilyPond follows what printed music does.
It may be more awkward than required when generating Midi or
programmatically manipulating music but it's firmly tied into notation
practice.

> The point is that the current implementation does not support the
> necessary semantics.
>
> So, you can whine about people not understanding how the
> implementation works, but if you want to be helpful, instead, please
> try to help us understand what the gap is so that others can work on
> figuring out how to address it.

I think that if you bother to read what I write while not getting
distracted by everyone shouting me down, you'll find that I actually do
write what the problems are, including giving examples.

-- 
David Kastrup