[Top][All Lists]

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

Re: TimeSignature with note in denominator

From: David Kastrup
Subject: Re: TimeSignature with note in denominator
Date: Mon, 15 Nov 2021 19:25:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Aaron Hill <> writes:

> On 2021-11-15 3:30 am, David Kastrup wrote:
>> 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 agree.  6/8 communicates precisely six eighth notes--nothing more,
> nothing less.  While 2/4. might be a common conventional feel, it is
> not a hard-and-fast rule.
> And correct me if I am wrong, but the problem you stated about 20 not
> being a duration (as Lilypond defines it) is that it is not a
> *singular* duration.  For instance, all of these durations have the
> same length (moment) of 1/20:
> 1*1/20
> 4.*2/15
> 16*4/5
> Writing "\time 8/20" leaves one wondering how that /20 should be
> rendered if not as a simple number.
> Writing "\time \musicFraction 8 \tuplet 5/4 { 16 }" lets the composer
> be explicit about the intention.

There are basically three components we are talking about here.  There
is the strictly functional component of the length of a measure, there
are more subtle functional components reflected in beat structure and
related to that beaming patterns (and possibly some MIDI renderings),
and there is the visual representation in the score.  Forcing an
artificial intermingling of those components in the internals when it is
not necessarily intended by the composer seems like asking for trouble.

Programmatically it seems to make more sense to do something like

\withMusicFraction 8 \tuplet 5/4 { 16 } \time 8/20

where \withMusicFraction essentially overrides the stencil of the \time
command (of course \time works in a much more cumbersome manner where
making this a surefire thing would take some more work).  But then there
is little motivation left to not just make a separately named command

David Kastrup

reply via email to

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