2008/1/14, Mats Bengtsson <[EMAIL PROTECTED]>:
> - In "Relative octave entry", I would reorder the items in the itemized
> list and
> move the first item last (or at least below the currently second
> item), since
> the other items explain the concept of "relative to ..." which is
> mentioned in the
> first item.
> Also, in the (currently) last item, I would start the last sentence
> with "For example
> '' and ,, will alter the ...".
OK, done.
I absolutely do not like the idea that (see the last sentence in this
section) the \relative { blablabla } syntax could be removed. I use it
all the time!
> - In Accidentals, I wouldn't refer to "Nordic and Germanic languages"
Hm, the sentence says: "This syntax is _derived_ from". I don't know
the exact meaning of this word in English, but in French it would
clearly imply that it is not the _exact_ same note naming but a
sligthly different (and simpler) derivative.
> since both Swedish,
> Danish, Norwegian and German use "-iss" and "-ess" .
I will just mention it in the following section.
> - The example with neutraliseMusic doesn't seem to work, right?
It's a snippet. See with the LSR guy.
(Oh, I forgot! damn! it's me!) ;-)
> - In "Clef", the text on "These same clef symbols are used in different
> positions on
> the staff to change the ..." seems more appropriate in a music theory
> treatise than
> here, but maybe it doesn't hurt to include it as long as a competent
> musician doesn't
> get offended by the trivial information.
Absolutely. Paedagogy inside (r) :)
> - In Clef, there's a "% Begin verbatim" shown in the HTML output, which
> probably
> shouldn't be there. Also, isn't it too much redundancy in "by setting
> the explicitClefVisibility Staff property to the value |
> end-of-line-invisible: \set Staff.explicitClefVisibility =
> #end-of-line-invisible"?
> |- In the final example of "Clef", there's something fishy with the line
> breaks. The
> text refers to "the second line" and there is a \break command in the
> code shown,
> still we only see a single score line in the typeset example.
OK, I talked to the LSR guy, and he corrected the snippet :)
> - In "Key signature", the explanation of keySignature is wrong. One
> alternative is to
> write:
> "... The format of this command is a list: |
> \set Staff.keySignature = #'(((octave . step) . alter) ||((octave .
> step) . alter) ...)| where, ..."
> However, if we compare to the information in the IR, we see that this
> does not tell the
> full story. For each item in the list, you can also use the
> alternative format (step . alter)
> which specifies that the same alteration should hold in all octaves.
Snippet updated (god, I love LSR).
> - In "Instrument transpositions", it should be clarified already in the
> first sentence that
> this only relates to scores where not all parts are typeset in concert
> pitch. Also, you
> shouldn't have to read half a page to realize that it only influences
> MIDI output and
> que notes. Finally, I guess it would make sense to cite this section
> from "Transpose".
LOL, I figured this out before reading your mail :)
> - In "Ambitus", the last example (ambiti-multiple-voices.ly) seems like
> bogus to me.
> A relevant use of X-offset is shown already in the second example of
> the section.
> In the last example, the setting does not influence the result at all,
> since the setting is
> done in the Voice context whereas the engraver is in the Staff
> context. Also, there's
> no point in removing the engravers from the Voice context (where they
> don't exist by
> default).
Snippet updated. (LSR forever!)
> - In "Note heads", why not move the subsection "Special noteheads" first?
> (Is it "noteheads" or "note heads"?) since, at least to me, it seems much
> less exotic than the other subsections.
I completely agree. I moved it.
Risto: I have changed the sentence. Tell me if it is better this way.
Rune: I've just seen your mail and removed the Danish thing.
OK. The changes have been pushed.
Graham: however, you need to use the updated LSR snippets to get rid
of things Mats reported.
Many thanks,
Cheers,
Valentin
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
