I have enclosed two messages which I think are getting at the same problem in
different ways. Regardless of \tuplet vs. \times and the associated programming
discussion, I think the fact that Lily's default is to print nonsense in this
kind of case, should be thought of as a bug.
Jonathan Henkelman wrote:
>I understand from the manual and the archives that \set tupletSpanner... etc.
>will do what I am expecting, but in the interest of making the language more
>intuitive, esp. for new users, it is worth considering having the default
>behaviour as follows:
>
>\tuplet 3:2 {c8 d e f g a} yielding:
> __3__ __3__
> | | | | | |
> | | | | | |
>X X X X X X
>
>which is what I would expect from an instruction told to parse a musical
>stream such that 3 notes take the space of two. Instead, what I do get is
>rather meaningless:
>
> +-------3-------+
> _____ _____
> | | | | | |
> | | | | | |
>X X X X X X
>
>It means a new user has to set an internal variable to get the behaviour they
>expect. It would make more sense to have an experienced user, who might want
>the latter, setting the internal variable to get the more unusal behaviour.
and Trevor Bacˇa wrote:
>On 12/20/06, Kress, Stephen <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>> Ok. Based on what everyone has been saying and seeming to come to an
>> agreement on, here's the details of the changes that we are proposing
>be
>> made.
>>
>> 1. \times is replaced by \tuplet since tuplet makes more musical
>sense and
>> convert-ly can easily be updated to make the change. Because of
>convert-ly,
>> there's not a real reason (other than the status quo people are used
>to) to
>> keep \times around.
>>
>> 2. The first argument to \tuplet may be either a ratio (more
>> understandable to musicians) or a division (as is currently
>supported). The
>> punctuation between the two numbers marks what it is. A single number
>will
>> not be supported.
>>
>> 3. The second argument remains an arbitrary musical expression.
>There is
>> no reason to force the expression to contain only the "proper"
>duration of
>> notes since LP is already built to engrave this situation properly.
>>
>> 4. By default, a single number will be engraved in the tuplet
>bracket.
>> There is already the text property of the TupletNumber object that can
>be
>> tweaked to get the ratio printed if one so desires. In other words,
>no
>> changes need to be made to LP in how the single number vs. ratio
>engraving
>> is done; LP already does it right.
>
>The first three of these suggestions make great sense.
>
>But could we please change #4?
>
>Note that, today, the expression
>
> \times 3/5 { c'16 c'16 c'16 c'16 c'16 }
>
>prints with a lone "5" above the backet. A lone 5 is interpreted as an
>abbreviation of "5:4" and not as "5:3". This means that hte output is
>not merely typographically incorrect but musically incorrect.
>
>(The solution in the current implementations of the program is to
>override TupletNumber to a fraction, which definitely does work.
>However, this means that we have a rare example of a case where Lily's
>default behavior is actually musically incorrect.)
>
>If we're going to change tuplet input and rendering behavior, I think
>a better version of #4 might be something like "print, by default, a
>lone integer over the bracket, except where a lone integer is
>musically incorrect, in which case print the ratio over the bracket".
>
>See
>http://lists.gnu.org/archive/html/lilypond-user/2006-11/msg00514.html
>
>
>
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
