[PD] How does vline~ work under the hood?
brbrofsvl at gmail.com
Sat Oct 3 01:41:40 CEST 2015
You'll get zipper noise with the samphold per block approach.
Cost to dereference a struct member is probably a little more than just
using or getting a value. It's possible it'll be cached, though.
On Oct 2, 2015 5:26 PM, "Jonathan Wilkes via Pd-list" <pd-list at lists.iem.at>
> There are probably a lot more ways to implement ramps. For example, you
> could increment only at block boundaries and just repeat that value for the
> rest of the block. That would looks a lot like Supercollider's "kr"
> ugens. (I
> actually thought that's how [line~] worked until I looked at the code.)
> Btw-- does it cost anything significant to dereference x->x_inc inside the
> while loop of line_tilde_perform? Or is the compiler able to somehow
> optimize that?
> On Friday, October 2, 2015 11:36 AM, i go bananas <hard.off at gmail.com>
> 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.93
> So, 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list