Doc updates from NEWS
Cameron, you can delete 2.8 "Subproperties, like the details field of Slur and Tie may now be tuned with \override. [This obviously belongs in Section 9, but I don't understand it enough to say more!]" (I've documented that) Full list at http://web.netcall.com.au/horsburgh/DocUpdate.html Everybody else, do any of the below items need to be in the docs? If so, please write something for them, because I don't understand them. This is the last call; if nobody writes something for these soon, we'll remove them from the TODO list. (Actually, even if somebody _does_ write docs for them, they'll still be removed from the list. :) # Each grob property may also be a "grob closure." This means that it is possible to combine functions. # # Generic music functions may now also be used on articulations and chord elements # # String arguments for music functions may be specified without # marks. Now, \clef and \bar are also music functions. # # Calculation of extent and offset of grob is now controlled via the X-extent, Y-extent, X-offset and Y-offset properties, [I suspect this is documented, but I don't really understand it enough to tell for sure.] # # Each grob property can be a procedure. If this is the case, it is assumed to be a routine that calculates said property. This is a major internal cleanup, which also provides advanced tweakability for power users. [I don't even know what this means...!] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
bug database?
Han-Wen, is there any estimate on when the new bug database will be online? If it's going to be a long time off, I could start running my own bug tracker, just so that I have something to do with all the bug reports. We could figure out how to transfer that data to your bug tracker when it goes up. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting the height of a system.
Joe Neeman schreef: Looks good. small question: why is pure-relevant coming in from Scheme C++ seems more applicable? It's not a user serviceable part, is it? Just because the Y-XX-conversions and pure-Y-XX lists are in scheme, and I thought it was nicer not to make them public, but to provide public accessing functions instead. I can move it to C++, though, if you'd prefer. Now that I go back to look at it, I see that the lists are actually public. That's fixed now. It's not that important, but all the jumping back and forth between C++ and scheme makes things a bit difficult to understand. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic page breaks changed for 2.9.8?
Joe Neeman wrote:
On Thu, 2006-06-08 at 17:17 -0700, Paul Scott wrote:
A part produced with:
\book {
\score { }
\score { }
}
Using 2.9.8 seems to force a page break at the end of a movement
(\score) whether there is room for part of the next movement or not.
That is unless there is room for the next whole movement. This is very
neat but if there is not a way for a choice I think there should be.
2.8.4 does the more normal page breaking.
I can produce my example if necessary.
Please do. The following example works for me on 2.9 CVS (the first 4
systems of the second score are on the bottom of the first page)
\book {
\score { {\repeat unfold 55 {a b c d}} }
\score { {\repeat unfold 55 {a b c d}} }
}
It will take a while since will have to factor out several macro files.
Paul
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic page breaks changed for 2.9.8?
Kieren MacMillan wrote:
Hi, Paul:
if there is not a way for a choice I think there should be.
\score
{
\layout
{
breakbefore = ##t
}
}
and
\score
{
\layout
{
breakbefore = ##f
}
}
I do use breakbefore = ##t when I want a break. Does this mean that the
default changed from false to true from 2.8.4 to 2.9.8? That is the
behavior I see.
Thanks,
Paul
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic page breaks changed for 2.9.8?
On Thu, 2006-06-08 at 17:17 -0700, Paul Scott wrote:
> A part produced with:
>
> \book {
> \score { }
> \score { }
> }
>
> Using 2.9.8 seems to force a page break at the end of a movement
> (\score) whether there is room for part of the next movement or not.
> That is unless there is room for the next whole movement. This is very
> neat but if there is not a way for a choice I think there should be.
> 2.8.4 does the more normal page breaking.
>
> I can produce my example if necessary.
Please do. The following example works for me on 2.9 CVS (the first 4
systems of the second score are on the bottom of the first page)
\book {
\score { {\repeat unfold 55 {a b c d}} }
\score { {\repeat unfold 55 {a b c d}} }
}
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automatic page breaks changed for 2.9.8?
Hi, Paul:
if there is not a way for a choice I think there should be.
\score
{
\layout
{
breakbefore = ##t
}
}
and
\score
{
\layout
{
breakbefore = ##f
}
}
Best regards,
Kieren.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
automatic page breaks changed for 2.9.8?
A part produced with:
\book {
\score { }
\score { }
}
Using 2.9.8 seems to force a page break at the end of a movement
(\score) whether there is room for part of the next movement or not.
That is unless there is room for the next whole movement. This is very
neat but if there is not a way for a choice I think there should be.
2.8.4 does the more normal page breaking.
I can produce my example if necessary.
Paul Scott
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting the height of a system.
On Thu, 2006-06-08 at 17:18 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> > On Thu, 2006-06-08 at 09:05 +1000, Joe Neeman wrote:
> >> Anyway, here's another try. Same ChangeLog as before
> >
> > After your last email, I've removed the changes to
> > Item::handle_prebroken_dependencies and changed axis-group-interface.cc.
> > I'm only attaching the part of axis-group-interface.cc with the most
> > recent changes.
> >
>
> > + vector relevant_elts;
> > + SCM is_relevant = ly_lily_module_constant ("pure-relevant");
>
> > + if (piece && to_boolean (scm_apply_1 (is_relevant,
> > piece->self_scm (), SCM_EOL)))
> > + relevant_elts.push_back (elts[i]);
>
> Looks good. small question: why is pure-relevant coming in from Scheme
> C++ seems more applicable? It's not a user serviceable part, is it?
Just because the Y-XX-conversions and pure-Y-XX lists are in scheme, and
I thought it was nicer not to make them public, but to provide public
accessing functions instead. I can move it to C++, though, if you'd
prefer.
Now that I go back to look at it, I see that the lists are actually
public. That's fixed now.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Help with polymetric music!
Hi, Mats: You have removed the timing translator from the Score context but only added it to the Staff context, not to the DrumStaff context. D'oh! =\ Thanks for correcting my oversight! Cheers, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spacing bug in 2.8.2?
Hi, Mats: The simple answer is probably that the changes you have noticed are side-effects of several changes to the algorithms, that presumably have improved lots of other aspects of the layout. True -- and so much of what's happening is ab fab! =) Best, Kieren. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spacing bug in 2.8.2?
Kieren MacMillan wrote: ... However, in general I have felt that beginning- and end-of-measure spacing has altered dramatically (not for the better) in the past version or so -- you may remember several postings (by me and others) on this issue. For example, I now find that: 1. nearly *every* "carry-over" slur and tie essentially disappears (n.b., this behavior is seen in Shamus's example as well); 2. accidentals, arpeggios, etc., attached to a measure's first note are almost always within only a few points of the bar line itself (and in some cases actually *touch* the bar line!); 3. noteheads themselves sometimes (but much less often than other Objects) seem too close to the bar line (leading and trailing). None of these were a problem a few versions ago -- I would really love to know what has happened to effect this change, and where the spacing code is located so I could revert this. The simple answer is probably that the changes you have noticed are side-effects of several changes to the algorithms, that presumably have improved lots of other aspects of the layout. /Mats ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Help with polymetric music!
Kieren MacMillan wrote:
What *really* seems odd is that, when I compile the code, the *first*
staff takes on the time signatures of the *fourth* one (drum) which
doesn't display the time sigs. I'm not sure it's a bug really -- I
imagine it's related to the \alias Staff in the DrumStaff context
definition, but I don't know how to fix it, so I'm forwarding it to
the development list.
Best wishes,
Kieren.
p.s. Note that here I have moved your TimeSig style command to the
Score context -- I think that's more efficient (unless you really do
potentially want different TimeSig *styles* in each Staff?)...
You have removed the timing translator from the Score context
but only added it to the Staff context, not to the DrumStaff context.
Just add
\context
{
\DrumStaff
\consists "Timing_translator"
\consists "Default_bar_line_engraver"
}
in your \layout block.
/Mats
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
example for chord tie bug
Here's a really ugly example of the already reported tie bug in
chords (well, maybe it's a different bug, I don't know).
Werner
==
\version "2.9.7"
\paper {
ragged-right = ##t
}
\relative c' {
1 ~ |
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: incorrect ties in cues
> > This bug makes me crazy! For my project it is a real showstopper > > (I've attached an image snippet of my drum part. > > > > Please fix it ASAP. > > fixed in CVS. Thanks a lot for the *really* quick fix! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Getting the height of a system.
Joe Neeman schreef:
On Thu, 2006-06-08 at 09:05 +1000, Joe Neeman wrote:
Anyway, here's another try. Same ChangeLog as before
After your last email, I've removed the changes to
Item::handle_prebroken_dependencies and changed axis-group-interface.cc.
I'm only attaching the part of axis-group-interface.cc with the most
recent changes.
+ vector relevant_elts;
+ SCM is_relevant = ly_lily_module_constant ("pure-relevant");
+ if (piece && to_boolean (scm_apply_1 (is_relevant,
piece->self_scm (), SCM_EOL)))
+ relevant_elts.push_back (elts[i]);
Looks good. small question: why is pure-relevant coming in from Scheme
C++ seems more applicable? It's not a user serviceable part, is it?
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: incorrect ties in cues
Werner LEMBERG schreef: This bug makes me crazy! For my project it is a real showstopper (I've attached an image snippet of my drum part. Please fix it ASAP. fixed in CVS. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
glyph placement does not use font baseline
Hello, all --
The following example finally clarifies something that has been
nagging at me for a while, but I've never been able to figure out
exactly why...
Note how the markup is placed: not according to the baseline of the
font, but according to the extreme edge of each particular glyph
(e.g., bottom of 'p' descender, top of the 'b' ascender), and thus
how the 'n', 'p', 's', and 'b' in the example do not rest on the same
baseline, even though the padding (placement) would lead one to
believe they should. [The same is true of dynamic markup text,
obviously, which is where this irritation first became apparent to me.]
I really think this should be fixed -- all other graphics/layout
programs I've used consider the font baseline as the anchor point for
glyph placement, which naturally leads to a more consistent user
(and, probably, programmer) experience.
I'm happy to hunt down the culprit and fix it myself, but I need to
know whether it's
1. a font problem (fixed in metafont or FontForge?);
2. a PostScript problem (fixed in C++ code?);
3. a Lilypond layout problem (fixed in Scheme?); or,
4. some combination of #1-3.
Any thoughts?
Thanks,
Kieren.
___
%%% CODE SNIPPET BEGINS
\version "2.9.7"
pFour = \once \override TextScript #'padding = #4
sFour = \once \override TextScript #'staff-padding = #4
\paper
{
indent = 0
line-width = 5.5\in
ragged-bottom = ##t
}
\relative c'
{
f4^"n" \pFour f^"p" \sFour f^"s" \pFour\sFour f^"b"
g,4^"n" \pFour g^"p" \sFour g^"s" \pFour\sFour g^"b"
f'4_"n" \pFour f_"p" \sFour f_"s" \pFour\sFour f_"b"
d''4_"n" \pFour d_"p" \sFour d_"s" \pFour\sFour d_"b"
}
%%% CODE SNIPPET BEGINS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Help with polymetric music!
Hi, Dylan:
I modified your code slightly, and it works--except when the
bottom staff is a drum staff!
Below is my code. The resulting score is what I want, but the
bar lines and time signatures are in the wrong places.
Perhaps this is a bug?
What *really* seems odd is that, when I compile the code, the *first*
staff takes on the time signatures of the *fourth* one (drum) which
doesn't display the time sigs. I'm not sure it's a bug really -- I
imagine it's related to the \alias Staff in the DrumStaff context
definition, but I don't know how to fix it, so I'm forwarding it to
the development list.
Best wishes,
Kieren.
p.s. Note that here I have moved your TimeSig style command to the
Score context -- I think that's more efficient (unless you really do
potentially want different TimeSig *styles* in each Staff?)...
%%% CODE SNIPPET BEGINS
\version "2.9.8"
\layout
{
%% move the Timing and Bar functions
%% from the Score context ...
\context
{
\Score
\remove "Timing_translator"
\remove "Default_bar_line_engraver"
\override TimeSignature #'style = #'()
}
%% ... to the Staff context.
\context
{
\Staff
\consists "Timing_translator"
\consists "Default_bar_line_engraver"
}
}
%% Music in 4/4 (intro) and 3/4 (the piece)
one = \relative c'
{
\time 4/4 \repeat "unfold" 2 { c4 c c c }
\bar "||"
\time 3/4 \repeat "unfold" 3 { c4 c c c }
}
two = \relative c'
{
\time 4/4 \repeat "unfold" 2 { c4 c c c }
\bar "||"
\time 3/4 \repeat "unfold" 3 { c4 c c c }
}
three = \relative c'
{
\time 4/4 \repeat "unfold" 2 { c4 c c c }
\bar "||"
\time 3/4 \repeat "unfold" 3 { c4 c c c }
}
%% Music in 4/4 (intro) and 9/8+8/8+7/8 (the piece)
four = \drummode
{
\time 4/4 \repeat "unfold" 2 { r4 r r r }
\bar "||"
\time 9/8
r4 r8 r4 r8 r4 r8
\time 8/8
r4 r4 r4 r4 \break
\time 7/8
r4 r4 r4.
}
%% Put all of it together!
\score
{
<<
\new Staff \one
\new Staff \two
\new Staff \three
\new DrumStaff \four
>>
}
%%% CODE SNIPPET ENDS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: incorrect ties in cues
Hi, Werner: This bug makes me crazy! For my project it is a real showstopper For the record, it (i.e., the bug) appears to be true with grace notes as well: Picture 1.png Description: application/applefile Best regards, Kieren.___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: incorrect ties in cues
This bug makes me crazy! For my project it is a real showstopper
(I've attached an image snippet of my drum part.
Please fix it ASAP.
Werner
--- Begin Message ---
%
% [EMAIL PROTECTED]
\version "2.9.7"
\header { texidoc = "
Voices from different cues must not be tied together.
" }
\paper {
ragged-right = ##t
}
cueI = \relative c'' {
a1 ~ | a ~ | a |
}
\addquote "cueI" { \cueI }
cueII = \relative c' {
R1 | e | a |
}
\addquote "cueII" { \cueII }
\new Staff {
\cueDuring "cueI" #UP { R1 } |
\cueDuring "cueII" #UP { R1 | R1 } |
}
% EOF
--- End Message ---
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Staff.instr
I just send some code to lilypond-user... thank you ! On 7 juin 06, at 23:56, Cameron Horsburgh wrote: On Wed, Jun 07, 2006 at 04:22:00PM +0200, Papazian Christophe wrote: Hello, In Lilypond 2.4, I was used to set Staff.instr inside my main Voice, to print some useful notation during a song (so each new line could have a different instr). But now, I just upgraded to 2.8, and it doesn't seem to work anymore. /set Staff.instr only seems to be useful if used before anything else in a Staff. Is there some workaround ? Oops, forgot to copy the list! Could you post an example? It seems to me you're trying to manually typeset multipart scores, which Lilypond can do automatically. BTW, this would probably be better to send to lilypond-user. -- = Cameron Horsburgh /dev/random says: Dinner not ready: (A)bort (R)etry (P)izza http://web.netcall.com.au/horsburgh _ _ _ _ _ / ___| _ __ ___ (_) | ___| | | | \___ \| '_ ` _ \| | |/ _ \ | | | ___) | | | | | | | | __/_|_|_| |/|_| |_| |_|_|_|\___(_|_|_) = ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
updated files for (doc help) applyMusic -> music functions: smart-transpose.ly
Here's the last one (hope it's not outdated by another function...)
"smart-transpose.ly"
%
% Start cut-&-pastable-section
%
\paper {
#(define dump-extents #t)
indent = 0\mm
line-width = 160\mm
}
\layout {
}
%
% ly snippet:
%
\sourcefilename "smart-transpose.ly"
\header {
texidoc="@cindex Smart Transpose
There is a way to enforce enharmonic modifications for notes in order
to have the minimum number of accidentals. In that case, ``Double
accidentals should be removed, as well as E-sharp (-> F), bC (-> B),
bF (-> E), B-sharp (-> C).'', as proposed by a request for a new feature.
In this manner, the most natural enharmonic notes are chosen in this example.
"
}
%
% Modified to use the standard transpose mechanism. The question is
% how useful these enharmonic modifications are. Mats B.
%
% Why not to have a function that minimizes the number of accidentals? -HJJ
% Works also for quarter tones. -HJJ
%
#(define (naturalise-pitch p)
(let* ((o (ly:pitch-octave p))
(a (ly:pitch-alteration p))
(n (ly:pitch-notename p)))
(cond
((and (> a 1) (or (eq? n 6) (eq? n 2)))
(set! a (- a 2))
(set! n (+ n 1)))
((and (< a -1) (or (eq? n 0) (eq? n 3)))
(set! a (+ a 2))
(set! n (- n 1
(cond
((> a 2) (set! a (- a 4)) (set! n (+ n 1)))
((< a -2) (set! a (+ a 4)) (set! n (- n 1
(if (< n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if (> n 6) (begin (set! o (+ o 1)) (set! n (- n 7
(ly:make-pitch o n a)))
#(define (naturalise music)
(let* ((es (ly:music-property music 'elements))
(e (ly:music-property music 'element))
(p (ly:music-property music 'pitch)))
(if (pair? es)
(ly:music-set-property!
music 'elements
(map (lambda (x) (naturalise x)) es)))
(if (ly:music? e)
(ly:music-set-property!
music 'element
(naturalise e)))
(if (ly:pitch? p)
(begin
(set! p (naturalise-pitch p))
(ly:music-set-property! music 'pitch p)))
music))
music = \relative c' { c4 d e f g a b c }
naturaliseMusic =
#(define-music-function (parser location m)
(ly:music?)
(naturalise m))
\score {
\context Staff {
\transpose c ais \music
\naturaliseMusic \transpose c ais \music
\transpose c deses \music
\naturaliseMusic \transpose c deses \music
}
\layout { ragged-right = ##t}
}
%
% end ly snippet
%
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation - index bug - noteheads
On 8-Jun-06, at 1:20 AM, Anthony Youngman wrote: 6.6.1 - Basic polyphony. Sorry - I've got the docs for 2.8.0 - I'm running 2.8.2. Ok, added. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated files for (doc help) applyMusic ->musicfunctions:unfold-all-repeats.ly
Mats Bengtsson ee.kth.se> writes: > > Right! The example is probably much older than the current \unfoldRepeats > command, so we could just skip it. > >/Mats > > Han-Wen Nienhuys wrote: > > > Michael Meixner schreef: [...] some newbie-developer-stuff deleted [...] Sorry for the bandwidth - just didn't check all unfold-stuff in the doc. Won't happen again :-) Greetings from Vienna Michael ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated files for (doc help) applyMusic -> music functions: unfold-all-repeats.ly
Right! The example is probably much older than the current \unfoldRepeats
command, so we could just skip it.
/Mats
Han-Wen Nienhuys wrote:
Michael Meixner schreef:
\header { texidoc = "Applying the standard function
@code{unfold-repeats} unfolds recursively all repeats for a correct
MIDI output."
}
unfoldAll = #(define-music-function (parser location music )
(ly:music?)
#{
\unfoldRepeats $music
#})
I don't get this. Why don't you do
#(define unfoldAll unfoldRepeats)
or just skip unfoldAll. Note that the docstring is still incorrect.
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updated files for (doc help) applyMusic -> music functions: unfold-all-repeats.ly
Michael Meixner schreef:
\header {
texidoc = "Applying the standard function @code{unfold-repeats} unfolds
recursively all repeats for a correct MIDI output."
}
unfoldAll =
#(define-music-function (parser location music )
(ly:music?)
#{
\unfoldRepeats $music
#})
I don't get this. Why don't you do
#(define unfoldAll unfoldRepeats)
or just skip unfoldAll. Note that the docstring is still incorrect.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software Design
-- Code for Music Notation
http://www.lilypond-design.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Documentation - index bug - noteheads
6.6.1 - Basic polyphony. Sorry - I've got the docs for 2.8.0 - I'm running 2.8.2. As for NoteHeads being generating automatically, I'm sure I came across a couple of examples that weren't indexed. But I can't remember where they were, and I'm not going to search for them now :-) I don't tend to run development versions, so I'll probably go to 2.10 not 2.9, but as soon as I get a chance to go to my scanner and sort out the jazz stuff I've sponsored I'll probably have to upgrade :-) Cheers, Wol -Original Message- From: Graham Percival [mailto:[EMAIL PROTECTED] Sent: 07 June 2006 23:42 To: Anthony Youngman Cc: lily-devel Subject: Re: Documentation - index bug - noteheads On 7-Jun-06, at 3:19 AM, Anthony Youngman wrote: > Section 6.6.1 should just be indexed as "NoteHead". It contains an > example of its use - indeed as I say the only example that appears to > be > for generic use. Looking at it in the index led me to believe the > references were for ancient music (although in part that was me not > looking hard enough, but I still wouldn't have found what I was looking > for). What's the section name of 6.6.1 in your docs? In the latest 2.9 docs, 6.6.1 is Articulations, and I can't see any noteheads in there. > The existing "note heads" entry should be retitled "note heads, > ancient" > because it points you at "7.7.1 Ancient note heads". Actually, having Done, thanks. > found and looked at the index for NoteHead, the "note heads" entry > should either be dropped, or expanded to make it consistent with > NoteHead. I'd prefer the latter, but the result will be a bloated index > ... The "NoteHead" entries are added automatically whenever the internals docs are referenced. If I were writing the docs from scratch, I wouldn't have added them, but I'm reluctant to remove those links without a great reason. > Suggestions are "note heads, special" for 8.4.5, "note heads, shape" > for > 8.5.4, "note heads, easy notation" for 8.5.5 (sorry this was what I was > looking for as a "practice notehead" - I obviously didn't look hard > enough). Done, thanks. Again, please state the section title as well (8.4.5 Special noteheads, 8.5.4 Shape note heads...). When I'm looking at the source code for the docs, I don't see any numbers. If I only have "8.5.4", I need to look at the HTML docs to find out what the title is. I gave easy notation two entries: @cindex note heads, practice @cindex note heads, easy notation > By the way, is there an overarching philosophy behind the manual, or > has > it "just growed" as users have made suggestions? It has mostly "just growed" as developers have added things. User suggestions don't write documentation; people write docs. And anybody can write docs; all you need is an email client and some interest. I have a general idea of an overarching philosophy for the docs, and I make sure that new docs fit that. And every so often I'll review a chapter and modify it to fit in with that overarching philosophy. Each chapter review takes between 5 and 15 hours, though. That's a large chunk of my volunteer time. - Graham * * This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 8272 5300, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333. * * ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
