[PD] How does vline~ work under the hood?

Jonathan Wilkes jancsika at yahoo.com
Sat Oct 3 04:01:28 CEST 2015

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 at 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 witha duration of a second or so, and I don't remember hearing zipper noise.  (Alsomade a little Pd demo using [bang~] and a counter, but I don't know what Idid with it.)


     On Friday, October 2, 2015 7:41 PM, Matt Barber <brbrofsvl at 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 at lists.iem.at> wrote:

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?

     On Friday, October 2, 2015 11:36 AM, i go bananas <hard.off at 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 at lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151003/b973603f/attachment.html>

More information about the Pd-list mailing list