Implement chord selection algorithm

The issue is there is no sense of resolution anywhere. It still kinda meanders.

The initial structures: chords, and valid chord transitions.

Query: given a current chord, and a new lead note, find all the valid chords to transition to.

I am trying to transition D4 in the key of C. This should give me two chords (G and Dm). But I'm getting no chords.

Ah, my "RE" constant was miscoded. Phew.

Chords need to be removed.

Oh just figured it out. I was using "chord index" instead of "index".

This has an interface that applies the heuristic to the candidate, which effectively removes the previous chord in place.

I'm querying the chord, removeing the previous transition chord, and updating the note pair table in 3 separate steps. It feels maybe too low-level and could be consolidated better?

It has no effect at all apparently.

I'm 99% sure it's the problem, but is it worth the problem?

There are two kinds of references right now: zero-index and one-indexed. The one-indexed ones are used because it means 0 can be reserved for None. was_used_last expects a zero-indexed chord. But really, these indexes are transparent for the most part. add_chord returns a zero-indexed position as well.

I think it makes sense to 1-index everything because that 0 is so critical.

Wow, that was tedious. Glad I had the tests. It almost makes me wished I used Option...

There is no way to account for this yet. It will catch it as having zero candidates though.

Because it's harder to calculate what that second index is going to be. There also needs to be a check to make sure prev/next is not equal.

It occured to me yesterday that I am actually close to a proof-of-concept system. I already have one heuristic working. I don't need to build out the others yet.

I do need to build a fallback set of chords in case a chord isn't found for a particular note.

Instead of a lookup table, dynamically find the closest voices above and below a lead note given a chord.

I am incredibly exhausted today. What a long day.

I believe I have identified the entry points for the chord manager in the existing code, and I have built an initial dummy interface for it. There is a failing test now with the methods.

If I can implement this interface, I think it'll be ready for actual integration.

Upper/lower voice selection is based on minimal distance from lead voice. This could also change to be based on the minimal distance from the voice it is currently at while also being above/below the lead.

Writing this down, I'm realizing there's potential for chaos (an upper voice that somehow keeps drifting upwards, for instance). Could be a cool thing though.

Also running into a bug with chord harmonies. I get wrong chords. If I keep tapping on Do, I'll land on sustained chords, which aren't correct.

Still not fixing the bug I described above. The lower note is incorrectly holding onto the note of the previous chord for some reason.

Retriggering the lowest note causes it to alternate between a major chord (correct) and a sustained chord (incorrect) The upper note is correct, while the lower note is incorrect.

The state transitions aren't shuffling through the states as well as I'd like. Also, there's too much unnecessary voice movement.

How can the system choose interesting chords and also minimize movement?

Specifically: I want the system to be introduced to the minor 4 (without resorting to randomness), and I want the voices to resolve in an expected way.

It is a constraint problem. Each voice has different behavior.

Upper voice should move as little as possible while still being above the lead voice.

Lower voice should move the minimum number of steps required to complete the chord, based on what the current upper and lead pitches are.

New heuristic idea: of the candidates, choose the least used chord so far. Probably keep a running heat map. This solves the chord selection problem, but not the voice leading issue

Another heuristic for chord selection is to find a candidate chord that requires the least amount of movement, given the current upper/lower pitches. This would require storing the current pitches of upper/lower, calculating the upper/lower pitches for each chord, and getting the combined step change for each chord. The one with the lowest score wins.

These are two different heuristics for selection, and I can imagine there would be a way to choose one over the other.

Least movement: for each candidates, get the working upper and lower notes of those chords given the current lead pitch. Get the absolute differences between those and the current lower/upper. The one with the lowest score wins.

A good hybrid could be something called "Lazy Least Used". Go for the least used, but only if the movement required is under a certain score. Otherwise, choose the one with least movement

Firstly, make sure the low-level chord measurement mechanics are in place and working properly. Then, simulate a chord change.

You need to store what the pitch actually is somewhat reliably. There isn't currently a caching mechanism in place for this.

The entry points for this happen when a pitch is actually scheduled.

Minimal movement means lots of situations where a note stays the same.

Shouldn't really matter, for now. It'll cause more complication if a check is introduced (for example, handle what happens if there is no previous note).

Lazy Least Frequent Heuristic, Y-axis expression.

Nice thing to have: some way to go from staggered to instantaneous behavior.

Fixed.

This one seems difficult to make a test for. I am tempted to just implemented it without tests, as the amount of effort it would take to find the perfect test situation wouldn't be worth it.

This is a good stopping point for my chords engine.

Even though I still want to tweak the chord selection algorithm, the core work is done.