@yannseznec there is a limit in precision for any finite numerical representation. However, for floating point that becomes more complicated to calculate. The relevant code is

```
x->x_biginc = (x->x_target - x->x_value)/(t_float)nticks;
x->x_inc = x->x_1overn * x->x_biginc;
```

and in the dsp function:

```
x->x_1overn = 1./sp[0]->s_n;
```

so the inc will be (target value - current value)/(total time in samples). Time in samples will be rounded to the block size. I believe whether or not this number will increment the line~ depends on how big or small the current value of the line~ is. (again, it's complicated since it's floating point).

for instance if the current value of line~ is 1 then inc would have to be less than 2^-24 to not be able to increment I think. this would correspond to going from 1 to 2 over 16777216 samples, or ~6 minutes 20 seconds @ 44100 samplerate. (so you couldn't go from 1 to 2 any slower than that and have it represent the correct values within the block). Every time the value of line~ doubles so does the smallest representable increment.

however, line~ also uses the biginc variable, which means that after every block it will be able to update using a bigger increment. This means that line~ will still be able to increment up to blocksize times more than that calculation ^ after every block, though values inside every block would be the same. (so ~6 hours 46 minutes @ blocksize 64 according the above calculation I think)

if going from 0 to 1 all of those values would be doubled (it could represent increments corresponding to twice that time, bounded by the lowest representable increment that corresponds to going from 0.5 to 1)

there are other considerations of precision as well. If the increment can only be represented with a certain number of binary digits when added to the current value then there will be round-off errors in the values generated. (but if you need values of that precision you would have round-off errors somewhere else anyways probably)

another numerical bound on the use of line~ is the use of an int to represent ticksleft. If we assume this is a 32-bit signed integer then there can only be 2,147,483,647 blocks, which is ~36 days @ 44100 samplerate and a blocksize of 64. (this would be longer than whatever limitation the floating-point would impose tho I think)

this is all assuming that the size pd uses for samples and floats are 32-bit floating point. If pd is compiled to use 64-bit doubles instead then all of those values would be 2^29 times longer

edit: actually, looking at the code vline~ does use doubles for everything, so if you need really long ramps you should have no problem if you use vline~ instead of line~, even in normal non-double pd. It would take a time longer than 6,472 years for a vline~ going from 1 to 2 to stop being able to increment within a block of 64 samples @ 44.1k. (and a time of 414216 years to stop incrementing at all across blocks)

In the case of vline~ the bounding factor of precision might be in the representation of time actually since it doesn't use ticksleft

edit 2: it couldn't represent incrementing ~1.45 ms which is the time for a block of 64 @ 44100 samples if the current time were ~ 2^53 ms, which would be 9007199254740992, or 285,421 years before stopping to work completely.

long story short: you should be able to use vline~ (but not line~) for ramps of at least a few years long (depending on the range of its values) before it stops incrementing within a block. For the specific case of going from 0 to 1 @ 44.1k, you should be able to run a vline~ for ~129,000 years before it stops incrementing within a block (though it would still increment between blocks)