lilypond-devel
[Top][All Lists]
Advanced

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

Re: \time 2


From: Juergen Reuter
Subject: Re: \time 2
Date: Fri, 13 Dec 2002 11:41:54 +0100 (CET)


On Fri, 13 Dec 2002, Heikki Johannes Junes wrote:

>
> "\time 2" should print number "2" in the middle of the staff, in the
> same manner than "\time 2/1" prints "2" above "1". In fact, "2/1" is
> as good a representation as is "2". Hence, there should be a choise
> to leave out the denominator "1".
>

I think this can already be done by setting property #'style of grob
TimeSignature to #"1".  As far as I know, Lilypond requires a
denominator for internal timing; hence syntax like "\time 2" would be
inappropriate, since it does not deliver enough information.  Of course,
lily could assume a default denominator, e.g. "1".  However, what
people consider the "right" default denominator depends on how you
transcribe a specific piece old music (e.g. if you transcribe a brevis
into a whole or half note).  Hence, it may turn out to be a bad thing to
assume "1" as denominator; for another piece of music, "2" or "4" may be
the correct default.

Be careful with the meaning of \time requests: I think it is a bad idea
to mix musical (i.e. with regard to the contents) information (which is
afterwards needed e.g. for bar checks, etc.) with purely notational (i.e.
representational) information (such as engraving style).  Instead, I would
like to propose putting purely notational information into TimeSignature
properties.  This is convenient especially from an editorial point of
view: you can e.g. set up these properties once for a complete edition, or
have a set of editions (e.g. when transcribing music).  In other words,
this way you will be able to separate musical contents from notational
constraints.  BTW., SGML and XML were designed with similar goals in mind
(i.e. seperating contents from representation); cascading style sheets
(CSS) for HTML/XML are a typical example.

BTW. (Han-Wen/Jan?), I did not yet look into the new multiple-times
feature of 1.7.x, but I strongly hope it also follows this spirit (I will
anyway have to check that it will not clash with mensuration, which I plan
to implement maybe in 1.9.x).

Greetings,
Juergen




reply via email to

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