lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Reinhold Kainhofer
Subject: Re: [PATCH] Add a way to override the part-combination decision
Date: Fri, 17 Sep 2010 12:48:30 +0200
User-agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.5.1; i686; ; )

Am Freitag, 17. September 2010, um 05:01:12 schrieben Sie:
> On Thu, Sep 16, 2010 at 2:24 PM, Reinhold Kainhofer
> 
> <address@hidden> wrote:
> > I have now implemented overriding the part-combine decisions. For this, I
> > abuse \set partcombineForced =... events to extract the desired
> > combination strategy in the \partcombine function (scheme code in
> > scm/part-combine.scm), before the property_iterator actually gets a
> > chance to set those properties.
> 
> General comment (have not looked in detail).
> 
> If you are not using the actual values, why use properties at all?

1) The parser does not accept anything else than set/unset/override/revert and 
\change between notes (i.e. not in postfix notation), AFAICS:

simple_music:
        event_chord
        | MUSIC_IDENTIFIER
        | music_property_def
        | context_change
        ;
I didn't want to pollute the parser once again with some notation specific to 
one particular feature.

2) For properties, \once is already properly implemented (i.e. the 
property_iterator inserts the corresponding \unset command at the end of the 
current time step), so I don't have to care about that special case. 
\once is actually crucial for the part combiner, as I found with a recent 
score. Quite often the two instruments are unisono only for the final (or the 
first) note of a phrase, so it it much more natural to simply use \once to fix 
part-combination for that one note. More than half of the times I needed to 
override the automatic part-combiner can actually be implemented as \once\....

3) All other customization in LilyPond works via Context or Grob properties, 
so it appeared consistent to me.

> You could create your own type of event that the part-combiner
> specifically could look for, and which is ignored for normal
> processing.   Would that not be more natural?


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?)

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]