Re: A simple diagram of a .ly file?
Don Blaheta wrote:
Finally, the score. A score looks
like this:
\score {
\midi { ... }
\layout { ... }
...
}
No, the music expression has to come before the \midi and
\layout blocks (at least in most LilyPond versions).
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
Graham Percival wrote: I'll add some info like this, but I'll make it clear that a lilypond file _usually_ has three parts, that this is a simplification, and that users should consult section x.y for an accurate description. I think you need to make clear that the .ly format is actually very much free-form, and that you are merely listing conventions. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ray! And a happy new year to you too!
I found a similar problem with understanding when and how tweaking
properties can be used, so I know what you mean. I've got no excuse:
the manual even tells you what to look up, how and in which order, but
it is one of those that you read, think Yeah, I understand that, then
find yourself unable to actually do any of it! A bit like doing
Schenkerian analysis really. It's really easy if you know the answer
before you start :) Lilypond is a salutary experience and has made me a
lot more tolerant of some of my first-year C programming students!
I don't know if this is just because the problem of music layout is
inherently complex. Maybe. Or perhaps I'm just getting old.
One thing about syntax and layout: I do find the lilypond mode for
emacs rather useful. If I'm thinking about higher things, I'm still
sufficiently inexperienced to write c2' instead of c'2, and the syntax
colouring of emacs immediately points up the error. I use Debian
Gnu/Linux so I just installed it from the repository. I don't know
about its availability for other platforms, or if similar capabilities
exist for other portable editors (jedit and kate are popular around
here). But it might be worth looking into. It might not be so good at
helping with global structure though.
I hope you carry on with Lilypond. It seems to me like using LaTeX.
Dreadfully over-complicated at first, but with familiarisation comes
the feeling of amazement that you could ever have put up with what you
were using before, and astonishment that you ever found it hard to use.
Nick/.
http://cmt.gla.ac.uk
On 5 Jan 2006, at 4:54 am, Ray wrote:
First off, I think Lilypond is amazing and I had very few problems
installing
it or using it, despite a relatively limited musical knowledge. I'm an
amateur songwriter with no ambitions of ever going pro but wanted to
print out
my music as a gift for my mom at Christmas. We're talking very simple
stuff:
a melody, lyrics, and the markup guitar chords at (approximately) the
right
time.
Through the tutorial I quickly gained fluency in the make up of an .ly
file,
but I found that as the file got larger it got harder and harder to
keep track
of. Furthermore, when any kind of bug appeared it was almost
impossible to
sleuth out...as there is almost no documentation (that I could find,
anyway)
dealing with the syntax or _general_ form of a .ly document. I don't
see this
as a failing per se, but perhaps it might be something that folks
could push
for as time permits? Alternatively, additional templates might be
nice, ones
that address non-classical music forms.
In my case, I found it hard not to compare Lilypond to HTML...they
both seem
essentially like markup languages and they both have header files.
Getting
the hang of Lilypond _should_ be relatively easy. But having a visual
sense
of the .ly body is much, much harder. In the example files it's
hard to
discern what are the variables and what are the Lilypond syntax codes
(color
coding the examples would be a great boon for anyone trying to figure
them
out). And there doesn't seem to be any kind of simple discussion
about how
to organize a file, such as:
A .ly file has 3 basic parts. The header, the body, and the score.
In the
header, info about the piece is given (composer, title, etc.) as well
as any
other useful info the program may need but which doesn't relate to the
notes
themselves. The body is where the notes and the lyrics are set down.
The
score is where the printing (whether to paper or MIDI) is done.
Variables
are written in the 'body' part and then used later as part of the
score.
I'm not even sure I'm right about what I've just written, actually,
but it's
what I'm gleaning from the current examples, most of which are fine for
explaining the particular microscopic issue but which don't place it
in a
macroscopic context. After about 2 weeks of solid sleuthing and head
scratching, I am still having a heck of a time getting my .ly file to
print
a pdf and a MIDI file at the same time, and I haven't had any luck in
using
the score section. I can get a nice pdf if I comment out my score
part,
but then it won't play MIDI. I also have had a heck of a time with
getting
my lyrics to match the right notes. I tried using the \lyrics line
but
couldn't get the syntax to work.
Also, what the tutorial needs is some kind of sense of how these
smaller
pieces fit into a larger whole. It's easy enough to see that {a2 b1
c4is
(d8 e16)} will write appropriate notes. It's much harder to know
what's
going wrong when they _don't_ appear that way as part of a larger song.
Please don't take this as a vent or that I'm upset---I'm not: I could
never
write music like this without Lilypond and really want to become more
fluent
in writing it so that it doesn't take me so long to write songs down.
If I
can help in
Re: A simple diagram of a .ly file?
On 4-Jan-06, at 8:54 PM, Ray wrote:
Furthermore, when any kind of bug appeared it was almost impossible to
sleuth out...as there is almost no documentation (that I could find,
anyway)
dealing with the syntax or _general_ form of a .ly document. I don't
see this
as a failing per se, but perhaps it might be something that folks
could push
for as time permits? Alternatively, additional templates might be
nice, ones
that address non-classical music forms.
Did you read chapter 4: putting it all together? Section 4.2 is
specifically aimed at solving this issue... this is an honest question,
not a rhetorical one. If section 4.2 wasn't understandable, I should
work on that. If you didn't notice 4.2, then I should work on
improving its visibility (say, by having a link to it from within the
tutorial).
In the example files it's hard to
discern what are the variables and what are the Lilypond syntax codes
(color
coding the examples would be a great boon for anyone trying to figure
them
out).
Color coding is a feature of editors. I know that emacs and vim do
syntax highlighting; I'm pretty sure that jedit uses it as well.
And there doesn't seem to be any kind of simple discussion about how
to organize a file, such as:
A .ly file has 3 basic parts. The header, the body, and the score.
In the
header, info about the piece is given (composer, title, etc.) as well
as any
other useful info the program may need but which doesn't relate to the
notes
themselves. The body is where the notes and the lyrics are set down.
The
score is where the printing (whether to paper or MIDI) is done.
Variables
are written in the 'body' part and then used later as part of the
score.
Most people have said that since the lilypond syntax is so flexible, it
doesn't make sense to include such information; I take the opposite
view. We need to have _some_ discussion about the general syntax -- in
the tutorial section -- since so many people are confused by this.
There's a technical description of the syntax in 5.8, but we should
cover some of that material in the tutorial.
I've bumped this higher on my list of stuff to do.
If I can help in providing some new documentation along these lines
please let me
know.
Of course you can help! See
http://lilypond.org/web/devel/participating/documentation-adding
Just remember to be as specific as possible. there isn't enough docs
about guitars isn't very helpful; saying a lot of guitar music uses
BLAH; it would help those users if you added blah blah foo to the
manual and included an example like { \blah \blah \foo } is
_extremely_ helpful.
1. An annotated deconstruction of a well known song (melody and
vocals).
Preferably several---a classic rock piece, a classical piece, and a
more
complex piece would work nicely.
That's been proposed, and one or two people have offered to do so, but
I haven't seen them yet. There's room for them in chapter 4, but I'd
prefer short pieces (or portions of pieces). And by short, I mean
about eight or sixteen bars (depending on the complexity of the piece).
If the example is longer than that, people will be less likely to read
the whole thing carefully... besides, the shorter the example, the less
work you need to do in writing the annotations. :)
3. A dictionary of syntax codes, linked (again) directly to larger
examples
so that we can see how they work. Saying \score { . . . } doesn't
really
help us if what's inside the brackets is a multi-nested set of
commands.
It's been proposed... there's an index, and we may soon have a command
index, with links to the manual. As for larger (presumably annotated)
examples... I'm not certain about that.
There's basically two sides to basic lilypond use: knowing what certain
commands do (say, looking up \repeat to figure out that you want
\repeat volta 2 (... or is that \repeat 2 volta ? :)), and knowing how
to fit them together. Putting them together is a general input file
thing, and should be discussed on its own.
5. Much more detailed syntax debugging, with a list of what the error
codes
mean.
That would be a big technical undertaking, which I can't see happening
in the near future.
6. Perhaps, some clearer discussion about how to best _organize_ a
song so
that as one writes, changes lyrics, switches notes around, the piece
needs as
little rewriting as possible.
4.1 attempts to address this... again, did you notice it, or was it
lacking?
7. The MIDI info seems quite thin.
If you know any more info about MIDI, please let me know. :)
There are three categories of problems with the docs:
1. Stuff I'm aware of, and is on my list of things to fix.
2. Stuff I'm not aware of, but can either fix or put on my list of
things to fix.
3. Stuff I may or may not be aware of, but am not able to fix due to
my lack of knowledge. MIDI certainly qualifies for this, as does
everything in chapter 7.
Cheers,
- Graham
Re: A simple diagram of a .ly file?
Quoth Graham Percival:
On 4-Jan-06, at 8:54 PM, Ray wrote:
Furthermore, when any kind of bug appeared it was almost impossible
to sleuth out...as there is almost no documentation (that I could
find, anyway) dealing with the syntax or _general_ form of a .ly
document.
Did you read chapter 4: putting it all together? Section 4.2 is
specifically aimed at solving this issue... this is an honest question,
not a rhetorical one. If section 4.2 wasn't understandable, I should
work on that. If you didn't notice 4.2, then I should work on
improving its visibility (say, by having a link to it from within the
tutorial).
I don't know about Ray, but I can say that for myself, I never really
noticed Section 4 there; because the manual is not really structured as
a read-straight-through document (yes, I know you can get it in that
form, but the default is clickable-ToC), I sort of bounced around.
But I've just now read it, and it *really* doesn't address this concern,
which is also a problem I've had. That chapter is still all about
tweaking templates. I realise that everyone learns differently, but
when I was first figuring LP out I would've really appreciated something
that just gave the layout of a file, almost like a BNF grammar (but
don't call it that or you'll scare people away). E.g.
Every Lilypond document has three parts: a header, other definitions,
and the score, in that order. The header looks like this:
\header {
...
}
and contains lines giving the title, composer, and so on (see section
X.Y). The other definitions can actually be empty, but many lilypond
users like defining the melody or harmony at this point, to make their
file more modular and easily organised. (See section Z.W for how to
make and access these definitions.) Finally, the score. A score looks
like this:
\score {
\midi { ... }
\layout { ... }
...
}
The \midi block can be left blank, or it can contain tempo information
(or it can be omitted entirely if you don't want MIDI output). The
layout block contains global information about staff layout (see
section U.V). In the main body of the \score block comes the actual
music, which can be typed in directly or can refer back to music entered
in the other definitions section in the middle of the file. See
sections S-T for how to enter the music itself.
Finally, it is recommended that at the top of the file, before even
the \header block, you include two lines to let the lilypond
interpreter know what style of input you are using:
\version 2.6.0
\include english.ly
The first line gives your current lilypond version; if you ever
upgrade, lilypond will be able to warn you about changes you need to
make. The language definition need not match your native language or
those of the lyrics in the file, but indicates how you refer to
different notes: what the English-speaking world calls B flat and
notates bf in lilypond, the German-speaking world calls B, and the
French-speaking world calls si, so lilypond needs to know which
naming system you're using. See section Q.R for a list of valid choices.
The important thing to remember is that for anything but a detailed
program reference, you can give the big picture without telling the
whole story all at once. Yes, lilypond will let you omit \layout
sometimes, but if you say that, then you have to talk about when and
why. And then the reader gets confused, and you've not helped much.
Sure, you can arrange your file in a variety of ways, but it doesn't
hurt to say it has three parts..., because it *can* and that will work
just fine until the user understands enough to want to rearrange it.
I meant to just type a short example, but it looks like what I've
written is just about right for the first page of the section I'm
envisioning. Feel free to use it as you like
There are three categories of problems with the docs:
1. Stuff I'm aware of, and is on my list of things to fix.
Is your list public or semi-public? That might help. Could we maybe
use the wiki for some of this?
--
-=-Don [EMAIL PROTECTED]http://www.blahedo.org/-=-
UNIX is user friendly. It's just very selective about who its friends are.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
On 6-Jan-06, at 6:53 PM, Don Blaheta wrote: Quoth Graham Percival: Did you read chapter 4: putting it all together? Section 4.2 is specifically aimed at solving this issue... this is an honest question, not a rhetorical one. If section 4.2 wasn't understandable, I should work on that. If you didn't notice 4.2, then I should work on improving its visibility (say, by having a link to it from within the tutorial). I don't know about Ray, but I can say that for myself, I never really noticed Section 4 there; because the manual is not really structured as a read-straight-through document (yes, I know you can get it in that form, but the default is clickable-ToC), I sort of bounced around. Ok. I'll add links from the tutorial or something. But I've just now read it, and it *really* doesn't address this concern, which is also a problem I've had. That chapter is still all about tweaking templates. Only one section is. Another is on general lilypond usage (which could apply to templates), but the third is about overlapping notation, which has nothing to do with templates. I realise that everyone learns differently, but when I was first figuring LP out I would've really appreciated something that just gave the layout of a file, almost like a BNF grammar (but don't call it that or you'll scare people away). E.g. Have you read 5.7? That's where the BNF-type thing should go. If 5.7 isn't technical / strict enough for you, please send me more info to include in it. Every Lilypond document has three parts: a header, other definitions, and the score, in that order. The header looks like this: ... although this type of definition would be useful, I'm torn on whether to include it in the tutorial. It would certainly help some people... but I also winced when I read it, since it's incorrect. Now, it's quite common in North American schools to teach incorrect, but useful, information. I remember being by a teacher that you couldn't do 5-4 (I think I was 6 years old) and pointed out that the weatherman talked about minus 1, so why not? It isn't uncommon to be told ok, remember how a few years ago you learned that foo? Well, that's not actually right; actually, bar happens. That even happened in high school (such as 16-year old). Some of it was unintentional (like the math teacher that claimed that there were three kinds of numbers: positive, negative, and absolute. Absolute numbers aren't positive, apparently). I don't know if this kind of educational philosophy is practiced in Europe. I certainly hope not, since I think it's terrible. :( However, it does make things easier for some students (and certainly for the teachers) I'll add some info like this, but I'll make it clear that a lilypond file _usually_ has three parts, that this is a simplification, and that users should consult section x.y for an accurate description. I meant to just type a short example, but it looks like what I've written is just about right for the first page of the section I'm envisioning. Feel free to use it as you like I will. There are three categories of problems with the docs: 1. Stuff I'm aware of, and is on my list of things to fix. Is your list public or semi-public? That might help. Could we maybe use the wiki for some of this? It's not worth a wiki. Contributed material should be sent to me and/or lilypond-devel, and I'm the only person who should be editing my list of things I need to fix. :) I'll send a list of things out in a bit over a week. There are a bunch of things I want to fix before inviting people to compare the manual with my list of stuff to do (and that's what will happen as soon as I post such a list :) Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
A simple diagram of a .ly file?
First off, I think Lilypond is amazing and I had very few problems installing
it or using it, despite a relatively limited musical knowledge. I'm an
amateur songwriter with no ambitions of ever going pro but wanted to print out
my music as a gift for my mom at Christmas. We're talking very simple stuff:
a melody, lyrics, and the markup guitar chords at (approximately) the right
time.
Through the tutorial I quickly gained fluency in the make up of an .ly file,
but I found that as the file got larger it got harder and harder to keep track
of. Furthermore, when any kind of bug appeared it was almost impossible to
sleuth out...as there is almost no documentation (that I could find, anyway)
dealing with the syntax or _general_ form of a .ly document. I don't see this
as a failing per se, but perhaps it might be something that folks could push
for as time permits? Alternatively, additional templates might be nice, ones
that address non-classical music forms.
In my case, I found it hard not to compare Lilypond to HTML...they both seem
essentially like markup languages and they both have header files. Getting
the hang of Lilypond _should_ be relatively easy. But having a visual sense
of the .ly body is much, much harder. In the example files it's hard to
discern what are the variables and what are the Lilypond syntax codes (color
coding the examples would be a great boon for anyone trying to figure them
out). And there doesn't seem to be any kind of simple discussion about how
to organize a file, such as:
A .ly file has 3 basic parts. The header, the body, and the score. In the
header, info about the piece is given (composer, title, etc.) as well as any
other useful info the program may need but which doesn't relate to the notes
themselves. The body is where the notes and the lyrics are set down. The
score is where the printing (whether to paper or MIDI) is done. Variables
are written in the 'body' part and then used later as part of the score.
I'm not even sure I'm right about what I've just written, actually, but it's
what I'm gleaning from the current examples, most of which are fine for
explaining the particular microscopic issue but which don't place it in a
macroscopic context. After about 2 weeks of solid sleuthing and head
scratching, I am still having a heck of a time getting my .ly file to print
a pdf and a MIDI file at the same time, and I haven't had any luck in using
the score section. I can get a nice pdf if I comment out my score part,
but then it won't play MIDI. I also have had a heck of a time with getting
my lyrics to match the right notes. I tried using the \lyrics line but
couldn't get the syntax to work.
Also, what the tutorial needs is some kind of sense of how these smaller
pieces fit into a larger whole. It's easy enough to see that {a2 b1 c4is
(d8 e16)} will write appropriate notes. It's much harder to know what's
going wrong when they _don't_ appear that way as part of a larger song.
Please don't take this as a vent or that I'm upset---I'm not: I could never
write music like this without Lilypond and really want to become more fluent
in writing it so that it doesn't take me so long to write songs down. If I
can help in providing some new documentation along these lines please let me
know.
As an enthusiastic beginner learning the ropes, what I would love to see is:
1. An annotated deconstruction of a well known song (melody and vocals).
Preferably several---a classic rock piece, a classical piece, and a more
complex piece would work nicely.
2. Color-coded examples throughout, so that the variable names and the .ly
codes are more easily distinguishable.
3. A dictionary of syntax codes, linked (again) directly to larger examples
so that we can see how they work. Saying \score { . . . } doesn't really
help us if what's inside the brackets is a multi-nested set of commands.
4. The tutorial examples reused in larger pieces so that we can more clearly
see how the small pieces become part of a larger whole.
5. Much more detailed syntax debugging, with a list of what the error codes
mean.
6. Perhaps, some clearer discussion about how to best _organize_ a song so
that as one writes, changes lyrics, switches notes around, the piece needs as
little rewriting as possible.
7. The MIDI info seems quite thin.
If anyone out there knows answers or if this info already exists and I've
just been missing it, please post and tell me about it. I'd love to get more
fluent with this neat program and look forward to helping improve it.
Happy New Year 2006 to all!
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
Am 2006-01-05 um 05:54 schrieb Ray:
Alternatively, additional templates might be nice, ones
that address non-classical music forms.
Here's a two-voices-with-lyrics-and-chords template for you.
(It's public domain, use and distribute at will.)
3. A dictionary of syntax codes, linked (again) directly to larger
examples
so that we can see how they work. Saying \score { . . . } doesn't
really
help us if what's inside the brackets is a multi-nested set of
commands.
That would be really valuable!
6. Perhaps, some clearer discussion about how to best _organize_ a
song so
that as one writes, changes lyrics, switches notes around, the
piece needs as
little rewriting as possible.
I'd appreciate comments on the attachment.
7. The MIDI info seems quite thin.
The MIDI output of LilyPond is poor; I'd offer some Euros for an
enhancment, as mentioned in the Why aren't repeats unfolded
automatically in MIDI? thread.
Greetlings from Lake Constance
---
fiëé visuëlle
Henning Hraban Ramm
http://www.fiee.net
http://angerweit.tikon.ch/lieder/
http://www.cacert.org (I'm an assurer)
\version 2.6.3
\header{
title = Your Song
poet = T:
composer = M:
% instrument = 2 voc + git
source =
maintainer = Henning Hraban Ramm
maintainerWeb = http://angerweit.tikon.ch/lieder/;
lastupdated = 2006-01-05
tagline =
copyright =
}
global = {
\clef treble
\key a \minor
\time 4/4
}
guitarChords = \chordmode {
% put your guitar chords here
% use the same repeats as in the voices!
}
dynamics = \relative c {
% use this to influence MIDI dynamics
r1\mp
}
% if you use \voiceOne and \voiceTwo,
% you can print two voices on one staff
upperVoice = \relative c'' {
%\voiceOne
\repeat volta 2 {
}
\alternative {
{ }
{ }
}
}
lowerVoice = \relative c' {
%\voiceTwo
\repeat volta 2 {
}
\alternative {
{ }
{ }
}
}
text = \lyricmode {
%\set stanza = 1.
% You know how to write ly -- rics, donât you?
}
% Paper Output
\score {
\context ChordNames {
% \germanChords
\set chordChanges = ##t
\guitarChords
}
\context Staff = Upper
\global
\context Voice = one \upperVoice
%\context Voice = two \lowerVoice
\lyricsto one \new Lyrics { \text }
% comment this if you need only one voice:
\context Staff = Lower
\global
%\context Voice = one \upperVoice
\context Voice = two \lowerVoice
\layout {
indent = 0\cm
}
}
% MIDI Output
\score {
\unfoldRepeats { % otherwise you get no repeats in the MIDI
\context Staff = chords
\set Staff.midiInstrument = fx 4 (atmosphere)
\context Voice = chords {
\dynamics \akkorde
}
\context Staff = Upper
\set Staff.midiInstrument = violin
\context Voice = ober \upperVoice
\context Staff = Lower
\set Staff.midiInstrument = viola
\context Voice = unter \lowerVoice
}
\midi{ \tempo 4=180 } % tempo doesn't change in most players
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
Sorry, the first version of the template contained some untranslated
leftovers from my German version and thus won't work.
Greetlings from Lake Constance
---
fiëé visuëlle
Henning Hraban Ramm
http://www.fiee.net
http://angerweit.tikon.ch/lieder/
http://www.cacert.org (I'm an assurer)
\version 2.6.3
\header{
title = Your Song
poet = T:
composer = M:
% instrument = 2 voc + git
source =
maintainer = Henning Hraban Ramm
maintainerWeb = http://angerweit.tikon.ch/lieder/;
lastupdated = 2006-01-05
tagline =
copyright =
}
global = {
\clef treble
\key a \minor
\time 4/4
}
guitarChords = \chordmode {
% put your guitar chords here
% use the same repeats as in the voices!
}
dynamics = \relative c {
% use this to influence MIDI dynamics
r1\mp
}
% if you use \voiceOne and \voiceTwo,
% you can print two voices on one staff
upperVoice = \relative c'' {
%\voiceOne
\repeat volta 2 {
}
\alternative {
{ }
{ }
}
}
lowerVoice = \relative c' {
%\voiceTwo
\repeat volta 2 {
}
\alternative {
{ }
{ }
}
}
text = \lyricmode {
%\set stanza = 1.
% You know how to write ly -- rics, donât you?
}
% Paper Output
\score {
\context ChordNames {
% \germanChords
\set chordChanges = ##t
\guitarChords
}
\context Staff = Upper
\global
\context Voice = one \upperVoice
%\context Voice = two \lowerVoice
\lyricsto one \new Lyrics { \text }
% comment this if you need only one voice:
\context Staff = Lower
\global
%\context Voice = one \upperVoice
\context Voice = two \lowerVoice
\layout {
indent = 0\cm
}
}
% MIDI Output
\score {
\unfoldRepeats { % otherwise you don't get repeats in the MIDI
\context Staff = chords
\set Staff.midiInstrument = fx 4 (atmosphere)
\context Voice = chords {
\dynamics \guitarChords
}
\context Staff = Upper
\set Staff.midiInstrument = violin
\context Voice = Upper \upperVoice
\context Staff = Lower
\set Staff.midiInstrument = viola
\context Voice = Lower \lowerVoice
}
\midi{ \tempo 4=180 } % tempo doesn't change in most players
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A simple diagram of a .ly file?
Ray wrote:
Through the tutorial I quickly gained fluency in the make up of an .ly file,
but I found that as the file got larger it got harder and harder to keep track
of. Furthermore, when any kind of bug appeared it was almost impossible to
sleuth out...as there is almost no documentation (that I could find, anyway)
dealing with the syntax or _general_ form of a .ly document. I don't see this
as a failing per se, but perhaps it might be something that folks could push
for as time permits? Alternatively, additional templates might be nice, ones
that address non-classical music forms.
One answer to this problem is to use jEdit, which includes
an assistant to setup a template that matches your specific
needs.
...
A .ly file has 3 basic parts. The header, the body, and the score. In the
header, info about the piece is given (composer, title, etc.) as well as any
other useful info the program may need but which doesn't relate to the notes
themselves. The body is where the notes and the lyrics are set down. The
score is where the printing (whether to paper or MIDI) is done. Variables
are written in the 'body' part and then used later as part of the score.
This is merely a convention. I hope you have realized that there
is no need at all to use variables, for example. However, I and
most other people find that it helps to structure your file.
I'm not even sure I'm right about what I've just written, actually, but it's
what I'm gleaning from the current examples, most of which are fine for
explaining the particular microscopic issue but which don't place it in a
macroscopic context. After about 2 weeks of solid sleuthing and head
scratching, I am still having a heck of a time getting my .ly file to print
a pdf and a MIDI file at the same time, and I haven't had any luck in using
the score section.
Basically, the structure of the score block, if you want both
MIDI and PDF output, should be:
\score{
Here comes the music as {...} or ...
\layout{...}
\midi{...}
}
One tricky detail is that if you don't have any \midi, then you
don't need any \layout either, but as soon as you have a \midi,
you also explicitly have to include a \layout as well to also get
a PDF.
I can get a nice pdf if I comment out my score part,
but then it won't play MIDI. I also have had a heck of a time with getting
my lyrics to match the right notes. I tried using the \lyrics line but
couldn't get the syntax to work.
The basic idea is very simple, provide a name for the music
voice that the lyrics should follow:
\context Voice = theMelody {...}
then use \lyricsto to attach your lyrics to that voice:
\new Lyrics \lyricsto theMelody {Here come the ly -- rics}
This is not in the tutorial, you have to read the main manual.
Also, what the tutorial needs is some kind of sense of how these smaller
pieces fit into a larger whole. It's easy enough to see that {a2 b1 c4is
(d8 e16)} will write appropriate notes. It's much harder to know what's
going wrong when they _don't_ appear that way as part of a larger song.
Please don't take this as a vent or that I'm upset---I'm not: I could never
write music like this without Lilypond and really want to become more fluent
in writing it so that it doesn't take me so long to write songs down. If I
can help in providing some new documentation along these lines please let me
know.
Yes, please take this opportunity as a relative beginner, to
come with suggestions for improvements on the documentation.
I've used the program for almost 10 years, so it's much harder
for me to provide suggestions for improvements that are relevant
to the beginner. Note that the manual for version 2.7 includes
many updates that also are relevant to version 2.6, but haven't
been included in that manual.
Send any comments to the mailing list.
/Mats
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
