lilypond-devel
[Top][All Lists]
Advanced

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

[proposal] easy triplets and tuplets - Draft 3


From: Ian Hulin
Subject: [proposal] easy triplets and tuplets - Draft 3
Date: Sun, 07 Oct 2012 16:04:41 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120912 Thunderbird/15.0.1

Thanks to everyone for their feedback so far.
Here is Version 3 of the proposal.

There will be new commands to supplement (or eventually replace) the
current \times command.

1. \tuplet n/m {<music expression>}
%  does what \times does, but not so easily confused with \time
%  command.
2. \triplet {<music expression>} % shorthand for current
%  \times 2/3 command
3. \duplet {<music expression>} % shorthand for current
%  \times 3/2 command
4. \quadruplet {<music expression>} % shorthand for current
%  \times 3/4 command
5. \sextuplet {<music expression>} % shorthand for current
%  \times 4/6 command
Discussions seemed to imply that we also might need
6. \quintuplet {<music expression>} % shorthand for current
%  \times 4/5 command.

The design was deliberately restricted to providing
shorthands for the \times commands with 2:3 and 3:2 ratios expressed in
the n/m rational parameter, however there seemed to be a feeling that
the 5:4 ratio was just as common.  (See 6. above).

This should be relatively easy to implement by adding declarations to
music-functions-init.ly.

The following questions were put forward in Version 1:
1. Should the new \tuplet retain the \times meaning of the fraction,
i.e. \tuplet 2/3 {c8 c c} uses 2/3 because that's what you'd use if you
were just using durations: c8*2/3 c c , or
invert it as \tuplet 3/2 {c8 c c} because that reflects better the
"three notes in the time of two" definition of a triplet.

Feeling generally has been that \tuplet 3/2 {c8 c c} for a triplet was
better than the current \times 2/3 style.
One vote was for representing this as a ratio
e.g. \tuplet 3:2 {c8 c c}. The downside of this is that it would require
a parser extension, and provision of a home-brew ratio? predicate to
allow validation in the music function.
Another suggestion was that the commoner tuplets should be represented
as by an integer argument i.e. \tuplet 3 as an equivalent to the current
\times 2/3 and equivalent to \tuplet 3/2.  These would stand instead of
the proposed \triplet etc. commands.

Decisions:
Use the inverted fraction rather than the ratio format.
Use the above \triplet etc. commands in tandem with the new \tuplet:
they are more readable although less syntactically elegant.

2. Should the \tuplet command attempt to validate the length of the
incoming music expression?  I.e. add up the lengths of the constituent
notes in the music expression, and see if it would be a valid
note-length once multiplied (or divided depending on decision for 1.
above) the fraction.
Those who commented felt this was not possible.

Decision:
The \tuplet command will not attempt to validate the length of the
incoming music expression.

3. Another suggestion was that \tuplet command could be flexible
enough to cater for the the commoner forms of tuplets by using
defaults to arguments which the user could omit, e.g.:
\tuplet {<music impression>} % implies \tuplet 3/2 {<music
expression>} % \times 2/3 {<blah>} in current syntax.
\tuplet with an integer rather than a fraction implies other common
tuplets
\tuplet 2 implies \duplet
\tuplet 3 implies \triplet
\tuplet 4 implies \quadruplet
\tuplet 6 implies \sextuplet etc.

Decision:
After looking at some prototype code the \tuplet command will act as
simple replacement for \times.  Although the idea behind the
defaulting/implied values for the fraction parameter are quite elegant
as an idea, the disadvantage is that they actually make source code
potentially less readable, particularly when we using the command with
an integer "fraction" parameter, as we are using number in this case
as a keyword.  If users want not to code the complete fraction
parameter as, they can use \triplet and friends.

Cheers,

Ian





reply via email to

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