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
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=1id=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
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
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
-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
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
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 :-) inline: incipit.tiff 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
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
[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
