Create "trio" demo

I think I might call it "trio", and the elevator pitch is that you control one voice in a trio, and there is an algorithm that controls the other two pitches to form 3 part harmony.

Follow-up task created: demo-trio.

For now: given a pitch (octave-wrapped, 0-11), find the corresponding triad. Use a lookup table (vector, probably).

I'm going to need to rework this to make it work with gesture and chords, but this is a good start.

Attempt voice staggering using event-driven gesture algorithm, see what goes wrong.

Now that I supposedly have an event-driven gesture, I need to begin work incorporating those mechanics into the existing demo.

Now, for the initial process of introducing these eventful gestures.

Before any events can be added to any gestures, we need to be able to simulate adding events. Events should only be added after the lead has held onto a pitch for one period.

The easiest way to do this using a global timer that keeps track the phasor ticks, which occur once a second. If a u32 is used, how many seconds is that?

Okay, so that's about a millenium short of 50k years. I think there's no general risk of things overflowing. I will be long dead and forgotten before that happens to a potential user.

Is this enough granularity though if I want to detect pitch changes? Maybe not actually.

Might need to ink this one out.

First, implement things so that it detects changes in pitch. Then, build a sample and hold with along with a global monotonically increasing clock that increments at the start of every tick.

Now, any time a pitch change occurs in the lead, it can be compared against the sampled pitch. If the pitch is different, but the timestamps aren't, the whole period is marked as having been changed for the rest of the period.

The "dirty bit" trick is used in situations where the pitch changes quickly inside a period.

I think there may be another state required.

How about this: If there has been a requested pitch change from the current lead pitch, and this request has been held for a period, apply this changed pitch to the current lead.

This should happen at the start of every period.

I was setting things to be negative oops.

Caching the lead value and also storing the last changed value may be what I'm looking for.

Essentially, this lead value needs ot be updated regardeless, but the other two voices need to be delayed.

I can't simply cache the last lead pitch every time because I'm setting it every time.

Now I am looking to delay chord changes on the upper/lower voices.

I think I'm going to have to do this anyways because the event scheduler in the eventful gesture is so small, and can really only take one vertice at a time.

The logic would need to be: lower gets set first, then upper.

Initially I had it so that the chord would be determined, and then you'd send off the events with delays. Rethinking this a bit.

I want it so that the upper pitch only changes if it waits 2 beats, and the lower pitch changes if it waits 1 beat.

I want to have a state when the lower changed, but the upper hasn't. When the upper gets changed, the lower changed gets setup.

This causes some very rude sounding glisses sometimes.

One of the things I am doing in Trio is forcing a phase reset on pen down so the voices always stagger the same way. The funderlying rephasor in the gesture signal generator does not have a way of handling phase resets, so it'll assume a faster tempo change and cause unwanted jumps in time. The rephasor needs a way to be told that there has been a phase reset, which would cause it to skip calculating the delta time in the next sample tick.

I wonder if we can build a test around this?

I want to not only do the fix, but create a test in the test suite that showcases the problem before the fix is created, just so I know that I properly understand the problem that I am trying to solve.

It did not crash. Not one crash. Thanks, Rust.

This can be like a method or something like immediate(). Setting the next/prev values to be some scalar value should work for the most part. The event queue should also be cleared as well.

There's too much spaghetti right now. I think I need to actually attempt to model this as a state machine and add some tests. Otherwise, I'm never going to figure out the issue, and this code will become too unwieldy to maintain.

Not sure if this is my scheduling logic, or some subtle bug with the gesture event queue, or a mix of both.

Testing is definitely in order. But like, not today. I'm pretty drained.

Yeah, considering I want to change the chord selection logic, it's going to be even worse. This needs a rewrite.

I have built what is essentially a concurrent event system. So yeah, this is tough one to do correctly.

I turned on gesture again, and I think the wrong notes are caused by the event graph not removing events at the right time. I think. Anyways, this needs to be rebuilt for sure because I don't want to live life doing guess and check.

I'm trying to more formally establish a way to manage how the voice scheduling works for trio.

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

We want to make a query: given some pitch (0-11), and a current chord, provide a range of potential candidates for the next chord.

Since this is going to be used in a realtime situation. My thinking is to populate with a pre-allocated fixed size array that is managed internally.

Added a new shape. Really expressive now. Vibrato not as bad as I remembered (with headphones on now instead of speakers).

Should resolve to tonic more often. There should be a built in bias to choose tonic.

I'm desiring the instantaneous mode again.

The chord changes are happening too quickly. If I select a pitch, go down quickly, and og back up, the chord shouldn't change. But it does.

Right now, a changing pitch triggers a set of chord progressions. But if they move too quickly, only the last one is heard. Which means effectively an arbitrary chord transition.

How to prevent this? A chord isn't a chord until all 3 voices commit. If the lead changes pitch, it uses the stored chord as a reference point. As it continues to change, this chord will continue to be used. The upper voice is the last person to commit to a chord, so only then should the reference chord be updated.

When the chord is officially committed for selection, only then does that chord get registered in the chord frequency table.

Oh my god this is consensus in a distributed system.

That's how I know this is close.

I want to see if I can get the webaudio API to request a sampling rate (44.1kHz) because the voices are just going to sound better.

I am now coming to understand why gnuspeech decided to go the route of resampling from 16kHz to the host sampling rate. It's just going to sound better that way. The changes sound too weird.

I'm finding it's very hard to find in my interface, because the sliders end up being very close to zero. I almost feel the urge to have a min/max slider too to be able to "zoom in".