On 05/10/12 08:47, David Kastrup wrote:
> Ian Hulin <i...@hulin.org.uk> writes:
>
>> 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.
>
> Well, I definitely remember enough of my learning curve with LilyPond to
> recommend taking the opportunity of renaming for reversing the fraction,
> making it correspond with the output from
>
> \override TupletNumber #'text = #tuplet-number::calc-fraction-text
I'll take that as a 1+ for \tuplet 3/2 { blah...} representing a
triplet/Triole.
>
> I don't think we need a wealth of shorthands, though: we can instead
> just take the tuplet number as a shorthand as 3 is perfectly
> distinguishable from 3/1 as LilyPond input.
>
> So \tuplet 3 can be the same as \tuplet 3/2, and \tuplet 2 the same as
> \tuplet 2/3, and \tuplet 5 as tuplet 5/4 and \tuplet 6 as \tuplet 6/4.
>
> I am not sure whether other tuplet numbers are unambiguous enough to
> warrant a shorthand.
>
Hmmm... interesting, but I'd still like like \tuplet to be able to
handle anything \times does.
We could handle your suggestion and achieve this with some fiddling
around at Scheme level, but I feel that it wouldn't support one of the
aims of the proposals of making the source code more readable for
musicians. I think \triplet or \sextuplet would be simpler to
understand at first reading.
>> 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.
>
> Probably not.
>
Thanks. I'll take this as as -2 from you and Keith combined.
Many thanks for the feedback here and in other bits of the thread, it's
been really useful.
Cheers,
Ian
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
