lilypond-devel
[Top][All Lists]
Advanced

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

timing (the 1.7 approach)


From: Rune Zedeler
Subject: timing (the 1.7 approach)
Date: Thu, 23 May 2002 16:07:05 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313

What the heck, I think that now would be a good time to mention an idea I got a while ago. Afaics this would solve some of the mensural notation problems in a relatively clean way; and further more would make entering triplets a lot easier. The idea is quite simply to allow durations to instead of being a tuplet of dotcount and power-of-two to be a TRIPLET of dotcount, power-of-two and power-of-three. This means that i.e. 12 would be a legal duration (because 12 can be written as a product of powers of two and three). This way the different mensural modus could (afaics) be entered context-freely (that is: the music wouldn't depend of the time-signature), and when entering triplets one could substitute
c8 d8 \times 2/3 { e8. f16 g8 }
with
c8 d8 e12. f24 g12
Then the time signature would only have influence of how this was turned into notation and not on how the durations was to be interpreted.

Over time one should make an auto-tuplet-engraver automatically grouping triplet notes in approx. the same way as the auto-beam-engraver does, but for a start we could add grouping syntax, like
c8 d8 [[e12. f24 g12]]
to indicate where the tuplets go. - Or perhaps the new ligature-grouping-syntax (which I don't remember) could be used for this.

I know that strictly speaking, following this idea, any integer duration should be allowed (not just powers of 2 and 3) - but I think that storing the duration (2^n)*(3^m) as (n,m,0) would make things a lot easier to cope with - and for practical purposes I see no problems in sticking with the old times-syntax whenever one needs a non-triplet tuplet.

-Rune




reply via email to

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