implement proper voice schedule
task id: demo-trio-voice-scheduler2024-07-22 09:16: Some initial inking of voice scheduler #demo-trio-voice-scheduler #timelog:00:49:09
2024-07-22 10:36: Attempts at initial code and tests #demo-trio-voice-scheduler
2024-07-22 11:23: How to set up event scheduling logic? #demo-trio-voice-scheduler #timelog:00:59:47
2024-07-22 13:10: Inking out thoughts on triggers #demo-trio-voice-scheduler #timelog:00:20:12
2024-07-22 13:35: Attempts to implement triggers #demo-trio-voice-scheduler #timelog:01:57:19
2024-07-22 13:53: Core trigger built. Now to try to use them #demo-trio-voice-scheduler
2024-07-22 14:36: Inking and brainstorming #demo-trio-voice-scheduler
I was trying to figure out when to trigger certain events like gates and pitch changes. I was has having difficulty getting to the bottom of pitch changes for auto voices: when they are initially turned on (happens when the gate is first on), the pitch needs to be instantaneous, otherwise it is scheduled. How does the voice know the difference? What state information is needed?
2024-07-22 14:43: Introduce two boolean gates indicating on/off state for auto-voices? #demo-trio-voice-scheduler
This is the best I got so far.
Consider the state needed to determine a pitch change for an autovoice: it happens when when the lead note is on, and the timer has reached a particular value. An extra value could be used to determine whether to immediate set or schedule based on if the voice is turned on.
An auto voice will always be immediately set to a pitch first, and would therefore set the voice flag to on. Subsequent voice changes will be scheduled until this voice flag is turned off.
The only way the voice flag is turned off is when an gate off event happens. This will turn off all the voices in the state.
2024-07-22 14:51: attempting to code this line of thinking up #demo-trio-voice-scheduler
I'm tempted to have this be a set of state separate from the current set of state. I believe you could make the case that the flow of information is one-way: changes from the main state influence the states of the auto voices, and not the other way around.
Separating state like this I think will make it easier to test.
2024-07-22 15:14: These states need triggers hooked into them now. #demo-trio-voice-scheduler
2024-07-22 15:41: initial firing logic works for a lower voice #demo-trio-voice-scheduler
Right now, it doesn't know the difference between an instantaneous vs scheduled pitch change, but the scaffolding is there.
2024-07-23 14:13: Trio Triggers #demo-trio-voice-scheduler #timelog:01:24:34
2024-07-23 14:44: Already shooting myself in the foot with this code #demo-trio-voice-scheduler
Going to create an interface where hooks are automatically appended and interated through.
2024-07-23 15:22: Working on UpperVoice now #demo-trio-voice-scheduler
Lower voice seems to behave as expected.
2024-07-23 15:53: UpperChange works as expected. Triggers are done #demo-trio-voice-scheduler
2024-07-23 15:55: Voice scheduler hookup #demo-trio-voice-scheduler #timelog:00:42:19
2024-07-23 16:39: Voice manager has been integrated into Trio! #demo-trio-voice-scheduler
Most of the event logic behaves as expected. I'm a little stumped as to why is starts so late. But it feels a lot better now. What's important is that I can reason about it now, and construct simulations in a very precise way.
I think the event handler needed to reset the head/tail indices as well. That fix seemed to clear up all the gesture related issues which I was suspecting.
2024-07-24 09:51: This feels completed. #demo-trio-voice-scheduler #demo-trio-low-timing
There's one timing issue that I'm going to look at, but that feels like another task.
I have the basic actions and primitives for the most part. Now, they need to be composed and worked together to trigger events for the other voices.
These events need to be triggered exactly once.
Event triggers at the start of a tick.
In a test, one should be able to tick() then ask the state questions. Is the voice supposed to launch? Is it playing already? Did the voice just turn off? Is it supposed to turn off? Etc, etc.
These events need to happen exactly once. Tick, check and see if things need to be done, tick, those things are done.
prev/curr state system could probably do this? At each tick, update prev to be curr. So, that means changes and probing would have to happen together before the next tick?