]> git.donarmstrong.com Git - lilypond.git/commitdiff
* lily/include/sequential-iterator.hh (class Sequential_iterator):
authorHan-Wen Nienhuys <hanwen@xs4all.nl>
Sat, 13 Jul 2002 17:07:20 +0000 (17:07 +0000)
committerHan-Wen Nienhuys <hanwen@xs4all.nl>
Sat, 13 Jul 2002 17:07:20 +0000 (17:07 +0000)
bugfix: protect music list from GC.

* Documentation/user/introduction.itely: misc fixes.

* scripts/ly2dvi.py (run_latex): show latex error log. Ask for
bugreport if lilypond is killed by a signal.

* lily/beam.cc: complete rewrite of multiplicity. This fixes 16th
knees code.
(quanting): add french beaming support (property french-beaming)
(stem_beams): removed.

ChangeLog
Documentation/user/introduction.itely
Documentation/user/macros.itexi
Documentation/user/preface.itely
Documentation/user/tutorial.itely
lily/beam.cc
lily/include/sequential-iterator.hh
lily/sequential-iterator.cc
scripts/ly2dvi.py

index d2e6c9654d1e19b5efced162b9b56c27f752c097..41999735eeccd11c6f41e850537bbad8ac082c5c 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,16 +1,14 @@
 2002-07-13  Han-Wen  <hanwen@cs.uu.nl>
 
-       * scripts/ly2dvi.py (run_latex): show latex error log. Ask for
-       bugreport if lilypond is killed. 
+       * lily/include/sequential-iterator.hh (class Sequential_iterator):
+       bugfix: protect music list from GC.
 
-2002-07-12  Mats Bengtsson  <matsb@s3.kth.se>
+       * Documentation/user/introduction.itely: misc fixes.
 
-       * lily/beam.cc (after_line_breaking): Set correct stem lengths
-       also when beam positions are set manually.
-       (consider_auto_knees): Do not use automatic knees if the directions
-       are set manually by the user.
+       * scripts/ly2dvi.py (run_latex): show latex error log. Ask for
+       bugreport if lilypond is killed by a signal. 
 
-2002-07-13  Han-Wen  <hanwen@cs.uu.nl>
+       * input/regression/beam-funky.ly:  new file
 
        * lily/input-smob.cc (make_input): GUILE 1.7 compatibility fixes.
 
        (quanting): add french beaming support (property french-beaming)
        (stem_beams): removed.
 
+2002-07-12  Mats Bengtsson  <matsb@s3.kth.se>
+
+       * lily/beam.cc (after_line_breaking): Set correct stem lengths
+       also when beam positions are set manually.
+       (consider_auto_knees): Do not use automatic knees if the directions
+       are set manually by the user.
+
 2002-07-12  Han-Wen  <hanwen@cs.uu.nl>
 
        * input/regression/grace-auto-beam.ly: new file
index 5d0109babddd6b33411a8025bcb9b0ed0ff236d3..866aeb508418c0e9e156d7aa250dd030fa580c68 100644 (file)
@@ -3,86 +3,80 @@
 @node Introduction
 @chapter Introduction
 
-LilyPond is a program to print sheet music. If you have used such
+LilyPond is a program to print sheet music. If you have used notation
 programs before, then the way to use this program might be surprising
 at first sight. To print music with lilypond, you have to enter
 musical codes in a file. Then you run LilyPond on the file, and the
-music is produced without any user intervention. For example,
-something like this:
+music is produced without any intervention. For example, something
+like this:
 
 @lilypond[fragment,verbatim, relative 1, intertext="produces this"]
 \key c \minor r8 c16 b c8 g as c16 b c8 d | g,4 
 @end lilypond
 
-We can very well imagine that encoding music using letters may appear
-strange, intimidating or even clumsy at first. Nevertheless, when you
-take the effort to learn the codes and the program you will find that
-it is not so difficult as it seems, entering music can be done
-quickly, and you never have to remember how you made the program do
-something complicated: it's all in the input code, and you only have
-read the file to see how it works. Moreover, when you use LilyPond,
-you are rewarded with very nicely looking output.
-
-This form of computing (produce the output in one go, without user
-intervention), is called @emph{batch} computing, and the program that
-is used is normally called a @emph{compiler}. In contrast, it is now
-fashionable to produce interactive programs that rely on a Graphical
-User Interface (GUI).
-
-When we started with developing LilyPond in a time that were studying
-at the university. Back then GUIs were not as ubiquitous as they are
-today, and we were immersed in the UNIX operating system, where it is
-very common to use compilers to achieve computing tasks, so our
+ Encoding music using letters and digits may appear strange,
+intimidating or even clumsy at first. Nevertheless, when you take the
+effort to learn the codes and the program you will find that it is
+easier than it seems.  Entering music can be done quickly, and you
+never have to remember how you made the program do something
+complicated: it's all in the input code, and you only have to read the
+file to see how it works. Moreover, when you use LilyPond, you are
+rewarded with very nicely looking output.
+
+When we started with developing LilyPond, we were interested in music
+notation, not as publishers or musicians, but as students and
+scientists. We wanted tried to figure to what extent formatting sheet
+music could be automated.  This was when we were still studying at the
+university. Back then GUIs were not as ubiquitous as they are today,
+and we were immersed in the UNIX operating system, where it is very
+common to use compilers to achieve computing tasks, so our
 computerized music engraving experiment took on the form of a
 compiler.
 
 One other decision was also motivated by our academic background. In
 the scientific community it has always been a tradition to share
-knowledge, and to a lesser extent, to share the software you
-wrote. One of the most visible groups that stimulated this philosopy,
-was the Free Software Foundation, whose GNU project aimed to replace
-the closed and proprietary computing solutions with free (as in
-"Libre") variants. We jumped on that bandwagon, and that is the reason
-that you can still get LilyPond at no cost, and with no strings
-attached.
-
-When we started, we were interested in music notation, not as
-publishers or musicians, but as students and scientists. We wanted
-tried to figure to what extent formatting sheet music could be
-automated.  Making sheet music may seem trivial at first (``you print
-5 lines, and then put in the notes at different heights''),
-@emph{music engraving}, i.e. professional music typography, is in
-another ballpark.
-
-The term music engraving derives from the traditional process of music
-printing.  A few decades ago, sheet music was made by cutting and
+knowledge, and, to a lesser extent, the software you wrote. One of the
+most visible groups that stimulated this philosopy, was the Free
+Software Foundation, whose GNU project aimed to replace closed and
+proprietary computing solutions with free (as in ``Libre'')
+variants. We jumped on that bandwagon, and that is the reason that you
+can still get LilyPond at no cost without any strings attached.
+
+
+Making sheet music may seem trivial at first (``you print 5 lines, and
+then put in the notes at different heights''), @emph{music engraving},
+i.e. professional music typography, is in another ballpark.  The term
+music engraving derives from the traditional process of music
+printing.  Only a few decades ago, sheet music was made by cutting and
 stamping the music mirrored into zinc or pewter plates. The plate
 would be inked, and the depressions caused by the cutting and stamping
-would hold ink thus forming an positive image. Stamping and cutting
-was completely done by hand, and making corrections was cumbersome, so
-engraving had to be correct in one go. As you can imagine this was a
-highly specialized skill, much more so than the traditional process of
-printing books.
-
-In fact, the traditional german craftmanship required six years of
-full-time training, before a student could call himself a master of
-the art. After that many more years of practical experience were
+would hold ink.  A positive image was formed by pressing paper to the
+plate. Stamping and cutting was completely done by hand, and making
+corrections was cumbersome, so engraving had to be correct in one
+go. As you can imagine this was a highly specialized skill, much more
+so than the traditional process of printing books.
+
+In fact, in the traditional German craftmanship six years of full-time
+training were required, before a student could call himself a master
+of the art. After that many more years of practical experience were
 needed to become an established music engraver.  Even today, in the
 era of high-speed computers, music requires lots of manual fine tuning
 before it acceptable to be published.
 
-The first step of making music prints is to have the symbols
-available.  Unfortunately, most of the knowledge about music engraving
-has not been laid down in an easily accessible form, so when we wanted
-to write a computer program to do create music typography, we
-encountered the first problem: there were no sets of musical symbols
-available: either they were not available freely, or they didn't look
-well to our subtle tastes. That was the reason for us to create a font
-of musical symbols, relying mostly on nice printouts of hand-engraved
-music.
+When we wanted to write a computer program to do create music
+typography, we encountered the first problem: there were no sets of
+musical symbols available: either they were not available freely, or
+they didn't look well to our taste. That was the reason for us to
+create a font of musical symbols, relying mostly on nice printouts of
+hand-engraved music.  It was a good decision to design our own
+font. The experience helps develop a typographical taste, and it makes
+one appreciate subtle design details. Without that experience, we
+would not have realized how ugly the fonts were that we admired at
+first.
+
 
 @lilypond
-#(define magfact 2.0)
+#(define magfact 3.0)
 \score {  \notes { as'2 r4 }
          \paper {
              linewidth = -1. 
@@ -99,19 +93,14 @@ music.
                  } } }
 @end lilypond
 
-In the figure above, a few notable glyphs are shown. For example, the
+The figure above shows a few notable glyphs. For example, the
 half-notehead is not elliptic but slightly diamond shaped.  The stem
 of a flat symbol should be slightly brushed, i.e. becoming wider at
 the top. Fine endings, such as the one on the bottom of the quarter
 rest, should not end in sharp points, but rather in rounded shapes.
-The blackness of the font must be carefully tuned to the thickness of
-lines, beams and slurs to give a strong yet balanced overall
-impression.
-
-It was a good decision to design our own font. The experience helps
-develop a typographical taste, and it makes one appreciate subtle
-design details. Without that experience, we would not have realized
-how ugly the fonts were that we admired at first.
+Taken together, the blackness of the font must be carefully tuned
+together with the thickness of lines, beams and slurs to give a strong
+yet balanced overall impression.
 
 Producing a strong and balanced look is the real challenge of music
 engraving. It is a recurring theme with many variations. One of these
@@ -127,13 +116,13 @@ which is which?
       \property Staff.NoteSpacing \set #'stem-spacing-correction
         = #0.6
       c'4 e''4 e'4 b'4 |
-      c'4 e''4 e'4 b'4 |
+      b'4 e''4 b'4 e''4|
       \property Staff.NoteSpacing \override #'stem-spacing-correction
       = #0.0
       \property Staff.StaffSpacing \override #'stem-spacing-correction
       = #0.0
       c'4 e''4 e'4 b'4 |
-      c'4 e''4 e'4 b'4 |            
+      b'4 e''4 b'4 e''4|      
     }
     \paper { linewidth = -1. } }
 @end lilypond
@@ -143,65 +132,64 @@ played in a constant regular rhythm. The spacing should reflect
 that. Unfortunately, the eye deceives us a little: the eye not only
 notices the distance between note heads, but also between consecutive
 stems. Depending on the different vertical positions, the notes of a
-upstem-downstem should be put farther apart, and the notes of a
-down-up combination should be put closer. The first two measures are
-printed with this correction, the last two measures without. The notes
-in the last two measures form downstem/upstems clumps of notes.
+upstem-downstem combination should be put farther apart, and the notes
+of a down-up combination should be put closer together. The first two
+measures are printed with this correction, the last two measures
+without. The notes in the last two measures form downstem/upstems
+clumps of notes.
 
 We hope that these examples serve to show that music typography is a
 subtle business, and that it requires skill and knowledge to produce
-good engraving---skill and knowledge most people lack.  It was our
-challenge to see if we could put such knowledge into a computer
-program.
+good engraving.  It was our challenge to see if we could put such
+knowledge into a computer program.
  
 One of the first questions that pop up when you design such a program,
 is what kind of input the program should expect. Many music notation
-programs offer a graphical interface that shows notation, and allows
+programs offer a graphical interface that shows notation, and allow
 you to enter the music by placing notes on a staff. Although this is a
 obvious way to design a program, from our point of view, this is
 cheating. After all, the core message of a piece of music notation
-simply is the music itself. If you start by offering music notation to
-the user, you have already skipped one conversion, even if it perhaps
-is implicit. If we want to generate music notation, then the obvious
-candidate for the source format should be the music itself.
+simply is the music itself. If you start by offering notation to the
+user, you have already skipped one conversion, even if it perhaps is
+implicit. If we want to generate music notation from something else,
+then the obvious candidate for the source should be the music itself.
 
 Of course, on paper this theory sounds very good. In practice, it
 opens a can of worms. What really @emph{is} music? Many philosophical
-treatises must have been written on the subject. Even if you're more
+treatises must have been written on the subject. Even if you are more
 practically inclined, you will notice that an enormous number of
 different ways to represent music in a computer exist, and they are
 much more incompatible than the formats for wordprocessors and
 spreadsheets.  Anyone who has tried to exchange data files from
-between different computer programs can attest to this.
+between different notation programs can attest to this.
 
 The cause of this problem is that music is inherently two-dimensional:
 in polyphonic music, notes have time and pitch as their two
 coordinates, and they often are related in both directions. Computer
 files on the other hand are essentially one-dimensional: they are a
 long stream of characters. When you represent music in a file, then
-you have to flatten this two-dimensional information breaking the
-timing or the pitch, relations, and there is no universal agreement on
-how to do this.
-
-It might seem that when designing a music representation, we have
-myriad of choices.  Luckily, we have some requirements that shaped the
-input format into what it is now.  A music representation is about
-@emph{music}, so it should be free from notation as much as possible:
-the format is about pitches and durations, not about symbols and
-offsets. Since LilyPond is a compiler, the input format is its user
-interface, and users have to key in the music into the file directly,
-requiring that the input format has a friendly syntax. We, as
-programmers and scientists also like the format to have a clean formal
-definition. After all, producing music notation is a difficult
-problem, and in the scientific world, difficult problems always must
-be well-specified. Moreover, formally defined formats are easier to
-write programs for. Finally, enough information should be present to
-be able to produce a printed score.
-
-These ideas shaped music representation elegantly builds complex
-musical constructs from simple entities like notes and rests, in much
-the same way that one builds complex formulae from simple expressions
-such as numbers and mathematical operators.
+you have to flatten this two-dimensional information breaking either
+timing or pitch relations, and there is no universal agreement on how
+to do this.
+
+Luckily, our application has guided us a little with the design of the
+format: we want to produce a printed score from a music
+representation.  A music representation is about @emph{music}, so it
+should be free from notation as much as possible: the format is about
+pitches and durations, not about symbols and offsets.  Since LilyPond
+is a compiler, the input format is its user interface, and users have
+to key in the music into the file directly, requiring that the input
+format has a friendly syntax. We, as programmers and scientists want a
+clean formal definition. After all, producing music notation is a
+difficult problem, and in the scientific world, difficult problems
+always must be well-specified. Moreover, formally defined formats are
+easier to write programs for. Finally, enough information should be
+present to be able to produce a printed score.
+
+These ideas shaped our music representation which elegantly builds
+complex musical constructs from simple entities like notes and rests,
+in much the same way that one builds complex formulae from simple
+expressions such as numbers and mathematical operators.
 
 The strict separation between musical information and typesetting also
 gives a blueprint of the program: first it reads the music
index 326a4d290f74748881ce3217f1438963a658c100..64c289553b01c4943c1a5d36d76055772616b2b2 100644 (file)
@@ -48,7 +48,7 @@
 @iftex
 @macro texisharp {word}
 @tex
-$\\sharp$
+$\\sharp$%
 @end tex
 @end macro
 @end iftex
index 7cbcc7da7b54da29a924de6f5bdecfd121bbec58..7b1274f03f4922d9faaf4c2c5e19e11c564c0438 100644 (file)
@@ -33,6 +33,7 @@ Jeremie Lumbroso,
   should mention many more people, these are from AUTHORS
 @end ignore
 
+
 We always maintain that wrote this program to satisfy our curiosity,
 to have fun together, to help people, but ultimately, LilyPond is a
 way to express our deep love for music. May it help you create lots of
index 5ab44df9fb8fa5cc1ac12439bf5da15929514d65..61329cb14f478a6b29b5c80726fe4ed6c302c78f 100644 (file)
@@ -35,19 +35,12 @@ LilyPond to produce printed output; you should then be able to create
 your first sheets of music. The tutorial continues with more and more
 complex examples.
 
-Some of the examples discussed are included as separate files in the
-distribution, in the subdirectory @file{input/tutorial/} of the source
-package.
-
 @node First steps
 @section First steps
 
-In this section, we show how to make small, very simple pieces of
-music in LilyPond.  If you have not seen LilyPond input files before,
-this section is for you.
-
-You get a simple note by typing its note name, from @code{a} through
-@code{g}. So if you enter
+We tsart off with showing how very simple music is entered in
+LilyPond:  you get a simple note by typing its note name, from
+@code{a} through @code{g}. So if you enter
 @quotation
 @example
 c d e f g a b
@@ -1094,7 +1087,7 @@ The complete file is listed here:
 @section A melody with chords
 
 In this section we show how to typeset a melody with chord
-accompaniment. This file is included as @file{flowing.ly}.
+accompaniment. This file is included as @file{input/tutorial/flowing.ly}.
 
 @example 
 \include "paper16.ly"
@@ -1669,7 +1662,7 @@ lily version.
 Our fourth subject is a piece of piano music.  The fragment in the
 input file is a piano reduction of the G major Sinfonia by Giovanni
 Battista Sammartini.  It was composed around 1740.  It's in the source
-package under the name @file{sammartini.ly}.
+package under the name @file{input/tutorial/sammartini.ly}.
 
 @lilypondfile[verbatim]{sammartini.ly}
 
@@ -1931,8 +1924,8 @@ to the page layout of this document.
 
 In this section, we show some ways to fine tune the final output of a
 piece. We do so using a single measure of a moderately complex piano
-piece: a Brahms intermezzo (opus 119, no. 1).
-@cindex Brahms, Johannes
+piece: a Brahms intermezzo (opus 119, no. 1). Both fragments (the
+tuned and the untuned are in the @file{input/tutorial/}).
 
 The code for the untuned example shows us some new things.
 
@@ -2294,8 +2287,8 @@ for transposing instruments.
 @subsection The full score
 
 
-The second file, @file{os-score.ly} reads the definitions of the first
-(@file{os-music.ly}), and defines the @code{\score} block for the full
+The second file, @file{input/tutorial/os-score.ly} reads the definitions of the first
+(@file{input/tutorial/os-music.ly}), and defines the @code{\score} block for the full
 conductor's score.
 
 
index 915363e4acedddd3060a0e7df2dd3b32cb5c9ed3..acfb18ff7a43d229d419840941d9f03b355016d6 100644 (file)
@@ -9,11 +9,15 @@
 */
 
 /*
-  
+TODO:
+
+
   * Junk stem_info.
 
   * Use Number_pair i.s.o Interval to represent (yl, yr).
 
+  * cross staff 
+  
 Notes:
 
  - Stems run to the Y-center of the beam.
@@ -303,9 +307,6 @@ Beam::brew_molecule (SCM grob)
   Real last_xposn = -1;
   Real last_width = -1 ;
   
-
-  * Determine auto knees based on positions if it's set by the user.
-  
   Molecule the_beam;
   Real lt = me->paper_l ()->get_var ("linethickness");
   for (int i = 0; i< stems.size(); i++)
@@ -1355,11 +1356,6 @@ where_are_the_whole_beams(SCM beaming)
 /*
   Calculate the Y position of the stem-end, given the Y-left, Y-right
   in POS, and for stem S.
-
-  If CORRECT, correct for beam_count of beam in case of knees.
-
-
-  TODO: junk CORRECT from this.
  */
 Real
 Beam::calc_stem_y (Grob *me, Grob* s, Interval pos, bool french) 
index d56d8ad0a69bfb7fbd594920dff3dca97531b5b4..13b471ec90cc9893ed98eda7742421cf44bcb281 100644 (file)
@@ -10,6 +10,7 @@
 #define SEQUENTIAL_ITERATOR_HH
 
 #include "music-iterator.hh"
+#include "protected-scm.hh"
 
 /*
 
@@ -71,6 +72,7 @@ protected:
 protected:
   Moment here_mom_;
   Music_iterator * iter_p_;
+  Protected_scm  list_;
   SCM cursor_;
   
   virtual void next_element (bool side_effect);
index 3e5d8a5dd5eb294323d77b19b626aee88f011778..de12d9362e33bf805e6799abfd96ae95de258106 100644 (file)
@@ -68,6 +68,7 @@ Sequential_iterator::Sequential_iterator (Sequential_iterator const &src)
 {
   grace_fixups_ = copy_grace_fixups (src.grace_fixups_);
   cursor_ = src.cursor_;
+  list_ = src.cursor_;
   here_mom_ = src.here_mom_;
   if (src.iter_p_)
     iter_p_ = src.iter_p_->clone ();
@@ -139,7 +140,8 @@ copy_grace_fixups (Grace_fixup* src)
 void
 Sequential_iterator::construct_children ()
 {
-  cursor_ = get_music_list ();
+  list_ = get_music_list ();
+  cursor_ = list_; 
 
   iter_p_ = gh_pair_p (cursor_) ?  get_iterator_p (unsmob_music (ly_car (cursor_))) : 0;
   while (iter_p_ && !iter_p_->ok ())
index bdd9f4ac5a3fb8c18cfdac074862582b0dea21d3..b023a3de0068034cfd8f8149c8325bfd4d1f7ac1 100644 (file)
@@ -481,7 +481,7 @@ def run_lilypond (files, outbase, dep_prefix):
        exit_status = status >> 8
 
        # 2 == user interrupt.
-       if signal <> 2:
+       if signal and  signal <> 2:
                error("\n\nLilyPond crashed (signal %d). Please submit a bugreport to bug-lilypond@gnu.org\n" % signal)
 
        if status: