#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.
RedHat RPMS don't include guile-config. You need guile-config as it was produced during the RPM build run. Build the RPM from source (.src.rpm), and use the guile-config that is in /usr/src/redhat/BUILD/guile-1.3/guile-config/.
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 send a bug report to the mailing list.
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 symbolic links to the compiled executables.
Yes. It is included with the source archive as mudela-mode.el. If you have an rpm it is in /usr/doc/lilypond-X/. You have to install it yourself.
You don't. The .tfm files should be generated automatically by Metafont when you run TeX. Check your TeX installation, or ask your local TeX guru. The supplied .afm files are intended to be used by LilyPond, not by any other programs.
LilyPond development is moving quite fast, documentation will often lag a bit behind. We must always make a choice between writing more doco, writing more code and answering email.
If you think you can make a correction, or devised a solution that should be documented, please do so and send in a patch.
#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. Go ahead and send a patch.
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. At this time you can choose between 11, 13, 16, 19, 20, 23 and 20 pt staff-size. Use the staffLineLeading property for setting the size of the staff, and fontSize for setting the size of the glyphs.
No. Go ahead.
Yes. See input/test/grace.ly
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 input/test/bar-scripts.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).
LilyPond currently has no graphical interface. The authors seriously doubt if a simple-minded approach (dragging and dropping notes) is any easier or quicker to use than mudela. But for composing a graphical environment probably is indispensable.
In any case Derek Wyatt(wyatt@scar.utoronto.edu) is working on GTK based editor, but that effort practically died. (see http://harmonia.scar.utoronto.ca.
Matthew Hiller is working on extending Midiscore and Koobase to handle mudela. Check out http://zoo.cs.yale.edu/~meh25/.
There is also a GUI package RoseGarden that could be extended to output mudela.
If you want to work on this, please send e-mail to the mailing list gnu-music-discuss@gnu.org.
Your best bet of getting us to include code, is to present it as a "fait accompli", i.e., to send a patch to the mailing list.
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 :-]
Please always send a -u diff, even if it is larger than the whole file.
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
.
You should also have a look using Javadoc like tools. Try DOC++, http://www.imaginator.com/doc++
No comment.
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.
Supporting more compilers than EGCS/G++ 2.8 is unlikely to make LilyPond run on more platforms. It would give us an enormous headache in detecting and catering for every variant of every compiler: 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.
Mats Bengtsson <mats.bengtsson@s3.kth.se> writes:
The simple solution used by Anthony Fok in the Debian distribution of Lilypond is to link the mf/ directory to /usr/lib/texmf/fonts/source/public/lilypond Depending on what distribution of teTeX and Linux you have installed, there might also be other places like /usr/local/lib/texmf/fonts/source/public/lilypond or /var/spool/texmf//fonts/source/public/lilypond
Wherever you put it, don't forget to run mktexlsr (or texhash for older installations) afterwards, so that TeX will find the files. Also, don't forget to remove all old .tfm and .*pk files when the font is updated (as it will be in version 1.1.40, for example).
Yes, they are type-3 fonts. In the mf/ subdirectory, issue:
make pfain the mf/ subdirectory. This will also make mfplain for metapost. The pfas will be in the subdirectory out/.
-f ps
:
lilypond -fps foo.ly
i.e. do something like:
export GS_FONTPATH=$HOME/usr/src/lilypond/mf/out export GS_LIB=$HOME/usr/src/lilypond/ps gv foo.ps &
Direct PS output is still experimental. For creating nice looking ps
output, use TeX and dvips
.
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 { output = "myfile.midi"; \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.
Silas S. Brown <ssb22@hermes.cam.ac.uk>:
There are several aspects to sheet music copyright:
1. The music itself - copyright for the composer's life plus 70 years (so not applicable to Bach).
2. If the music is an arrangement, then the arranger holds copyright on that arrangement. However, you can produce your own arrangement using that arrangement as a reference point. Obviously your arrangement must be sufficently different to be called your own arrangement - you need to do more than change one note!
3. In some countries, the same applies for editions. This could be relevant to the Bach example. If a modern person has edited the music, then they hold the copyright on the edition. This does not stop you from removing the editorial features - remove all editorial slurs, phrasemarks, ornaments etc and only leave those that you know to be original. You can then add some of your own if you want to be your own editor.
4. If there are lyrics, then the lyricist also holds copyright. This does not stop you from using the music without the lyrics if it is otherwise out of copyright.
5. The copyright of the printed page is held by the publisher for 30 years after printing (25 in some countries). This stops you from photocopying (unless it's "fair use" eg. you're partially sighted and need to enlarge the music) or otherwise reproducing the typesetting that is used on it. But the copyright is only held over the typesetting work, not the music itself. Since Mudela specifies the notes, independently of any typesetting work that went into your reference copy, you are not duplicating any of the publisher's work.
6. If you want to violate copyright, there are two main cases where you may do so: fair use, and with permission. The former is rather fuzzily defined, but it includes such things as including small extracts of a score in a critique, and making a large print or Braille copy for a blind or partially-sighted performer (many people argue that in this case it should always be kept with the original copy and/or destroyed after it is no longer needed). The latter is obvious: You can always write to the composer, arranger, editor, lyricist or publisher in question and ask if you can do whatever it is you're trying to do. Some will respond more readily than others, but anything that they say will override any copying restrictions imposed on you.
References - best one I know is the UK-based Performing Right Society, http://www.prs.co.uk/ (especially "membership") and their links to other international equivalents.
Juergen Reuter <reuterj@ira.uka.de>:
[More information can be had at: ]
http://lcweb.loc.gov/copyright/ (USA copyright law)
http://fairuse.stanford.edu/ (meta site about copyright with many links to other resources)
http://host.mpa.org/crc.html (copyright from the viewpoint of the USA music publishers' association)
http://www.wipo.int (World Intellectual Property Organization (a UNO agency); with information about international copyright)
John Sankey:
See http://www.geocities.com/Vienna/Studio/1714/harpsichord.html for a summary of copyright relative to old music, also for the expert forum for such questions.
Werner Lemberg <sx0005@sx2.HRZ.Uni-Dortmund.DE>:
This is not correct. Urtext editions per se are not copyrighted -- if you print exactly what the composer has written, how can there some copyright be added? Copyrighted are usually only the `Critical notes', the foreword, and the cadenzas some editors have added.
This means that the `Photocopying forbidden' sign in many scores is not always correct for e.g. J.S. Bach -- you are allowed to copy the pages which don't contain editorial stuff which is probably copyrighted.
A very unfortunate situation for the publishers.
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!
Please send GNU LilyPond questions and comments to gnu-music-discuss@gnu.org.
Please send comments on these web pages to
(address unknown),
send other FSF & GNU inquiries and questions to
Copyright (c) 1997, 1998, 1999 Han-Wen Nienhuys and Jan Nieuwenhuizen.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.