lilypond-user
[Top][All Lists]
Advanced

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

Re: Constructive Criticism and a Question


From: David Rogers
Subject: Re: Constructive Criticism and a Question
Date: Thu, 21 Dec 2006 11:09:11 -0800

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 <address@hidden> 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
>
>
>




reply via email to

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