Re: Part Combiner

[Kristof Bastiaensen]

At Mon, 29 Aug 2005 00:52:17 +0200,
Han-Wen Nienhuys wrote:
> 
> ned Kristof Bastiaensen wrote:
> > Hi,
> > <snip>
> > 
> > I'd appriciate an answer for these issues.
> 
> Hi,
> 
> I'm somewhat reluctant to add the code, since it is a large body of code 
> that I don't understand well enough to deal with bugreports.

I am not sure if I could do something about this.  Perhaps I could
refactor the code a bit to make it clearer to understand.  Especially
the final part is too complicated.  I am considering if some kind of a
pattern-matcher could simplify the whole thing.

If there are comments that don't make sense, I would gladly modify
them.

> In addition, the whole design of the part-combiner will be trashed
> anyway when we have sensible music stream datastructures (see the
> mail in lilypond-devel by Erik S)
>

That looks interesting.  The music-stream datastructure looks to me
like an AST (Abstract Syntax Tree) for a compiler.  Many functional
languages (Haskell, Ocaml, SML) are based on such datatypes, and their
type-system makes handling such AST's especially easy, together with
other features like pattern-matching on types.

I don't see why these ideas affect the part-combiner.  The code is
already written, and integrating it in the current system would be
effortless (just patching it, basicly).  Fixing the last bugs would be
a bit of an effort, but I had the impression they were just small
bugs, and wouldn't require large rewrites of code.

> My conditions for integrating this patch are
> 
> - I will need a copyright disclaimer for the code
>

For me it is ok to add any (open-source) license.  I heard that
contributors for FSF owned projects need to sign a paper for copyright
issues.  If that is the case, then I'll fill in the necessary
paperwork (if I have the right papers).

> - There should be no regressions: ie. if your code should not have bugs 
> that the old code did not have.
>

It doesn't have as far as I know (as much as that is possible to say
about new code).  The regression tests that came with the previous
part-combiner will not work anymore, but that is deliberatly.  My
part-combiner only makes changes (from and to solo, a due, ...) for
larger blocks (with a rather complicated algorithm to determine the
beginning and end of blocks).  That is to prevent to many changes from
happening in a short time, making the score more cluttered and less
readable.  The regression tests are all small fragments, and my
part-combiner will likely put the whole fragment apart, a due or solo.

There are still bugs in it, but these bugs were also there in the old
part-combiner.  For example when there are two rests of different
length in the beginning of a measure, sometimes it eats the shorter
rest, leaving a hole where the shorter rest should have been.  I still
have a small file with examples that show these bugs.  If you would
like I could send them to the list.

> If you need the code, also consider to add it yourself;  \partcombine is 
> defined in ly/music-functions-init.ly , so it should not be hard to 
> write a partcombine-init.ly that defines a \myPartcombine and loads a 
> my-partcombine.scm file.
>

Ok, I'll probably do that for now.

> -- 
>   Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen