Re: [PATCH] Add a way to override the part-combination decision

[Han-Wen Nienhuys]

On Mon, Sep 20, 2010 at 3:07 PM, Reinhold Kainhofer
<address@hidden> wrote:
> Am Freitag, 17. September 2010, 14:52:50 schrieb Han-Wen Nienhuys:
>> On Fri, Sep 17, 2010 at 7:48 AM, Reinhold Kainhofer
>>
>> <address@hidden> wrote:
>> > So, you think we should rather extend the parser to cater for that
>> > feature? (Or do you know any way to insert an event in simple_music
>> > without extending the parser?)
>>
>> I was thinking of inserting a zero duration music event, similar to
>> eg. barcheck, through an identifier.
>
> 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)
>
> New patch is up at:
> http://codereview.appspot.com/1698054/
>
>
> My only problem now is that when I add definitions like (so that one can also
> force other types than the pre-defined ones):

>
>
> Strangely, it does not happen when I define partcombineApart etc. as
>

>
> Any idea what the difference between these two definitions are?

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.

> 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.




-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen