Re: [patch] first-clef property
On Sat, 2 Feb 2008, Nicolas Sceaux wrote: ... I have worked today on a draft, simple incipit engraver, with clef, key signature and time signature. Might someone comment on it? I have no experience with that part of the code. If something can be made more eleguant, please speak :-) Thanks a lot! To me, your code looks fine, except for the condition + if (clef_) +clef_ = key_signature_ = time_signature_ = 0; which probably should be something like: + if (clef_ || key_signature_ || time_signature_) +clef_ = key_signature_ = time_signature_ = 0; Or maybe completely remove the condition. However, I see a very important feature missing in this approach: An incipit should (at least in my view) be thought of as the beginning of a piece written in notation that comes close to the autograph or first publishing. That is, the incipit actually starts the music. Then, at some point (e.g. after the clef or after the first note of each voice or after the first few notes), the music is reset to its start, the notation switches to modern style, and printing starts again, this time from the very beginning to the very end. In particular, as Laura points out, many people want to include one or more notes in the incipit. More generally, virtually any music expression could appear in an incipit -- it's just printed in an old-fashioned style or otherwise coming much closer to the original. Thus, the ideal behavior of an incipt engraver would be to ordinary start printing the piece, using (for example) a mensural context and the info from IncipitClef, IncipitSignature, and IncipitTimeSignature. Then, when the InciptEngraver has done its work, the music should rewind back to the very beginning, and ordinary type setting should start. A couple of weeks ago, I think I already posted the idea of having a scheme function, say "\makeIncipit { }", that takes all of the music as argument and creates from it another music expression with the incipit. You could then say something like "\makeIncipt { } " to create the incipit, followed by the actual music. However note, that currently it is not possible to implement such a scheme function for several technical details, such as the system start delimiter that would also have to be placed *after* the incipit. Maybe with some more changes at your incipit engraver, this engraver can be used to actually implement the "\makeIncipit" scheme function. This is what I thought of when I used the word "challenging". ;-) Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
> "Nicolas" == Nicolas Sceaux <[EMAIL PROTECTED]> writes: Nicolas> I have worked today on a draft, simple incipit engraver, with clef, Nicolas> key signature and time signature. Might someone comment on it? The incipits I use also have the first note. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (501) 641-5011 233 Broadway, Cambridge, MA 02139 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Reinhold Kainhofer: > Am Freitag, 1. Februar 2008 schrieb Nicolas Sceaux: > > 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 ... > Actually, we're already two ;-) > I'm transcribing some old pieces by Schubert, who wrote the vocal voices > using > soprano/alto/tenor clef, while modern typesetting practice uses only the > treble clef for these voices. Now, I want to make two editions, one with the > original clefs, the other with modern clefs (but the original clefs as > incipits). So, you see, I'm having exactly the same problem. ... There is two problems here, 1, should the clef look ancient or modern, e.g. { \clef "petrucci-f" } or { \clef "bass" } 2, should we exchange a C clef for a G clef For problem 1 one can look at what theese do \displayMusic { \clef "petrucci-f" c1 c } \displayMusic { \clef "bass" c1 c } (make-music 'SequentialMusic 'elements (list (make-music 'ContextSpeccedMusic 'context-type 'Staff 'element (make-music 'SequentialMusic 'elements (list (make-music 'PropertySet 'value "clefs.petrucci.f" 'symbol 'clefGlyph) (make-music 'EventChord ... (ly:make-pitch -1 0 0 (make-music 'EventChord ... (ly:make-pitch -1 0 0)) Where the difference is "clefs.petrucci.f" vs. "clefs.F". So an \ancientToModernClef should traverce the list and exchange ancient "clefs.xx" to a modern variant. === Problem two is similar \displayMusic { \clef "petrucci-c2" c1 c } \displayMusic { \clef "petrucci-c3" c1 c } gives this diff $ diff -u b.log b2 --- b.log 2008-02-02 20:46:38.888477652 +0100 +++ b2 2008-02-02 20:47:08.884108561 +0100 @@ -12,19 +12,19 @@ (list (make-music 'PropertySet 'value -"clefs.petrucci.c2" +"clefs.petrucci.c3" 'symbol 'clefGlyph) (make-music 'PropertySet 'value --2 +0 'symbol 'middleCPosition) (make-music 'PropertySet 'value --2 +0 'symbol 'clefPosition) (make-music and \displayMusic { \clef "petrucci-c2" c1 c } \displayMusic { \clef "petrucci-g" c1 c } this $ diff -u b.log b2 --- b.log 2008-02-02 20:48:23.373258918 +0100 +++ b2 2008-02-02 20:48:44.370200812 +0100 @@ -12,13 +12,13 @@ (list (make-music 'PropertySet 'value -"clefs.petrucci.c2" +"clefs.petrucci.g" 'symbol 'clefGlyph) (make-music 'PropertySet 'value --2 +-6 'symbol 'middleCPosition) (make-music To make a generic \changeClef one has to find the part between a-b below (a list), and exchange it for something else (make-music 'SequentialMusic 'elements (list (make-music 'ContextSpeccedMusic 'context-type 'Staff 'element (make-music 'SequentialMusic 'elements a (list (make-music 'PropertySet 'value "clefs.petrucci.g" 'symbol 'clefGlyph) (make-music 'PropertySet 'value -6 'symbol 'middleCPosition) (make-music 'PropertySet 'value -2 'symbol 'clefPosition) (make-music 'PropertySet 'value 0 'symbol 'clefOctavation b ... (ly:make-pitch -1 0 0)) = Or what do you think. /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Le 2 févr. 08 à 20:31, Juergen Reuter a écrit : Maybe creating an incipit engraver, reading new context properties, like incipitKeySignature, incipitTimeSignature, etc, and creating a grob of the same nature as the instrument name. Yes, this idea definitely sounds very reasonable! Still, implementing such an engraver may turn out challenging... I have worked today on a draft, simple incipit engraver, with clef, key signature and time signature. Might someone comment on it? I have no experience with that part of the code. If something can be made more eleguant, please speak :-) <> incipit.patch Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
On Sat, 2 Feb 2008, Nicolas Sceaux wrote: ... 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. As I understand it, incipits are hackingly achieved using the instrument name. This is just one possible approach. Template A.5.1 demonstrates a different approach. Apparently, both approaches have limitations/flaws. I want instrument names to be defined separately from incipit (they are not the same thing, there is no serious reason to bind them, beside purely technical ones): \new Staff << \global \set Staff . instrumentName = \markup { The instrument name } \clef "xyz" %% automagically set the incipit clef { ... the notes ... } How could you make the mix of the two? Ok, I think I understand the problem. Now, seeing the incipt examples, I realize that my patch is a hack too, for it would be nice to have also the time and key signatures, not only the ancient clef. Maybe creating an incipit engraver, reading new context properties, like incipitKeySignature, incipitTimeSignature, etc, and creating a grob of the same nature as the instrument name. Yes, this idea definitely sounds very reasonable! Still, implementing such an engraver may turn out challenging... Greetings, Juergen nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 1. Februar 2008 schrieb Nicolas Sceaux: > 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. > > 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... Actually, we're already two ;-) I'm transcribing some old pieces by Schubert, who wrote the vocal voices using soprano/alto/tenor clef, while modern typesetting practice uses only the treble clef for these voices. Now, I want to make two editions, one with the original clefs, the other with modern clefs (but the original clefs as incipits). So, you see, I'm having exactly the same problem. I thought about using tags, but that's really messy and prone to breaking (since there is no "else" part in the tag, so you can either remove one part or not remove it, but not have something else instead). Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], 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.6 (GNU/Linux) iD8DBQFHpJ7vTqjEwhXvPN0RAuewAJ0Y4f2IWjCo/wk5AZJFPB+bYy0+kQCfVgbQ 36Bl5xldpbnJxEtiHWMBzRQ= =ycK8 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Nicolas Sceaux: ... > \tag does not solve the first-clef detection problem, but the two > editions problem, about which the proposed patch is not about. > I know about \tag, ... I also find \tag messy and there is no "else" part either. > > 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. > > As I understand it, incipits are hackingly achieved using the > instrument name. I want instrument names to be defined separately > from incipit (they are not the same thing, there is no serious > reason to bind them, beside purely technical ones): > > \new Staff << >\global >\set Staff . instrumentName = \markup { The instrument name } >\clef "xyz" %% automagically set the incipit clef >{ ... the notes ... } > >> > > How could you make the mix of the two? > > Now, seeing the incipt examples, I realize that my patch is a hack > too, for it would be nice to have also the time and key signatures, > not only the ancient clef. For the time and key signatures you can have to varialbles like mensural = { \override Accidental #'style = #'mensural \override NoteHead #'style = #'petrucci \override Rest #'style = #'neomensural \override Staff.TimeSignature #'style = #'mensural \override Stem #'flag-style = #'mensural \override Stem #'thickness = #0.8 \set timing = ##f \set Staff.defaultBarType = "" #(set-accidental-style 'forget) } normal = { \override Accidental #'style = #'default \override NoteHead #'style = #'default \override Rest #'style = #'default \override TimeSignature #'style = #'default \override NoteHead #'font-size = #'0 \override Stem #'flag-style = #'default \override Stem #'thickness = #1.9 % default \override TimeSignature #'style = #'default #(set-accidental-style 'default) } and use them like \new Staff { \normal \relative c' { ... } } \new Staff { \mensural \relative c' { ... } } For the clefs I use %clefcs = { \clef "petrucci-c2" } %clefct = { \clef "petrucci-c4" } %clefcb = { \clef "petrucci-f" } clefcs = { \clef "treble" } clefct = { \clef "treble_8" } clefcb = { \clef "bass" } What I think would be useful is either a setting \override Clef = #'style = #'petrucci % e.g "alto" -> "petrucci-c3" \override Clef = #'style = #'modern % e.g "petrucci-c3" -> "alto" \override Clef = #'style = #'lazysinger % e.g "petrucci-c3" -> "treble" so I can include them in the variable above or a function like % always keep as close to source as possible aa = \relative c { \clef "petrucci-f" \time 2/2 c\breve d\longa ... } \makeThisMensural { \aa } % no change? \makeThisModern { \aa } % "petrucci-f" -> "bass", c\breve -> c1 ... \makeThisIncipit { \aa } % mensural but only first breve or semiminima > Maybe creating an incipit engraver, reading new context properties, > like incipitKeySignature, incipitTimeSignature, etc, and creating a In some instances it would be useful to be able to append \score's on the same line, somewhat like if you used { \startStaff s1 \stopStaff }. Regards, /Karl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: GDP: NR 1.1 Piano Templates
> David Fedoruk wrote 02 February 2008 05:30 (to -user) > The "Piano Centered Dynamics" template in > particular is overwhelming. > Perhaps separating the pedal performer out from > the rest would make > this template less overwhelming. > Piano-centered dynamics are very commonly required when writing piano music. This would be much simpler to achieve if the two Dynamics contexts created in the template were available by default. All that is required to achieve this is to add the two Dynamics contexts to engraver-init.ly and performer-init.ly respectively. The template then becomes very simple, and almost self-explanatory. This seems a trivial but very worth-while change. Trevor D ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Le 2 févr. 08 à 01:48, Juergen Reuter a écrit : 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. \tag does not solve the first-clef detection problem, but the two editions problem, about which the proposed patch is not about. I know about \tag, and also that in the end one have to use \removeFromTag or \keepWithTag. After years experimenting with that, I don't find it very practical when applied to clef, because of its verbosity. Less LilyPond instructions ==> more maintainable. And I have many thousands of LilyPond loc to maintain. 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. As I understand it, incipits are hackingly achieved using the instrument name. I want instrument names to be defined separately from incipit (they are not the same thing, there is no serious reason to bind them, beside purely technical ones): \new Staff << \global \set Staff . instrumentName = \markup { The instrument name } \clef "xyz" %% automagically set the incipit clef { ... the notes ... } >> How could you make the mix of the two? Now, seeing the incipt examples, I realize that my patch is a hack too, for it would be nice to have also the time and key signatures, not only the ancient clef. Maybe creating an incipit engraver, reading new context properties, like incipitKeySignature, incipitTimeSignature, etc, and creating a grob of the same nature as the instrument name. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel