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
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
_______________________________________________
bug-lilypond mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-lilypond
