Re: lilypond-user Digest, Vol 58, Issue 105

[Frederick Dennis]

Dear LilyPond users,
Thank you for your advice.
Some progress.

\version "2.8.7"

\header { title = "Singin' In The Rain"
composer = "Freed and Brown"
meter = "Medium Swing"}

melody = \transpose c d \relative c'' {
\clef treble
\key f \major
\time 4/4
\set Score.skipBars = ##tt

%line 1
R1*3 r2 r4 c
\once \override Score.SeparationItem #'padding = #1
\mark \markup { \musicglyph #"scripts.segno" } \bar "||" c'2~ \times 2/3 {
c4 a8 } \times 2/3 ( g4 f8 } d2 r4 c

% more notes
% bar 27 starts the next line

c2~ \times 2/3 ( c4 a8 } g4 d2 r4 c \times 2/3 ( c'4 c8~ } c4 r4 c,^"To
Coda" \times 2/3 { e4 e8~ }
e8.~ a16~ a4
\mark \markup { \musicglyph #"scripts.coda" } c,

%more notes
% bar 53 starts the next line

bes2 aes4 ges ges aes2 bes4 bes f f f~ f2. f4 f2 ees4 des4 des ees2 f4 aes f
\once \override TextScript #'extra-offset = #'( -1.0 . 2.5 )
aes\mark "D.S. al Coda " c~ c2. c,4 \bar "||" \break
f2. \mark \markup { \musicglyph #"scripts.coda" CODA }
f1~ r4 R!*2 r1^\fermataMarkup \bar ".|."
}

\score {
\new Staff \melody
\layout {}
\midi {}

}

Score.SeparationItem moves the note after the segno along a bit, avoiding
the collision.
However, the coda signs and texts are very untidy.  The extra.offset doesn't
seem to have any effect.
Yours,
Frederick Dennis.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Writing a book (libretto) using LilyPond

[Nicolas Sceaux]

"Valentin Villenave" <[EMAIL PROTECTED]> writes:

> Hello everybody, hello Nicolas,
>
> (by the way: many thanks for handling the \smallCaps bug)
>
> I'm editing (as a small book) the libretto of my opera, and I thought
> it would be just great if I could do this using LilyPond, particularly
> thanks to the \markuplines etc commands.
>
> [...]
>
> Basically, what I need is a Scheme macro that I could use for each
> line of the dialogue. This includes:
> -the name of the Character who's speaking (smallCaps, centered)
> -optionally a small indication following the name (italic, in parentheses)
> -the line itself, which can include short indications in italic with 
> parentheses
> -optionally an independant indication before the next character starts 
> talking.

You may look at:

  prose: /Le Bourgeois Gentilhomme/, Molière, Lully
  

  verses: /Amour Malade/, Lully, Butti
  

where commands are defined for displaying character name, didascalies
(don't know the English for that), verses, text, etc.

nicolas


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proper use of Devnull

[Francisco Vila]

2007/9/29, Graham Percival <[EMAIL PROTECTED]>:
>
> According to some bug reports (specifically about shifted lyrics with
> devnull), devnull is not the proper solution to use.


Oh. I've seen it (your last comment is only two days old). I see this is
not  a "Medium priority Defect" anymore but a "Low priority Enhancement". A
pity, IMO.

Anyway, I still have two questions. From the great examples around I still
cannot see how to do alternate Lyrics when the melody is the same but
melismata are different fot each one.

My second question is, how to change the default left alignment for
melismata texts? Imagine the situation I mentioned where alternate lyrics
with different melismata want to be equally centered on their noteheads. I'd
like to center all of them regardless of this. In fact I'dl like to center
all texts, all the time. Is it possible?

Thank you.

-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

GDP: learning manual

[Graham Percival]

Another poorly-explained idea is the split between the Learning Manual 
and the Notation Reference.  I've expanded parts of the LM now, so it 
should hopefully be a bit more clear.  As always, the latest docs are there:


http://opihi.cs.uvic.ca/~gperciva/

Please note that I am not looking for help with the LM right now. 
Everybody else should be working on chapter 1; when we find material 
that should be in the LM, I'll move it there and work on it.  I'll ask 
for help with the LM once everything else is running smoothly.


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

GDP: Pitches rewrite draft

[Graham Percival]

Ok, let's start the other half of real GDP work (two halves:
formatting and rewriting) by examining Pitches.  As always, please
examine the latest docs here:
http://opihi.cs.uvic.ca/~gperciva/

DON'T BOTHER COMMENTING
- inspirational headword will be reinstated on 1 Jan 2008.
- tables in "Note names in other lanuages" are messed up.  That's a
  formatting change that will be completed soon.
- HTML split.  This is a technical problem that I'm looking for help,
  but that discusion takes place elsewhere.
- need links to LSR; that's on the list for Formatters.


SEEKING COMMENTS / OFFERS OF HELP
- move Cautionary accidentals into Accidentals.
- move Micro tones into Accidentals.
- do "note names in other lanuages" need anything more than cleaning up
  the tables?  I never use non-Dutch stuff (even though I'm Canadian),
  so I'm not the best judge of this.
- need a @refbugs above the final paragraph of Relative octaves.
- Relative octaves: should we omit the discussion about the default
  value of c' ?  (ie \relative {} )   I believe that this construct is
disliked by some developers and might disappear in the future, so should
we start preparing newbies by never mentioning it?  Or should we simply
list this in the @refbugs section?
(+1 leave them in)
- I'm not too happy with Octave check, but I can't think of any specific
  change right now.  Simply add to the list of "rewrite whole
subsection"?
- ditto for Transpose: rewrite whole subsection.
- Key signature: should we move the warning ("accidentals and key
  signatures often confuse new users..." to the top of the page?  Or
omit it entirely, since users are supposed to have read the Learning
Manual?   for that matter, should the warnings in the Tutorial be
beefed up?
- Instrument transposition: might need more explanation about \transpose
  vs. \transposition.

- anything else not in this list.  :)


Pitches is one of the most straightforward sections, so there's
relatively little in this list.  That said, if you don't like anything
in the new Pitches section, please speak up now or forever hold your
peace.


Cheers,
- Graham



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

GDP: main phase

[Graham Percival]

We have now entered the main phase of GDP.  I seem to have done a
poor job of explaining what's happening, so I'll try to explain it
better.  Please read this message carefully.

If something in this message contradicts anything I said in the
past couple of days, please treat this message as correct.
(and/or ask for clarification :)


OVERALL

We are currently working on Chapter 1 of the user manual /
notation reference: "1 Musical notation".  Sorry vocal guys: we're
not touching your stuff again for at least a month.

There are two main tasks in GDP: Formatting and Rewriting.  We
will be Rewriting two sections at most.


REWRITING

I will post a Draft Rewrite message when we begin examining a
section.  Please discuss the changes there.  After about a week,
we will start rewriting the section, then we'll post a second
draft.  Again, please read the section and comment on anything
else that should be changed.

Translators: please, PLEASE, take part in this.  If there's
anything you don't understand in a section, comment during the
Draft Rewrite time.  It is _much_ easier to rewrite the
documentation while we're actually rewriting it.  If you ask
questions about a doc section three months after we've finished
working on it... well, we'll still help you, of course.  But it
would be really nice if you could ask those questions when we're
actually working on each section.


TIMEFRAME

There will be a week for discussion about a section.  Then we'll
have about a week of rewriting, followed by another week of
discussion.  If all goes well, the section will be finished;
otherwise we'll add another week of work and discussion.

It will probably take two months to cover chapter 1.  If we have
enough manpower (sorry ladies, it's a generic term; I'm not being
sexist), we might start chapter 2 earlier.


FORMATTING

These were formally known as "trivial/easy" tasks, but I thought
that term was a bit insulting.  My general rule of thumb is that a
task is Formatting if I could do these jobs on a document about
Chinese History, rewritten in Swahili -- a language I don't
understand, about a subject for which I am totally ignorant.

There are 8 sections in the chapter, so ideally I would like 6
formatting helpers.  I currently have four helpers; most of whom
are interested in Rewriting.  But we need to get these formatting
things done, so I've asked them to work on formatting instead.  If
you're interested in having these people work on rewriting
instead, please volunteer!

Each week, a formatting helper will take one section that we're
not rewriting.  They will make whatever improvements they feel
comfortable doing -- if you think some English is bad, but you
don't really understand it, feel free to leave it alone!  If
you don't have a clue what microtones are, but you see that the
indentation in the lilypond example uses 1 space instead of 2, go
ahead and fix the spaces without touching the actual lilypond
code.


SUMMARY

Currently we are discussing the rewrite for Pitches, and I am seeking
formatting helpers to get the rest of chapter 1 in slightly better
shape.  I'll open up the discussion about the rewrite for Rhythms
as soon as I feel that everything else is working smoothly.

If you are interested in another part of the docs (learning
manual, vocal stuff, scheme, etc), then please wait until we get
to that section.  The more help we get for chapter 1, the sooner
we'll get to other sections.

Cheers,
- Graham



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: lilypond imbedded in text

[fiëé visuëlle]

Am 2007-09-27 um 09:02 schrieb Mats Bengtsson:

Quoting Kieran Coulter <[EMAIL PROTECTED]>:

I am planning on starting a method book series for lilypond.
I am curious what the general format is for mixing various fonts and
styles, pictures, and lilypond exercises and pieces to play.


With lilypond-book, you can insert LilyPond examples in a LaTeX  
document, meaning that you have the full typesetting flexibility of  
LaTeX available.


There's also a plugin for Openoffice to insert LilyPond examples
into documents.


There's also a LilyPond module for ConTeXt, see http:// 
wiki.contextgarden.net/LilyPond
It works with sections (complete lines) but not yet with in-line  
snippets.


Greetlings from Lake Constance
---
fiëé visuëlle
Henning Hraban Ramm
http://www.fiee.net
http://angerweit.tikon.ch/lieder/
https://www.cacert.org (I'm an assurer)




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: translations

[Graham Percival]

John Mandereau wrote:

Le mardi 25 septembre 2007 à 09:01 +0200, michał poręba a écrit :

Then I will start translating the web page as you say. And later we
will see if there is still time to do tutorial translation. I see that
you are hard working on documentation, reorganising everything. How
may I fit in it with my translation? Should I work as a easy helper?


You are free to spend your time for LilyPond contributions as you
like  :-).


I'm reluctant to disagree with this statement, but since you _did_ 
ask... I would suggest that it would be better to work as an easy helper 
(now called "Formatting helpers").  There's a lot of Formatting work 
that needs to be done.


Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proper use of Devnull

[Graham Percival]

According to some bug reports (specifically about shifted lyrics with 
devnull), devnull is not the proper solution to use.  It might say 
otherwise in the manual; we'll be checking this in about a month.


Sorry,
- Graham

Francisco Vila wrote:

Hello all,

I'm trying to typeset a song that has two lyrics with different 
melismata in the same melody.
I've found that the Devnull context may help, but I don't know why the 
lyrics associated to it appears with a slight displacement to the right 
(see attached PNG).


 % \version "2.11.32"

one = { c'1 }
two = { d'1 }
oneLyrics = \lyricmode { One }
twoLyrics = \lyricmode { Two }

\score {

<<
\new Voice { \one } \addlyrics { \oneLyrics }
\new Devnull = "hidden" { \two }% \addlyrics { \twoLyrics }
\new Lyrics \lyricsto hidden { \twoLyrics }
 >>
}


 From my limited knowledge it appears to be in voiceTwo, how is it 
forced to be voiceOne?


Also, if I uncomment the \addlyrics of the hidden part (and comment out 
the third line instead), then the hidden staff gets printed on its own 
staff (and properly aligned as a voiceOne). Why?


I'd thank a clue for learning it by myself, but maybe the manual is too 
terse in this matter.

Thank you!
--
Francisco Vila. Badajoz (Spain)
http://www.paconet.org





___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Proper use of Devnull

[Francisco Vila]

Hello all,

I'm trying to typeset a song that has two lyrics with different melismata in
the same melody.
I've found that the Devnull context may help, but I don't know why the
lyrics associated to it appears with a slight displacement to the right (see
attached PNG).

 % \version "2.11.32"

one = { c'1 }
two = { d'1 }
oneLyrics = \lyricmode { One }
twoLyrics = \lyricmode { Two }

\score {

<<
\new Voice { \one } \addlyrics { \oneLyrics }
\new Devnull = "hidden" { \two }% \addlyrics { \twoLyrics }
\new Lyrics \lyricsto hidden { \twoLyrics }
>>
}


>From my limited knowledge it appears to be in voiceTwo, how is it forced to
be voiceOne?

Also, if I uncomment the \addlyrics of the hidden part (and comment out the
third line instead), then the hidden staff gets printed on its own staff
(and properly aligned as a voiceOne). Why?

I'd thank a clue for learning it by myself, but maybe the manual is too
terse in this matter.
Thank you!
-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org
<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

RE: GDP: add "elision" to the glossary?

[Trevor Daniels]

The symbol to indicate two syllables should be sung on one
note is called a 'lyric tie' in the LP manual.  Coda Music
(Finale) call it an 'elision'.  I agree it should be
included in the glossary too, as well as 'lyric tie', maybe.

BTW, I found that the small curved line which indicates an
elision in LP in not found in any of the fonts on my PC
(Windows XP), as coding one generates an error in LP.  The
manual recognises this and suggests obtaining DejaVuLGC.  I
don't know how to go about doing this.  Could this or some
other suitable font not be packaged with the LP
distribution?

Trevor

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:lilypond-user-bounces+t.daniels=treda.co.u
> [EMAIL PROTECTED] Behalf Of
> Eyolf Ostrem
> Sent: 29 September 2007 12:27
> To: lilypond-user Mailinglist
> Subject: Re: GDP: add "extender line" to the glossary?
>
>
> On 29.09.2007 (13:08), Till Rettig wrote:
>
> Graham Percival wrote:
> > Should we add "extender line" to the glossary?
> Is this a real musical
> > term, or a made-up lilypond term?  Any
> vocalists want to comment?
>
> Another word that should perhaps be there, is
> "elision" (with whatever
> second word is correct -- mark, slur, tie, bow,
> line?), i.e. the small
> bow used to tie together syllables from different
> words that still
> belong to the same note, most frequent in italian music.
>
> e
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>
> --
> University politics are vicious precisely because
> the stakes are so small.
>   -- C. P. Snow
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
>
>





___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Writing a book (libretto) using LilyPond

[Werner LEMBERG]

> Ach, ich füll's...

Hehe.  This means `Oh, I'm filling it' :-)

You probably mean `Ach, ich fühl's'...


Werner


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

GDP: three additional instructions for helpers

[Graham Percival]

As an aside, I'm starting every email with "GDP: " in the subject line 
so that people can easily filter them.  If you care about GDP, make a 
new mailbox for these emails; if you don't care about it, then send all 
these emails straight to the trash.  :)



I've added some more instructions to the readme.txt, but you probably 
wouldn't read that file again normally, so I'm sending them here.


GDP: if you see a @refcommands, move those items into the top of the
@commonprop section and delete the @refcommands.
 (Valentin: your offer with regards to this is appreciated but not 
necessary, there's a better way to do it)


GDP: if you see any TODO items, send them to Graham and delete
them from the file (I'll add them to my master TODO list for that
section).  We will resolve all these issues before declaring a doc
section finished.

GDP: treat any questions in comments like TODO items.

Cheers,
- Graham


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fwd: Users' Manual

[Eyolf Østrem]

On 29.09.2007 (06:07), Rick Hansen (aka RickH) wrote:
> 
> I would buy the manual in a nice spiral book, perhaps the sales could be used
> to pay developers.  The cost of printing and binding the PDF at my local
> office store is not cheap, and I'd much rather have the money go to the
> devs. and to the doc writers.  If you guys could work something out and sell
> it on the lp site profitably.

THat's actually one of the first things I did when I realized that
"hey, I'm going to ditch Finale!": I went to the copyshop and made
myself a spiral bound version of the manual, since, as I thought: I'm
going to use this one a lot. 
Which I did, although I've used the pdf file more. But some kind of
print-on-demand solution (there is also lulu.com) where some money
could go to the devs, wouldn't be a bad solution, and probably both
better and cheaper than what I got.

e
-- 
"A University without students is like an ointment without a fly."
-- Ed Nather, professor of astronomy at UT Austin


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Writing a book (libretto) using LilyPond

[Valentin Villenave]

Hello everybody, hello Nicolas,

(by the way: many thanks for handling the \smallCaps bug)

I'm editing (as a small book) the libretto of my opera, and I thought
it would be just great if I could do this using LilyPond, particularly
thanks to the \markuplines etc commands.

I know I'm not the only one to be interested in writing books using
only LilyPond; AFAIK Nicolas has been very succesful in it with his
great Couperin book (which has become kind of my bible btw; I always
invite all my pupils to read it :)

Basically, what I need is a Scheme macro that I could use for each
line of the dialogue. This includes:
-the name of the Character who's speaking (smallCaps, centered)
-optionally a small indication following the name (italic, in parentheses)
-the line itself, which can include short indications in italic with parentheses
-optionally an independant indication before the next character starts talking.


Example:


PUNCH

Lasci darem la mano... (he smiles) La mi dirai di si.

(Enters Judy)

   JUDY, without noticing him

Ach, ich füll's...


%%

% I wrote three macros, one for Punch, one for Judy and
% one for the indications

#(define-markup-list-command (punch layout props args) (markup-list?)
   (let ((indication (chain-assoc-get 'indic props "")))
 (interpret-markup-list layout props
   (make-justified-lines-markup-list (cons
  (markup #:column ( #:hspace 0 #:fill-line
( #:concat ( #:smallCaps "Punch" #:italic indication ))
   #:hspace 0 )) args)

#(define-markup-list-command (judy layout props args) (markup-list?)
   (let ((indication (chain-assoc-get 'indic props "")))
 (interpret-markup-list layout props
   (make-justified-lines-markup-list (cons
  (markup #:column ( #:hspace 0 #:fill-line
( #:concat ( #:smallCaps "Judy" #:italic indication ))
   #:hspace 0 )) args)

#(define-markup-command (indic layout props text) (string?)
 (interpret-markup layout props
  (markup #:italic text)))

% The code I'd like to use is something like

\markuplines {
  \punch { Lasci darem la mano... \indic #"(he smiles)"
 La mi dirai di si }
  \indic #"(Enters Judy)"
  \override-lines #'(indic . ", without noticing him") \judy {
 Ach, ich füll's }
}

%%


There are many problems, the first one being the \smallCaps bug which
Nicolas has offered to work on.

The second problem is that \indic blocks are not justified; if they're
too long, they're not wrapped by the page at all. Currently, I make
them as markups, and not markup-lists, but I can't find a way to make
it work, no matter the commands I try.

The third problem is that, unlike \markups, \markuplines can't be
stored in identifiers (e.g. if I want to include the libretto in
another file, I have to actually *copy* it, or split it into several
\markup blocks; both solutions are annoying).

The fourth problem is that I would like to make sure that, if a \punch
block occurs at the end of a page, the character's name *never* gets,
printed independently from its corresponding dialogue line. Maybe this
would imply that the whole Name+line block should be treated as a
markup; I don't know. If it's a long, long line, I do want it to be
split, but just not *before* the beginning of the actual line.

It's really a pity that such new features can't be demonstrated yet in
the LSR btw. (says the LSR editor :)

I hope someone will have an idea, thank you in advance.

Cheers,
Valentin

PS. What would really be awesome would be to have an
"automatic-lyrics-cleaning" feature, which could take the text from
the lyrics and remove the hyphens, melismas indications etc, to output
 nice plain text for the libretto, on the fly; currently, I'm using
shared identifiers for all the scenic indications in both the score
and the libretto; and doing the same for the whole text would be a
dream -- pure science-fiction though, I guess...


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: translations

[John Mandereau]

Le mardi 25 septembre 2007 à 09:01 +0200, michał poręba a écrit :
> OK, so first I will learn git and other tools you mentioned. Then I
> start with translating. 

This sounds good.  README contains the minimal hints for using Git, but
it's also good to know a bit more, especially about the concepts.
README isn't the place for explaining Git concepts, so I hope they are
well explained in Git documentation, web site and wiki.  Anyway, if you
still have questions after reading all sorts of docs, ask on the
lilypond-devel list.


> 
> Then I will start translating the web page as you say. And later we
> will see if there is still time to do tutorial translation. I see that
> you are hard working on documentation, reorganising everything. How
> may I fit in it with my translation? Should I work as a easy helper?

You are free to spend your time for LilyPond contributions as you
like  :-).  I suggest you to concentrate on translating the web site
first, because as Jan said it has a large audience.  Then, you'll decide
yourself whether it's more important for you to work on the English docs
or start translating in Polish, according to your taste and the work
needed to be done in the English docs.



>  Should I send my translations every week? 

It depends of what needs to be updated and whether you have translated
new files.  The first translations you send should contain all files
marked with priority 1 in TRANSLATION, then you may send other
translations as you have done them.  You can send me translations
privately, or (only if the email is less than 64 KB) to lilypond-devel.
> 

> Francisco, how do you check (and how often) if the page you have
> translated has changed?

A script (called check-translation.py) shows the change made in the
pages in English since the last time you made or updated the
translation.  More details are explained in README.

Checking and updating the web site translations once a week is enough --
twice is better if you have time.

Send any questions by private email, or if it may be interesting for
other translators to lilypond-devel -- I sometimes give instructions to
all translators on lilypond-devel list, so I expect you to be suscribed
to it.

Good luck with translations!
Cheers
--
John Mandereau
LilyPond translations meister



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: documentation guidelines

[John Mandereau]

Le vendredi 28 septembre 2007 à 20:15 -0700, Graham Percival a écrit :
> John Mandereau wrote:
> > There's no need to add README.txt to the compiled docs, as we can
> > directly refer to the sources:
> > http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=Documentation/user/README.txt;hb=lilypond/gdp
> > 
> > Why not adding it on documentation-adding and "Developers
> > resources" (linked from Documentation index)?
> 
> Sounds good.  Could you add this to your list, John?  We only need to 
> link to the GDP branch until 2.13 exists (and we merge GDP); thereafter 
> it should point to master.

Done.  I also added blurb in documentation-adding, please fix if needed.

Cheers,
John



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Fwd: Users' Manual

[Rick Hansen (aka RickH)]

I would buy the manual in a nice spiral book, perhaps the sales could be used
to pay developers.  The cost of printing and binding the PDF at my local
office store is not cheap, and I'd much rather have the money go to the
devs. and to the doc writers.  If you guys could work something out and sell
it on the lp site profitably.



Mark Knoop-4 wrote:
> 
> Han-Wen Nienhuys wrote:
>> -- Forwarded message --
>> From: Jonathan Ano <[EMAIL PROTECTED]>
>>  Hi, I recently downloaded GNU Lilypond and I don't understand a thing
>> unless I spend hours reading the manual, which would kill my eyes if I
>> spent hours reading it off of a computer screen. The users' manual for
>> the stable branch version is 451 pages long, and it's extremely
>> inconvenient to print that. I was wondering if you have the manual in
>> a book form that you ship; something like that would be helpful.
> 
> Perhaps something like this?
> 
> http://www.cafepress.com/cp/info/sell/products/books
> 
> -- 
> Mark Knoop
> 
> 
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-user
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Fwd%3A-Users%27-Manual-tf4515869.html#a12955422
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: add "extender line" to the glossary?

[Eyolf Østrem]

On 29.09.2007 (13:08), Till Rettig wrote:

Graham Percival wrote:
> Should we add "extender line" to the glossary?  Is this a real musical 
> term, or a made-up lilypond term?  Any vocalists want to comment?

Another word that should perhaps be there, is "elision" (with whatever
second word is correct -- mark, slur, tie, bow, line?), i.e. the small
bow used to tie together syllables from different words that still
belong to the same note, most frequent in italian music.

e
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


-- 
University politics are vicious precisely because the stakes are so small.
-- C. P. Snow


___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: add "extender line" to the glossary?

[Till Rettig]

At least for the German translation I had really problems finding a word 
for that -- I think it is still untranslated... Is there any real term 
for this that could then also be translated easily?
On the other hand -- so far we have this term, so it really should show 
up in the glossary if translations are not too difficult to find (in the 
other languages...).
If some German speaking has ideas on the translation I will see to 
intergrate them...


Greetings
Till

Graham Percival wrote:
Should we add "extender line" to the glossary?  Is this a real musical 
term, or a made-up lilypond term?  Any vocalists want to comment?


Cheers,
- Graham


___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel




___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user