I often like to think through something like this with a concrete example.
Let's start with 10 seconds of audio: phasor = 0 --> time 0, phasor = 1 --> time 10000 (ms).
Then, at 5000 ms, you change the end time to 7000 ms.
So, now, phasor = 0.5, time = 5000. And you need phasor = 1 now to map onto 7000 ms.
So two things need to happen:
- The phasor, running at its current speed, would reach its end 5000 ms later -- but you actually need it to reach the end in 2000 ms. So the phasor's speed has to increase by a factor of 5/2 = current_time_to_end / new_time_to_end.
- The linear mapping currently locates phasor = 1 at time = 10000, but now you need phasor = 1 --> time 7000. So the slope of the linear mapping will have to adjust by a factor of 2/5 = new_time_to_end / current_time_to_end (and the linear function's intercept would have to change too).
The changes in phasor frequency and linear slope should cancel out.
Then, at the start of the next cycle (which can be detected by [samphold~]), you would have to recalculate the slope for the entire start <--> end segment.
I might be overthinking it, but e.g. jameslo admits that in a simpler solution "the pitch is not steady as you adjust the start and end" so I think there aren't many shortcuts to be taken.
BTW there is another way to integrate a rate: rpole~. With an integrator, you don't have to worry about rejiggering slopes -- it just continues on its way, and reaches the end value in its own time. But, you would be responsible for triggering the reset at that point. This version uses control messages for triggering, so it would be quantized to block boundaries. To do it sample-accurately involves feedback and I never worked that out.
And a quick test patch (array "a" is 44100 samples, vertical range -10 to +50):
PS Hm, now I guess the [route float bang] isn't needed after all.