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" <[email protected]> wrote:
> 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? > > -Jonathan > > > > On Friday, October 2, 2015 11:36 AM, i go bananas <[email protected]> > 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.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? > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
