Re: part combiner

[Kristof Bastiaensen]

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