It'll have more to do with how large the increment is, and what an increment means psychoacoustically. If you ramp over the range of a piano in pitch over a second, incrementing every 64 samples, each increment will be about 12.5¢, which is likely to be audible. Or if you ramped from 20hz to 20khz in frequency, you'd be adding some 28hz per increment, which is a lot of pitch at the low end.
There are probably a lot more ways to implement ramps. For example, youcould increment only at block boundaries and just repeat that value for therest of the block. That would looks a lot like Supercollider's "kr" ugens. (Iactually thought that's how [line~] worked until I looked at the code.)Btw-- does it cost anything significant to dereference x->x_inc inside thewhile loop of line_tilde_perform? Or is the compiler able to somehowoptimize that?-JonathanOn Friday, October 2, 2015 11:36 AM, i go bananas <hard.off@gmail.com> wrote:
Hi, me again.Thanks for the discussion. It has really opened my eyes.So, i got my naive c++ implementation of line~ basically working.And of course, just running a for loop incrementing by ticks, i run into the exact precision error that this block quantizing seems to avoid. My line from 0 to 100 over 44100 samples only gets to 99.93So, i also need to add something like pd's block quantization to make sure my line goes all the way to the specified value.My questions then are 2:Is pd's method the way i should do it? Or is there a better alternative?And, if i do it the pd way, how does that work? Does the increment get updated every block? Or is it just the last block that is stretched?
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list