implement event driven gesture

Using the trait system in place, the problem is a matter of how to build the "next" gesture. I'm thinking of implementing an event queue, possibly fixed sized.

I think the plan is to have this work in a single-threaded context first, then building abstractions around that inside of an existing event system. (in a webaudio worklet, this would wrap around the "onmessage" passing interface used).

push/pop makes sense to me, but those are stack terms not queue terms.

Wikipedia tells me they use the terms "dequeue" and "enqueue".

Side note: my tired brain is having a great time parsing the "ueue"s of these words. Imagine if you pronounced it "wehweh". Hilarious.

I'm kludging it into a struct with optionals for now. This doesn't spark joy. I'm going to test this well, and when/if I refactor, I can rely on these tests.

For enqueue, I should only be passing specific data types, and then mutating the internal event array. Right now, deep copying an entire event.

For dequeue, I should either return a reference or an id that eventually resolve to a reference.

I don't love this. This feels like busywork.

I'm crashing when I run cargo clippy. Let's make it not crash. I can deal with the warnings later.

Scalars are being handled, now to work with the other types.

This is why nothing gets done. I've been wasting time trying to make Clippy happy all in the name of supposedly "better" code, and I'm almost 45 minutes with nothing to show.

It warps the brain, seeing all these squigglys in an editor. Like a teacher marking up an essay in red. I don't think it's actually possible to turn syntax off in nvim. The usualy "syntax off" trick doesn't work.

I think it's reasonable to think about starting the Gesture.

I'm liking these incremental tests. What's a good way to test that things are working as expected?

For starters, I need to be able to initialize this gesture by pushing an initial set of events.

Behavior we want: events should only be processed at the start of a new phase.

Situation: I push an event A and call preinit. I then push event B, after the tick is called. What is the expected set of states for each period?

Pre-init sets things up so that our first period for sure starts with A. I believe that first tick sets things up such that the next state it is transitioning to is also A. Either that, or it is uninitialized. Not sure. Checking.

My test is currently failing to get the next point as expected.

Oh wait, it's because I'm checking the external clock's phase changes, not the internal change.

The order that things get set is very crucial. I want to see if I am doing the timing correctly here.

It is eventually correct, but I have to wait about 5 samples after the first period.

Before the first tick, event A is pushed, and then preinit is called. This triggets the next event to happen, which dequeues the event and sets the value.

At the first tick, next vertex is called immediately. There are no values. The cached vertex is left unchanged, so it is still A.

Note to self: I am using new_period wrong. The timeline

Event B is pushed as an event before the next tick. It will not be read until the next period. When will the next period happen? The current phasor is currently set to have a incrementor value of 0.1, so 10 samples per period. The rate multiplier has been set to be 2/3, which is like slowing things down by a factor of 1.5. The test does seem to pass after about 15 samples through trial and error.

I need keep track of the interal rephasored value and watch for new periods there.

Works!

Wait are events that tell the clock to wait some number of periods before processing the next events in the queue.

A wait time of 1 will wait one whole period before allowing further events in the queue to be processed.

If I push a wait of 1, and then a scalar in the middle of period A, the start of the next period, B will dequeue the wait, and then suspend reading other events. At the next period C, there will no longer be a wait, and the next value will be set.

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