Re: Enhancement: Non-power-of-2 note values

[Simon Albrecht]

On 25.11.2015 23:59, Simon Albrecht wrote:
> On 25.11.2015 23:45, Noeck wrote:
> > Hi Simon,
> >
> > > do we have an issue in the tracker for notation like
> > > \relative { c'8  d24 c d }
> > > instead of
> > > \relative { c'8  d16*2/3 c d }
> > > ?
> > How should it be defined what the shown duration is?
>
> Well, the most common use case is a triplet without indication (like 
> when you indicate the tuplets in the first bar only). And it’s pretty 
> straightforward that a 24th note is 1/24 the duration of a whole note.
>
> > Always 2/3 of the duration* if the duration is of the form 3*2^n?
> > Or the next smaller power of 2?
> > Would d25 or d15 also be allowed?
>
> The question is: why not? We can document it appropriately, and then 
> it would be the user’s responsibility to choose sensible values, of 
> course, but generally it seems to me to be well-defined.
> A 16th quintuplet could be written as a 20, as there are 20 of them to 
> a whole note.

Sorry, too short thinking of mine. You mean, that if arbitrary values 
were possible, it would be difficult to draw a line and to compute a 
sensible "length" (as first argument to ly:make-duration).
And, for an absurdly extreme example, what about a Chopin flourish, 
fitting 58 single-beamed notes into a 3/4 measure? So, I am getting your 
point.
Normally, we have to code 8*58/6, which makes sense, whereas 48/58 to 
represent the same duration would be madness and impossible to correctly 
interpret (as having only one beam! – per proximity we’d use three or 
four of them).

But, to return in realistic realms, what about limiting it to triplets 
and (maybe) quintuplets, i.e. 3, 6, 12, 24, 48; 5, 10, 20, 40. In other 
words, 3*2^n to be interpreted as 2^(n+1)*2/3.

At least it’s worthwhile considering.

> And we already have time signatures with non-power-of-2 denominators 
> supported, such as occur in complex modern music.
>
> > This looks like a very mathematically and programming-wise inspired
> > feature request to me. Some syntactic sugar for a rare use case which is
> > much more understandable if written as 16*2/3.
>
> I think it’s not so difficult to understand, and music theory, such as 
> we have to know when writing LilyPond code, certainly features 
> mathematical aspects.
> The use case of ‘implicit tuplets’ is not quite so rare, and it’s 
> tedious to write alternations of 16*2/3 and 8, much more so than of 24 
> and 8.
>
> Yours, Simon
>
> _______________________________________________
> bug-lilypond mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-lilypond