Re: how to beam non-tuplets with tuplets?

[Adam James Wilson]

Perhaps two examples - one manually beaming non-tuplets->tuplets and
one manually beaming tuplets->non-tuplets (maybe just the examples
below) - could be added to the 2.11 manual under "tuplets?"  I'd be
happy to write up a little chunk of text if that would help.

Best,
Adam

On 9/10/07, Adam James Wilson <[EMAIL PROTECTED]> wrote:
> Nevermind - I've answered my own question - here it is, for those interested:
>
> r16[ g16 \times 2/3 {r16 e'8] }
>
> Best,
> Adam
>
> On 9/10/07, Adam James Wilson <[EMAIL PROTECTED]> wrote:
> > It seems you can beam together tuplets followed by non-tuplets (v. 2.11):
> >
> > \times 2/3 {c'16[ c'8 } c'16 c'16]
> >
> > But beaming together non-tuplets followed by tuplets fails with an
> > "unexpected ']'" error:
> >
> > c'16[ c'16 \times 2/3 {c'16 c'8 } ]
> >
> > Any known methods/hacks to get the second beaming example to work?
> >
> > Best regards,
> > Adam
> >
>


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

Re: how to beam non-tuplets with tuplets?

[Adam James Wilson]

Nevermind - I've answered my own question - here it is, for those interested:

r16[ g16 \times 2/3 {r16 e'8] }

Best,
Adam

On 9/10/07, Adam James Wilson <[EMAIL PROTECTED]> wrote:
> It seems you can beam together tuplets followed by non-tuplets (v. 2.11):
>
> \times 2/3 {c'16[ c'8 } c'16 c'16]
>
> But beaming together non-tuplets followed by tuplets fails with an
> "unexpected ']'" error:
>
> c'16[ c'16 \times 2/3 {c'16 c'8 } ]
>
> Any known methods/hacks to get the second beaming example to work?
>
> Best regards,
> Adam
>


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

how to beam non-tuplets with tuplets?

[Adam James Wilson]

It seems you can beam together tuplets followed by non-tuplets (v. 2.11):

\times 2/3 {c'16[ c'8 } c'16 c'16]

But beaming together non-tuplets followed by tuplets fails with an
"unexpected ']'" error:

c'16[ c'16 \times 2/3 {c'16 c'8 } ]

Any known methods/hacks to get the second beaming example to work?

Best regards,
Adam


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

Re: how to "damp" TupletBracket slope?

[Adam James Wilson]

Thanks again Kieren and Trevor!

Maybe you can help me with a separate issue involving beaming tuplets
to non-tuplets (I'll also publish this to the list under an
appropriate heading):

It seems you can beam together tuplets followed by non-tuplets:

\times 2/3 {c'16[ c'8 } c'16 c'16]

But beaming together non-tuplets followed by tuplets fails with an
"unexpected ']'" error:

c'16[ c'16 \times 2/3 {c'16 c'8 } ]

Any methods/hacks to get the second beaming example to work?

Best,
Adam

On 9/10/07, Kieren MacMillan <[EMAIL PROTECTED]> wrote:
> Hi Adam,
>
> > I'd like to be able to "damp" TupletBrackets the way you can damp
> > Beams to force horizontal TupletBrackets.  I can't seem to find a
> > similar method in the docs (I'm using 2.11.32).
>
> %%% BEGIN SNIPPET %%%
>
> \version "2.11.32"
>
> triplets = \relative c'''
> {
> \tupletUp
> \times 2/3 { c a e }
> \override TupletBracket #'positions = #'(6 . 6)
> \times 2/3 { c' a e }
> }
>
> \score
> {
> \triplets
> }
>
> %%% END SNIPPET %%%
>
> Hope this helps!
> Kieren.
>
>


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

Re: sunday school songs

[Mark Dewey]

Are they hymns you're dealing with?  If so, I might recommend using a template 
of mine and looking at the source of some full songs, comparing it (the source) 
with the music while looking for how to do certain things.

All of the articles linked from the following URL have hymns/songs made with 
LilyPond, including the source, PDF files and midis:
http://www.hymnwiki.org/wiki/index.php?title=Category:Public_Domain_PDF_Sheet_Music

Here's a template link:
http://www.hymnwiki.org/wiki/images/e/e4/MODEL.ly

I'm sure it requires some explanation, though, if you're new to LilyPond.  So, 
feel free to ask questions.  Remember that anything directly after a percent 
sign is a comment (meaning it doesn't do anything; it's just there for you to 
read, or, it will do something if you remove the percent sign).

If you want some help notating the songs, I may be able to help out at least a 
little (let me know) while you're getting used to things.

- Mark


Tim Litwiller wrote:
I have a bunch on sunday school songs like this that I need to put into 
lilypond so we can make clean nice prints.


I have been playing with it for a week now and going thru the manual and 
tutorial, downloading samples and layout tools like Jedit and the pspad 
plug ins and canorus.


I haven't been able yet to make it look like I want.

I need to have all the stanza's between the music
I need to combine the flags on all notes that where the head don't colide

so far I've been able to either have lyrics or combine notes - but not 
both.

then where notes collide I need to have a flag go each direction.
I've circled examples in the attachment.

Also lilypond is adding naturals in the printout and I haven't yet found 
a way to make it not do that.


I'm not very music literate and we can't afford a commercial music 
program for our sunday school. But I found lilypond and it looked like 
it should do everything we need to have good looking music sheets.  So 
far it has been quite a learning curve but I need help to get past these 
obstacles.


since I can't attach a file here is a link to an example
http://www.litwiller.net/images/fishers.gif











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

GTK and LilyPond

[Mark Dewey]

I use LilyPond 2.10.29 on Windows 2000.

I've long noticed that installing the GTK separately from LilyPond (as it is 
needed for other programs) sometimes causes problems (and so does installing 
LilyPond after installing the separate GTK).

Is it possible to get a distribution of LilyPond that doesn't have the GTK or 
GTK elements bundled, but rather just relies on the one already installed?

Anyway, whenever I install LilyPond, GIMP doesn't work anymore because of 
something to do with this.

When I installed the separate GTK afterward (and then GIMP), this time at 
least, LilyPond was behaving 'strangely' (the computer slowed down 
tremendously, even after all the programs stopped running, and almost crashed; 
I had to restart it to get it back to normal).  GIMP works fine in this case, 
though (until I install a new version of LilyPond).

I know something that could potentially fix the problem, but I'm a little 
afraid to try.  When I install the GTK (with LilyPond already there), it asks 
me if I want to rename some of the LilyPond files (I've always said no).  Will 
LilyPond still work if I rename these files?



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

Re: footnotes?

[Arvid Grøtting]

Wilbert Berendsen <[EMAIL PROTECTED]> writes:

> Is there a way to create footnotes? I.e. a command to add a footnote 
> (containing markup) to the bottom of the current page, without stopping a 
> \score and writing a toplevel \markup ?

I don't think there is[1], and I definitely think it would be useful.

The few times I've needed footnotes I've used end notes instead, using
a \markup block after the score, but then again I mostly typeset quite
short pieces and have only needed to add such notes to either a short
piece or the end of a longer piece.


[1] so, if there is a way, it's fairly new and hasn't been discussed
much

-- Arvid



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

Re: how to "damp" TupletBracket slope?

[Kieren MacMillan]

Hi Adam,


I'd like to be able to "damp" TupletBrackets the way you can damp
Beams to force horizontal TupletBrackets.  I can't seem to find a
similar method in the docs (I'm using 2.11.32).


%%% BEGIN SNIPPET %%%

\version "2.11.32"

triplets = \relative c'''
{
\tupletUp
\times 2/3 { c a e }
\override TupletBracket #'positions = #'(6 . 6)
\times 2/3 { c' a e }
}

\score
{
\triplets
}

%%% END SNIPPET %%%

Hope this helps!
Kieren.



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

Re: how to "damp" TupletBracket slope?

[Trevor Bača]

On 9/10/07, Adam James Wilson <[EMAIL PROTECTED]> wrote:
> I'd like to be able to "damp" TupletBrackets the way you can damp
> Beams to force horizontal TupletBrackets.  I can't seem to find a
> similar method in the docs (I'm using 2.11.32).
>
> It seems that there was a "delta-y" argument for bracket slope in a
> much much older version of Lily . . .
>
> Is there a way of doing this in the current version?


Hi Adam,

If you're wanting to dampen brackets to the make them perfectly flat,
you're in luck: just set the TupletBracket's staff-padding to a
sufficiently large value; the bracket will push away from the staff
and flatten completely. (As a global setting this works well to
produce flat brackets to accompany, for example, flat beams set with
Beam #'positions = #'(x . x).)

If, on the other hand, you're wanting to dampen brackets *not* to make
them perfectly flat but rather to *keep* them sloped (while
simultaneously controlling the *amount* of slope), then that's a
different matter entirely. No idea how you would get at that ...


Trevor.


-- 
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: PianoStaff spacing in 2.11

[Trevor Bača]

On 9/10/07, Neil Puttock <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> A short while back, I was under the misapprehension that there was something
> wrong with the spacing in piano staves when using version 2.11. Having
> erroneously submitted a bug report to this effect, I found out that thanks
> to the new spacing engine, the fixed distance workaround present in 2.10 was
> no longer necessary (hence why the "PianoStaff centred dynamics" template no
> longer works properly).
>
> I have been typesetting a few piano pieces, and have found that the spacing
> can vary wildly, especially when adding dynamics. This is, in my opinion, a
> rather unfortunate situation, and one not in keeping with traditional
> engraving rules for piano music.
>
> My question is this: Is it possible to force fixed distance between the
> staves in a PianoStaff under version 2.11? I've tried various overrides, but
> all they tend to do is influence the minimum spacing and amount of system
> stretching.


Hi Neil,

Have you tried using the alignment-offsets part of the
NonMusicalPaperColumn's line-break-system-details property?

Here's an example where we override the NonMusicalPaperColumn grob in
the Score's context block; the result is completely fixed vertical
distance throughout the score:

%%% BEGIN %%%

\version "2.11.32"

\layout {
   \context {
  \Score
  \override NonMusicalPaperColumn
  #'line-break-system-details =
  #'((alignment-offsets . (0 -14))) } }

\new Score <<
   \new PianoStaff <<
  \new Staff {
 c'1
 \break
 c'1
 \break
 c'1
  }
  \new Staff {
 \clef bass
 c'1
 c'1
 c'1
  }
   >>
>>

%%% END %%%



And here's an example where we override the NonMusicalPaperColumn grob
on the fly at different points (but always at line breaks) throughout
the score; the result is precisely controlled -- but varying --
amounts of vertical space between systems:

%%% BEGIN %%%

\version "2.11.32"

\new PianoStaff <<
   \new Staff {
  \overrideProperty #"Score.NonMusicalPaperColumn"
  #'line-break-system-details
  #'((alignment-offsets . (0 -10)))
  c'1
  \break
  \overrideProperty #"Score.NonMusicalPaperColumn"
  #'line-break-system-details
  #'((alignment-offsets . (0 -20)))
  c'1
  \break
  \overrideProperty #"Score.NonMusicalPaperColumn"
  #'line-break-system-details
  #'((alignment-offsets . (0 -30)))
  c'1
   }
   \new Staff {
  \clef bass
  c'1
  c'1
  c'1
   }
>>

%%% END %%%


Note that you can freely combine the two types of override shown here.
This will let you set a default fixed space for the entire score and
then freely override that default fixed space to other (but equally
specific) values as necessary.

Note also that you use plain old \override in a \context (or \with)
block but that you use the special \overrideProperty command when
making changes to the NonMusicalPaperColumn grob inline with note
entry.

(Note finally that these settings work for ALL types of staff ...
including, but not limited to, piano and other grouped staves.)

If you like this way of accounting for vertical positioning, there's
some more at 11.5.3 "Explicit staff and system positioning".


Trevor.


-- 
Trevor Bača
[EMAIL PROTECTED]
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

how to "damp" TupletBracket slope?

[Adam James Wilson]

I'd like to be able to "damp" TupletBrackets the way you can damp
Beams to force horizontal TupletBrackets.  I can't seem to find a
similar method in the docs (I'm using 2.11.32).

It seems that there was a "delta-y" argument for bracket slope in a
much much older version of Lily . . .

Is there a way of doing this in the current version?

Best regards,
Adam


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

Re: GDP: length/page-splitting of subsections

[John Mandereau]

Le lundi 10 septembre 2007 à 20:49 +0200, Eyolf Østrem a écrit :
> > >BTW I'd like to see an forever-working URL like 
> > >http://lilypond.org/doc/current/Documentation/ (instead of the version; 
> > >should need only one symlink; maybe "current-stable" and "current-dev").
> 
> > Well,
> > http://lilypond.org/doc/v2.11/Documentation/
> > gives you the current-dev.  Yes, you need to update this link whenever we 
> > release a new stable branch... but that only happens once or twice a  
> > year.
> 
> But what the OP said, is true, and a very simple thing to do, and it
> means nobody will have to change their links as often as twice a year
> :-)

That's wrong, the webmaster will have to change the symlinks :-P

Such symlinks already exist, but were only known by the webmasters and
the translators.

Have a look at this updated page to know about those permanent links:
http://lilypond.org/web/documentation
(Wait for one hour or two for the automatic regeneration of lilypond.org
from the web sources.)

Cheers,
John



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

Re: GDP: structure of index

[John Mandereau]

Le lundi 10 septembre 2007 à 11:06 -0700, Graham Percival a écrit :
> Juergen Reuter wrote:
> > Furthermore, I would like to see entries like
> > 
> >   \displayLilyMusic: Displaying LilyPond notation
> >   \displayLilyMusic: Displaying music expressions
> > 
> > rather being structured as follows:
> > 
> >   \displayLilyMusic:
> >   Displaying LilyPond notation
> >   Displaying music expressions
> > 
> 
> I'm not certain if texinfo 4.8 can do that.  Werner, do you know?

I've just looked at Texinfo 4.8 manual (the latest release 4.9 only
differs about texi2dvi, texinfo.tex and some bugfixes), and found no way
to format an index as Juergen suggested.


> If not, we could always make a feature request to the texinfo 
> developers;

It's already in Texinfo TODO file, which is quite big [1] -- Texinfo
needs a lot of C hackers to tackle all TODO items :-|  We can always try
to ask them to raise the priority for implementing this particular
feature.  (I'm suscribed to bug-texinfo, which discusses Texinfo bugs,
development and feature requests.)

[1] http://savannah.gnu.org/cgi-bin/viewcvs/texinfo/texinfo/TODO?rev=HEAD
See also http://www.gnu.org/software/texinfo/


>  it might be possible for them to add it before 4.9.

FWIW 4.9 was released on June 29, and the latest beta is 4.9.92, so they
might add it before 4.11... (or before 5.1 in case they decide to
release 5.0 instead of 4.10)

Cheers,
John



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

GDP: read the 2.11 docs

[Graham Percival]

To anybody involved in the GDP discussion, please take a few minutes to 
look at the documentation for 2.11.  There have been a few significant 
changes since 2.10; please look at those changes so we avoid reinventing 
the wheel.  Specifically,


- Manual is only for lilypond input format.
- Program Usage takes over everything else.
- regtests and tips are gone.
- LSR snippets are on the main page, and there are links from the docs 
to the relevant LSR sections.


Please also don't bother commenting that the main page of the snippets 
is ugly, or that we need more links from docs to LSR.  That's one of 
whole reasons I began GDP.



The idea of a table of comments on the left-hand side of the docs 
(whether frames or CSS) is interesting, and I'm not at all opposed to 
it.  However, I don't know how we would go about doing this.  If anybody 
knows how to do this with texinfo, please discuss.  If not, then my 
"ruthlessly practical" side suggests that we drop the discussion.


Sorry to be a wet blanket, but I'm honestly just trying to save your 
time and effort.

- Graham


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

PianoStaff spacing in 2.11

[Neil Puttock]

Hi everybody,

A short while back, I was under the misapprehension that there was something
wrong with the spacing in piano staves when using version 2.11. Having
erroneously submitted a bug report to this effect, I found out that thanks
to the new spacing engine, the fixed distance workaround present in 2.10 was
no longer necessary (hence why the "PianoStaff centred dynamics" template no
longer works properly).

I have been typesetting a few piano pieces, and have found that the spacing
can vary wildly, especially when adding dynamics. This is, in my opinion, a
rather unfortunate situation, and one not in keeping with traditional
engraving rules for piano music.

My question is this: Is it possible to force fixed distance between the
staves in a PianoStaff under version 2.11? I've tried various overrides, but
all they tend to do is influence the minimum spacing and amount of system
stretching.

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

Re: GDP: rearrangement (third attempt)

[Graham Percival]

fiëé visuëlle wrote:
How about collecting the page layout with other print related stuff like 
lilypond-book, graphics formats etc.?

As collecting the sound output related (everything else than MIDI?)


No, lilypond-book is in the Program Usage now.  The manual deals with 
lilypond input format.


As for MIDI, we barely have three subsections -- if we go the 
merging-subsections route, then we probably only have *one* subsection.


Cheers,
- Graham


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

Re: LilyPond Grand Documentation Project (GDP)

[Neil Puttock]

Hi Graham,

I'm willing to help in any of the trivial, easy or medium categories.

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

Re: GDP: length/page-splitting of subsections

[Reinhold Kainhofer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I know we're now drifting away from the goal of restructuring the 
documentation into sections. Instead, this thread seems to be turning into 
improving the general documentation system, which I regard as a step that 
should be done before going into details of restructuring the actual manual.

- From the mails so far, I think it makes sense to have:
- -) Introductury tutorial covering the basics of Lilypond. The full docs need 
to assume that the reader is aware of these. The current tutorial is too 
basic to help in this regard.
- -) Extensive documentation (basically what we have now, after the 
restructuring)
- -) LSR as an official part on the lilypond page, linked from the doc. The 
regression testing page and the tips pages are a useful piece of resources, 
but with hundreds of examples are simply not usable when you look for 
something specific. LSR should (and is intended to, anyay) take over that 
job.

As a personal comment: The documentation of lilypond is really great!!! It's 
just that due to the load of small pages, it's easy to get lost and hard to 
find a page again when you can't remember exactly.

Am Montag, 10. September 2007 schrieb Rune Zedeler:
> Citat Graham Percival <[EMAIL PROTECTED]>:
> > The all-in-one HTML page is **5 megs**.  I'm astounded that so many
> > people (ie more than 0) are choosing to download that monster _every
> > time_ they want to look something up in the docs.
>
> We don't.
> Browsers have caches, you know :-)

Konqueror even has that nice feature to save a web page locally (in a .war 
file, which ist just a zip file) including all images from that page... It 
just takes a while for the browser to format a 5MB web page correctly, laying 
out all images as they load...


Am Montag, 10. September 2007 schrieb fiëé visuëlle:
> BTW I'd like to see an forever-working URL like http://lilypond.org/
> doc/current/Documentation/ (instead of the version; should need only
> one symlink; maybe "current-stable" and "current-dev").

Fully agree with that!

Another suggestion: set up lsr.lilypond.org to point to the LSR (it might 
still be located on the current .it server, but honestly who remembers that 
URL???). That would also make the LSR appear as an official part of lilypond 
instead of a third-party service.


Am Montag, 10. September 2007 schrieb Rune Zedeler:
> Citat Valentin Villenave <[EMAIL PROTECTED]>:
> > I think CSS allows to do this without needing an extra (ugly) frame.
>
> It is possible with css, but you would have to redownload the entire toc
> each time.
> With frames the toc stays and you only load the pages themself.

But you can't easily bookmark...

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)

iD8DBQFG5a4/TqjEwhXvPN0RAvS5AJ9O/ZOKoOokkzC4AHr0Ik/ENw12ywCfSM0a
L+YSFbu8KZNnzToqvW1hISI=
=3WR+
-END PGP SIGNATURE-


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

Re: GDP: length/page-splitting of subsections

[fiëé visuëlle]

Am 2007-09-10 um 20:45 schrieb Graham Percival:


fiëé visuëlle wrote:
samples (in contrary to the PDF), and often I only need a working  
sample of usage (the in-text samples are often too short or not on  
topic as I understand it or too cluttered - or too simple).
Hmm.  Samples are too sort, too cluttered, or too simple.  That  
will be hard to fix.  :)


I know. Sorry for being no help here. And I didn't mean to blame you  
or anyone.
It's only that I often enough couldn't find a sample or an  
explanation (that I could understand) for my problems.

(I use LilyPond nearly exclusively for folk songs and choir settings...)

I'm very glad that you take on this big task (I know that coding is  
more fun than finding bugs and typos, being a developer and  
typesetter myself). I'd like to help, but simply am swamped with  
other projects.


Enough OT. EOT.

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: Multiple pitched trills, trillspan length

[Kieren MacMillan]

Hi Stefan,


So now the first TrillSpan collides with the second. Is there a
possibility to decimate the length of the trill span somehow?


See .


Cheers,
Kieren.


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

Multiple pitched trills, trillspan length

[Stefan Kägi]

Hi

I have a little issue with pitched trills:
http://lilypond.org/doc/v2.10/Documentation/user/lilypond/Trills#Trills

I'm trying to do this but with multiple trills. So the code looks kind
of like the following:


RH = \relative c'' {

\clef treble
\time 4/4
\key d \minor

16
\pitchedTrill d8.\startTrillSpan f \pitchedTrill cis4\stopTrillSpan
\startTrillSpan e d2\stopTrillSpan 

}

\score {
the known things...

}


So now the first TrillSpan collides with the second. Is there a
possibility to decimate the length of the trill span somehow?

Thx for your hints





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

Re: footnotes?

[Nicolas Sceaux]

Wilbert Berendsen <[EMAIL PROTECTED]> writes:

> Is there a way to create footnotes? I.e. a command to add a footnote 
> (containing markup) to the bottom of the current page, without stopping a 
> \score and writing a toplevel \markup ?

No.  However, adding numbered notes to the end of the book or of a
chapter is quite easily doable.

Footnotes would go in the page footer, so you could manually add a
footnote to the footer of the desired page.  If the notes have very few
lines, it could be automated: some space for footnotes is reserved on
each page, eventually used to hold a short footnote.  In the following
book, the page header is changed according to the current chapter title:
you could adapt it for footnotes.

file titling-commands.ily

nicolas


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

[no subject]

[Stefan Kägi]

[EMAIL PROTECTED]



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

Re: GDP: length/page-splitting of subsections

[Eyolf Østrem]

> >BTW I'd like to see an forever-working URL like 
> >http://lilypond.org/doc/current/Documentation/ (instead of the version; 
> >should need only one symlink; maybe "current-stable" and "current-dev").

> Well,
> http://lilypond.org/doc/v2.11/Documentation/
> gives you the current-dev.  Yes, you need to update this link whenever we 
> release a new stable branch... but that only happens once or twice a  
> year.

But what the OP said, is true, and a very simple thing to do, and it
means nobody will have to change their links as often as twice a year
:-)

e


-- 
love, n.:
When, if asked to choose between your lover
and happiness, you'd skip happiness in a heartbeat.


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

Re: GDP: length/page-splitting of subsections

[Graham Percival]

fiëé visuëlle wrote:


samples (in contrary to the PDF), and often I only need a working sample 
of usage (the in-text samples are often too short or not on topic as I 
understand it or too cluttered - or too simple).


Hmm.  Samples are too sort, too cluttered, or too simple.  That will be 
hard to fix.  :)


BTW I'd like to see an forever-working URL like 
http://lilypond.org/doc/current/Documentation/ (instead of the version; 
should need only one symlink; maybe "current-stable" and "current-dev").


Well,
http://lilypond.org/doc/v2.11/Documentation/
gives you the current-dev.  Yes, you need to update this link whenever 
we release a new stable branch... but that only happens once or twice a 
 year.


My preference is for 2 -- I can't believe that users want to see 
articulations, dynamics, and trills on the same HTML page.  But as I 
said, we should probably disregard my opinion on this issue.


If you rework the docs anyway, then 2 is good. Otherwise I'd prefer 1.


We're reworking the docs now.  :)   ok, one more vote for 2.

Cheers,
- Graham


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

Re: GDP: rearrangement (third attempt)

[Graham Percival]

John Mandereau wrote:

Tu sum up your suggestion, which I like quite much, I propose the
following section (inside chapter 7 "Decorating musical notation", and
replacing "Special use"):

7.6 Note heads and stems
   7.6.1 Stems
   7.6.2 Special noteheads
   7.6.3 Improvisation
   7.6.4 Selecting notation font size
   7.6.5 Hidden notes
   7.6.6 Parentheses


I still this this could be improved, but let's go with it for now (until 
we've resolved the merging subsections)


If we move Stems out of 6.6 Polyphony, then we now have 6.6.6 Automatic 
part combining.  Given the number of bug reports about that, I think 
this is extremely fitting, so I approve of this suggestion.  :)


Cheers,
- Graham


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

Re: I'm having a problem with this file

[Tim Litwiller]

Thanks so much for that, another thing to add to my watch for this list.



Ralph Little wrote:


Tim Litwiller wrote:
Yeh, I'm moving along trying different suggested methods as I go,  
keeping notes as to what works. and what doesn't.



Hi Tim,
Could you mail the file to me as an attachment, I can't seem to 
access the file from gnu.org?


Sounds like things are moving on for you :D

Cheers,
Ralph




Hi,
OK, I have made 2 changes to your file:

First, so that new voices always get the aikenHeads by default, I've 
removed the \aikenHeads setting from \global and added the following 
to \layout:


   \context {
   \Voice
   shapeNoteStyles = ##(do re mi fa #f la ti)
   }

This adds the \aikenHeads definition to the default Voice.
So when using the <<\\>> notation, any new Voices created get 
aikenHeads by default.


The reason that you weren't getting the tenor and bass parts together 
was that they should be encapsulated in << >>.


So you now have:

   <<
   \new Voice = tenor {
   \global
   \PartsThree
   }
   \new Voice = bass {
   \global
   \PartsFour
   }
   >>


instead of :
   \global
   \PartsThree
   \PartsFour

Regards,
Ralph

File follows:

=
\version "2.11.32"
%\include "english.ly"
% template for song with no repeating - several verses and a common 
chorus

\header {
  title="It's a Long, Long Road"
  poet="get from source"
  composer="get from source"
  tagline="Copyright Larry Ensz 2006"
}

\paper {
   %#(set-paper-size "letter")
   %line-width = 189\mm
   %line-width = #(- line-width (* mm  3.00))
   %between-system-space = 6\mm
   %force-assignment = #""
   %between-system-padding = #6
   ragged-bottom=##f
   ragged-last-bottom=##f
}


mBreak = { }

leftbrace = \markup { \override #'(font-encoding . fetaBraces) \lookup 
#"brace260" }

rightbrace = \markup { \rotate #180 \leftbrace }
dropLyrics =
{
   \override LyricText #'extra-offset = #'(0 . -5)
   \override LyricHyphen #'extra-offset = #'(0 . -5)
   \override LyricExtender #'extra-offset = #'(0 . -5)
}
raiseLyrics =
{
   \revert LyricText #'extra-offset
   \revert LyricHyphen #'extra-offset
   \revert LyricExtender #'extra-offset
}
skipFour = \repeat unfold 4 { \skip 8 }

global = {
   \key aes \major
  %\tempo 4=180
  \partial 4
   \autoBeamOff
}

PartsOne = {
  \key aes \major
  \relative c' {
   \voiceOne
   ees4
   aes2. aes4
   f des f aes
   ees1
   b'4\rest ees, f g
   aes2. aes4
   bes2 ees2
   ees1
   \mBreak
   b4\rest ees4 d d
   ees1
   b4\rest ees, f g
   g2. \bar "||" g8^"Chorus" g8
   g4 bes bes aes
   bes4. aes8
   \mBreak
   f4. f8
   ees4 aes c aes
   bes2( bes8) bes8 c des
   ees4 ees4 ees4 des8 c8
   des8 des4
   \mBreak
   des8 des4 des
   c8 c4 c8 c4 bes8 aes
   bes4 f f f
   ees2 g2
   aes1
   }
}

PartsTwo = {
  \key aes \major
  \relative c' {
   \voiceTwo
   ees4
   aes2. aes4
   f des f aes
   ees1
   b'4\rest ees, d d
   bes2. bes4
   ees2 g2
   g1
   b4\rest
   \mBreak
   g aes aes
   g1
   b4\rest ees, d d
   bes2. bes8 bes
   bes4 ees ees ees
   des4. des8
   \mBreak
   des4. des8
   c4 c ees ees
   ees2( ees8) ees8 ees f
   aes4 aes aes ees8 ges
   f8 f4
   \mBreak
   f8 f4 f4
   ees8 ees4 ees8 ees4 ees8 ees
   des4 des des b
   c2 des
   c1
  }
}



PartsThree = {
  \relative c {
   \voiceOne ees4
   aes2. aes4
   f4 des f aes
   ees1
   b1\rest
   ees2. aes4
   g2 bes
   bes1
   d,4\rest
 bes'4 bes bes
   bes1
   d,4\rest aes'4 aes ees
   ees2. ees8 ees
   ees4 aes aes g
   f2
 aes4. aes8
   aes4 aes aes aes
   g2( g8) g8 aes aes
   c4 c c bes8 aes8
   aes8 aes4
 aes8 aes4 aes4
   aes8 aes4 aes8 aes4 g8 aes8
   f4 aes aes aes
   aes2 ees2
   ees1
   \break
  }
}

PartsFour = {
  \relative c {
   \voiceTwo ees4
   aes2. aes4
   f4 des f aes
   ees1
   b1\rest
   aes2. f'4
   ees2 ees2
   ees1
   d4\rest
 ees4 bes bes
   ees1
   d4\rest c bes ees
   aes,2. aes8 aes8
   aes4 aes aes
   c
   des2
 des4. des8
   aes4 aes aes c
   ees2( ees8) ees8 ees ees
   aes4 aes aes aes8 aes8
   des,8 des4

   des8 des4 des4
   aes8 aes4 aes8 aes4 aes8 des8
   des4 des des des
   ees2 ees
   ees1
  }
}


\score {
<<
  \new Staff = top
  { <<
   \override Staff.TimeSignature #'style = #'()
   \set Staff.midiInstrument="recorder"
   \global
   \clef treble
   %\new Devnull="nowhere" \PartsOne
   \new Voice = "soprano" {
   \global  \PartsOne
   }
   \new Voice = "alto" {
   \global
   \PartsTwo
   }  
   \new Lyrics \lyricsto "soprano" { \set stanza = "1. "
   I walked one morn -- ing by the sea, and all the waves reached out 
to me

   I took thier fears, Then let them be.
   }
 %\new Lyrics \lyricsto "nowhere" { \set stanza = "1. "
   %I walked one morn -- ing by the sea, and all the waves reached out 
to me

   %I took thier fears, Then let them be.
   %}
 \new Lyrics \lyric

Re: I'm having a problem with this file

[Ralph Little]

Tim Litwiller wrote:
Yeh, I'm moving along trying different suggested methods as I go,  
keeping notes as to what works. and what doesn't.



Hi Tim,
Could you mail the file to me as an attachment, I can't seem to 
access the file from gnu.org?


Sounds like things are moving on for you :D

Cheers,
Ralph




Hi,
OK, I have made 2 changes to your file:

First, so that new voices always get the aikenHeads by default, I've 
removed the \aikenHeads setting from \global and added the following to 
\layout:


   \context {
   \Voice
   shapeNoteStyles = ##(do re mi fa #f la ti)
   }

This adds the \aikenHeads definition to the default Voice.
So when using the <<\\>> notation, any new Voices created get aikenHeads 
by default.


The reason that you weren't getting the tenor and bass parts together 
was that they should be encapsulated in << >>.


So you now have:

   <<
   \new Voice = tenor {
   \global
   \PartsThree
   }
   \new Voice = bass {
   \global
   \PartsFour
   }
   >>


instead of :
   \global
   \PartsThree
   \PartsFour

Regards,
Ralph

File follows:

=
\version "2.11.32"
%\include "english.ly"
% template for song with no repeating - several verses and a common chorus
\header {
  title="It's a Long, Long Road"
  poet="get from source"
  composer="get from source"
  tagline="Copyright Larry Ensz 2006"
}

\paper {
   %#(set-paper-size "letter")
   %line-width = 189\mm
   %line-width = #(- line-width (* mm  3.00))
   %between-system-space = 6\mm
   %force-assignment = #""
   %between-system-padding = #6
   ragged-bottom=##f
   ragged-last-bottom=##f
}


mBreak = { }

leftbrace = \markup { \override #'(font-encoding . fetaBraces) \lookup 
#"brace260" }

rightbrace = \markup { \rotate #180 \leftbrace }
dropLyrics =
{
   \override LyricText #'extra-offset = #'(0 . -5)
   \override LyricHyphen #'extra-offset = #'(0 . -5)
   \override LyricExtender #'extra-offset = #'(0 . -5)
}
raiseLyrics =
{
   \revert LyricText #'extra-offset
   \revert LyricHyphen #'extra-offset
   \revert LyricExtender #'extra-offset
}
skipFour = \repeat unfold 4 { \skip 8 }

global = {
   \key aes \major
  %\tempo 4=180
  \partial 4
   \autoBeamOff
}

PartsOne = {
  \key aes \major
  \relative c' {
   \voiceOne
   ees4
   aes2. aes4
   f des f aes
   ees1
   b'4\rest ees, f g
   aes2. aes4
   bes2 ees2
   ees1
   \mBreak
   b4\rest ees4 d d
   ees1
   b4\rest ees, f g
   g2. \bar "||" g8^"Chorus" g8
   g4 bes bes aes
   bes4. aes8
   \mBreak
   f4. f8
   ees4 aes c aes
   bes2( bes8) bes8 c des
   ees4 ees4 ees4 des8 c8
   des8 des4
   \mBreak
   des8 des4 des
   c8 c4 c8 c4 bes8 aes
   bes4 f f f
   ees2 g2
   aes1
   }
}

PartsTwo = {
  \key aes \major
  \relative c' {
   \voiceTwo
   ees4
   aes2. aes4
   f des f aes
   ees1
   b'4\rest ees, d d
   bes2. bes4
   ees2 g2
   g1
   b4\rest
   \mBreak
   g aes aes
   g1
   b4\rest ees, d d
   bes2. bes8 bes
   bes4 ees ees ees
   des4. des8
   \mBreak
   des4. des8
   c4 c ees ees
   ees2( ees8) ees8 ees f
   aes4 aes aes ees8 ges
   f8 f4
   \mBreak
   f8 f4 f4
   ees8 ees4 ees8 ees4 ees8 ees
   des4 des des b
   c2 des
   c1
  }
}



PartsThree = {
  \relative c {
   \voiceOne  
   ees4

   aes2. aes4
   f4 des f aes
   ees1
   b1\rest
   ees2. aes4
   g2 bes
   bes1
   d,4\rest
  
   bes'4 bes bes

   bes1
   d,4\rest aes'4 aes ees
   ees2. ees8 ees
   ees4 aes aes g
   f2
  
   aes4. aes8

   aes4 aes aes aes
   g2( g8) g8 aes aes
   c4 c c bes8 aes8
   aes8 aes4
  
   aes8 aes4 aes4

   aes8 aes4 aes8 aes4 g8 aes8
   f4 aes aes aes
   aes2 ees2
   ees1
   \break
  }
}

PartsFour = {
  \relative c {
   \voiceTwo  
   ees4

   aes2. aes4
   f4 des f aes
   ees1
   b1\rest
   aes2. f'4
   ees2 ees2
   ees1
   d4\rest
  
   ees4 bes bes

   ees1
   d4\rest c bes ees
   aes,2. aes8 aes8
   aes4 aes aes
   c
   des2
  
   des4. des8

   aes4 aes aes c
   ees2( ees8) ees8 ees ees
   aes4 aes aes aes8 aes8
   des,8 des4

   des8 des4 des4
   aes8 aes4 aes8 aes4 aes8 des8
   des4 des des des
   ees2 ees
   ees1
  }
}


\score {
<<
  \new Staff = top
  { <<
   \override Staff.TimeSignature #'style = #'()
   \set Staff.midiInstrument="recorder"
   \global
   \clef treble
   %\new Devnull="nowhere" \PartsOne
   \new Voice = "soprano" {
   \global   
   \PartsOne

   }
   \new Voice = "alto" {
   \global
   \PartsTwo
   }   


   \new Lyrics \lyricsto "soprano" { \set stanza = "1. "
   I walked one morn -- ing by the sea, and all the waves reached out to me
   I took thier fears, Then let them be.
   }
  
   %\new Lyrics \lyricsto "nowhere" { \set stanza = "1. "
   %I walked one morn -- ing by the sea, and all the waves reached out 
to me

   %I took thier fears, Then let them be.
   %}
  
   \new Lyrics \lyricsto "alto"  { \set stanza = "2. "
   I walked one morn -- ing at the dawn, When 

Re: GDP: structure of index

[Graham Percival]

Juergen Reuter wrote:

Furthermore, I would like to see entries like

  \displayLilyMusic: Displaying LilyPond notation
  \displayLilyMusic: Displaying music expressions

rather being structured as follows:

  \displayLilyMusic:
  Displaying LilyPond notation
  Displaying music expressions



I'm not certain if texinfo 4.8 can do that.  Werner, do you know?

If not, we could always make a feature request to the texinfo 
developers; it might be possible for them to add it before 4.9.



Given the large size of the documentation, a single person probably can 
not care for documentation-wide consistency of these (important!) 
nitpicks.  Maybe a general good idea is to collect a couple of "do" and 
"don't" examples as guideline for documentation writers?


Oh, totally.  README.txt is intended as that, and the main focus of GDP 
is to fix all these consistency issues.  That's why I have 70 hours 
budgeted for text-entry stuff (ie checking the .tely files) and only 40 
for complicated stuff (like this rearrangement discussion)


Cheers,
- Graham


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

Re: GDP: length/page-splitting of subsections

[Rune Zedeler]

Citat Valentin Villenave <[EMAIL PROTECTED]>:

> Rune: I think it's possible with some JScript tweaking (at least, some
> buzzword-compliant technologies allow to do this without frames).

Maybe. I have just never seen it.
Javadoc still uses frames, and about everything else I have encountered reloads
the entire toc whenever you select a new entry in the toc.



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

Re: GDP: length/page-splitting of subsections

[Valentin Villenave]

2007/9/10, fiëé visuëlle <[EMAIL PROTECTED]>:

> No. I always use the online manual in several tabs (the fewer single
> pages, the fewer tabs!) and a Google tab with "site:lilypond.org/
> doc/...", because it also finds the commands in samples (in contrary
> to the PDF), and often I only need a working sample of usage (the in-
> text samples are often too short or not on topic as I understand it
> or too cluttered - or too simple).

This demonstrates what I said about people not using the LSR manual
search tool :)

Fiëé: you might be interested in opening
http://lsr.dsi.unimi.it/LSR/Manual in your google-tab. (or you might
not :)

> BTW I'd like to see an forever-working URL like http://lilypond.org/
> doc/current/Documentation/ (instead of the version; should need only
> one symlink; maybe "current-stable" and "current-dev").

Oh yes! Veeery good point!

Rune: I think it's possible with some JScript tweaking (at least, some
buzzword-compliant technologies allow to do this without frames). But
you're right, 1993-1994 were fun too :)

Valentin


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

Re: GDP: length/page-splitting of subsections

[fiëé visuëlle]

Am 2007-09-10 um 17:00 schrieb Graham Percival:

- Does anybody _like_ the current layout?  If so, speak up now or  
forever hold your peace.  :)


No. I always use the online manual in several tabs (the fewer single  
pages, the fewer tabs!) and a Google tab with "site:lilypond.org/ 
doc/...", because it also finds the commands in samples (in contrary  
to the PDF), and often I only need a working sample of usage (the in- 
text samples are often too short or not on topic as I understand it  
or too cluttered - or too simple).


BTW I'd like to see an forever-working URL like http://lilypond.org/ 
doc/current/Documentation/ (instead of the version; should need only  
one symlink; maybe "current-stable" and "current-dev").



There are two solutions for this:
1)  Don't split HTML by into subsections; have one html page per  
section.


2)  Merge many subsections.  For example,
6.1 Pitches
6.1.1 Writing pitches(includes 6.1.1, 6.1.2, 6.1.3, 6.1.4, and  
6.1.5 in the latest proposal)

6.1.2 Octaves/jumping pitches   (includes 6.1.6, 6.1.7, and 7.1.8)
6.1.3 Rests(includes 6.1.9 and 6.10)

My preference is for 2 -- I can't believe that users want to see  
articulations, dynamics, and trills on the same HTML page.  But as  
I said, we should probably disregard my opinion on this issue.


If you rework the docs anyway, then 2 is good. Otherwise I'd prefer 1.


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: GDP: rearrangement (third attempt)

[fiëé visuëlle]

Am 2007-09-10 um 18:29 schrieb John Mandereau:


11 Page layout (new chapter)
   11.1 Paper and pages (moved from Spacing issues)
   11.2 Titles and headers
   11.3 Breaks (moved from Spacing issues)

The problem is, this breaks the unity of Spacing stuff in a single
chapter, and if we do this, we must have a look at the subsections  
to be

moved (which I haven't done here in my naive proposal).

Without spacing stuff (can anything else be added to this chapter,
btw?), a chapter about page layout containing only "Titles and  
headers"
would be too small, so IMHO it's not a so good idea.  Rune, we  
welcome a

better and more precise proposal, though ;-)


How about collecting the page layout with other print related stuff  
like lilypond-book, graphics formats etc.?

As collecting the sound output related (everything else than MIDI?)

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: I'm having a problem with this file

[Ralph Little]

Hi Tim,
Could you mail the file to me as an attachment, I can't seem to access 
the file from gnu.org?


Sounds like things are moving on for you :D

Cheers,
Ralph


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

Re: Lilypond fonts in Latex

[fiëé visuëlle]

Am 2007-09-10 um 13:08 schrieb Stuart Pullinger:


Briefly: Has anyone created the font descriptor (*.fd) and style
(*.sty) files that would enable Lilypond's fonts to be used in LaTeX?

I'd like to use Lilypond's fonts in the body of a Latex document as  
well

as using lilpond-book for the musical examples. Searching the
lilypond-user archives reveals this answer which seems to be out of
date:


If you only mean the text fonts: that's Century Schoolbook, part of  
PSNFSS,
see http://www.ctan.org/tex-archive/macros/latex/required/psnfss/ 
psnfss2e.pdf


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: GDP: rearrangement (third attempt)

[John Mandereau]

Le lundi 10 septembre 2007 à 05:22 -0700, Graham Percival a écrit :
> Rune Zedeler wrote:
> > Very first I comment on the stuff I wrote below: When I wrote it I 
> > didn't really notice / think about the fact the the first five sections 
> > are left out. Probably some of my comments are not totally valid. Well, 
> > I will think some more, and post another message about the overall 
> > structure of the manual.
> 
> As I said earlier,
> 
> - the manual will be split even more into Learning Manual / Notation
>   Reference.  This is the notation reference, so we assume that users
>   have read the LM.  They know about music expressions, \override, etc.
>   The LM will be increased to accomodate for this, but that's a separate
>   discussion.
> 
> 
> The division between Basic/Advanced was a somewhat artificial thing for 
> newbies reading the NR for the first time.  But the main use of the NR 
> is to be a *reference* -- ie knowledgeable users look stuff up in it. 
> So I don't think it's worth putting things in a weird order for just to 
> make it easier for new users -- the Learning Manual is the place for 
> them, and that document most definitely *can* and *should* be read from 
> start to finish.

I totally agree with you on these points.




> >>+ 6.4.7 Proportional notation (introduction)
> > 
> > No, this is too layout specific for this section. It has nothing to do 
> > with the musical content, only with how it is displayed.
> 
> Trevor already proposed deleting this entirely.

Shall I go ahead and remove this in master?  I'd add the LSR links in
the deleted subsec to "Proportional notation" in chapter "Spacing
issues".


> ... my general concern with "it isn't musical content, only with how it 
> is displayed" is that most musicians don't make that distinction.  Most 
> people _would_ say that ottava changes pitches.
> 
> OTOH, we try to enforce this mentality in our discussion about key 
> signatures.  Hmm, what would think about
> 
> 6.1 Pitches
> 6.2 Displaying pitches
> (move Transpose into 6.1)
> 6.3 Rhythms
> 6.4 Displaying rhythms
> 6.5 Bars
> (strictly speaking Bars would be a subset of Displaying rhythms, but I 
> think this section works well by itself, with bar numbers, multi-measure 
> rests, and the like all together)

I really like these section names.  Let's adopt them!



> >>+ 6.4.8 Automatic beams
> >>+ 6.4.9 Manual beams
> >>+ 6.4.10 Feathered beams
> > 
> > I don't think that beams belong in this section - they belong together 
> > with phrasing slurs.
> 
> IMO, beaming is intricately bound up in meter.  I could be convinced 
> otherwise, though.  Anybody else have opinions about this?

No, I just second your opinion here too.



> >>  o 8.6 Bowed strings
> >>+ 8.6.1 Artificial harmonics
> > 
> > Well, isn't this also used in classical guitar? I am not sure, though.
>
> I used to get into arguments with a classical guitarist about what 
> artificial vs. harmonics meant.  He thought they were opposite to what 
> orchestral string players did, and I have no knowledge of guitar 
> terminology so I couldn't be certain that he was wrong about that 
> instrument.  To avoid these matters, I called it "artificial harmonics 
> (strings)"

I've played with a classical guitarist for one year, and in two pieces
we played there were artifical harmonics (or if you want to avoid
arguments let's call them just "harmonics").  I'm sure anybody who wants
to notate harmonics for the guitar will most probably get enough
inspiration to look for "harmonics" in the index or look for harmonics
in the section about strings.  That's why we can keep harmonics in the
strings section.


> >>  o 9.4 Titles and headers
> > 
> > I would like a "Page layout" chaper, where this section should go. 
> > Mentioning "multi scores in one files" would also fit nicely in there, 
> > along with the discussion of the paper- and layout-blocks.
> 
> I agree with this, but not very strongly yet.  John, Valentin?  You guys 
> wanted this in Text; feel like defending this position?  :)

Yes.  After arguments brought in this discussion, I can propose (without
being fully convinced):

9 Text (or "Text and vocal music" or "Text and lyrics", I don't mind)
   9.1 Text in a score
   9.2 Text markup
   9.3 Vocal music

10 Input and output (like in Graham's first proposal)

11 Page layout (new chapter)
   11.1 Paper and pages (moved from Spacing issues)
   11.2 Titles and headers
   11.3 Breaks (moved from Spacing issues)

The problem is, this breaks the unity of Spacing stuff in a single
chapter, and if we do this, we must have a look at the subsections to be
moved (which I haven't done here in my naive proposal).

Without spacing stuff (can anything else be added to this chapter,
btw?), a chapter about page layout containing only "Titles and headers"
would be too small, so IMHO it's not a so good idea.  Rune, we welcome a
better and mo

Re: Lilypond fonts in Latex

[Werner LEMBERG]

> >   . The LaTeX encoding of the lilypond font(s) is clearly `U'; it
> > makes no sense to create a new encoding for it.
> 
> Could you explain what you mean by `U'?

Please consult the `fontenc' guide of the LaTeX base distribution.
`U' means `unspecified'.

> The example in the tutorial above uses an encoding called
> TeX'n'ANSI, also called LY1 in LaTeX.

LY1 is only usable for a text font.

> The conversion program afm2pfm requires an encoding files found at
> texmf/dvips/base/texnansi.enc. This encoding doesn't work with the
> feta font - is there an equivalent file for the feta font?

Yes, attached -- those files are created during the build process;
however, they aren't installed (since they are of no use normally).

> If I understand correctly the .enc file matches the TeX glyph name
> to the glyph number in the font. Is this correct?

Yes.


Werner


lilyenc.tar.bz2
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: rearrangement (third attempt)

[John Mandereau]

Le lundi 10 septembre 2007 à 14:37 +0200, Mats Bengtsson a écrit :
> Graham Percival wrote:
> >
> >>>+ 6.6.2 Stems
> >>
> >> Currently, this subsection has nothing to do with polyphony.
> >> Furthermore it is layout specific, and should therefore be postponed.
> >
> > I have _always_ hated this section.  I remember trying -- and failing 
> > -- to find a home for it when I did my very first doc rearrangement, 
> > and it's still a pain.
> >
> > Help?  Anybody have a suggestion for where to move this to?  (or 
> > perhaps delete entirely, and put info about \stemDown... where?)
> How about some combined subsection on (ordinary) notes which deals with 
> both
> note heads and stems? Currently, we don't have any specific subsection 
> on note
> heads (though there are a few related to special notation). Any section 
> that
> describes \xxxDown and \xxxUp macros should also refer to the section
> that describes \voiceOne and \voiceTwo, since that's mostly a better 
> solution.
> (Sorry, couldn't help leaving the structure and talking about content 
> for a moment).

Tu sum up your suggestion, which I like quite much, I propose the
following section (inside chapter 7 "Decorating musical notation", and
replacing "Special use"):

7.6 Note heads and stems
   7.6.1 Stems
   7.6.2 Special noteheads
   7.6.3 Improvisation
   7.6.4 Selecting notation font size
   7.6.5 Hidden notes
   7.6.6 Parentheses

My two cents: maybe "Parentheses" should be included in a (sub)section
in chapter 7, called "Editorial notation", which would also deal with
bracketed dynamics for example.  Then, I don't know where to move
"Coloring objects", what a pain!  What about including it as an example
subsection in "9.3 The \override command", with proper index entries,
and adding a "See also" link from the main page of chapter 7?

Cheers,
John



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

Re: Lilypond fonts in Latex

[Stuart Pullinger]

 
> > 4. Install the feta type1 fonts. As in:
> > http://www.mamster.net/tex/latex-fontfaq-amster-burton.pdf
> 
> This is probably the most straightforward way; additionally, you can
> use such fonts with virtually all TeX environments because all of them
> support Type 1 fonts.

After trying the other methods, this is the one I am now using ;^)
 
>   . The LaTeX encoding of the lilypond font(s) is clearly `U'; it
> makes no sense to create a new encoding for it.

Could you explain what you mean by `U'? The example in the tutorial
above uses an encoding called TeX'n'ANSI, also called LY1 in LaTeX. The
conversion program afm2pfm requires an encoding files found at
texmf/dvips/base/texnansi.enc. This encoding doesn't work with the feta
font - is there an equivalent file for the feta font? If I understand
correctly the .enc file matches the TeX glyph name to the glyph number
in the font. Is this correct?

Thanks for your help,
Stuart


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

Re: GDP: length/page-splitting of subsections

[Eyolf Østrem]

On 10.09.2007 (11:09), Kieren MacMillan wrote:
> Hi Graham (et al.):

> >Does anybody _like_ the current layout?


> That being said...  ;-)

> >My preference is for 2

> Me 2.

Me 3.

-- 
paak, n:A stadium or inclosed playing field. To put or leave (a
a vehicle) for a time in a certain location.
patato, n:  The starchy, edible tuber of a widely cultivated plant.
Septemba, n:The 9th month of the year.
shua, n:Having no doubt; certain.
sista, n:   A female having the same mother and father as the speaker.
tamato, n:  A fleshy, smooth-skinned reddish fruit eaten in salads
or as a vegetable.
troopa, n:  A state policeman.
Wista, n:   A city in central Masschewsetts.
yaad, n:A tract of ground adjacent to a building.
-- Massachewsetts Unabridged Dictionary


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

Re: GDP: rearrange manual

[Graham Percival]

John Mandereau wrote:


We could use @anchor to get links (@ref's in Info) on the same page, but
I'm not sure *Menu items can redirect to an @anchor.


@menu items direct to @section items.  This is no problem.


We will decide about having larger HTML pages (and thus larger Info
nodes) in a further step of the Grand Documentation Project.  Now we
only decide about naming new chapters and sections, moving sections
between chapters and subsections between sections.


Sorry, I disagree.  If we decide to merge an average of 4 subsections 
into a single subsection, that will drastically change the way the 
chapter/sections look.


If we were just talking about one or two specific subsections, I'd agree 
with you, but a general change like this should be settled now.  For 
example, if we combine subsections, then it makes sence for 6.1 and 6.2 
to be a single section.


Cheers,
- Graham


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

Re: GDP: length/page-splitting of subsections

[John Mandereau]

Le lundi 10 septembre 2007 à 08:00 -0700, Graham Percival a écrit :
> To summarize some discussions:
> - there seems to be considerable dislike for the current 
> "one-short-subsection-per-HTML-page" layout of the manual.  That 
> surprises me, since I've never had a problem with it, but of course I'm 
> intimately familiar with the layout of the manual, so I'm happy to 
> disregard my own opinion in this matter.
> 
> - Does anybody _like_ the current layout?  If so, speak up now or 
> forever hold your peace.  :)
> 
> 
> There are two solutions for this:
> 1)  Don't split HTML by into subsections; have one html page per section.
> 
> 2)  Merge many subsections.  For example,
> 6.1 Pitches
> 6.1.1 Writing pitches(includes 6.1.1, 6.1.2, 6.1.3, 6.1.4, and 6.1.5 
> in the latest proposal)
> 6.1.2 Octaves/jumping pitches   (includes 6.1.6, 6.1.7, and 7.1.8)
> 6.1.3 Rests(includes 6.1.9 and 6.10)
> 
> the names obviously need work.
> 
> 
> My preference is for 2 -- I can't believe that users want to see 
> articulations, dynamics, and trills on the same HTML page.  But as I 
> said, we should probably disregard my opinion on this issue.


I vote for option 2 too, as it's a better compromise between easier full
text search and load time when reading docs online.

John



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

Re: GDP: length/page-splitting of subsections

[Kieren MacMillan]

Hi Graham (et al.):


Does anybody _like_ the current layout?


In some ways, my opinion won't matter, because I don't use (nor do I  
really understand why anyone else uses) the HTML manual -- the PDF  
documentation is all I ever use because:

1. It's perfect for printing;
2. Full-text searching is better, faster, and more convenient;
3. It doesn't require me to be on-line to access it (nor to have/ 
build a local copy of the HTML docs).


That being said...  ;-)


My preference is for 2


Me 2.

Best regards,
Kieren.


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

GDP: length/page-splitting of subsections

[Graham Percival]

To summarize some discussions:
- there seems to be considerable dislike for the current 
"one-short-subsection-per-HTML-page" layout of the manual.  That 
surprises me, since I've never had a problem with it, but of course I'm 
intimately familiar with the layout of the manual, so I'm happy to 
disregard my own opinion in this matter.


- Does anybody _like_ the current layout?  If so, speak up now or 
forever hold your peace.  :)



There are two solutions for this:
1)  Don't split HTML by into subsections; have one html page per section.

2)  Merge many subsections.  For example,
6.1 Pitches
6.1.1 Writing pitches(includes 6.1.1, 6.1.2, 6.1.3, 6.1.4, and 6.1.5 
in the latest proposal)

6.1.2 Octaves/jumping pitches   (includes 6.1.6, 6.1.7, and 7.1.8)
6.1.3 Rests(includes 6.1.9 and 6.10)

the names obviously need work.


My preference is for 2 -- I can't believe that users want to see 
articulations, dynamics, and trills on the same HTML page.  But as I 
said, we should probably disregard my opinion on this issue.


Thoughts?
- Graham


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

Re: GDP: rearrange manual

[John Mandereau]

Le lundi 10 septembre 2007 à 15:31 +0200, Reinhold Kainhofer a écrit :
> Am Montag, 10. September 2007 schrieb Graham Percival:
> > Rune Zedeler wrote:
> > > Well, in its current state I find the "each subsection has its own page"
> > > version of the manual unusable, and therefore always uses the one big
> > > page manual. I suggest that we gives each section its own page containing
> > > section and all subsections. Ofcourse each section should still contain a
> > > table of links, but the links should stay on the same page (just as the
> > > one big page documentation does now).

We could use @anchor to get links (@ref's in Info) on the same page, but
I'm not sure *Menu items can redirect to an @anchor.



> Often I know what I need, but I don't know how to name it exactly, so an 
> index 
> with some selected keywords is not so helpful. In these cases, I tend to go 
> to a page that treats that subject, and do a full text search (or with the 
> short subsections in the lilypond documentation click through all subsections 
> of that sections, manually scanning the section for what I'm looking for). If 
> lilypond's documentation has larger sections (one for each larger topic), 
> doing a text search is possible and I don't have to "read" (i.e. quickly scan 
> each page visually for what I'm looking for).
> 
> The other reason is that it's easier to remember where to find somethings. 
> Currently, whenever I look for that nice lilypond example of all 
> articulations, I go to the contents, search for "articulation", and then from 
> that page, I know I have to take the "Articulations" link to the page I'm 
> actually looking for.
> 
> Having everything related on one page removes the need to click through many 
> pages, and additionally makes it possible to print out only the wanted 
> section.

The PDF manual is certainly much more suitable for printing, and easy
full text searching is one purpose of the big page HTML manual.

We will decide about having larger HTML pages (and thus larger Info
nodes) in a further step of the Grand Documentation Project.  Now we
only decide about naming new chapters and sections, moving sections
between chapters and subsections between sections.

Cheers,
John



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

Re: Lilypond fonts in Latex

[Werner LEMBERG]

> Briefly: Has anyone created the font descriptor (*.fd) and style
> (*.sty) files that would enable Lilypond's fonts to be used in
> LaTeX?

No.

> 1. Use lilypond-book - Seems to create a large amount of whitespace
> around the character.

The surrounding whitespace can be suppressed; however, it is quite
inconvenient to do that in case you want to access just a single glyph
of the font.

> 2. Use a tool such as otftotfm to install the emmentaler*.otf fonts.
> Use a tool such as autoinst or fontools to create the fd and sty
> files.  - These tools don't seem to like the emmentaler fonts,
> possibly something to do with the size being reported as 0?

Hmm.  Since the emmentaler fonts definitely work it looks like a bug
in otftotfm or the related tools.

> 3. Copy the metafont source files (*.mf) to my TeX directory and
> create the fd and sty files manually.

This will give suboptimal results (this is, bitmap glyphs only) in
case you want to create PDF or PS output.

> 4. Install the feta type1 fonts. As in:
> http://www.mamster.net/tex/latex-fontfaq-amster-burton.pdf

This is probably the most straightforward way; additionally, you can
use such fonts with virtually all TeX environments because all of them
support Type 1 fonts.

The LaTeX support should be quite easy:

  . The LaTeX encoding of the lilypond font(s) is clearly `U'; it
makes no sense to create a new encoding for it.

  . Write a script which converts the lilypond glyph names in the AFM
or ENC file(s) into LaTeX commands which map to glyph indices.
Since the glyph names contain both dots and digits, it's probably
best to define and access those glyphs with macros (untested):

   \def\fetadef#1#2{%
 \expandafter\expandafter\expandafter\chardef
   \expandafter\csname #1\endcsname #2}

   -> \fetadef{rests.M2}{38}

   \def\fetaglyph#1{%
 \expandafter\csname feta#1\endcsname}

   -> \fetaglyph{rests.M2}

Since some of those names are extremely long you might manually add
some shorthands where necessary.


  Werner


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

Re: GDP: rearrange manual

[John Mandereau]

Le lundi 10 septembre 2007 à 14:46 +0200, Mats Bengtsson a écrit :
> Yes, I guess my main point was the on-line manual, where the splitting into
> separate HTML pages is a problem in some cases, like Valentin just
> illustrated. As far as I understand, it's the texinfo -> HTML conversion 
> that
> imposes the constraint that each subsection ends up in a separate HTML.
> It would really be a pity to be forced to use a specific kind of document
> structure just because these tools are not so flexible.

But Texinfo does not force us to have one HTML page per subsection!
HTML splitted pages are generated just like Info nodes, with the @node
command.  E.g. if you want to get a whole section in one single page,
you just need to remove @node commands for all its subsections.

Cheers,
John



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

Re: GDP: rearrange manual

[Reinhold Kainhofer]

Am Montag, 10. September 2007 schrieb Graham Percival:
> Rune Zedeler wrote:
> > Well, in its current state I find the "each subsection has its own page"
> > version of the manual unusable, and therefore always uses the one big
> > page manual. I suggest that we gives each section its own page containing
> > section and all subsections. Ofcourse each section should still contain a
> > table of links, but the links should stay on the same page (just as the
> > one big page documentation does now).
>
> What makes the "each subsection has its own page" unusable?  Is it the
> lack of a good index?  

Often I know what I need, but I don't know how to name it exactly, so an index 
with some selected keywords is not so helpful. In these cases, I tend to go 
to a page that treats that subject, and do a full text search (or with the 
short subsections in the lilypond documentation click through all subsections 
of that sections, manually scanning the section for what I'm looking for). If 
lilypond's documentation has larger sections (one for each larger topic), 
doing a text search is possible and I don't have to "read" (i.e. quickly scan 
each page visually for what I'm looking for).

The other reason is that it's easier to remember where to find somethings. 
Currently, whenever I look for that nice lilypond example of all 
articulations, I go to the contents, search for "articulation", and then from 
that page, I know I have to take the "Articulations" link to the page I'm 
actually looking for.

Having everything related on one page removes the need to click through many 
pages, and additionally makes it possible to print out only the wanted 
section.

> One possibility is to have larger subsections, but use @subheading to
> visually divide the page.  

Yes, I would prefer that. 

> In the table of contents, we would see a 
> single "Dynamics" subsection, but the HTML page itself would be

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-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: rearrangement (third attempt)

[Eyolf Østrem]

On 10.09.2007 (09:06), Kieren MacMillan wrote:
> Hi Valentin,

> >I doubt we have enough stuff to make a whole "Page layout" chapter.

> I disagree...

> There's *more* than enough for a Page Layout chapter: even if some (much?) 
> of the material is referenced elsewhere/earlier, it would be beneficial to 
> have a single coherent section in which all of the features are collated.

Agree wholeheartedly. Besides, what's wrong with having a chapter
which is smaller than others if it fulfills an independent function?
Which page layout definitely is.

e


-- 
   I'm killing time while I wait for life to shower me with meaning and
happiness.-- Calvin


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

Re: GDP: rearrangement (third attempt)

[Kieren MacMillan]

Hi Valentin,


I doubt we have enough stuff to make a whole "Page layout" chapter.


I disagree...

There's *more* than enough for a Page Layout chapter: even if some  
(much?) of the material is referenced elsewhere/earlier, it would be  
beneficial to have a single coherent section in which all of the  
features are collated.


Cheers,
Kieren.


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

Re: GDP: rearrange manual

[Valentin Villenave]

2007/9/10, Graham Percival <[EMAIL PROTECTED]>:

> Err.. we're talking about Changing defaults, a chapter which hasn't been
> significantly changed in the past three years, and which you've
> _already_ complained as being a pile of garbage... and using this as an
> argument for changing the way the rest of the manual is displayed?  :)

I guess garbage can be fun though :)
This whole chapter has to be rewritten indeed. But in this case, I
just wanted to emphasize the positive (pedagogical) aspects of a
linear documentation. Maybe such tricks are more convenient in LM than
NR anyway.

> I disagree; I think the short loading time for pages is important.

Oh yes. Good point.
Like Rune, I'm always using the big-page manual; but that's because I
have a DSL connection, and Firefox makes searching very easy...

Valentin


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

Re: GDP: rearrange manual

[Eyolf Østrem]

On 10.09.2007 (05:28), Graham Percival wrote:
> Eyolf Østrem wrote:
> >I would also say -- although this may exceed the limits of what kind
> >of suggestions were allowed -- that one thing that is missing is a
> >comprehensive survey of the syntax of Lilypond.

> Like Appendix E Cheat sheet ?  It's quite limited at the moment, but is 
> that what you're talking about?

Something like that, but also containing a summary of what is in ch. 9
Changing defaults and 10. File structure. Anyone who uses LP is to
some extent a programmer, and one doesn't have to stray very far from
the simplest pieces before it becomes necessary to look into those
chapters. But although the information is probably there, there is a
gap between the simple basics and the syntactically quite complicated
stuff in scheme: it takes a while to get one's head around "Why should
this word be in CamelCase?  Why are there no braces here?" etc. 

In an earlier mail, I mentioned one such case:

  "9.1.5 Changing context default settings 
   
   \layout { 
 ... 
 \context { 
   \Staff 
 ... 
 } 
   } 
   Here \Staff takes the existing definition for context Staff from the 
  identifier \Staff." 
   
  Why is this an identifier, which usually (it seems) are lower-case? Why isn't 
  what follows it enclosed in {}? And, again, do the three "Staff"s in the 
  explaining sentence refer to three different (types of) objects? Is the first 
  \Staff a different item than the context Staff, which just happens to have 
  the same name? Is this \Staff the "identifier \Staff" which is mentioned 
  later in the sentence, or is it yet another thing with the same name? 
  I'm confused... Mostly because of the {}-less syntax, but also by the 
  same-same-but-different names. 

> Expanding the Cheat sheet has been discussed from time to time; it comes 
> down to resources.  At the moment, I think it's more important to clean up 
> the notation reference.  If we have time/energy left afterwards, we could 
> tackle this... or if anybody wants to volunteer specifically to do this, 
> that would be great; I could help you get started.

I fully understand the resources thing, and I greatly appreciate your
work on this. 

Eyolf

-- 
Seek for the Sword that was broken:
In Imladris it dwells;
There shall be counsels taken
Stronger than Morgul-spells.

There shall be shown a token
That Doom is near at hand,
For Isildur's Bane shall waken,
And the Halfling forth shall stand.
-- J. R. R. Tolkien


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

Re: GDP: rearrangement (third attempt)

[Valentin Villenave]

2007/9/10, Graham Percival <[EMAIL PROTECTED]>:

> >>+ 6.2.1 Clef
> >>+ 6.2.2 Key signature
> >
> > Hmm, neither clefs nor key signatures affect pitches. They only affect
> > how they are displayed.
>
> Yes, true.  Rename section?

Hell yes!
What about :
"Pitches notation" or something like that?
This way, both transposing and ottava stuff should stay.

> 6.1 Pitches
> 6.2 Displaying pitches
> (move Transpose into 6.1)
> 6.3 Rhythms
> 6.4 Displaying rhythms
> 6.5 Bars
> (strictly speaking Bars would be a subset of Displaying rhythms, but I
> think this section works well by itself, with bar numbers, multi-measure
> rests, and the like all together)
>

> Hmmm... would we have enough material to create a
> Display polyphony
> section?

This could be worth trying.

> > I do not in the same way see the meaning in "decorating musical notation".

Rune: As i've told John before, "decorating" isn't necessarily
pejorative. It isn't just about making the score fancy and eye-candy
at all. When writing my music, I always start by entering just the
notes, then I print it and go to the piano to add every performance
indications. These are two completely different steps, different
logics.

I've managed to convince John, so maybe I'll convince you too :)


> > Well, isn't this also used in classical guitar? I am not sure, though.
>
> I used to get into arguments with a classical guitarist about what
> artificial vs. harmonics meant.  He thought they were opposite to what
> orchestral string players did, and I have no knowledge of guitar
> terminology so I couldn't be certain that he was wrong about that
> instrument.  To avoid these matters, I called it "artificial harmonics
> (strings)"

Well, artificial harmonics can be used in guitar music, but it is
non-standard. It is "officially" a bowed-strings practice.

> >>  o 8.7 Ancient notation
> >
> > Hmm, not really instrument specific.
>
> "Specific-purpose notation" ?
> "Notation for limited use" ?

"Specific notation"?

> >>  o 9.1 Text in a score
> >
> > This is definitely decorative. Put it in the decorative section now it's
> > there.
> >
> >>  o 9.2 Text markup section
> >
> > This would be a great candidate for its own chapter, imo.
>
> IMO we should include 9.1 with 9.2.

Agreed. But let's put the lyrics stuff before.

>
> >>  o 9.3 Vocal music
> >
> > If we consider the human voice an instrument, then this is very
> > instrument specific. Move it to that section.
>
> That's where it used to be, but singers complained.  :)
>
> >>  o 9.4 Titles and headers
> >
> > I would like a "Page layout" chaper, where this section should go.
> > Mentioning "multi scores in one files" would also fit nicely in there,
> > along with the discussion of the paper- and layout-blocks.
>
> I agree with this, but not very strongly yet.  John, Valentin?  You guys
> wanted this in Text; feel like defending this position?  :)

Well, IIRC it was your idea :)
I like that every text elements can be in a same chapter (I'd have add
instrument names as well). The main question a user will ask is: "ok,
I've typeset my music; now how can I add some text".
I do think we should start with Vocal music.
Other than that, i'm fine with it as it is.
Plus, I doubt we have enough stuff to make a whole "Page layout" chapter.

Valentin


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

Re: GDP: rearrange manual

[Mats Bengtsson]

Yes, I guess my main point was the on-line manual, where the splitting into
separate HTML pages is a problem in some cases, like Valentin just
illustrated. As far as I understand, it's the texinfo -> HTML conversion 
that

imposes the constraint that each subsection ends up in a separate HTML.
It would really be a pity to be forced to use a specific kind of document
structure just because these tools are not so flexible.

Being able to quickly scroll through a section in the on-line documentation
is clearly very valuable when you're looking for an answer to a specific
problem but don't know exactly what subsection to look into, or to get an
overview of a more complicated solution as in the example Valentin
brought up.

  /Mats

Valentin Villenave wrote:

Just a question...

(by the way, is it really relevant to cross post this entire
discussion to -devel?)

I'm finishing translating the current chapter #9 (changing-defaults)
and here's what I see:

9.3.2
"Suppose we want to move the fingering indication in the fragment below:"
===> but it actually doesn't tell how to do it; you have to keep reading...

9.3.3
"The HTML page that we found in the previous section"
===> now we're beginning to understand what we've seen previously.
*but* we still don't have the bloody answer :)

9.3.4
"Recall that we wanted to change the position of the..."
===> And *now* we have the answer...

It's fun, interesting, thrilling, very well thought. great pedagogy;
but it implies that the subsections are absolutely not independant
from each other.

Therefore, I would second Rune's proposal for gathering subsections on
a single page.
Or we'd have to rewrite this whole section (and that would be a pity).

Graham, what do you think?
Valentin


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


--
=
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-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: GDP: rearrangement (third attempt)

[Eyolf Østrem]

On 10.09.2007 (05:22), Graham Percival wrote:
> Rune Zedeler wrote:

> >And in all cases, it is way too early. The user has not even learned what 
> >the "4" in "c4" means.

> Tutorial.  If a user hasn't read the LM, they're on their own and I have 
> *no* sympathy for them.

That's definitely the right approach. The *Documentation* should be in
a reference form, arranged according to contents.  This, IMHO, relates
also to the question: bigger or smaller sections/subsections: it is
rarely the case that one has a very specific question which can be
answered by looking at a small subsection. My own usage is to open the
pdf, search through the whole document for some word I expect to be
relevant, and hopefully find the answer, either in some specific
place, or from what I can piece together. I hardly ever use the ToC.
For the same reason, I hardly ever use the one-page-per-subsection
version of the doc.

> ... my general concern with "it isn't musical content, only with how it is 
> displayed" is that most musicians don't make that distinction.  Most 
> people _would_ say that ottava changes pitches.

This is also the right way to go, I think. Whether or not something
CHANGES the pitch, it still has to do with representing pitches, and I
have no problem at all with a main heading "Pitches", which then, if
necessary, can be subdivided into "Entering pitches" and "modifying
the display" or something.

> >I don't think that beams belong in this section - they belong together 
> >with phrasing slurs.

> IMO, beaming is intricately bound up in meter.  I could be convinced 
> otherwise, though.  Anybody else have opinions about this?


> >> o 8.7 Ancient notation
> >Hmm, not really instrument specific.

> "Specific-purpose notation" ?
> "Notation for limited use" ?

Why not a section of its own? 

> >> o 9.3 Vocal music
> >If we consider the human voice an instrument, then this is very 
> >instrument specific. Move it to that section.

> That's where it used to be, but singers complained.  :)

And rightly so... :-) If it should go anywhere else, it could perhaps
be together with "Text", since that is (mainly) what distinguishes it
from "normal" music.


Eyolf

-- 
David Brinkley: The daily astrological charts are precisely where, in my
  judgment, they belong, and that is on the comic page.
George Will:  I don't think astrology belongs even on the comic pages.
  The comics are making no truth claim.
Brinkley:  Where would you put it?
Will:  I wouldn't put it in the newspaper.  I think it's transparent rubbish.
  It's a reflection of an idea that we expelled from Western thought in the
  sixteenth century, that we are in the center of a caring universe.  We are
  not the center of the universe, and it doesn't care.  The star's alignment
  at the time of our birth -- that is absolute rubbish.  It is not funny to
  have it intruded among people who have nuclear weapons.
Sam Donaldson:  This isn't something new.  Governor Ronald Reagan was sworn
  in just after midnight in his first term in Sacramento because the stars
  said it was a propitious time.
Will:  They [horoscopes] are utter crashing banalities.  They could apply to
  anyone and anything.
Brinkley:  When is the exact moment [of birth]?  I don't think the nurse is
  standing there with a stopwatch and a notepad.
Donaldson:  If we're making decisions based on the stars -- that's a cockamamie
  thing.  People want to know.
-- "This Week" with David Brinkley, ABC Television, Sunday, May 8, 1988,
   excerpts from a discussion on Astrology and Reagan


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

Re: GDP: rearrange manual

[Graham Percival]

Valentin Villenave wrote:

Just a question...

(by the way, is it really relevant to cross post this entire
discussion to -devel?)


We're talking about some major lilypond development work here. 
Documentation is still development.  A better question is "is it really 
relevant to cross post this entire discussion to -user?"  In this case, 
I think it's worth it.



I'm finishing translating the current chapter #9 (changing-defaults)
and here's what I see:


It's fun, interesting, thrilling, very well thought. great pedagogy;
but it implies that the subsections are absolutely not independant
from each other.

Therefore, I would second Rune's proposal for gathering subsections on
a single page.
Or we'd have to rewrite this whole section (and that would be a pity).
Graham, what do you think?
Valentin



Err.. we're talking about Changing defaults, a chapter which hasn't been 
significantly changed in the past three years, and which you've 
_already_ complained as being a pile of garbage... and using this as an 
argument for changing the way the rest of the manual is displayed?  :)


I disagree; I think the short loading time for pages is important.  Now, 
I'm not opposed to merging existing subsections... and I was already 
planning on completely rewriting Changing defaults as part of GDP.


Cheers,
- Graham



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

Re: GDP: rearrangement (third attempt)

[Mats Bengtsson]

Graham Percival wrote:



   + 6.6.2 Stems


Currently, this subsection has nothing to do with polyphony.
Furthermore it is layout specific, and should therefore be postponed.


I have _always_ hated this section.  I remember trying -- and failing 
-- to find a home for it when I did my very first doc rearrangement, 
and it's still a pain.


Help?  Anybody have a suggestion for where to move this to?  (or 
perhaps delete entirely, and put info about \stemDown... where?)
How about some combined subsection on (ordinary) notes which deals with 
both
note heads and stems? Currently, we don't have any specific subsection 
on note
heads (though there are a few related to special notation). Any section 
that

describes \xxxDown and \xxxUp macros should also refer to the section
that describes \voiceOne and \voiceTwo, since that's mostly a better 
solution.
(Sorry, couldn't help leaving the structure and talking about content 
for a moment).


   /Mats


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

Re: GDP: rearrange manual

[Valentin Villenave]

Just a question...

(by the way, is it really relevant to cross post this entire
discussion to -devel?)

I'm finishing translating the current chapter #9 (changing-defaults)
and here's what I see:

9.3.2
"Suppose we want to move the fingering indication in the fragment below:"
===> but it actually doesn't tell how to do it; you have to keep reading...

9.3.3
"The HTML page that we found in the previous section"
===> now we're beginning to understand what we've seen previously.
*but* we still don't have the bloody answer :)

9.3.4
"Recall that we wanted to change the position of the..."
===> And *now* we have the answer...

It's fun, interesting, thrilling, very well thought. great pedagogy;
but it implies that the subsections are absolutely not independant
from each other.

Therefore, I would second Rune's proposal for gathering subsections on
a single page.
Or we'd have to rewrite this whole section (and that would be a pity).

Graham, what do you think?
Valentin


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

Re: GDP: rearrange manual

[Graham Percival]

Eyolf Østrem wrote:

I would also say -- although this may exceed the limits of what kind
of suggestions were allowed -- that one thing that is missing is a
comprehensive survey of the syntax of Lilypond.


Like Appendix E Cheat sheet ?  It's quite limited at the moment, but is 
that what you're talking about?


Expanding the Cheat sheet has been discussed from time to time; it comes 
down to resources.  At the moment, I think it's more important to clean 
up the notation reference.  If we have time/energy left afterwards, we 
could tackle this... or if anybody wants to volunteer specifically to do 
this, that would be great; I could help you get started.


Cheers,
- Graham


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

Re: GDP: rearrangement (third attempt)

[Graham Percival]

Rune Zedeler wrote:
Very first I comment on the stuff I wrote below: When I wrote it I 
didn't really notice / think about the fact the the first five sections 
are left out. Probably some of my comments are not totally valid. Well, 
I will think some more, and post another message about the overall 
structure of the manual.


As I said earlier,

- the manual will be split even more into Learning Manual / Notation
 Reference.  This is the notation reference, so we assume that users
 have read the LM.  They know about music expressions, \override, etc.
 The LM will be increased to accomodate for this, but that's a separate
 discussion.


The division between Basic/Advanced was a somewhat artificial thing for 
newbies reading the NR for the first time.  But the main use of the NR 
is to be a *reference* -- ie knowledgeable users look stuff up in it. 
So I don't think it's worth putting things in a weird order for just to 
make it easier for new users -- the Learning Manual is the place for 
them, and that document most definitely *can* and *should* be read from 
start to finish.



   + 6.2.1 Clef
   + 6.2.2 Key signature


Hmm, neither clefs nor key signatures affect pitches. They only affect 
how they are displayed.


Yes, true.  Rename section?


   + 6.2.4 Instrument transpositions


No, This subsection is very advanced (try reading it!) - I think it is 
way too early in the manual.

I am not even sure, that I understand it properly.


It makes sense to have this next to Transposition.  Making that 
subsection easier to read is certainly a goal of later stages of GDP.



   + 6.2.5 Ottava brackets


No, again they do not affect pitches. They just affect how they are 
displayed.


Summa summarum I only accepted the "Transpose" subsection in this 
section - and hence really do not think that this section has any 
purpose.


Rename section?  Alternately, where should we move those subsections to?

And in all cases, it is way too early. The user has not even 
learned what the "4" in "c4" means.


Tutorial.  If a user hasn't read the LM, they're on their own and I have 
*no* sympathy for them.




   + 6.3.5 Automatic note splitting


This does not work before the "Bars" section.
I see no problem in simply moving this to there.


Could do... I'm certainly not opposed to this change, but I'll need a 
bit more convincing.



   + 6.4.7 Proportional notation (introduction)


No, this is too layout specific for this section. It has nothing to do 
with the musical content, only with how it is displayed.


Trevor already proposed deleting this entirely.

... my general concern with "it isn't musical content, only with how it 
is displayed" is that most musicians don't make that distinction.  Most 
people _would_ say that ottava changes pitches.


OTOH, we try to enforce this mentality in our discussion about key 
signatures.  Hmm, what would think about


6.1 Pitches
6.2 Displaying pitches
(move Transpose into 6.1)
6.3 Rhythms
6.4 Displaying rhythms
6.5 Bars
(strictly speaking Bars would be a subset of Displaying rhythms, but I 
think this section works well by itself, with bar numbers, multi-measure 
rests, and the like all together)



   + 6.4.8 Automatic beams
   + 6.4.9 Manual beams
   + 6.4.10 Feathered beams


I don't think that beams belong in this section - they belong together 
with phrasing slurs.


IMO, beaming is intricately bound up in meter.  I could be convinced 
otherwise, though.  Anybody else have opinions about this?



   + 6.6.2 Stems


Currently, this subsection has nothing to do with polyphony.
Furthermore it is layout specific, and should therefore be postponed.


I have _always_ hated this section.  I remember trying -- and failing -- 
to find a home for it when I did my very first doc rearrangement, and 
it's still a pain.


Help?  Anybody have a suggestion for where to move this to?  (or perhaps 
delete entirely, and put info about \stemDown... where?)



   + 6.6.5 Collision resolution


No, this should be postponed to some "tweaking" section. A "Polyphony" 
section should not contain layout-specific subsections.


Hmmm... would we have enough material to create a
Display polyphony
section?


   * 7 Decorating musical notation


The way I always thought of the distinction between "basic" and 
"advanced" notation is that the basic notation contained the parts that 
lilypond understands the musical meaning of whereas the advanced 
notation was the parts that lilypond does not know how to interpret 
musically. I.e. if you do stuff that you have read about in the "basic" 
section, the generated midi will (or at least should) reflect it; if you 
do stuff in the "advanced" section, the midi will not reflect it.
I can see that this is not strictly correct, but this is the way I have 
always thought about it and therefore I think that the distinction made 
great s

Re: GDP: rearrange manual

[Graham Percival]

Trevor Bača wrote:

~ subsection 8.4.3 "Proportional notation" can be removed completely
in favor of subsection 11.6.5 "Proportional notation"


I'd rather not remove subsections yet; we'll do that when we GDPify that 
particular chapter.



~ subsections 8.4.4 "Clusters" and 8.4.5 "Special noteheads" can
become the very last subsections of section 6.1 "Pitches"


General note: I'd like to have between 5 and 9 subsections inside each 
section.  Besides, IMO "clusters" are polyphony.  :)



~ subsection 8.4.8 "Selecting notation font size"; how did this ever
wind up here? I don't understand the intent of this section; it talks
only about notehead font size (not about font sizes in general), so if
we keep it (which seems unnecessary, actually) then it should go to
section 6.1 "Pitches"


It doesn't belong in pitches, but I really don't know what to do with 
it.  The whole 7.6 Special use  (in the new arrangement) is kind-of 
giving up; I'd really like to move those sections elsewhere, or get a 
better title, or something.




(I make the preceding recommendation on contemporary notation based on
the fact that we've come a *TREMENDOUSLY* far way with contemporary
notation in the last major releases and I think that the most
professional way to reflect this fact is to un-ghetto-ize the
contemporary stuff and just include it -- elegantly and cleanly -- in
the other major sections of the manual.)


Yes, absolutely.  Already done. :)

Cheers,
- Graham


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

Re: GDP: rearrangement (third attempt)

[Graham Percival]

Tim Litwiller wrote:

In email setting
under your account
Composition & Addressing - do you have it set to Compose message in HTML 
format
and then if you have preferred to recieve message format as plaintext in 
the addressbook.

if they are different thunderbird will try to convert


Thank you!  I was always looking in Preferences, instead of Account 
settings.  I mean, Preferences _does_ include a section about "html 
preferences", but it didn't include "turn it off".  :|


Cheers,
- Graham


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

Re: GDP: rearrange manual

[Graham Percival]

Rune Zedeler wrote:

Well, in its current state I find the "each subsection has its own page" version
of the manual unusable, and therefore always uses the one big page manual.
I suggest that we gives each section its own page containing section and all
subsections. Ofcourse each section should still contain a table of links, but
the links should stay on the same page (just as the one big page documentation
does now).
  

What makes the "each subsection has its own page" unusable?  Is it the
lack of a good index?  That's certainly something I plan on improving in
GDP.

Given that all subsections for the same section live on the same webpage I agree
with graham that further splitting would be a good idea.
  

One possibility is to have larger subsections, but use @subheading to
visually divide the page.  In the table of contents, we would see a
single "Dynamics" subsection, but the HTML page itself would be

Dynamics


Dynamics (absolute)

\ff \mp blah blah


Dynamics (crescendi)

\cr \! blah blah


Dynamics (positioning)

\override blah blah


This will satisfy my desire to have short, logically-bundles pieces of
information.  When a newbie is browsing the docs, he'll easily see the
"Dynamics (positioning)" section, so if he cares about that info he can
read it.

Cheers,
- Graham



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

Lilypond fonts in Latex

[Stuart Pullinger]

Hi,

Briefly: Has anyone created the font descriptor (*.fd) and style
(*.sty) files that would enable Lilypond's fonts to be used in LaTeX?

I'd like to use Lilypond's fonts in the body of a Latex document as well
as using lilpond-book for the musical examples. Searching the
lilypond-user archives reveals this answer which seems to be out of
date:

http://lists.gnu.org/archive/html/lilypond-user/2006-08/msg00115.html

I have found the feta20.tex file but I presume this is a left-over from
the days when Lilypond used TeX as its layout engine.

As I understand it, there are 4 options open to me:

1. Use lilypond-book - Seems to create a large amount of whitespace
around the character.

2. Use a tool such as otftotfm to install the emmentaler*.otf fonts.
Use a tool such as autoinst or fontools to create the fd and sty files.
http://www.ece.ucdavis.edu/cerl/publications/owens:2006:tia/owens-otfinst-tugboat2006.pdf
- These tools don't seem to like the emmentaler fonts, possibly
something to do with the size being reported as 0?

3. Copy the metafont source files (*.mf) to my TeX directory and create
the fd and sty files manually.

4. Install the feta type1 fonts. As in:
http://www.mamster.net/tex/latex-fontfaq-amster-burton.pdf

I'm going to try option 3. If anyone has any advice or experience in
doing this it would be greatly appreciated.

Stuart Pullinger


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

Re: LilyPond Grand Documentation Project (GDP)

[Joseph Haig]

I should be able to help with some of the trivial to easy sections,
and possibly some medium.

Thanks for your work on the documentation.  It is one of the best of
any project I have seen.

Regards,

Joe


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

footnotes?

[Wilbert Berendsen]

Is there a way to create footnotes? I.e. a command to add a footnote 
(containing markup) to the bottom of the current page, without stopping a 
\score and writing a toplevel \markup ?

tia,
Wilbert Berendsen

-- 
http://www.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi


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