[Top][All Lists]
[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