Am Montag, 20. September 2010, um 20:25:30 schrieb Han-Wen Nienhuys: > On Mon, Sep 20, 2010 at 3:07 PM, Reinhold Kainhofer > > My only problem now is that when I add definitions like (so that one can > > also force other types than the pre-defined ones): > > > I am not sure. The warning comes from generic code in translator.cc. > Since the partcombiner passes music through translation twice (once to > determine the split list, once to do the actual typesetting), it may > be helpful to figure out if this comes from the first or the second > run. Without looking more closely I'd suspect that somehow two > different force events are delivered to the same context in the second > pass.
Sigh, okay, the problem was that I thought it would be appropriate for the PartCombineForceEvent to be in the event-class part-combine-event, too. Unfortunately, the UnisonoEvent etc. are added by the part-combiner and the PartCombineForceEvent survives the part-combiner, too. Now, the Part_combine_engraver listens to all part-combine-events and really receives two (one UnisonoEvent and one PartCombineForceEvent), triggering an error in the listen_part_combine call, where ASSIGN_ONCE is used... Removed PartCombineForceEvent from the part-combine-event class now. > > And the other small issue I have: Is there any way to let a > > music-function take a symbol (the forced part-combine strategy) or ##f > > (to revert to automatic part-combination) as argument? That would let me > > combine the partcombineAutomatic and partcombineApart etc. definitions > > to one single definition. > > I guess you could create a type predicate symbol-or-false? that > accepts either a symbol or false. I thought that would be seen as quite some hack, so I tried to find out if there is any other way. But weighing defining of such a function against code duplication, the function definition wins ;-) Am Montag, 20. September 2010, um 21:11:57 schrieb Neil Puttock: > On 20 September 2010 19:07, Reinhold Kainhofer <reinh...@kainhofer.com> wrote: > > Okay, I have now changed the code to use a new PartCombineForceEvent (had > > to add a dummy translator listener to the part-combine engraver to > > silence lilypond) > > Adding the event to `unlistened-music-event-classes' will silence it > without having to add a listener. Ah, thanks, I missed that (I grepped for some other events to see how they are handled without a listener, but I neglected to check the second hit in the define-event-classes.scm file). New patch is up now, which has included all comments and fixed all problems: http://codereview.appspot.com/1698054 Cheers, Reinhold -- ------------------------------------------------------------------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel