On 2015/10/01 08:33:11, dak wrote:
into the user interface as well as extending the code. Let's assume
that we
make chord extent changeable on the fly via setting a context
property. How
would you implement that using your part combiner structure?
Then I would remove it from the structure. For the force commands, it would be good to survey where they have been used so far. Some of them are obsolete now that the chord range is configurable. Some of them could be blamed on bugs that should be fixed. Some of them would be unnecessary with different state machines. Some of them might be easily replaced with other work-arounds like manual beams or invisible phrasing slurs. I don't mean to say that there shouldn't be a method of working around unwanted decisions, but that the number of situations in which they are necessary probably does not justify a high level of elegance. Really, I couldn't care less how the force commands are implemented. But I am skeptical about converting the chord range to a context property because from what I have seen so far, it seems to involve having the property-set commands within the parts being combined, and that doesn't make sense. Configuring the part combiner's decisions from within the parts breaks down cases where a part might be used in different ways in multiple situations: % flute.ly \include "hymn.ly" ... \partcombine \transpose c c' \tenor \soprano % violin.ly \include "hymn.ly" ... \partcombine \soprano \alto ... % viola.ly \include "hymn.ly" ... \partcombine \alto \tenor ... I have collections that do that kind of thing. Putting all that aside, what I really want in the near term is to reduce the amount of Lilypond code I have duplicated with my compositions. Without defining a <Part-combiner> class, I could still do that by passing the chord range and state machines as individual arguments. <Part-combiner> was a nice way to help me organize things on the way there, but I could still achieve this goal without it. Would you feel any better about that? Or do you think that it is proper for me to have to make my own copy of make-directed-part-combine-music in order to use the part combiner with different state machines? Alternatively, if exposing the state machines as options to public scheme methods is itself objectionable, what would be the reaction to my submitting a patch with a new command that does exactly what I want (no a2/solo passages) out of the box? https://codereview.appspot.com/265260043/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel