Consider Restricting Progression and Expansion Abilities

[johnameyer]

The current predicate-producer progression model, along with the expansion chainable operator model, offer a great deal of flexibility in generating chord progressions. However this flexibility prevents tabular lookup and prevents a simpler generation of chord progressions. If this was reasonably curtailed, the language could be lower on the Chomsky hierarchy and be parsed or generated more easily. Advanced voicing rules could be moved into the part-writing instead as was done with the Cadential 64 implementation.

Possible Restrictions Include:

• Removing scale from being passed in to operators
• No specification of voicing
• Purely operating off of the previous chord (or previous progression class Clean Up Expansion-Progression Overlap #28)

[johnameyer]

Short term realization would be to make the lookups cache-able, e.g. instead of running all the predicates again on (I V), just look up in the table (I V) to get [I vi IV6].

This is made a little more difficult with the introduction of minor keys but should still be possible, but if appending-expansions is embraced more this may be even more difficult (e.g. if there weren't already rules for V7 - I, when V was transformed into V7 as an expansion no matches would be found - relates to GH-28)

[johnameyer]

Current thoughts:

• Move to a regular language (i.e. finite state machine) model, since no rules currently have need of the context beyond the immediate prior
• Cache the progressions that occur from a certain progression chord at a certain point (i.e. dynamic programming) - E.g. if we see an IV progression chord at m. 8, we know all the progressions that come afterward
• Write the rules simpler, so we also can recognize all the possible chords we know how to start from and end on
• Move expansions to a similar model