lilypond-devel
[Top][All Lists]
Advanced

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

Re: [proposal] easy triplets and tuplets - Draft 3


From: David Kastrup
Subject: Re: [proposal] easy triplets and tuplets - Draft 3
Date: Tue, 09 Oct 2012 10:12:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Graham Percival <address@hidden> writes:
>
>> On Mon, Oct 08, 2012 at 11:49:39PM +0100, Trevor Daniels wrote:
>>> 
>>> David Kastrup wrote Monday, October 08, 2012 10:45 PM
>>> 
>>> > Thomas Morley <address@hidden> writes:
>>> > 
>>> >>> In this case, i
>>> >>> think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time
>>> >>> of 2), because it corresponds to mathematical ratio, and is similar to
>>> >>> scaling durations.
>>> >
>>> > -1 from me for this one.  We have \times for that already and I can't
>>> > count the times it took me to get the fraction right.  And with the name
>>> > "\times" there is at least the mnemonic of the name itself.
>>> 
>>> Absolutely!  Inverting the fraction for \tuplet was the original reason
>>> for inventing it, IIRC.
>>
>> Woah, really?  I thought the whole point was to avoid the
>> confusion between \time and \times.
>
> Both "the whole point" impressions are mistaken if you look at the
> original proposal in
> <URL:http://permalink.gmane.org/gmane.comp.gnu.lilypond.devel/50803>.
> It was one, deliberately separate point to discuss.  It was discussed,
> and a consensus was reached.

Obviously, "a consensus was reached" was inaccurate since at at the time
of writing, Janek had already voted against this.  I actually had to
reread his take on this since the detailed argument he makes _strongly_
argues in favor of \tuplet 3/2, but his conclusion is definitely quite
opposite.

Since then, also Martin has spoken up to express his dislike of a
\tuplet behaving substantially different from \times.  I disagree with
this take since substituting a new command should also give us a chance
to reconsider the best behavior without being bogged down by history.  A
new command name is the best chance of reevaluating the best semantics
for users we get.  We should not lightly waste it.

-- 
David Kastrup




reply via email to

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