This is a huge work in progress so what I'm going to do is just attach a zip of the whole damn thing in its current state. The file you want is called array-read-comparison.pd, which is currently incomplete and a total mess, but it does enough to show you how the interpolators work, and you can get to the interpolator abstractions themselves from there. array-abs-intro.pd gives you an idea of the scope of the project, what I've finished, and what I haven't. I had to set the whole thing down for a few months to finish a composition and be a dad to my twin babies; there are contributions from others I haven't incorporated yet. I do have a github page for it but I haven't touched it in some time.
Matt
On Mon, Feb 15, 2016 at 11:01 AM, Alexandre Torres Porres porres@gmail.com wrote:
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 brbrofsvl@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 <claude@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:
- 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
- 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
- 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
- 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
- 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
- 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
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