Re: [patch] first-clef property
Hmmh, maybe I do not understand correctly, but wouldn't it be possible to
get equivalent behavior with tagged music? I mean, put both \clef
commands ('\clef "soprano"' and '\clef "treble"') into the code, put
different tags on each of them, and then "turn" them "on/off" or switch
between the two editions by filtering the music for the proper tags.
Anyway, wouldn't it be nicer to have some kind of scheme macro that
expands to code that prints an incipit? Your "first clef" could then be
just part of the incipit that the macro creates. And maybe the clef's
name either could passed as argument to the scheme macro. Or,
alternatively, you set an, say, "original-clef" property that the macro
recognizes and accordingly acts upon.
Greetings,
Juergen
On Fri, 1 Feb 2008, Nicolas Sceaux wrote:
Hi,
When typesetting ancient music, one may want to produce two editions:
eventually one with original clefs, as found in the manuscripts, and an
other one with new fashioned clefs. It is also custom in the later case
to print first the ancient clef (which bears some extra meaning, for
instance which particular instrument should play that part), then the
modern one, at the beginning of a piece.
I use a customized version of the \clef command, which allows specifying
two clefs, eg. \clef "soprano/treble". If some option is set, it behaves
like \clef "soprano", otherwise it behaves like \clef "treble", except
at the beginning of the first line, where a little soprano clef is
printed before the treble clef. The first-clef property makes it
possible to detect when it is the beginning of the piece.
The attached patch adds this first-clef grob property. May I apply it?
I understand that it may not be preferable to add code that presumably
would be useful to a single person... but this patch is very tiny :-)
And I've seen some posts showing interest for this kind of feature.
Nicolas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] first-clef property
Hi, When typesetting ancient music, one may want to produce two editions: eventually one with original clefs, as found in the manuscripts, and an other one with new fashioned clefs. It is also custom in the later case to print first the ancient clef (which bears some extra meaning, for instance which particular instrument should play that part), then the modern one, at the beginning of a piece. I use a customized version of the \clef command, which allows specifying two clefs, eg. \clef "soprano/treble". If some option is set, it behaves like \clef "soprano", otherwise it behaves like \clef "treble", except at the beginning of the first line, where a little soprano clef is printed before the treble clef. The first-clef property makes it possible to detect when it is the beginning of the piece. The attached patch adds this first-clef grob property. May I apply it? I understand that it may not be preferable to add code that presumably would be useful to a single person... but this patch is very tiny :-) And I've seen some posts showing interest for this kind of feature. Nicolas first-clef.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam thickness
2008/2/1, Trevor Daniels <[EMAIL PROTECTED]>: > If we are to propose a change it might be better to change > the property name for the thickness of all beams to be > "beam-thickness", which has the descriptive string, "Beam > thickness, measured in staff-space units", and a default > value of 0.48. It would seem ideal! However, it is a > property of the stem-tremolo-interface, not the > beam-interface, so the change is not likely to be easy. Or > is it? This is a good idea. The interfaces merely serve to group and limit the properties, so you don't get all properties listed on all grobs; it should not be a problem. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Beam thickness
Mats Bengtsson wrote on 01 February 2008 16:07 (to -user) > > Trevor Daniels wrote: > > > > By default the beam thickness is set to 0.48 of a > > staff-space (Note the IR is wrong is this respect; > > it says in units of line-thickness, which is normally > > right, but not for beams). So to move a beam with > > its top edge aligned to a position with its centre > > aligned you'll need to move it an extra 0.24. > > > > > Right! This is a property name that's used on > many different layout objects > and is included in several different interfaces. > The problem with the > documentation is the old usual one that there's > only one documentation > string per property name, no matter how many > different uses there are > for the same property name. Strangely enough, > there's also a property > called beam-thickness, that's only used for > StemTremolo objects. > I cannot see why the property name "thickness" > could not be used in that > application as well. On the other hand, it may be > less obvious what > "thickness" > refers to for a stem tremolo, compared to other > objects like stems or > beams or ... > Still, for consistency, I'd propose to use the > property name "thickness" > also > for stem tremolos. > If we are to propose a change it might be better to change the property name for the thickness of all beams to be "beam-thickness", which has the descriptive string, "Beam thickness, measured in staff-space units", and a default value of 0.48. It would seem ideal! However, it is a property of the stem-tremolo-interface, not the beam-interface, so the change is not likely to be easy. Or is it? Trevor D ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
