lilypond-user
[Top][All Lists]
Advanced

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

Re: horizontally centering denominator in compound time signatures


From: Reinhold Kainhofer
Subject: Re: horizontally centering denominator in compound time signatures
Date: Sun, 30 Nov 2008 17:14:48 +0100
User-agent: KMail/1.10.3 (Linux/2.6.27-9-generic; KDE/4.1.3; i686; ; )

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Sonntag, 30. November 2008 16:07:39 schrieb Graham Percival:
> On Sun, Nov 30, 2008 at 12:41:46AM +0100, Reinhold Kainhofer wrote:
> > Now, in my first step, I'm implementing the display of (1+2+3)/8
> > fractions. My only problem with this is that with the methods shown in
> > the LSR snippets the 8 is always left-aligned and not centered between
> > the 1+2+3. How can I do this?
>
> You're going to kick yourself for this... :)
>
> s/make-column-markup/make-center-column-markup

Ah, thanks. I was grepping for make, column and markup in the lilypond 
sources, but since the make-*-markup commands are generated on the fly, of 
course I didn't find it...

> Now that said, this causes the 1+2+3 to collide with the clef.
> I'm not certain why, 

It seems that make-center*-markup only sets the correct extents to the right, 
but not to the left (which is apparently set to 0...).

> but you can probably work around it by
> setting X-offset manually.

Actually, I can't, since this is 1) supposed to be a general solution to 
complex time signatures and 2) supposed to be used by musicxml2ly, too.

> Incidentally, I still prefer my version:
> http://lists.gnu.org/archive/html/lilypond-user/2008-10/msg00681.html
> since the markup is constructed in close-to-normal lilypond markup
> language.  It would be fairly simply to change that function to
> use a centered column and no parentheses.

Actually, my solution goes a bit further: I also try to implement multiple 
fractions like (2+3)/8 + 2/4 + (5+1)/8

> Incidentally*2, I think there's enough interest in compound time
> signatures that we should add it to the main lilypond.  There's a
> lot of different styles (just compare yours with mine!), 

The only compound time signatures that I have seen so far are either of the 
form
(2+3)/8, 2/8+3/8 or 2/8 3/8
I've never seen your style in printed scores...

My solution allows the first two by giving different input:
\compoundMeter #'(2 3 8)
and 
\compoundMeter #'((2 8) (3 8))

The third style (which is however maily used for parts with alternating time 
signatures, so some measues are 2/8 then some in 3/8, then 2/8 again etc. I 
don't think this can be easily implemented in lilypond anyway) might be 
implemented by a flag to not insert the vcentered "+" markup.

Here is the current version of my \compoundMeter function, which displays 
general compound time signatures (modulo the broken make-center-column-markup) 
and automatically sets the correct measure length:
http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf
http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.ly

Auto-beaming and beatLength are not yet properly set, the first because I have 
not yet starting implemented it and the latter because I don't know what the 
base unit should be for compound signatures like 3/4 + 7/8. Maybe some of you 
has an idea what the correct beatLength should be in that case? Should it 
simply be the largest denominator (assuming all are a power of 2; otherwise 
the lcm?)

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJMrv5TqjEwhXvPN0RAr2BAJ9JgpnnRTSudIhNbN30g7640yOD2QCfQqGv
69oTHXxrZGx+ecHNArt1RY8=
=VX4A
-----END PGP SIGNATURE-----




reply via email to

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