Hello!
Currently Lilypond only supports powers of 2 for specifying duration. Could we
use the other numbers for common divisions?
For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7 for 8*7/8,
9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2 and so on.
This would be quite useful, especially for the divisions of three (*3/2),
because stuff like this
e8*2/3 dis cis cis8. dis16 e8*2/3 dis cis cis8. dis16
Is not really nice to enter, while
e12 dis cis cis8. dis16 e12 dis cis cis8. dis16
would be much less effort.
Cheers, Valentin
Thank you for proposing your ideas! That said,
I admit some skepticism to this particular
proposal, see below.
These things are done during parsing, and I don’t know if there is any way to
pass flags or tokens to the parser. If it is possible, one could try to pass a
rounding flag, or one might even be able to modify this such that the user can
pass a scheme function for parsing. But I do not know enough about the parser
to know if such stuff is possible (the problem here is that the file that is
being parsed would have to tell the parser how to parse it, which can be quite
a hen and egg problem).
The parser does already have such capabilities.
For example, you can define your own note
names -- so why not your own durations after all.
Le 26/03/2021 à 12:43, Werner LEMBERG a écrit :
For example: We could use 3 for 2*3/2, 5 for 4*5/4, 6 for 4*3/2, 7
for 8*7/8, 9 for 8*9/8, 10 for 8*5/4, 11 for 8*11/8, 12 for 8*3/2
and so on.
LilyPond is a notation program first, and your proposal does not map
to notation since tuplets also involve choices of beaming and
division.
There's a lot of music that contains tuplets (mainly triplets) without
tuplet numbers. Such a notation would simplify things.
In my experience, the triplets in question most often
come in a chain. The three-argument form of \tuplet
(as in \tuplet 3/2 8 { c16 c c c c c }) helps with
those cases.
Having special durations equivalent to multipliers
defeats separation of content and layout through
non-semantic markup since you can't get the tuplet
brackets and numbers back.
I'll also have to admit that my first thought when
reading the original post was: FRACTRAN++!
The point is: smart does not mean user-friendly;
often to the contrary in fact.
Best regards,
Jean
PS: https://esolangs.org/wiki/Fractran++
