I think I saw it used just to fade in and out on a sine tone.




On Friday, October 2, 2015 9:52 PM, Matt Barber <brbrofsvl@gmail.com> wrote:


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.
Doesn't the audibility of zipper noise depend on the duration of the ramp?

I seem to remember some Supercollider tutorials that used Line.kr with
a duration of a second or so, and I don't remember hearing zipper noise.  (Also
made a little Pd demo using [bang~] and a counter, but I don't know what I
did with it.)

-Jonathan



On Friday, October 2, 2015 7:41 PM, Matt Barber <brbrofsvl@gmail.com> wrote:


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@lists.iem.at> 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 <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.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@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list