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, 28 Dec 2006 11:30:40 -0800

Brett Duncan-2 wrote:
>> 
>> Here's a different idea: instead of specifying the ratio for a
>> tuplet or set of tuplets, what about specifying the duration of a
>> tuplet, and letting LP determine what number appears over the beam?


...to which Rick Hansen replied:

>Given your example of...
>
>bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
>
>could be even more intuitive by using only nested brackets with each
>nested bracket pair determining a tuplet bracket and note counter, and
>the outermost bracket pair encompassing the preceeding duration
>number, like this:
>
>bf16[d, f ef] \tuplet 4 { { d16 ef f g a } { bf32a c bf d c bf a g f g 
>ef }
>}
>
>Then tuplets can be nested both horizontally and depth-wise with the
>graphical brackets automatically generated with the note counter equal
>to the number of noted in that bracket pair.  If the user wants a
>different number or no number on the tuplet bracket then they can
>specify a different value within the bracket pair like this (with 0
>meaning no number):
>
>bf16[d, f ef] \tuplet 4 { { \tupletNbr 0 d16 ef f g a } { bf32a c bf d c 
>bf
>a g f g ef } }
>
>In the above they could eliminate the auto-generated "5" if for some
>reason they wanted to.
>
>With this syntax they could also create sub groupings of tuplet 
>brackets:
>
>bf16[d, f ef] \tuplet 4 { { { d16 ef f } { g a } } { bf32a c bf d c bf a 
>g f
>g ef } }
>
>The above would generate a parent tuplet with the number "5" and two
>sub-tuplets with "3" and "2", followed horizontally by the "12" tuplet.



Wow! Why didn't I think of that!

I have no idea what kind of work this would be to implement, but to me 
something like this seems an excellent solution. Clear to read under almost any 
circumstances, easy to write, and would (I think) reduce user errors 
considerably.


David




reply via email to

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