lilypond-devel
[Top][All Lists]
Advanced

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

Re: Request for comments: Redesign of TimeSignature


From: Laura Conrad
Subject: Re: Request for comments: Redesign of TimeSignature
Date: 23 May 2002 09:12:52 -0400
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence)

>>>>> "Han-Wen" == Han-Wen  <address@hidden> writes:


    Han-Wen> One thing that is not clear to me, is given the changing 
proportions
    Han-Wen> of notes in mensural notation, what the unit for these notes should
    Han-Wen> be. For example, we could take the Longa as the unit, then all 
shorter
    Han-Wen> notes should be multiplied by some fraction depending on the time
    Han-Wen> signature.

That's an interesting idea; in really early music there is a Maxima,
which our binary minds tend to take as 2 longas, but maybe when it's
colored it's really 3 longas?  (Most of what I know about is after
1550, where the maxima isn't used, and even the longa tends to be used
where we'd use a fermata, and coloration is used inconsistently if at
all.)

If anyone wants to implement maxima, I think it looks like a longa
with the notehead about twice as wide.

    >> Yes, unfortunately, they often change time signatures during the peace
    >> (and some even have different time signatures on different staves), as
    >> far as I know from the examples that I have seen so far; but maybe they
    >> are not representative.

I don't know what representative means in this context, but it's
certainly pretty common.

    Han-Wen> Ah, this is interesting. If different time sigs (implying different
    Han-Wen> ratios for the notes) are used, how are polyphonic voices 
synchronized?

The short answer is that often they aren't.  A more serious answer is
that the performers know the ratios, and the people singing in a
triple rhythm are feeling the same beat as the people singing in the
duple rhythm.  So modern editions usually put one part in triplets
(which may not be explicitly written).  This is one of the tedious
things to write in lilypond as it currently exists.

Speaking of which, if you are going to support mensural polyphony, one
thing that should change is the way barlines propagate between staves.
The fact that there's a barline in the top staff shouldn't necessarily
imply a barline in the others.  This would also make proofreading
easier.  Currently, when I get the barlines wrong on one staff out of
4, it's a pain to find out which because the correct barline has
propagated to the staff where it isn't there, and the wrong barline
propagates to the other staves.

    >> \time [2+2+3]/8
    >> 
    >> By the way, the "[" might clash with beams, as in:
    >> 
    >> \notes { \time 3 [f4 a c] }

    Han-Wen> \time 3 is not valid syntax. I propose that we keep it that way. 
If it
    Han-Wen> [ ] is in between \time and / , then there will be no clash.

This is a problem for transcribing music where the composer wrote "3"
as the time signature, though.  The transcriber soesn't always know
what unit the composer was thinking in 3 of.  And I always have trouble
remembering which denominator will give me a circle.

    Han-Wen> (and if you like, you could add support for

    Han-Wen>   6  (3)
    Han-Wen>   8  (4) 

    Han-Wen> what Laura seems to want.)


Do I?  What I want is written:

        C| 3/2

Or maybe:

        C 3/4

I suppose a real implementation would allow a barcheck that occurs after
either 2 or three quarter notes to succeed.  But since I don't usually
enter the barlines, I don't care about the barchecks; I just want my
printout to look ok.  

If nobody answered that question, I was going to spend some time
experimenting with entering an invisible note between the first and
second time signatures.

-- 
Laura (mailto:address@hidden , http://www.laymusic.org/ )
(617) 661-8097  fax: (801) 365-6574 
233 Broadway, Cambridge, MA 02139
(If I haven't invited you to my party on June 2, I'm sure it's an oversight.)



reply via email to

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