Problems with the Current Call Engine

[MarkNahabedian]

Knowing which formations to ignore

For something like PassThru from FacingLinesOfFour, after the first part, _StepToAWave, we have 4 RHMiniWaves which are relevant to the second part, _PassBy, but we also have 3 LHMiniWaves which we want to ignore. See issue #9.

Maybecan_do should return a Set of CanDoCall objects rather than a preference number. CanDoCall would still hold a preference value. We can index them by which dancers each concerns, eliminiate those that concern the most dancers, then reindex and re-eliminate until we have a set of CanDoCalls with no overlap. These can perform the _PassBy.

Simultaneous Parts and Actions

We need to deal with the cases where different dancers are performing different calls simultaneously, for example "Heads SquareThru while Sides Promenade 1/2".

There are other calls, like "CastAShadow" where three different actions are being performed simultaneously. This also suggests that our current definition of expand is too simpleminded.

We probably need to fully expand simultaneous calls all at once and merge the results into a schedule. Each time slot in that schedule might consist of a set of disjoint (no Dancer overlap) CanDoCall objects.

How do we organize the schedule? We need to know the timing for each part. We could introduce a call_timing function that returns the duration of a call.

[MarkNahabedian]

The schedule and corresponding improvements to expand_parts have been implemented.

get_call_options eliminates a CanDoCall unless it's the only one that applies to a particular dancer.