Re: [patch] first-clef property
Nicolas Sceaux schrieb: Le 7 févr. 08 à 02:49, Han-Wen Nienhuys a écrit : Since the incipit is a completely different piece of notation (eg. whose spacing and beat counting should not influence the main music), this should be implemented similiar to the hack with a \score inside the instrument name. I think the best approach is to figure out what the problems with that approach are, and try to solve those. Indeed, I've been convinced by Juergen, so that's what I'm trying to do. I have a question. So far, I've written an incipit engraver, which behaves just like the instrument name engraver, except for the first system where the incipit may be printed with the instrument name. Should there be an incipit engraver, specializing the instrument engraver (or a common base class), or should I add this feature right into the instrument name engraver? I'm asking because the impact on the user is different: - in the former case, one would have to use a function (eg \incipit) to define the incipit + remove the instrument name engraver + add the incipit engraver; Wouldn't it be possible to define an independend engraver that goes between instrument name engraver and staff? This feels somewhat more like a "real" solution instead of just a hack. I know I mentioned this already in another thread earlier and I really have no idea about the possibilities how to implement that, but if the whole lilypond idea is about logical input, it feels only like a temporary solution to mingle two different things. Greetings Till - in the later case, one just have to define the incipit with the dedicated music function. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Le 7 févr. 08 à 02:49, Han-Wen Nienhuys a écrit : Since the incipit is a completely different piece of notation (eg. whose spacing and beat counting should not influence the main music), this should be implemented similiar to the hack with a \score inside the instrument name. I think the best approach is to figure out what the problems with that approach are, and try to solve those. Indeed, I've been convinced by Juergen, so that's what I'm trying to do. I have a question. So far, I've written an incipit engraver, which behaves just like the instrument name engraver, except for the first system where the incipit may be printed with the instrument name. Should there be an incipit engraver, specializing the instrument engraver (or a common base class), or should I add this feature right into the instrument name engraver? I'm asking because the impact on the user is different: - in the former case, one would have to use a function (eg \incipit) to define the incipit + remove the instrument name engraver + add the incipit engraver; - in the later case, one just have to define the incipit with the dedicated music function. nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
2008/2/2, Juergen Reuter <[EMAIL PROTECTED]>: > 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. Hi, I concur with Juergen here. Since the incipit is a completely different piece of notation (eg. whose spacing and beat counting should not influence the main music), this should be implemented similiar to the hack with a \score inside the instrument name. I think the best approach is to figure out what the problems with that approach are, and try to solve those. -- 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
Re: [patch] first-clef property
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). Sorry for the off-topic (no opinions about that), but for people who are intersting , i made for me a \elseTag command a few months ago. I use it now a lot. http://lsr.dsi.unimi.it/LSR/Item?u=1&id=381 Gilles ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] first-clef property
Am Sonntag, 3. Februar 2008 schrieb Juergen Reuter: > 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. Exactly. The only difference is that the system start bracket should not be in front of the incipit, but between the incipit and the real start of the system, and that the incipit is often written in smaller notes... 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/ ___ 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:
...
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: [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
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
