[PD] Does Pd have a "sound"?

[Matt Barber]

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 at 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 at 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 at 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 at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>
>>
>> _______________________________________________
>> 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/20160215/09a71bf0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array-abs.zip
Type: application/zip
Size: 289926 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160215/09a71bf0/attachment-0001.zip>