slopes.c timing compensation for event queue approach

[trentgill]

3 techniques:

1 set a flag & start counting samples when the (*self->action)() is called. when the next toward() is called, we can compensate for this delay

2 setup a continuation so if the toward() is called before the samples have been served to the dac, they can be updated with the next slope. this may be more difficult once the shaper engine is implemented?

3 change boundary checks so self->action is run one dsp block before the breakpoint. the event loop is run between dsp blocks, so this hopefully means the toward() will have been called by the time the next sample runs. we update the slopes.c handling of toward to store the new values, which will be executed without a callback when the threshold is crossed. this will actually make it way easier to handle sub-sample compensation as there's no opaque state-change happening.

[trentgill]

The main S_step_v function needs to handle the edge cases recursively to allow for nested event triggers.

Note, the current timing compensation doesn't carry the timing buffer through nested triggers (eg. a sawtooth LFO will cancel the timing compensation when it instantly jumps to the destination, where it should note that it had 'countdown' leftover and pass it along to the following call.)

[trentgill]

Will be unnecessary with ASL2. Closing