If you send a new message to the [line] or [line~] object while it is active, it will use its current position x as a starting point for a new line with the newly given time n. This means that the total elapsed time will be x + n. Now I'm trying to make a patch where the total elapsed is just n, the newly selected time value. This would be useful ie. for changing tempo live, rather than waiting until [line] has finished before starting a new cycle.

Here is a prototype that works by sending a new value of n - x to [line].

live-line.pd

However, this only works for one iteration. If you select a second or third new time value, the total elapsed time will be off.

I'm afraid that this problem stretches my maths brain further than it will go. Can anyone work out how to get it to work for n iterations, so that if you drag the new time value, [line] will always update? Or has this been solved already in a different way?

@LiamG Hello Liam..
I think this does what you wish..........
It could be done slightly more elegantly (less wastefully) with [count] I think....
life_line.pd
David.

Thanks David, your updated version works! I'm going to be a pain though and ask if you or anyone can figure out a way of doing the job without the [timer] object.

The reason is that I suspect that it is computationally quite expensive to be banging the timer 100 times per second. I'm trying to add this to my Context patch, and I want to allow for hundreds of [line]'s working in parallel, while still leaving space for DSP. Am I just being paranoid? I'm willing to be convinced that [timer] is not in fact hogging my CPU, but I also have the feeling that the problem can be solved with an equation, rather than a timer.

@LiamG Hello again Liam....
I think this is mathematically correct......
life_line2.pd
Although there is always a small discrepancy, I think it is to be expected.
David.