1 \input texinfo @c -*-texinfo-*-
2 @setfilename internals.info
3 @settitle LilyPond internals
5 @node Top, LilyPond internals, (dir), (dir)
10 * LilyPond internals::
24 @node LilyPond internals, , Top, Top
28 * Request_engraver:: Request_engraver
32 @chapter Getting involved
34 Please help us make LilyPond a better program. You can help LilyPond in
35 several ways. Not all tasks requiring programming or understanding the
36 full source code. You can write to the mailing list
37 (@email{gnu-music-discuss@@gnu.org} for more information)
39 @unnumberedsubsec Users
41 Mutopia needs your help. The mutopia project is a collection of public
42 domain sheet music. You can help the project by entering music and
43 submitting. Point your browser to the
44 @uref{http://sca.uwaterloo.ca/Mutopia, Mutopia webpage}
46 @unnumberedsubsec Font designers
48 Our set of glyphs (the Feta font) is far from complete. If you know a
49 little MetaFont you can contribute a glyph
51 @unnumberedsubsec Writers
53 The documentation of LilyPond and related utilities needs a lot of work.
55 @unnumberedsubsec Translators
57 LilyPond is completely ready for internationalized messages, but there
58 are only three translations so far.
60 @unnumberedsubsec Hackers
63 There are lots of possibilities of improving the program itself. There are
64 both small projects and big ones. Most of them are listed in the TODO
65 file. A interesting and very big project is writing a GUI frontend to
70 @chapter LilyPond internals
73 This documents some aspects of the internals of GNU LilyPond. Some of
74 this stuff comes from e-mail I wrote, some from e-mail others wrote,
75 some are large comments taken away from the headers. This page may be
76 a little incoherent. Unfortunately, it is also quite outdated. A
77 more thorough and understandable document is in the works.
79 You should use @code{doc++} to take a peek at the sources.
81 @node Overview, mudela, Top, Top
84 GNU LilyPond is a "multi-pass" system. The different passes have been
85 created so that they do not depend on each other. In a later stage
86 some parts may be moved into libraries, or seperate programs, or they
87 might be integrated in larger systems.
93 No difficult algorithms. The .ly file is read, and converted to a list
94 of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
96 @item Interpreting music
98 The music is walked through in time-order. The iterators which do the
99 walking report Music to Translators which use this information to
100 create elements, either MIDI or "visual" elements. The translators
101 form a hierarchy; the ones for paper output are Engravers, for MIDI
104 The translators swallow Music (mostly atomic gobs called Requests),
105 create elements, broadcast them to other translators on higher or same
106 level in the hierarchy:
108 The stem of a voice A is broadcast to the staff which contains A, but
109 not to the stems, beams and noteheads of a different voice (say B) or
110 a different staff. The stem and noteheads of A are coupled, because
111 the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
114 The engraver which agrees to handle a request decides whether to to
115 honor the request, ignore it, or merge it with other requests. Merging
116 of requests is preferably done with other requests done by members of
117 the same voicegroups (beams, brackets, stems). In this way you can put
118 the voices of 2 instruments in a conductor's score so they make chords
119 (the Beam requests of both instruments will be merged).
123 Breakable stuff (eg. clefs and bars) are copied into pre and
128 Some dependencies are resolved, such as the direction of stems, beams,
129 and "horizontal" placement issues (the order of clefs, keys etc,
130 placement of chords in multi-voice music),
132 @item Break calculation:
134 The lines and horizontal positions of the columns are determined.
138 Through some magical interactions with Line_of_score and Super_elem
139 (check out the source) the "lines" are produced.
141 All other spanners can figure across which lines they are spread. If
142 applicable, they break themselves into pieces. After this, each piece
143 (or, if there are no pieces, the original spanner itself) throws out
144 any dependencies which are in the wrong line.
148 Some items and all spanners need computation after the Paper_column
149 positions are determined. Examples: slurs, vertical positions of
156 @node mudela, Request_engraver, Overview, Top
159 Most information is stored in the form of a request. In music
160 typesetting, the user might want to cram a lot more symbols on the
161 paper than actually fits. To reflect this idea (the user asks more
162 than we can do), the container for this data is called Request.
164 In a lot of other formats this would be called an 'Event'
167 @item @code{Barcheck_req}
168 Checks during music processing if start of this voice element
169 coincides with the start of a measure. Handy to check if you left out
171 @item @code{Note_req}
172 LilyPond has to decide if the ball should be hanging left or
173 right. This influences the horizontal dimensions of a column, and this
174 is why request processing should be done before horizontal spacing.
175 Other voices' frivolities may cause the need for accidentals, so this
176 is also for the to decide. The engraver can decide on positioning based on
177 ottava commands and the appropriate clef.
178 @item @code{Rest_req}
180 @item @code{Span_req}
181 This type of request typically results in the creation of a @code{Spanner}
182 @item @code{Beam_req}
184 Engraver has to combine this request with the stem_request, since the
185 number of flags that a stem wants to carry will determine the
188 Each dynamic is bound to one note (a crescendo spanning multiple
189 notes is thought to be made of two "dynamics": a start and a stop).
190 Dynamic changes can occur in a smaller time than the length of its
191 note, therefore fore each @code{Dynamic} request carries a time, measured
192 from the start of its note.
195 @node Request_engraver, , mudela, Top
196 @section Request_engraver
198 In the previous section the idea of Request has been explained, but
199 this only solves one half of the problem. The other half is deciding
200 which requests should be honored, which should merged with other
201 requests, and which should be ignored. Consider this input
205 \type Staff < % chord
206 @{ \meter 2/4; [c8 c8] @}
207 @{\meter 2/4; [e8 e8] @}
212 Both the cs and es are part of a staff (they are in the same
213 Voice_group), so they should share meters, but the two [ ] pairs
216 The judge in this "allocation" problem a set of brokers: the requests
217 are transmitted to so-called engravers which respond if they want to
218 accept a request eg, the @code{Notehead_engraver} will accept
219 @code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
220 cannot find a engraver that wants the request, it is junked (with a
223 After all requests have been either assigned, or junked, the Engraver
224 will process the requests (which usually means creating an @code{Item}
225 or @code{Spanner}). If a @code{Request_engraver} creates something, it
226 tells the enclosing context. If all items/spanners have been created,
227 then each Engraver is notified of any created Score_element, via a
230 @unnumberedsubsec example:
242 Note_request (duration 1/4)
243 Stem_request (duration 1/4)
247 Note_request will be taken by a @code{Notehead_engraver}, stem_request
248 will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
249 creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
250 @code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
251 will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
252 will add the @code{Notehead} to the @code{Stem} it just created.
254 To decide on merging, several engravers have been grouped. Please
255 check @file{init/engraver.ly}.
259 @node Graphic elements, , , Top
260 @section Graphic elements
263 Music notation is composed of a sets of interrelated glyphs. In
264 Lilypond every glyph usually is represented by one object, a so-called
265 Graphic Object. The primary relations between graphic objects involve
269 @item consecutive notes are printed left to right, grouped in a staff
270 @item simultaneous notes are horizontally aligned (internally grouped in
272 @item the staccato mark is horizontally centered on the note it applies
276 The abstract encoding of such relations is done with the concept
277 @dfn{reference point}. The reference point (in X direction) of the
278 staccato mark is the note it applies to. The (X) position of the
279 staccato mark is stored relative to the position of the note head. This
280 means that the staccato will always maintain a fixed offset wrt to the
281 note head, whereever the head is moved to.
283 In the same vein, all notes on a staff have their Y positions stored
284 relative to an abstract object called Axis_group_spanner. If the
285 Axis_group_spanner of one staff is moved, the absolute Y positions of
286 all objects in that spanner change along, in effect causing the staff
287 and all its contents to move as a whole.
289 Each graphic object stores a pointer and an relative offset for each
290 direction: one for the X-axis, one for the Y-axis. For example, the X
291 parent of a Note_head usually is a Note_column. The X parent of a
292 Note_column usually is either a Collision or a Paper_column. The X
293 parent of a Collision usually is a Paper_column. If the Collision
294 moves, all Note_heads that have that Collision as parent also move, but
295 the absolute position of the Paper_column does not change.
297 To build a graphical score with Graphic_elements, conceptually, one
298 needs to have one Root object (in Lilypond: Line_of_score), and
299 recursively attach objects to the Root. However, due to the nature
300 of the context selection mechanisms, it turns out to be more
301 advantageous to construct the tree the other way around: first small
302 trees (note heads, barlines etc.) are created, and these are
303 subsequently composed into larger trees, which are finally hung on a
304 Paper_column (in X direction) or Line_of_score (in Y direction).
306 The structure of the X,Y parent relations are determined by the
307 engravers and notation contexts:
309 The most important X-axis parent relation depends on the timing: notes
310 that come earlier are attached to Paper_column that will be positioned
313 The most important Y-axis relation depends on containment of contexts:
314 notes (created in a Thread or Voice context) are put in the staff where
315 the originating context lives in.
317 Graphical_axis_groups are special graphic objects, that are designed to
318 function as a parent. The size of a Graphical_axis_groups group is the
319 union of its children.
321 @node Score elements, , , Top
323 Besides relative positions there are lots of other relations between
324 elements. Lilypond does not contain other specialized relation
325 management (Like the relative positioning code). In stead, objects can
326 be connected through dependencies, which sets the order in which objects
329 Example: the direction of a beamed stem should equal the direction of
330 the beam. When the stem is a added to the beam, a dependency on the
331 beam is set in the stem: this means that @code{Beam::do_pre_processing
332 ()} (which does various direction related things) will be called before
333 @code{Stem::do_pre_processing ()}.
335 The code that manages dependencies resides in the class
336 @code{Score_element}, a derived class of @code{Graphical_element}. The
337 bulk of the code handles line breaking related issues.
339 To sketch the problems with line breaking: suppose a slur spans a line
343 c4( c'''' c | \break d d )d
346 In this case, the slur will appear as two parts, the first part spanning
347 the first three notes (the @code{c}s), the second spanning the last
348 three (the @code{d}s). Within Lilypond this is modeled as breaking the
349 slur in parts: from the Original slur, two new clones of the old slur
350 are made. Initially both clones depend on the six notes. After the
351 hairy code in Score_element, Spanner and Item which does substitutions
352 in sets of dependencies, the first clone depends on the first three
353 notes, the second on the last three.
355 The major derived classes of Score_element are Item and Spanner.
356 An item has one horizontal position. A spanner hangs on two items.
363 An item is a score element that is associated with only one
364 Paper_column. Examples are note heads, clefs, sup and superscripts, etc.
365 Item is a derived class of Score_element.
367 The shape of an item is known before the break calculations, and line
368 spacing depends on the size of items: very wide items need more space
369 than very small ones.
371 An additional complication is the behavior of items at linebreaks. For
372 example, when you do a time signature change, you get only one symbol.
373 If it occurs at a linebreak, the new time signature must be printed both
374 before and after the linebreak. Other `breakable symbols' such as
375 clefs, and bar lines also exhibit this behavior.
377 if a line of music is broken, the next line usually gets a clef. So in
378 TeX terms, the clef is a postbreak. The same thing happens with meter
379 signs: Normally the meter follows the bar. If a line is broken at that
380 bar, the bar along with the meter stays on the "last" line, but the next
381 line also gets a meter sign after the clef. To support this,
382 breakable items are generated in the three versions: original
383 (unbroken), left (before line break) and right (after line break).
384 During the line spacing, these versions are used to try how the spacing
387 Once the definitive spacing is determined, dependencies (and various
388 other pointers) are substituted such that all dependencies point at the
389 active items: either they point at the original, or they point at left
392 @node Spanners, , , Top
395 Spanners are symbols that are of variable shape, eg. Slurs, beams, etc.
396 Spanners is a derived class of Score_element.
398 The final shape can only be determined after the line breaking process.
399 All spanners are spanned on two items, called the left and right
400 boundary item. The X reference point is the left boundary item.
403 @node Future work, , , Top
406 There are plans to unify Spanner and Item, so there will no longer be
407 such a clear distinction between the two. Right now, Score_elements are
408 always either Item or either Spanner.
410 Most of the properties of a graphic object are now member variables of
411 the classes involved. To offer configurability, we want to move these
412 variables to scheme (GUILE) variables, and no longer use C++ code to
413 calculate them, but use Scheme functions.
415 @node Coding standards, , , Top
417 @chapter CodingStyle - standards while programming for GNU
420 Functions and methods do not return errorcodes.
423 @unnumberedsubsec Languages
425 C++ and Python are preferred. Perl is not. Python code should use an
426 indent of 8, using TAB characters.
428 @unnumberedsubsec Filenames
430 Definitions of classes that are only accessed via pointers
431 (*) or references (&) shall not be included as include files.
437 ".cc" Implementation files
438 ".icc" Inline definition files
439 ".tcc" non inline Template defs
445 (setq auto-mode-alist
446 (append '(("\\.make$" . makefile-mode)
447 ("\\.cc$" . c++-mode)
448 ("\\.icc$" . c++-mode)
449 ("\\.tcc$" . c++-mode)
450 ("\\.hh$" . c++-mode)
451 ("\\.pod$" . text-mode)
457 The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
459 @unnumberedsubsec Indentation
461 Standard GNU coding style is used. In emacs:
464 (add-hook 'c++-mode-hook
465 '(lambda() (c-set-style "gnu")
470 If you like using font-lock, you can also add this to your @file{.emacs}:
473 (setq font-lock-maximum-decoration t)
474 (setq c++-font-lock-keywords-3
476 c++-font-lock-keywords-3
477 '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
478 ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
482 @unnumberedsubsec Classes and Types
488 @unnumberedsubsec Members
492 Type Class::member_type_
493 Type Class::member_type ()
496 the @code{type} is a Hungarian notation postfix for @code{Type}. See below
498 @unnumberedsubsec Macros
500 Macros should be written completely in uppercase
502 The code should not be compilable if proper macro declarations are not
505 Don't laugh. It took us a whole evening/night to figure out one of
506 these bugs, because we had a macro that looked like
507 @code{DECLARE_VIRTUAL_FUNCTIONS ()}.
509 @unnumberedsubsec Broken code
511 Broken code (hardwired dependencies, hardwired constants, slow
512 algorithms and obvious limitations) should be marked as such: either
513 with a verbose TODO, or with a short "ugh" comment.
515 @unnumberedsubsec Comments
517 The source is commented in the DOC++ style. Check out doc++ at
518 @uref{http://www.zib.de/Visual/software/doc++/index.html}
523 C style comments for multiline comments.
524 They come before the thing to document.
530 Long class documentation.
533 TODO Fix boring_member ()
544 short memo. long doco of member ()
545 @@param description of arguments
548 Rettype member (Argtype);
552 data_member_ = 121; // ugh
559 Unfortunately most of the code isn't really documented that good.
561 @unnumberedsubsec Members (2)
567 ///check that *this satisfies its invariants, abort if not.
570 /// print *this (and substructures) to debugging log
574 protected member. Usually invoked by non-virtual XXXX ()
578 /**add some data to *this.
579 Presence of these methods usually imply that it is not feasible to this
584 /// replace some data of *this
589 @unnumberedsubsec Constructor
591 Every class should have a default constructor.
593 Don't use non-default constructors if this can be avoided:
601 is less readable than
614 Foo f(Foo_convert::int_to_foo (1))
618 @unnumberedsec Hungarian notation naming convention
620 Proposed is a naming convention derived from the so-called
621 @emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
622 uppercase, with the parts of the names separated by underscores.
624 The hungarian notation is to be used when variables are not declared
625 near usage (mostly in member variables and functions).
627 @unnumberedsubsec Types
631 unsigned char. (The postfix _by is ambiguous)
645 Zero terminated c string
650 @unnumberedsubsec User defined types
658 Slur* slur_p = new Slur;
662 @unnumberedsubsec Modifiers
664 The following types modify the meaning of the prefix.
665 These are preceded by the prefixes:
673 const. Note that the proper order is @code{Type const}
674 i.s.o. @code{const Type}
676 A const pointer. This would be equivalent to @code{_c_l}, but since any
677 "const" pointer has to be a link (you can't delete a const pointer),
680 temporary pointer to object (link)
682 pointer to newed object
687 @unnumberedsubsec Adjective
689 Adjectives such as global and static should be spelled out in full.
690 They come before the noun that they refer to, just as in normal english.
694 foo_global_i: a global variable of type int commonly called "foo".
698 static class members do not need the static_ prefix in the name (the
699 Class::var notation usually makes it clear that it is static)
703 Variable loop: an integer
705 Temporary variable: an unsigned integer
707 Variable test: a character
708 @item @code{first_name_str}
709 Variable first_name: a String class object
710 @item @code{last_name_ch_a}
711 Variable last_name: a @code{char} array
713 Variable foo: an @code{Int*} that you must delete
715 Variable bar: an @code{Int*} that you must not delete
718 Generally default arguments are taboo, except for nil pointers.
720 The naming convention can be quite conveniently memorised, by
721 expressing the type in english, and abbreviating it
725 static Array<int*> foo
729 @code{foo} can be described as "the static int-pointer user-array", so you get
738 @unnumberedsec Miscellaneous
740 For some tasks, some scripts are supplied, notably creating patches, a
741 mirror of the website, generating the header to put over cc and hh
742 files, doing a release.
746 @node Making patches, , , Top
752 PATCHES - track and distribute your code changes
754 This page documents how to distribute your changes to GNU lilypond
756 We would like to have unified context diffs with full pathnames. A
757 script automating supplied with Lily.
759 Distributing a change normally goes like this:
762 @item make your fix/add your code
763 @item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi
764 @item generate a patch,
765 @item e-mail your patch to one of the mailing lists
766 gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org
769 Please do not send entire files, even if the patch is bigger than the
770 original. A patch makes it clear what is changed, and it won't
771 overwrite previous (not yet released) changes.
773 @unnumberedsec Generating a patch
778 make -C lilypond-x.y.z/ distclean
779 make -C lilypond-x.y.z.NEW/ distclean
780 diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/
783 Complicated (but automated) version:
785 In @file{VERSION}, set MY_PATCH_LEVEL:
795 In @file{CHANGES}, enter a summary of changes:
802 Then, from the top of Lily's source tree, type
808 These handy python scripts assume a directory structure which looks
813 lilypond -> lilypond-x.y.z # symlink to development directory
814 lilypond-x.y.z/ # current development
815 patches/ # patches between different releases
816 releases/ # .tar.gz releases
820 (Some scripts also assume this lives in @file{$HOME/usr/src}).
823 @unnumberedsec Applying patches
826 If you're following LilyPond development regularly, you probably want to
827 download just the patch for each subsequent release.
828 After downloading the patch (into the patches directory, of course), simply
833 gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
837 and don't forget to make automatically generated files:
841 autoconf footnote(patches don't include automatically generated files,
842 i.e. file(configure) and files generated by file(configure).)