lilypond-devel
[Top][All Lists]
Advanced

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

Re: move .ly code out of .py


From: Reinhold Kainhofer
Subject: Re: move .ly code out of .py
Date: Thu, 18 Dec 2008 16:14:32 +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 Donnerstag, 18. Dezember 2008 schrieb Han-Wen Nienhuys:
> Can you put your timesig code into a .scm (or .ly) file ?  

yes and no (i.e. "yes" it should be added to lilypond directly, but "no" not 
in its current form). Currently it's unfinished (auto-beaming missing) and not 
really integrated into lilypond. That's why i asked a week ago what would be 
the best way to add it directly to lilypond:

Am Donnerstag, 11. Dezember 2008 schrieb Reinhold Kainhofer:
> Am Sonntag, 30. November 2008 16:07:39 schrieb Graham Percival:
> > Incidentally*2, I think there's enough interest in compound time
> > signatures that we should add it to the main lilypond.
>
> I have now found a nice workaround for my problems with the center-column-
> markup: Simply wrap a left-column-markup around to offset the shifted
> reference point...
>
> Here is my current version, where only the proper auto-beaming settings are
> missing. What do you think is the best way to add something like this
> directly to lilypond?
> http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf
> http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.ly
>
> Cheers,
> Reinhold


The issues I see are:
1) the engraver currently only keeps the whole fraction for the measure 
length, but not the exact time signature.
2) These methods use a text markup to print the time sig, while the default 
time sigs use their own printing function
3) The engraver currently stores the time sig as a two-number list (that's an 
implicit assumption used in several places in the code), which cannot directly 
be changed to a more complex structure.

Ideally, we would keep a fraction determining the exact measure length (needed 
e.g. for midi etc.), plus an optional full time signature (e.g. ((1 2 3 4 8) 
(2 4) (1 16)) for (1+2+3+4)/8 + 2/4 + 1/16). the formatting function would 
work on the full time signature (extending the current formatting), while midi 
would use the measure length fraction. Old code would work just as usual, 
since (3 4) still means a time signature 3/4. It's only that instead of the 
two-element list of numbers we allow list elements and more numerator numbers.

Also, the parser doesn't need to be changed, \time 3/4 is still allowed for 
simple time signatures, while \compoundMeter #'((1 2 3 4 8) (2 4) (1 16)) 
allows to set complex time signatures (or should we call it \complexMeter?).
Of course, \compoundMeter #'(3 4) can also be used instead of time 3/4.

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)

iD8DBQFJSmjZTqjEwhXvPN0RAsDcAKCoqaPIbC4Mobmqn/5J4rlt76LltwCdFOvL
pKWP3dVqa+eDI5astESnWpM=
=T45Y
-----END PGP SIGNATURE-----




reply via email to

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