can you share the patches? I'd like to see how the interpolation was implemented
thanks 2016-02-15 13:53 GMT-02:00 Matt Barber <brbrof...@gmail.com>: > Re: cubic interpolation. Yes and no. Pd and csound both use the same > Lagrange interpolator, which gives discontinuities at segment boundaries, > but the segments it generates are actually a bit closer to what you would > expect from sinc interpolation. SC3's Hermite interpolator, which matches > two points and first derivatives at the boundaries gets rid of the > discontinuities but at the price of some waveform distortion. The Hermite > interpolator is also not continuous at the 2nd derivative on boundaries and > is prone to sudden changes in concavity, while the Lagrange's 2nd > derivative discontinuities are removable; there are no sudden changes. > > You can see this in the screenshot I attached, which demonstrates five > interpolators in action. > > At the very top is the SR/4 cosine wave which serves as the source for the > interpolators. At the bottom left is what we'd expect from a sinc > interpolator (I haven't implemented it yet, but it should be very close to > a cosine wave). > > In red are 1) Pd's [tabread4] cubic Lagrange interpolator using an > array-reading abstraction [array-read4], and 2) The 4-point cubic Hermite > interpolator [array-read4h]. You can clearly see the 1st-derivative > discontinuities at the peaks in the former, and the 2nd-derivative > discontinuities at zero crossings of the latter. > > In purple are 1) A 6-point quintic Lagrange interpolator [array-read6], 2) > A 6-point quintic interpolator [array-read6h] which matches four points and > first derivatives, and 3) A 6-point quintic interpolator [array-read6h2] > which matches two points, first derivatives, and second derivatives. > > One important thing to notice is how the Lagrange interpolations are much > closer in overall shape to the cosine wave at bottom left. The cost of > matching derivatives is a compromise in the shape of the waveform between > breakpoints. > > > On Mon, Feb 15, 2016 at 9:57 AM, Claude Heiland-Allen <cla...@mathr.co.uk> > wrote: > >> On 14/02/16 22:27, Matti Viljamaa wrote: >> >>> Do you think Pd has a characteristic sound to it? Or whether >>> discussion board threads claiming Pd (and Max) have a distinct (and >>> not good) sound just have people who haven’t listened to good >>> patches? >>> >> >> Some issues with Pd that affect sound character: >> >> 1. cos~ (and osc~) use a small table with linear interpolation, which >> means there is quite a lot of interpolation noise - I wrote about it here: >> http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html >> >> 2. vcf~ (and probably other recursive filters) use single precision >> floating point in the feedback loop (pd-double might be different) which >> causes weird rounding artifacts - I wrote about it here: >> http://lists.puredata.info/pipermail/pd-list/2010-08/082104.html >> >> 3. cubic interpolation (tabread4~ etc) in Pd uses an (imho) incorrect >> algorithm - it makes a curve that goes through 4 points instead of matching >> the derivatives at the nearest 2 points, which leads to sharp corners at >> the original sample points with associated aliasing artifacts - this has >> been discussed on the lists many times in the past, for example here: >> http://lists.puredata.info/pipermail/pd-list/2008-06/062864.html and: >> http://lists.puredata.info/pipermail/pd-list/2010-03/077278.html >> >> 4. sig~ (and implicit sig~ from float messages to signal inlets) is >> steppy and only takes effect at block boundaries - compare with .kr in SC3 >> which is (afaik) linearly interpolated between each block boundary >> >> 5. Pd doesn't print enough digits to perfectly reconstruct floating point >> values when round-tripping through files, so (eg) biquad~ coefficients can >> become imprecise if you don't write them outside Pd in a text editor >> >> 6. other systems tend to come bundled with more nice-sounding stuff like >> bandlimited oscillators etc, with Pd you tend to have to find externals >> yourself (deken should make that easier now) >> >> >> Claude >> -- >> http://mathr.co.uk >> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list