Re: Where are the docs?
Cameron Horsburgh writes: The 2.9 manual seems to have disappeared off the web--the link just points back to the doc index. If somebody's borrowed it, could you please put it back? It works for me. What link is broken? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \espressivo direction
Graham Percival writes:
Since \espressivo is a hack of cresc/decr, it should be below the
staff by default (currently it is not). How would I change
scm/script.scm to fix this?
(espressivo .
((avoid-slur . around)
(quantize-position . #t)
Somewhere in the 2.7 cycle, follow-into-staff has been replaced by
quantize-position. So, I guess that removing that will fix it.
Would I use (direction . -1) ?
Possibly.
Many entries contain a
(side-relative-direction) and a (direction); how do those interact?
The doc says
(side-relative-direction ,ly:dir?
Multiply direction of
@code{direction-source} with this to get the direction of this
object.)
Jan.
--
Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
David Feuer writes: I would greatly appreciate some help changing the code in lookup.cc to match my new drawing procedures. I'm still not sure whether the polygon drawer should take a list of vertices or an array of vertices. It seems that you changed the polygon interface from (prefixing type name to parameter for clarity) (define (polygon list-of-points blot-diameter filled?) to (define (polygon vector-of-points blot-radius) What is the reason to change the interface? I appreciate that radius makes more sense than diameter, but blot-diameter is used throughout lily. So why not keep the scm interface as it was, ie, change your polygon code to (define (polygon list-of-points blot-diameter) (let ((vector-of-points (list-vector)) (blot-radius (/ blot-diameter 2))) ... Btw, what about the the filled? parameter, is it never used? Btw2, why the defines ... (define n (vector-length points)) (define startpoint (v* 0.5 (v+ (vector-ref points (- n 1)) (vector-ref points 0 (entity 'path ... instead of let* ? (let* ((n (vector-length vector-of-points)) (start-point (v* 0.5 (v+ (vector-ref vector-of-points (- n 1)) (vector-ref vector-of-points 0) Could you send a next version as a unified diff please? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request: Hairpin.hairpinFullLength
On Tue, 11 Apr 2006, Graham Percival wrote: (this'll probably get lost while HWN is away, but anyway...) From the docs, A hairpin starts at the left edge of the beginning note and ends on the right edge of the ending note. tupletFullLength (boolean) If set, the tuplet is printed up to the start of the next note. Could we have a feature, similar to tupletFullLength, which places the end of a hairpin just before the start of the next note? And a similar thing for TextSpanner would probably fix the \episem, which broke at some time during the 2.7 series (see manual Sect. 7.7.7). It seems that, for TextSpanners, the FullLength behavior is now always true, while it must be false for the \episem. Or do I miss something? Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request: Hairpin.hairpinFullLength
And a similar thing for TextSpanner would probably fix the \episem, which broke at some time during the 2.7 series (see manual Sect. 7.7.7). I think \episem needs more work anyhow. It should be going in the next staff space available above the notes, not over the staff. I monkeyed around with manual placement of a -_ articulation, but wasn't happy with that, either. Geoff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc updates from NEWS files
Cameron Horsburgh wrote: Howdy folks, I've been going through the NEWS files to see if there's anything that still needs documenting. I've come up with a couple of draft lists and discussed them with Graham Percival, and I now have a list of things we agree need to go in. We've already documented some but we don't have the time or the knowledge to do all of them. Okay folks, to make things a bit easier on everyone I've put the list of updates needed up on my website. You can find it at http://web.netcall.com.au/horsburgh/DocUpdate.html Merry writing, everyone! Cameron ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Where are the docs?
Jan Nieuwenhuizen wrote: Cameron Horsburgh writes: The 2.9 manual seems to have disappeared off the web--the link just points back to the doc index. If somebody's borrowed it, could you please put it back? It works for me. What link is broken? Jan. The link shows up as 'User manual' and points to http://lilypond.org/doc/v2.9/Documentation/user/lilypond/index.html It still isn't working for my Firefox, but other browsers seem to work. You can safely ignore me now. Cameron ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
\encoding
Hi folks, The 2.4 series news file tells me that The encoding of a file can be switched with \encoding. The strings for markup texts are translated automatically. Is this still relevant? Cam ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request: Hairpin.hairpinFullLength
Quoting Graham Percival [EMAIL PROTECTED]: (this'll probably get lost while HWN is away, but anyway...) From the docs, A hairpin starts at the left edge of the beginning note and ends on the right edge of the ending note. tupletFullLength (boolean) If set, the tuplet is printed up to the start of the next note. Could we have a feature, similar to tupletFullLength, which places the end of a hairpin just before the start of the next note? Silly question: what's the difference between up to and just before, i.e. how much before? This is at least partially related to the bound-padding property, though it affects both ends of the hairpin. Maybe the solution is to have a separate such property for each end or let the value of the bound-padding property be a pair of values. /Mats /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature request: Hairpin.hairpinFullLength
On 4/12/06, Mats Bengtsson [EMAIL PROTECTED] wrote: Quoting Graham Percival [EMAIL PROTECTED]: (this'll probably get lost while HWN is away, but anyway...) From the docs, A hairpin starts at the left edge of the beginning note and ends on the right edge of the ending note. tupletFullLength (boolean) If set, the tuplet is printed up to the start of the next note. Could we have a feature, similar to tupletFullLength, which places the end of a hairpin just before the start of the next note? Silly question: what's the difference between up to and just before, i.e. how much before? This is at least partially related to the bound-padding property, though it affects both ends of the hairpin. Maybe the solution is to have a separate such property for each end or let the value of the bound-padding property be a pair of values. Agreed that that final distance just before needs to be override-able. Using tuplet brackets as a guide, it seems like keeping that last bit of distance constant throughout a score is the goal ... but when you get backed into a corner it's really nice to be able to shave off a bit of the distance. -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Old-style F clef?
On 4/12/06, Geoff Horton [EMAIL PROTECTED] wrote: Do you mean this one: http://upload.wikimedia.org/wikipedia/en/7/79/Oldbassclef.png ? Yes. If I create one in Metafont, would it be hard to add to the progam? I'm not a LilyPond expert, so I'll pass this on to the list, but I would expect it to be fairly simple to change the clef font. A question of my own: can users build new fonts from old within LilyPond? It'd be cool to let users create, say, a clef font based on the usual clef font but substituting their preferred version of the F clef from another font. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
David Feuer writes: I didn't even think about that. I just wrote the functions and gave them the interface that made the most sense to me at the time. I'll change it in the next version. Ok. Btw, what about the the filled? parameter, is it never used? As far as I can tell from grepping the source, polygons are only drawn filled. Ok, I'll add an assert in the c++ code and remove the parameter to match your next polygon scheme code. I would suggest that the current code be put on a shelf somewhere in case someone needs it in the future, Just remove it; shelve is what cvs's Attic is for ;-) instead of let* ? Just a matter of style. Internal defines are equivalent to letrec (it looks like they'll be equivalent to letrec* in R6RS), which is technically unnecessary, but I thought the code was more readable that way. If you'd prefer let*, I can change to that. Yes, please do. Nicholas? Could you send a next version as a unified diff please? Sure. Thanks. Please keep discussions on the list (cc'd), thanks. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Old-style F clef?
David Feuer writes: On 4/12/06, Geoff Horton [EMAIL PROTECTED] wrote: Do you mean this one: http://upload.wikimedia.org/wikipedia/en/7/79/Oldbassclef.png ? Yes. If I create one in Metafont, would it be hard to add to the progam? That would be easy, but it would have to look very nice, both the code and glyph, for it to be included. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \encoding
Cameron Horsburgh wrote: Hi folks, The 2.4 series news file tells me that The encoding of a file can be switched with \encoding. The strings for markup texts are translated automatically. Is this still relevant? Cam With the introduction of UTF-8 support in the 2.5 series, this became obsolete. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Old-style F clef?
That would be easy, but it would have to look very nice, both the code and glyph, for it to be included. OK, I'll see what I can do. I fully appreciate the need to keep output looking good! Geoff ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: Ok, I'll add an assert in the c++ code and remove the parameter to match your next polygon scheme code. I'm not sure where you'll add it. The code in lookup.cc always calls the scheme function with filled?=#t I would suggest that the current code be put on a shelf somewhere in case someone needs it in the future, Just remove it; shelve is what cvs's Attic is for ;-) Okay. way. If you'd prefer let*, I can change to that. Yes, please do. Nicholas? Okay. Please keep discussions on the list (cc'd), thanks. Oops! Didn't mean to take that off list. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
David Feuer writes: I'm not sure where you'll add it. The code in lookup.cc always calls the scheme function with filled?=#t Indeed; no need for an assert. But in that case ... found it define-markup-command.scm: (define-markup-command (triangle layout props filled) (boolean?) A triangle, filled or not we use it to draw `white' triangles for chords... Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: Indeed; no need for an assert. But in that case ... found it define-markup-command.scm: (define-markup-command (triangle layout props filled) (boolean?) A triangle, filled or not we use it to draw `white' triangles for chords... Yuck. This makes a great argument for my proposal to get the arbitrary Scheme code out of stencils (so there's only -one- place in the source that produces output code). The easiest way to keep this working the same as it does now is to name my new functions filled-polygon and retain the old (really simple) polygon drawers in the backends. The polygon procedure in lookup.cc can still go away. I'm a bit curious, though, why the triangles are done that way, which lets the blot exceed the normal bounds. If that behavior is a bug, then something else will need to be done. One option might be to make triangle-shrinking code, which would be a bit icky, but not as icky as general polygon-shrinking code, because triangles have some pretty nice geometric properties. I have another couple ideas, but I'm still working those out. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
Hi, maybe I should also comment on this topic, since I originally contributed the whole polygon stuff in order to implement clusters, and thus still feel (very) little responsible for it. ;-) As for the triangle, yes, I also think it _is_ abuse to use the blot-diameter in order to control the line thickness of an unfilled polygon. In fact, an unfilled polygon should ideally have two separate parameters for controlling line thickness and blot-diameter. However, implementing such a drawing routine for unfilled polygons appears quite complicated to me. At least, you could re-use the polygon shrinking algorithm in lookup.cc in order to calculate the edges of the inner path of the polygon outline. However, the restrictions mentioned in lookup.cc would unfortunately also apply. BTW, I just noticed, that in define-markup-command.scm, markup commands draw-cricle and beam have an explicit thickness parameter, while all other markup commands retrieve the thickness value from the props parameter. Maybe this could be made more consistent. Greetings, Juergen On Wed, 12 Apr 2006, David Feuer wrote: On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: Indeed; no need for an assert. But in that case ... found it define-markup-command.scm: (define-markup-command (triangle layout props filled) (boolean?) A triangle, filled or not we use it to draw `white' triangles for chords... Yuck. This makes a great argument for my proposal to get the arbitrary Scheme code out of stencils (so there's only -one- place in the source that produces output code). The easiest way to keep this working the same as it does now is to name my new functions filled-polygon and retain the old (really simple) polygon drawers in the backends. The polygon procedure in lookup.cc can still go away. I'm a bit curious, though, why the triangles are done that way, which lets the blot exceed the normal bounds. If that behavior is a bug, then something else will need to be done. One option might be to make triangle-shrinking code, which would be a bit icky, but not as icky as general polygon-shrinking code, because triangles have some pretty nice geometric properties. I have another couple ideas, but I'm still working those out. David ___ 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: State of the docs, April 2006
Graham Percival [EMAIL PROTECTED] writes: SCHEME / MUSIC EXPRESSIONS EXPLAINED Lilypond knowledge required: lots Estimated time: 5 hours? 10? Many people have asked for clearer explanations of music expressions and scheme. I'm not as busy as Jan (just a day job, a house and a kid, no twins:), but have very little spare time. I can work on that with someone that have better writing skills than myself, that is I can explain the methodology to follow to inspect music expressions, build new ones, define music functions. (I've writen some time ago an article on that topic: http://nicolas.sceaux.free.fr/prelude/prelude.html) nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
David Feuer writes: The easiest way to keep this working the same as it does now is to name my new functions filled-polygon and retain the old (really simple) polygon drawers in the backends. Hmm. I'd much rather just have a simple dedicated white-triangle function, if we must. The polygon procedure in lookup.cc can still go away. Ok. I'm a bit curious, though, why the triangles are done that way, which lets the blot exceed the normal bounds. If that behavior is a bug, Yes, I guess so. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some code for polygons
On 4/12/06, Jan Nieuwenhuizen [EMAIL PROTECTED] wrote: David Feuer writes: The easiest way to keep this working the same as it does now is to name my new functions filled-polygon and retain the old (really simple) polygon drawers in the backends. Hmm. I'd much rather just have a simple dedicated white-triangle function, if we must. Is it really necessary to adjust the line thickness of the triangles, or can they be made into glyphs? David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \encoding
Daniel Johnson wrote: Cameron Horsburgh wrote: Hi folks, The 2.4 series news file tells me that The encoding of a file can be switched with \encoding. The strings for markup texts are translated automatically. Is this still relevant? Cam With the introduction of UTF-8 support in the 2.5 series, this became obsolete. That's what I thought. Ta. Cam ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2D vector code
My SVG polygon code uses 2D vectors ( (x,y) pairs ) a good bit. Does LilyPond already have basic functions (addition, subtraction, multiplication by a scalar, dot product, cross product, ...) for vectors I can use? If not, I think I should probably write them as a separate module. If I write them as a separate module, should vectors be pairs (convenient), or should they be SRFI 9 records (pretty)? David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2D vector code
I should have mentioned that I don't know yet how C++ code interacts with SRFI 9 records, if that's feasible at all. I'm sure C++ can interact with native Guile records, but I'm not sure I really want to deal with those. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: State of the docs, April 2006
On Tue, 11 Apr 2006, Graham Percival wrote:
...
TEMPLATES
Lilypond knowledge required: moderate
Estimated time: 5 hours
Do all the templates in chapter 3 work? I know that the Jazz ensemble one
is very old, and is generally icky. If nobody updates it, I think we should
just delete it. I don't know what the status is on the other templates. In
addition, all the templates should follow the same general style.
Attached is a diff that makes the template working again, with a minimal
set of changes. Still, the general style of the template is rather
peculiar, such that the comments immediately before the template still
hold. I do not know if this patch is of any value for user reading the
manual, but at least it fixes the appearance of the example.
Greetings,
JuergenIndex: examples.itely
===
RCS file: /cvsroot/lilypond/lilypond/Documentation/user/examples.itely,v
retrieving revision 1.60
diff -u -r1.60 examples.itely
--- examples.itely 28 Mar 2006 20:47:21 - 1.60
+++ examples.itely 12 Apr 2006 21:52:52 -
@@ -1033,8 +1033,12 @@
composer = Me
meter = moderato
piece = Swing
- tagline = LilyPond example file by Amelie Zapf,
- Berlin 07/07/2003
+ tagline = \markup {
+\column {
+ LilyPond example file by Amelie Zapf,
+ Berlin 07/07/2003
+}
+ }
texidoc = Jazz tune for combo
(horns, guitar, piano, bass, drums).
}
@@ -1082,7 +1086,7 @@
\global
\set Staff.instrument = #Trumpet
\clef treble
- \new Staff
+
\trpt
}
@@ -1099,7 +1103,7 @@
\global
\set Staff.instrument = #Alto Sax
\clef treble
- \new Staff
+
\alto
}
@@ -1116,7 +1120,7 @@
\global
\set Staff.instrument = #Bari Sax
\clef treble
- \new Staff
+
\bari
}
@@ -1133,7 +1137,7 @@
\global
\set Staff.instrument = #Trombone
\clef bass
- \new Staff
+
\tbone
}
@@ -1153,7 +1157,7 @@
\global
\set Staff.instrument = #Guitar
\clef treble
- \new Staff
+
\gtr
}
@@ -1185,7 +1189,7 @@
\clef treble
\global
\set Staff.midiInstrument = acoustic grand
- \new Staff
+
\new Voice = one \rhUpper
\new Voice = two \rhLower
@@ -1194,14 +1198,14 @@
\clef bass
\global
\set Staff.midiInstrument = acoustic grand
- \new Staff
+
\new Voice = one \lhUpper
\new Voice = two \lhLower
}
piano = {
- \new PianoStaff
+
\set PianoStaff.instrument = #Piano
\new Staff = upper \PianoRH
\new Staff = lower \PianoLH
@@ -1217,7 +1221,7 @@
\global
\set Staff.instrument = #Bass
\clef bass
- \new Staff
+
\Bass
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docu Sect. 3.5.2
The introduction for the Gregorian transcription template currently says: This example demonstrates how to do modern transcriptions of Gregorian music. Gregorian music has no measure, no stems; it uses only half and quarter notes, and two types of barlines, a short one indicating a rest, and a second one indicating a breath mark. The template has been recently updated, such that the text is now somewhat outdated. I would like to propose a slightly modified text, maybe something like: This example demonstrates how to do modern transcription of Gregorian music. Gregorian music has no measure, no stems; it uses only half and quarter noteheads, and special marks, indicating rests of different length. Greetings, Juergen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Docu Sect. 7.7.10.2
Hi,
considering the recent misreading of lily's Gregorian chant capabilities
that could be seen on this list, I would like to propose a minor update
with clarifications to Sect. 7.7.10.2. See attachment.
Greetings,
JuergenIndex: Documentation/user/instrument-notation.itely
===
RCS file:
/cvsroot/lilypond/lilypond/Documentation/user/instrument-notation.itely,v
retrieving revision 1.80
diff -u -r1.80 instrument-notation.itely
--- Documentation/user/instrument-notation.itely5 Apr 2006 00:01:18
- 1.80
+++ Documentation/user/instrument-notation.itely12 Apr 2006 23:37:30
-
@@ -3881,6 +3881,20 @@
@code{\[ \stropha b \stropha b \stropha a \]}
@end multitable
+The ligatures listed above mainly serve as a limited, but still
+representative pool of Gregorian ligature examples. Virtually, within
+the ligature delimiters @code{\[} and @code{\]}, any number of heads
+may be accumulated to form a single ligature, and head prefixes like
[EMAIL PROTECTED], @code{\flexa}, @code{\virga}, @code{\inclinatum},
+etc. may be mixed in as desired. The use of the set of rules that
+underlies the construction of the ligatures in the above table is
+accordingly extrapolated. This way, infinitely many different
+ligatures can be created.
+
[EMAIL PROTECTED] TODO: create a regression or tips tricks example document
with
[EMAIL PROTECTED] even more Gregorian ligatures, and add a link to this document
[EMAIL PROTECTED] here.
+
@refcommands
The following head prefixes are supported
@@ -3902,7 +3916,11 @@
@cindex @code{\quilisma}
@code{\quilisma},
@cindex @code{\deminutum}
[EMAIL PROTECTED]
[EMAIL PROTECTED],
[EMAIL PROTECTED] @code{\cavum}
[EMAIL PROTECTED],
[EMAIL PROTECTED] @code{\linea}
[EMAIL PROTECTED]
Head prefixes can be accumulated, though restrictions apply. For
example, either @code{\descendens} or @code{\ascendens} can be applied
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
