Re: partcombine, but including rests from quiet voices?

[Han-Wen Nienhuys]

2007/12/15, Reinhold Kainhofer <address@hidden>:

> On the other hand, I found the following patch on the mailing list:
> http://lists.gnu.org/archive/html/lilypond-devel/2005-07/msg00046.html
> http://lists.gnu.org/archive/html/lilypond-devel/2005-07/msg00050.html
>
> I haven't looked closely at the patch, but judging from the description, it
> does exactly what I had planned to do in determine-split-list. Does anyone
> know why these patches never got applied? Are there any problems with them?
> Or was there simply not enough interest?

IIRC the patch was supposed to fix a few small things, but was quite
huge. Requests for clarifications never materialized.

> I also read in some messages that the current implementation of the
> partcombiner is a hack and should be replaced by a version that uses
> streams... What's all this about? Are there still plans to significantly
> rewrite the partcombiner? If so, I won't touch it and invest time in code,
> which will later be replaced anyway.

The part combiner was written before Erik rewrote and cleaned the part
which reports events from music expressions to contexts (where the
events are transformed into graphic objects).
Before, the Music_iterators would directly access the Contexts.  The
streams layer was inserted in between, the two, so you can siphon off
the information into a file, or into a data structure, eg. for doing
the part combine analysis. If you're interested, check out Erik's
thesis which is on the website under the devel section.

To glue the old part-combiner code to the new interface, there is the function

  (define-public (recording-group-emulate music odef)

where you can see how the new interface works. Basically, there are
different event types, and for each type, you can setup a callback
that is executed when the event is seen.

The old code just gets a vector of (time-stamp, event) tuples, and
runs through that list in a couple of passes. Since it does not keep
track of event durations, the code cannot tell if a previously started
note is still playing or not.

Another reason why it is so hairy, is that the code tries to use a
half-baked object-oriented programming style in Scheme to achieve
this, and does so not very successfully. --  The OO constructs in
Scheme are poorly standardized, so we cannot use them.

If you go about this, I recommend that you start afresh. Probably, it
makes more sense to have a structure in which you can keep track of
more information.  By using listeners, build for each voice a
structure like

class VoiceState {

   // Iterate in time-order; uses info coming from listeners directly
   vector<StreamEvent> events_happening_at(Moment time_stamp, SCM event_type);
   Moment next_event_start(Moment time_stamp);
   Moment start_moment() const;
   Moment end_moment() const;

   // Build and query states
   SCM get_state_value(SCM symbol, Moment time_stamp);
   void set_state_value(SCM symbol, Moment time_stamp, SCM value);
   vector<StreamEvent> events_playing_at(Moment time_stamp, SCM event_type);
};

If you put all the info in trees (STL map<>'s should work), you can
have O(log n) access to any information you need, and flexibly add new
information.

You would iterate in a couple of different passes over the data,
populating state (dynamic level, current tuning, articulation, which
notes are playing, etc.) for each moment. With that information all
present, it should be easy to find sections which are eligible for
chord notation, and create a split-list based on that.

It might also be possible to have time-administration at this level,
so you can actually tell where the measure boundaries are.

Erik, is there a way to listen to that information wrt timing (measure
boundaries, etc.)?

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