#c
in stead of cis
?cis
anyway
()
Please read this document carefully. If you are still at loss, send your questions to the mailing list, and not to authors directly.
Note: relative paths are meant to be relative to the source directory
The DOS port is done with the cygnus gnu/windows32 port of the GNU utils. It does not work with windows 3.x; you need Windows-NT (95/98?). This is not a recommendation, however. We recommend you use Unix, in particular, use GNU/Linux. For further information see README-W32.
LilyPond uses features of bison version 1.25. Please confirm that you are using a version 1.25 or better, that is GNU bison 1.25. Don't forget to do "make clean" after installing it. Don't forget to remove the stale bison.simple as well.
If the problem persists, then please mail me.
Patches don't include automatically generated files, i.e. configure and files generated by configure. Regenerate them yourself:
autoconf configureYou might need to create some extra "out" directories. Do this with
make outdirs
[This only applies if you don't do make install
, and develop out
of the source directory]
I have a directory which contains all our development projects
~/usr/
which looks like /usr/
bin/ share lib/ share/ src/ etc....
The directory ~/usr/src/ contains something like
doos/ # gnu/windows32 build and binary releases harmonia -> harmonia-x.y.z harmonia-x.y.z/ lilypond -> lilypond-x.y.z # symlink to development directory lilypond-x.y.z/ # current development patches/ # patches between different releases RedHat/BUILD # RedHat build and binary releases RedHat/RPMS RedHat/SPECS releases/ # .tar.gz releases test/ # tarballs and diffs from current version yodl -> yodl-1.30.17 yodl-1.30.17with prefix $HOME/usr/src and (for building rpms only) in $HOME/.rpmrc:
topdir: /home/fred/usr/src/RedHat)
~/usr/src/bin is in the PATH, and contains symlinks to the compiled executables.
#c
in stead of cis
?We think that #c
looks as if you are entering the symbols to
print (which you are not; remember, you're entering the musical
content in Mudela)
Take this example
cis cisIndependently of how it was written and what the current key was, you would say that you are playing and reading "two C-sharp" notes. We have tried to make the language somewhat context-free. Of course sheet music is not context-free. Unfortunately, sheet music is also 2 dimensional, and ASCII is not.
Technically it would be feasible to have the Interpreting phase do tricky things to add (or leave out) the accidentals, but we think that it is impractical: it hampers the readability and portability of your source, since you need LilyPond to fill in the details and actually make sense of it.
cis
anywaycis
is the dutch naming for C-sharp. The notes are named
a, b,.., g. The suffix -is means sharp, and -es flat. This system is
common in a number of languages (such as swedish, dutch, german.)
Certain other languages (such as English, French and Italian) just add
the word for "sharp" to the notename.
We chose the Dutch system, because we're dutch. You are free to chose whatever names you like; they are user definable.
[] designate beams, a note can only be in one beam at the same time. () is a slur, which connects notes. You need to be able to specify
a()a()a
You shouldn't: it's against LilyPond philosophy to have typesetting
commands in the mudela source. Moreover, this would be difficult.
LilyPond uses TeX like a glorified output engine: the output consists
of (x,y) positions and symbols. You can only sensibly do TeX stuff in
the symbol string. You can access the symbol string easily for some
symbols (notably lyrics and ^"text"
commands).
Yes, see the twinkle-pop example.
No, not yet. We ourselves don't play guitar, and don't know the fine points of this notation. We would welcome anyone who could give this a try.
No. The same as for the previous question goes, but TAB is a lot more work than diagrams (TAB needs modification of Parser, Lexer, Staff, Notehead, Stem code and all the code that creates these graphic elements.)
Yes and no. At this time you can choose between 11, 13, 16, 19, 20, 23 and 20 pt staff-size. The sizes can't be changed per staff (yet). Look at standchen.ly for an example.
See lilyponddefs.tex, it has some comments. Or use ly2dvi.
You change the order lyrics and staves. You have to name all staves (lyric and melodic), otherwise they will end up in the same staff/lyricline
\score { < \melodic \type Staff = "treble" \trebleMelody \lyric \type Lyrics = "tlyrics" \trebtext \type Staff = "bass" \melodic \bassMelody \lyric \type Lyrics = "blyrics" \basstext > \paper { } }
You can stack them
c4^"a"^"b"or use spacing-notes to put markings at different horizontal positions
< c1 { s4\ff s4^"text" s4-\marcato s4 } >This also works for crescendi, eg,
< c1 { s4\< s2 \! s4 } >
See init/engraver.ly. You have to uncomment some entries. To do this `portably' you should redefine some engravers in your own source files. Check out init/rhythm.ly.
If it is reasonable, I'll add XXXX to the TODO list. In general finding a cute syntax (such as YYYY) isn't very hard. The complicated issue how to adapt the internals to do XXXX. The parser is really a simple front end to the complicated internals.
LilyPond development is open for anyone who wants to join. We try to use a Bazaar style development model for LilyPond, see http://locke.ccil.org/~esr/writings/cathedral.html. This means: frequent releases, everyone can send in a patch or do suggestions and all development discussions are public.
To be precise, discussions take place on the gnu-music-discuss mailing list, which is open for subscription to everyone.
There might be better ways of doing XXXX, so it's a good thing to ask about this before you start hacking. If you want to keep in touch with current developments, you should subscribe to the mailing list (see the "links" section of the documentation).
Your best bet of getting me to include code, is to present it as a "fait accompli", ie., to send me a patch.
Send in a patch:
diff -urN old-file new-file > patchor
diff -urN old-directory/ new-directory/ > patchAlternatively, you can use issue the command
make diff
Don't forget to put your name and e-mail address in the AUTHORS.pod file, or you won't get credits :-]
The entry point is in main()
. Good luck. :-)
Seriously, read, reread and reread internals and CodingStyle, and just start anywhere.
Anywhere? Well, most of the comment doco are in the header files, so
your best bet would be less lily/include/*.hh
. Some of the most
important data-structures are to be found in:
- *request.hh - engraver.hh - performer.hh - translator.hh - score-elem.hh - music.hh - music-list.hh - music-iterator.hh - item.hh - spanner.hh
Yes.
No. We have evaluated the standard GNU combination for compiling
programs (autoconf, automake, libtool) and found to be inadequate in
several respects. More detailed argumentation is included with
LilyPond's generic make package StepMake
(see stepmake-x.x.x/Documentation/automake.urgh)
LilyPond already compiles into a different directory ((the different directory is called out/, there is one in every source directory). make distclean essentially reduces to rm -f out/* in every directory
Upgrade to 4.17.
By using g++, GNU LilyPond is portable to all platforms which support g++ (there are quite a few). Not having to support other compilers saves us a lot of trouble.
You should use dvips and ghostscript to print the dvi
output:
the slurs and beams are PS \special
commands.
We obviously mucked with the fonts in the upgrade. Remove all previous fonts, including the .pk and .tfm fonts in /var/lib/texmf. A script automating this has been included, see buildscripts/clean-fonts.sh.
The beams and slurs are done in PostScript. XDvi doesn't show PostScript in the magnifying glass. Complain to the XDvi maintainers.
Your \score should include a \midi block, eg.
\score { \melodic { c4 c g g } \paper {} \midi { NOTRANS(ů)tput "myfile.mid"; \tempo 4=70; } }The -M option was added to LilyPond because processing the \paper block is so slow.
The MIDI output was originally put in as a proof that MIDI could be done, and as a method of proof"reading" the input. The MIDI support is by no means finished. Patches appreciated.
The website is usually made from the latest snapshots. Binary releases, in particular the windows32 binaries, are only made every once in a while. They may lag several versions behind the latest version.
Reconsider. Try Linux. It's fun!