At Mon, 29 Aug 2005 23:51:06 +0200,
Han-Wen Nienhuys wrote:
>
> Kristof Bastiaensen wrote:
> > 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.
>
> To me, the new code reads like a long list of small function
> definitions. It's difficult to tell how the different parts are related.
>
Yes, I wrote it that way because I believe it is easier to understand
many little functions that one monolithic block. This is a style that
is actually prefered by most scheme programmers. I had included a
roadmap in the source that documents the general structure, and the
source follows that structure. The different parts are:
- a list is made for the notes and the spanners containing the start
and end moment for each item (the note-lengths and spanner-lengths
functions).
- various information is extracted from the event-lists, like the
position in the measure for each moment (measure-positions), the
limits for blocks as calculated from the measure lengths
(measure-limits), the longest voice and the end-moment of that voice
(music-end+longest).
- input and output configurations are calculated between both voices
from those lists (as explained in the roadmap). This is in the
(probably not so well named :-/) function make-type-context-list.
(Perhaps I should rename it to make-configuration-list).
- Some merges are prevented to keep the flow of voices inside
measures (fix-rests-in-measures!).
- Changes in output configuration are only allowed for blocks that
have a large enough size (i.e. to avoid change from a due to solo and
back in one measure) (fix-blocks!).
The way the last two fases work is commented extensively in the source.
This structure can also be seen clearly from the definition of the
toplevel determine-split-list function:
(define-public (determine-split-list evl1 evl2)
"EVL1 and EVL2 should be ascending"
(multi-let*
((moments (merge-moments evl1 evl2))
(notes1 (note-lengths evl1))
(notes2 (note-lengths evl2))
(span1 (spanner-lengths evl1))
(span2 (spanner-lengths evl2))
(measurepos (measure-positions moments evl1 evl2))
(music-end longest (music-end+longest evl1 evl2))
(measurelimits (measure-limits longest))
(types (make-type-context-list moments notes1 notes2
span1 span2 measurepos
measurelimits)))
(fix-rests-in-measures! types #f #f)
(let loop ()
(if (fix-blocks! types #f #t music-end)
(if (fix-rests-in-measures! types #f #f)
loop)))
(synthesize-types types)))
> >>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.
>
> Yes, but it's not. You should rather think of a MIDI file, but
>
> - with rational numbers iso. ticks
> - with events suitable for typesetting
> - without arbitrary limits.
>
Ok, I hope to learn more about it when there is more info (or is there
already?).
> > 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.
>
> But the thresholds can be tuned, no? For the regtest, you could tune
> them down, so we can still verify whether everything works.
>
Erm, actually not, but making it tunable would be a trivial change.
> Also, it would be helpful if we could have the new and current
> partcombiner together for a couple of release so we can see the
> differences, and get some feedback.
>
Yes.
>
> --
> Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
