lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP2-3 - GLISS or not


From: Joseph Rushton Wakeling
Subject: Re: GOP2-3 - GLISS or not
Date: Tue, 31 Jul 2012 23:29:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0

On 30/07/12 17:52, Graham Percival wrote:
In general, yes.  But some aspects of our syntax haven't been
around for a long time -- footnotes, woodwind fingering, compound
meters, etc.  Do we have the best syntax for those?  I mean,
maybe David can figure out a way to allow us to write
   \compoundMeter (3+2)/8
or simply
   \time (3+2)/8
instead of
   \compoundMeter #(3 2 8)

That's another very good case for careful thought. Just some examples of what you might have to handle if you want to cover the gamut of expression in 20th century notation:

     (3+2+3)/8

     3/8 + 2/8 + 3/16

     (3+2)/8 + 3/16

     3.5/8   [or  (3+1/2)/8 ...]

     (2 + 1/3)/4   [Boulez in Le Marteau Sans Maitre]

     4/8 + 1/10

     3/8 + 4/10 + (3+2+2)/12

Note that these are all _logical_ extensions of traditional time signatures. There's no reason in principle why they can't all be supported. But (just as an example) if you try,

  \compoundMeter #'((3 2 3 8) (1 10))

  c'4. c'4 c'4. \times 4/5 { c'8 } |
  c'4. c'4 c'4. \times 4/5 { c'8 } |

... with current Lilypond, you get an error:

  warning: strange time signature found: 11/10
  ERROR: In procedure ly:make-moment:
  ERROR: Wrong type argument in position 1 (expecting integer): 15/4

... even though Lilypond supports so-called "irrational meters" like 3/10, 11/24, etc. (and if you replace the compound meter in the above example with a straightforward 11/10 time signature, it works fine).

You get a similar error with the following:

  \compoundMeter #'((4 2/3 4))

  c'4 c'4 c'4 c'4 \times 2/3 { 4 } |
  c'4 c'4 c'4 c'4 \times 2/3 { 4 } |

That is,

  Parsing...ERROR: In procedure ly:make-moment:
  ERROR: Wrong type argument in position 1 (expecting integer): 14/3

... which can again be avoided by using the equivalent time signature of 7/6.

This is probably actually quite easy to fix, but _as things stand_ it seems to me that compound time signatures probably need some careful consideration with respect to the styles and use-cases out there.

Based on the above it's _probably_ just an internals issue and not a syntax problem (I can make bug reports accordingly), but it's another contemporary music issue to throw into the mix regarding syntax.



reply via email to

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