At Sat, 09 Jul 2005 10:20:01 +0200, Han-Wen Nienhuys wrote: > <snip> > Hi, > > it's Officially Highly Cool that you have managed to rewrite the part > combiner. I would love to help solve the remaining problems with it. >
That's very nice to hear! > However, then I have to understand the code, and I'm missing the big > picture of what is happening. Maybe you could write a short overview of > the structure of your implementation? In particular, what data do you > use, and how do you store it? Actually I have only changed the internals of the determine-split-list function. It takes (almost) the same data-types, and returns the same data-types. The only change is that the recording group engraver now also sends an association list of settable properties (and the succes-values are removed before calling the determine-split-list function). However, since the output of determine-split-list list is structured differently, the backend will need to be adapted for these changes (though I think it will be more simple, not more complicated). The main difference is that all configuration types are grouped by blocks. This means that the engraver can always display "solo" and "a due" markings whenever the configuration changes. The current engraver sometimes doesn't display the markings (probably to prevent having a marking after each rest), but it will be safe to do so with the new combiner. > > Sorry if this sounds stupid: although I'm fairly knowledgeable about > theory of Scheme, I'm not all that fluent in reading and writing it. > I haven't written much scheme either. I believe one of the ideas behind functional programming is to make code more understandable and verifiable, but I don't think that's already the case for my code :-O Anyway I'll add more documentation, to make it more clear. I have attached a code-snippet which shows the bugs: - In bar one, the wrong rest gets eaten (the one of solo II, instead of solo I). - The slur in solo II in bar three should go until g, but the end somehow gets lost. - The multimeasure reast in bar six should be in a lower position (for voice 2), but it's sits in the standard mmrest position. Currently the time-signature must be part of the voice, if the part-combiner wants to be able to recognise it. Perhaps it could be possible to let the voice inherit the time-signature from the context when running the translator? Otherwise the behaviour of the part-combiner could be strange, without an indication to the user what is wrong. More improvements to the part-combiner: - At the beginning of a system, if a part is still in "a due" or "solo", repeat that mark in parentheses. - Perhaps the defaults for the markings should be "I." and "II.", at least that's what I found in the orchestral scores that I looked at. - It's a rare case, but actually occurs in my orchestration: after the solo melody the second voice comes in above the solo voice (in a voicecrossing). Perhaps it could be nice to display a little line to indicate where the melody is going (or maybe mark each voice with I. II.?). Kristof Bastiaensen
snippet.ly
Description: Binary data
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
