hi cyrille, hi miller, hi devs ...
i just saw that after receiving a |stop( message the value of the line / line3 objects are set to the destination value of the previous ramp command. so a future ramp won't start at the last output value, but at the last destination value.
i think this behaviour is not consistent with line~ and should be changed. cyrille, i'd like to change this in the line3 object in the cvs, unless you protest. it's more difficult with the line object ... i could change it for devel, but i don't want to change the semantics of the language pd and make patches incompatible. miller, i'd like to know, what you think about this object and if you'd accept a patch that would change the behaviour of line?
of course, other opinions on this topic are highly appreciated, too.
cheers ... tim
ps: i'm perfectly aware of a workaround for this problem, i'd just prefer a consistent behaviour ...
hello,
i also noticed this when i made line3. but i choose to have line3 as close as the original line object. IMHO it would be better to consider this as a bug, and correct line and line3 the same way. it should not brake so many patch, and an abstraction can be made to go back to the curent behavior.
cyrille
Tim Blechmann a écrit :
hi cyrille, hi miller, hi devs ...
i just saw that after receiving a |stop( message the value of the line / line3 objects are set to the destination value of the previous ramp command. so a future ramp won't start at the last output value, but at the last destination value.
i think this behaviour is not consistent with line~ and should be changed. cyrille, i'd like to change this in the line3 object in the cvs, unless you protest. it's more difficult with the line object ... i could change it for devel, but i don't want to change the semantics of the language pd and make patches incompatible. miller, i'd like to know, what you think about this object and if you'd accept a patch that would change the behaviour of line?
of course, other opinions on this topic are highly appreciated, too.
cheers ... tim
ps: i'm perfectly aware of a workaround for this problem, i'd just prefer a consistent behaviour ...