Re: Some fixes to musicxml2ly
On Fri, 2006-09-15 at 22:11 +0300, Tuukka Verho wrote: > The attached diff for musicxml.py now has an explanatory comment. Oops, sent a diff without the comment. Here comes the correnct version. Tuukka --- lilypond/python/musicxml.py 2006-08-26 01:04:08.0 +0300 +++ musicxml.py 2006-09-16 10:12:27.0 +0300 @@ -1,4 +1,5 @@ import new +import math from rational import * class Xml_node: @@ -193,7 +194,22 @@ 'long': -2, 'whole': 0} [log] else: - return 0 + # Using floating point arithmetic here to calculate logarithm + # the term 2**tolerance_exp ensures that borderline cases are + # rounded to the next whole duration + + tolerance_exp = -4 # means that notes that are 1/32 or less + # shorter than 1/4 will be quarter notes etc. + return int (math.ceil + (-math.log (self._duration) / math.log (2) - 2**tolerance_exp)) + +def get_num_dots(self): +if self.get_maybe_exist_typed_child (class_dict['type']): +return len (self.get_typed_children (Dot)) + +else: +factor = self._duration / 2**(-self.get_duration_log()) +return int (round (-math.log(2 - factor) / math.log(2))) def get_factor (self): return 1 @@ -351,27 +367,26 @@ elements.extend (m.get_all_children ()) start_attr = None - for n in elements: - voice_id = n.get_maybe_exist_typed_child (class_dict['voice']) - - if not (voice_id or isinstance (n, Attributes)): - continue - - if isinstance (n, Attributes) and not start_attr: - start_attr = n - continue - - if isinstance (n, Attributes): - for v in voices.values (): + for n in elements: + if (isinstance (n, Note)): + voice_id = n.get_maybe_exist_typed_child (get_class('voice')) + if voice_id: + id = voice_id.get_text () + else: + id = '1' + + if not voices.has_key (id): + voices[id] = Musicxml_voice() + + voices[id].add_element (n) + + elif isinstance (n, Attributes): + if not start_attr: + start_attr = n + + for v in voices.values (): v.add_element (n) - continue - - id = voice_id.get_text () - if not voices.has_key (id): - voices[id] = Musicxml_voice() - - voices[id].add_element (n) - + if start_attr: for (k,v) in voices.items (): v.insert (0, start_attr) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Some fixes to musicxml2ly
[EMAIL PROTECTED]: > On Fri, 2006-09-15 at 19:33 +0200, Han-Wen Nienhuys wrote: > > > > > else: > > > - return 0 > > > + tolerance_exp = -4 # means that notes that are 1/32 or less > > > shorter > > > than 1/4 are quarter notes etc. > > > + return int (math.ceil (-math.log(self._duration) / > > > math.log(2) - > > > 2**tolerance_exp)) > > > > Since music notation uses exact rational numbers, using math.log () is > > usually forbidden, and it's better to use exact arithmetic. Can you > > doublecheck whether or not exact arithmetic applies to your case, please > > add an explanation comment why you're using floating point numbers? > > In this case inexactness doesn't matter. The term 2**tolerance_exp makes > sure that notes that are slightly shorter than the next whole duration > are rounded to the whole duration instead of somethin like "c8.". In > some cases floating point arithmetic can cause some randomness regarding > whether the note becomes c8... or c4 (if the duration is exactly 1/32 > from the next whole duration), but I don't think that matters -- such > note length are weird enough to start with. > > When determining the number of dots the use of floating point arithmetic > doesn't obviously harm, because the result is rounded anyway. > > I can't think of any simple way to achieve the same result without using > math.log(). > > The attached diff for musicxml.py now has an explanatory comment. > I don't understand this: tolerance_exp = -4 a = - math.log(self._duration) / math.log(2) b = 2**tolerance_exp c = a - b 1: if tolerance_exp is a constant, why don't you simply say b = 1/16 (another constant), which is clearly a duration(?) value. 2: why are you taking the difference between the log of a duration and a duration? In physics there is something which is called a dimension test: you simply cannot do 1 meter - 1 second. In math, you don't easily agree to do log(entity) - entity. And in this case I read your code as -2log( seconds ) - seconds which is clearly wrong. Now b seems to be an implementation detail caused by using floating point values, the same with math.ceil, is it so? If you simply want to map a duration to its -2log, why don't you use something like arr = [ 1, 2, 4, ...]; f(x) = arr[x]; which is a clear statement about what you are doing (although incomplete, I sense that self._duration is a rational number). 3: I don't understand what you are trying to do and your comment does not match the code 4: using floating point values for exact things usually open up enough nasty bugs and is very hard to verify due to rounding errors. Unless you have VERY good reason, just don't do it, it is not worth the trouble. === Later in your patch: +factor = self._duration / 2**(-self.get_duration_log()) +return int (round (-math.log(2 - factor) / math.log(2))) If: a = 1/2**(-self.get_duration_log()) then: a = 2**self.get_duration_log() assuming that get_duration_log() returns a 2log and that get_duration() exists, then a = self.get_duration() get_duration() look suspiciously like _duration(), so my guess is that factor = self._duration ** 2 by quickly reading the code as a math guy. Now, if duration usually is less than 1 (we don't see many breves and longas today), then -math.log(2 - factor) / math.log(2) more or less reduces to a near constant -1. Is that your intention, or am I reading your code false? I assume that duration is the lenght of a note, like whole note is 1, a quater note is 1/4, ... Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340Networks S-742 94 Östhammar +46 173 140 57 Computers Sweden +46 70 511 97 84 Consulting --- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] export functions from layout-page-layout.scm
Hi, The attached patch exports some of the utility function names in scm/layout-page-layout.scm, so that they should be called by user defined page breaking functions. Make web runs fine, and the page breaking regression tests seem to look as expected. May I commit? nicolas Index: ChangeLog === RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v retrieving revision 1.5299 diff -u -r1.5299 ChangeLog --- ChangeLog 15 Sep 2006 18:04:16 - 1.5299 +++ ChangeLog 16 Sep 2006 11:15:25 - @@ -1,3 +1,18 @@ +2006-09-16 Nicolas Sceaux <[EMAIL PROTECTED]> + + * scm/layout-page-layout.scm: export utility function names to + enable custom page breaking function writing. Tabify. + (line-next-space): use ?-suffix only for predicates + (page-maximum-space-to-fill): new function. Return the space + between first and bottom system of a page, to give to + space-systems. + (space-systems): use a space-to-fill argument (for instance as + computed by page-maximum-space-to-fill) instead of computing + internaly this space with the page height. That way, the caller + can adjust the space to use. + (make-page-from-systems, walk-paths): compute space to fill before + calling space-systems. + 2006-09-15 Mats Bengtsson <[EMAIL PROTECTED]> * ly/engraver-init.ly: Make FiguredBass accepted in GrandStaff and Index: scm/layout-page-dump.scm === RCS file: /cvsroot/lilypond/lilypond/scm/layout-page-dump.scm,v retrieving revision 1.1 diff -u -r1.1 layout-page-dump.scm --- scm/layout-page-dump.scm 15 Jul 2006 10:34:29 - 1.1 +++ scm/layout-page-dump.scm 16 Sep 2006 11:15:27 - @@ -10,7 +10,9 @@ #:use-module (scm paper-system) #:use-module (scm page) #:use-module (lily) - #:export (write-page-breaks)) + #:export (write-page-breaks +;; utilisties for writing other page dump functions +record-tweaks dump-all-tweaks)) (define (record-tweaks what property-pairs tweaks) Index: scm/layout-page-layout.scm === RCS file: /cvsroot/lilypond/lilypond/scm/layout-page-layout.scm,v retrieving revision 1.21 diff -u -r1.21 layout-page-layout.scm --- scm/layout-page-layout.scm 4 Sep 2006 05:31:28 - 1.21 +++ scm/layout-page-layout.scm 16 Sep 2006 11:15:27 - @@ -3,7 +3,7 @@ source file of the GNU LilyPond music typesetter (c) 2004--2006 Jan Nieuwenhuizen <[EMAIL PROTECTED]> - Han-Wen Nienhuys <[EMAIL PROTECTED]> + Han-Wen Nienhuys <[EMAIL PROTECTED]> (define-module (scm layout-page-layout) #:use-module (srfi srfi-1) @@ -13,7 +13,13 @@ #:use-module (scm page) #:use-module (scm layout-page-dump) #:use-module (lily) - #:export (post-process-pages optimal-page-breaks make-page-from-systems)) + #:export (post-process-pages optimal-page-breaks make-page-from-systems + ;; utilities for writing custom page breaking functions + line-next-space line-next-padding + line-minimum-distance line-ideal-distance + first-line-position + line-ideal-relative-position line-minimum-relative-position + page-maximum-space-to-fill space-systems)) (define (post-process-pages layout pages) (if (ly:output-def-lookup layout 'write-page-layout #f) @@ -25,18 +31,18 @@ (define (line-next-space line next-line layout) "Return space to use between `line' and `next-line'. `next-line' can be #f, meaning that `line' is the last line." - (let* ((title? (paper-system-title? line)) - (next-title? (and next-line (paper-system-title? next-line -(cond ((and title? next-title?) - (ly:output-def-lookup layout 'between-title-space)) - (title? - (ly:output-def-lookup layout 'after-title-space)) - (next-title? - (ly:output-def-lookup layout 'before-title-space)) - (else - (ly:prob-property -line 'next-space -(ly:output-def-lookup layout 'between-system-space)) + (let* ((title (paper-system-title? line)) + (next-title (and next-line (paper-system-title? next-line +(cond ((and title next-title) + (ly:output-def-lookup layout 'between-title-space)) + (title + (ly:output-def-lookup layout 'after-title-space)) + (next-title + (ly:output-def-lookup layout 'before-title-space)) + (else + (ly:prob-property + line 'next-space + (ly:output-def-lookup layout 'between-system-space)) (define (line-next-padding line next-line layout) "Return padding to use between `line' and `next-line'. @@ -51,22 +57,22 @@ reference position. If next-line is #f, return #f." (and next-line (max 0 (- (+ (interval-end (paper-system-extent next-line Y)) -(if ignore-padding 0 (line-next-padding line next-line layout))) - (interval-start (paper-system-extent line Y)) + (if ignore-paddi
Re: [patch] export functions from layout-page-layout.scm
Nicolas Sceaux wrote: Hi, The attached patch exports some of the utility function names in scm/layout-page-layout.scm, so that they should be called by user defined page breaking functions. Make web runs fine, and the page breaking regression tests seem to look as expected. May I commit? please do. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] export functions from layout-page-layout.scm
Nicolas Sceaux wrote: Hi, The attached patch exports some of the utility function names in scm/layout-page-layout.scm, so that they should be called by user defined page breaking functions. Make web runs fine, and the page breaking regression tests seem to look as expected. May I commit? please do. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
The life of a Grob
Understanding the LilyPond source often boils down to figuring out what is happening to the Grobs. Where (and why) are they being created, modified and destroyed? I've spent many hours tracing Lily through a debugger and it is mind-blowingly tedious. So I quickly hacked a few things together and came up with something a bit better. I added hooks into internal_grob_set_property and make_grob_from_properties. You can register a scheme callback which will get called whenever a Grob is modified or created. The scheme callback will receive the file and line numbers in the C++ source where the call was made. This can help you to trace cause and effect through the C++ source. This is very hackish right now (I only started this morning), but I thought I'd share a quick application. The file test.ly produces a graphviz output file, "graph.dot", that lets you visualise the changes in Grobs throughout LilyPond execution. For now, you'll need to add a closing brace to the end of graph.dot. I attach a patch, an example input file and a sample output. diff --git a/lily/accidental-engraver.cc b/lily/accidental-engraver.cc index 39a66ba..20f0103 100644 --- a/lily/accidental-engraver.cc +++ b/lily/accidental-engraver.cc @@ -402,7 +402,7 @@ Accidental_engraver::make_standard_accid = make_grob_from_properties (trans, ly_symbol2scm ("Accidental"), note_head->self_scm (), - "Accidental"); + "Accidental", __FILE__, __LINE__); /* We add the accidentals to the support of the arpeggio, @@ -442,7 +442,7 @@ Accidental_engraver::make_suggested_acci = make_grob_from_properties (trans, ly_symbol2scm ("AccidentalSuggestion"), note_head->self_scm (), - "AccidentalSuggestion"); + "AccidentalSuggestion", __FILE__, __LINE__); Side_position_interface::add_support (a, note_head); if (Grob *stem = unsmob_grob (a->get_object ("stem"))) diff --git a/lily/align-interface.cc b/lily/align-interface.cc index afe4702..b2160d0 100644 --- a/lily/align-interface.cc +++ b/lily/align-interface.cc @@ -323,7 +323,7 @@ Align_interface::add_element (Grob *me, SCM sym = axis_offset_symbol (a); SCM proc = axis_parent_positioning (a); - element->internal_set_property (sym, proc); + element->internal_set_property (sym, proc, __FILE__, __LINE__); Axis_group_interface::add_element (me, element); } diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc index 1d509f0..2727751 100644 --- a/lily/axis-group-interface.cc +++ b/lily/axis-group-interface.cc @@ -37,7 +37,7 @@ Axis_group_interface::add_element (Grob e->internal_set_object ((a == X_AXIS) ? ly_symbol2scm ("axis-group-parent-X") : ly_symbol2scm ("axis-group-parent-Y"), - me->self_scm ()); + me->self_scm (), __FILE__, __LINE__); } /* must be ordered, because Align_interface also uses diff --git a/lily/break-align-engraver.cc b/lily/break-align-engraver.cc index e6a7935..7b4f4b7 100644 --- a/lily/break-align-engraver.cc +++ b/lily/break-align-engraver.cc @@ -85,7 +85,7 @@ Break_align_engraver::acknowledge_break_ left_edge_ = make_item_from_properties (random_source, ly_symbol2scm ("LeftEdge"), SCM_EOL, - "LeftEdge"); + "LeftEdge", __FILE__, __LINE__); add_to_group (left_edge_->get_property ("break-align-symbol"), left_edge_); } diff --git a/lily/break-substitution.cc b/lily/break-substitution.cc index 0c1e996..8d65f6b 100644 --- a/lily/break-substitution.cc +++ b/lily/break-substitution.cc @@ -397,7 +397,7 @@ Spanner::fast_substitute_grob_array (SCM if (!unsmob_grob_array (newval)) { newval = Grob_array::make_array (); - sc->internal_set_object (sym, newval); + sc->internal_set_object (sym, newval, __FILE__, __LINE__); } Grob_array *new_array = unsmob_grob_array (newval); @@ -500,14 +500,14 @@ Spanner::substitute_one_mutable_property if (!unsmob_grob_array (newval)) { newval = Grob_array::make_array (); - sc->internal_set_object (sym, newval); + sc->internal_set_object (sym, newval, __FILE__, __LINE__); } substitute_grob_array (grob_array, unsmob_grob_array (newval)); } else { SCM newval = do_break_substitution (val); - sc->internal_set_object (sym, newval); + sc->internal_set_object (sym, newval, __FILE__, __LINE__); } } } diff --git a/lily/context-property.cc b/lily/context-property.cc index 502fc92..0f77cfd 100644 --- a/lily/context-property.cc +++ b/lily/context-property.cc @@ -118,7 +118,7 @@ execute_general_pushpop_property (Contex { SCM base = updated_grob_properties (context, context_property); current_context_val = scm_cons (base, base); - context->internal_set_property (context_property, current_context_val); + context->internal_set_property (context_property, current_context_val, __FILE__, __LINE__); } if (!scm_is_pair (current_context_val)) @@ -180,7 +180,7 @@ execute_general
Re: The life of a Grob
Joe Neeman wrote: Understanding the LilyPond source often boils down to figuring out what is happening to the Grobs. Where (and why) are they being created, modified and destroyed? I've spent many hours tracing Lily through a debugger and it is mind-blowingly tedious. So I quickly hacked a few things together and came up with something a bit better. I added hooks into internal_grob_set_property and make_grob_from_properties. You can register a scheme callback which will get called whenever a Grob is modified or created. The scheme callback will receive the file and line numbers in the C++ source where the call was made. This can help you to trace cause and effect through the C++ source. Of course, having written much of the code myself, I don't need it, but this is extremely cool! Some comments: * can you add another macro layer, so __LINE__ and __FILE__ aren't sprinkled around in the code? For good measure, you could also add __FUNCTION__ . * similarly, can you add macro layering, so that passing around line numbers/file names is entirely optional, and doesn't happen for a -DNDEBUG build? * It might be possible to get some sort of causality in the diagram, by recursively tracing 'cause properties. Dunno if that helps understanding things, though. + protect (); + if (ly_is_procedure (modification_callback)) + scm_apply_0 (modification_callback, + scm_list_n (self_scm (), scm_makfrom0str (file), scm_from_int (line), + sym, v, SCM_UNDEFINED)); + unprotect (); this protection should not be necessary: as self_scm is passed as Stack variable it will be GC protected. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
> The file test.ly produces a > graphviz output file, "graph.dot", that lets you visualise the changes > in Grobs throughout LilyPond execution. For now, you'll need to add a > closing brace to the end of graph.dot. Very nice! A minor suggestion: Please add a counter to the boxes so that they are enumerated. Then the start of an arrow should be labeled with the number of the target box, and the end of an arrow should tagged with the number of the origin box. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote: > Some comments: > > * can you add another macro layer, so __LINE__ and __FILE__ aren't > sprinkled around in the code? For good measure, you could also add > __FUNCTION__ . How about something like the attached patch? I "overload" get_property so that it can take a SCM directly. Then I can replace every internal_get_property with get_property. > > * similarly, can you add macro layering, so that passing around line > numbers/file names is entirely optional, and doesn't happen for a > -DNDEBUG build? Sure. > > * It might be possible to get some sort of causality in the diagram, by > recursively tracing 'cause properties. Dunno if that helps understanding > things, though. Probably. There are a bunch more hooks I want to add too... this was just the start :) > > + protect (); > > + if (ly_is_procedure (modification_callback)) > > + scm_apply_0 (modification_callback, > > + scm_list_n (self_scm (), scm_makfrom0str (file), > > scm_from_int (line), > > + sym, v, SCM_UNDEFINED)); > > + unprotect (); > > this protection should not be necessary: as self_scm is passed as Stack > variable it will be GC protected. I was getting segfaults in scm_gc_mark and this magically solved it. Being in dirty hack mode, I didn't investigate further. But you're right. diff --git a/lily/include/lily-guile-macros.hh b/lily/include/lily-guile-macros.hh index 7002c0f..dcb0a13 100644 --- a/lily/include/lily-guile-macros.hh +++ b/lily/include/lily-guile-macros.hh @@ -29,6 +29,14 @@ #endif #ifdef CACHE_SYMBOLS +/* this lets us "overload" macros such as get_property to take + symbols as well as strings */ +inline SCM +scm_or_str2symbol (char const *c) { return scm_str2symbol (c); } + +inline SCM +scm_or_str2symbol (SCM s) { return s; } + /* Using this trick we cache the value of scm_str2symbol ("fooo") where "fooo" is a constant string. This is done at the cost of one static variable per ly_symbol2scm() use, and one boolean evaluation for @@ -43,10 +51,10 @@ #define ly_symbol2scm(x) \ if (__builtin_constant_p ((x))) \ { \ if (!cached) \ - value = cached = scm_gc_protect_object (scm_str2symbol ((x))); \ + value = cached = scm_gc_protect_object (scm_or_str2symbol (x)); \ } \ else\ - value = scm_str2symbol ((char *) (x));\ + value = scm_or_str2symbol (x); \ value;\ }) #else diff --git a/lily/tweak-engraver.cc b/lily/tweak-engraver.cc index a479935..1749228 100644 --- a/lily/tweak-engraver.cc +++ b/lily/tweak-engraver.cc @@ -33,7 +33,7 @@ Tweak_engraver::acknowledge_grob (Grob_i for (SCM s = music->get_property ("tweaks"); scm_is_pair (s); s = scm_cdr (s)) { - info.grob ()->internal_set_property (scm_caar (s), scm_cdar (s), __FILE__, __LINE__); + info.grob ()->set_property (scm_caar (s), scm_cdar (s)); } } } ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
On Sat, 2006-09-16 at 20:47 +0200, Werner LEMBERG wrote: > > The file test.ly produces a > > graphviz output file, "graph.dot", that lets you visualise the changes > > in Grobs throughout LilyPond execution. For now, you'll need to add a > > closing brace to the end of graph.dot. > > Very nice! A minor suggestion: Please add a counter to the boxes so > that they are enumerated. Then the start of an arrow should be > labeled with the number of the target box, and the end of an arrow > should tagged with the number of the origin box. I don't suppose you'd know how to do this in graphviz? I'm quite new to it. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
Joe Neeman wrote: On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote: Some comments: * can you add another macro layer, so __LINE__ and __FILE__ aren't sprinkled around in the code? For good measure, you could also add __FUNCTION__ . How about something like the attached patch? I "overload" get_property so that it can take a SCM directly. Then I can replace every internal_get_property with get_property. Clever! This means that we can do away with the whole internal_FOO business, right? (also for some other functions, I expect.) Can you prepare a patch that removes all the internal_XXX ? + protect (); + if (ly_is_procedure (modification_callback)) + scm_apply_0 (modification_callback, + scm_list_n (self_scm (), scm_makfrom0str (file), scm_from_int (line), + sym, v, SCM_UNDEFINED)); + unprotect (); this protection should not be necessary: as self_scm is passed as Stack variable it will be GC protected. I was getting segfaults in scm_gc_mark and this magically solved it. Being in dirty hack mode, I didn't investigate further. But you're right. ok, but to get this in lily, we have to get it out of dirty hack mode. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
On Sun, 2006-09-17 at 01:20 +0200, Han-Wen Nienhuys wrote: > Joe Neeman wrote: > > On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote: > >> Some comments: > >> > >> * can you add another macro layer, so __LINE__ and __FILE__ aren't > >> sprinkled around in the code? For good measure, you could also add > >> __FUNCTION__ . > > How about something like the attached patch? I "overload" get_property > > so that it can take a SCM directly. Then I can replace every > > internal_get_property with get_property. > > Clever! This means that we can do away with the whole internal_FOO > business, right? (also for some other functions, I expect.) > Can you prepare a patch that removes all the internal_XXX ? Except that I will need internal_FOO for the scheme hooks. It will be completely transparent to other parts of the code though (ie. internal_FOO shouldn't be called directly by anything any more). I should be able to do something similar for make_{item,spanner,paper_column} too. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: The life of a Grob
> > Very nice! A minor suggestion: Please add a counter to the boxes so > > that they are enumerated. Then the start of an arrow should be > > labeled with the number of the target box, and the end of an arrow > > should tagged with the number of the origin box. > > I don't suppose you'd know how to do this in graphviz? I'm quite new to > it. Sorry, no. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
page breaking and vector_sort cleanups
This patch STL-ifies vector_sort much like my previous patch for binary_search. It also includes my patch for rewriting the interpretation step for page turns. These changes touch a lot of files, so I'd like to get them committed before I mess up my working tree with grob graphing stuff. 2006-09-17 Joe Neeman <[EMAIL PROTECTED]> * scm/define-music-types.scm (music-descriptions): remove BreakEvent and fix {Page,Line}{Break,Turn}Event so Music::to_event doesn't complain. * lily/accidental-placement.cc (ape_compare): * lily/semi-tie.cc (compare): * lily/note-column.cc (shift_compare): replace by XXX_less * lily/tie-formatting-problem.cc (set_chord_outline): * lily/tie-column.cc (calc_positioning_done): * lily/system.cc (post_processing) (get_paper_system): * lily/stem.cc (note_head_positions) (calc_positioning_done): * lily/spanner.cc (do_break_processing) (find_broken_piece): * lily/span-bar.cc (print): * lily/semi-tie-column.cc (calc_positioning_done): * lily/rest-collision.cc (calc_positioning_done): * lily/program-option.cc (get_help_string): * lily/note-collision.cc (get_clash_groups): * lily/new-fingering-engraver.cc (position_scripts): * lily/keyword.cc (Keyword_table): * lily/hara-kiri-group-spanner.cc (request_suicide): * lily/grob-pq-engraver.cc (stop_translation_timestep): * lily/accidental-placement.cc (calc_positioning_done): (stagger_apes): * lily/beam.cc (get_beam_segments): * lily/grob-array.cc (remove_duplicates): use new vector_sort * input/mutopia/W.A.Mozart/mozart-hrn3-defs.ily: ragged-last-bottom = ##f (test the new page breaker) * flower/include/std-vector.hh (vector_sort): use STL sort stuff * scm/define-context-properties.scm (all-internal-translation-properties): remove properties that were used to communicate page-turn stuff to the paper-column engraver. * lily/lily-guile.cc (robust_scm2string): new function * lily/paper-column-engraver.cc: Clean up page turn stuff * lily/page-turn-engraver.cc: Re-write the page turn logic here instead of cluttering up paper-column-engraver.cc Index: ChangeLog === RCS file: /sources/lilypond/lilypond/ChangeLog,v retrieving revision 1.5304 diff -u -r1.5304 ChangeLog --- ChangeLog 16 Sep 2006 22:34:51 - 1.5304 +++ ChangeLog 17 Sep 2006 06:14:52 - @@ -1,3 +1,53 @@ +2006-09-17 Joe Neeman <[EMAIL PROTECTED]> + + * scm/define-music-types.scm (music-descriptions): remove + BreakEvent and fix {Page,Line}{Break,Turn}Event so + Music::to_event doesn't complain. + + * lily/accidental-placement.cc (ape_compare): + * lily/semi-tie.cc (compare): + * lily/note-column.cc (shift_compare): replace by XXX_less + + * lily/tie-formatting-problem.cc (set_chord_outline): + * lily/tie-column.cc (calc_positioning_done): + * lily/system.cc (post_processing) + (get_paper_system): + * lily/stem.cc (note_head_positions) + (calc_positioning_done): + * lily/spanner.cc (do_break_processing) + (find_broken_piece): + * lily/span-bar.cc (print): + * lily/semi-tie-column.cc (calc_positioning_done): + * lily/rest-collision.cc (calc_positioning_done): + * lily/program-option.cc (get_help_string): + * lily/note-collision.cc (get_clash_groups): + * lily/new-fingering-engraver.cc (position_scripts): + * lily/keyword.cc (Keyword_table): + * lily/hara-kiri-group-spanner.cc (request_suicide): + * lily/grob-pq-engraver.cc (stop_translation_timestep): + * lily/accidental-placement.cc (calc_positioning_done): + (stagger_apes): + * lily/beam.cc (get_beam_segments): + * lily/grob-array.cc (remove_duplicates): + use new vector_sort + + * input/mutopia/W.A.Mozart/mozart-hrn3-defs.ily: + ragged-last-bottom = ##f (test the new page breaker) + + * flower/include/std-vector.hh (vector_sort): use STL sort stuff + + * scm/define-context-properties.scm + (all-internal-translation-properties): remove properties that + were used to communicate page-turn stuff to the paper-column + engraver. + + * lily/lily-guile.cc (robust_scm2string): new function + + * lily/paper-column-engraver.cc: Clean up page turn stuff + + * lily/page-turn-engraver.cc: Re-write the page turn logic here + instead of cluttering up paper-column-engraver.cc + 2006-09-17 Han-Wen Nienhuys <[EMAIL PROTECTED]> * scm/script.scm (default-script-alist): set paddings for every Index: flower/include/interval.hh === RCS file: /sources/lilypond/lilypond/flower/include/interval.hh,v retrieving revision 1.58 diff -u -r1.58 interval.hh --- flower/include/interval.hh 11 Feb 2006 11:35:18 - 1.58 +++ flower/include/interval.hh 17 Sep 2006 06:14:52 - @@ -128,9