[PD] 4-point interpolation changes timbre depending on sample rate

Max abonnements at revolwear.com
Thu Apr 29 22:01:02 CEST 2021

Because it's too expensive.
Using the CPU meter in Pd, I'm getting at 48k with our waveguide patch 
which has 5 delreads in it

1x 12%
2x 21%
4x 33%

1x 15%
2x 26%
4x 39%

In effect it's delreadsinc~ at 15% (because it doesn't need upsampling) 
versus a 4-fold upsampled delread4~ at 33%.
It's a VST3 running libpd, so we need some headroom for the DAW and 
whatever other synths and effects the user might want to open.


On 29.04.21 18:59, Miller Puckette wrote:
> I think this is a bit too application-specific to put in Pd vanilla...  but
> anyway, I don't understand why you can't just run the entire waveguide
> at 4x sample rate - am I missing something?
> cheers
> M
> On Thu, Apr 29, 2021 at 02:06:11PM +0200, Max wrote:
>> Hi Miller,
>> I think the oversampling workaround is great for cases like slow playback of
>> a sound file, but I'm not sure how this would work in a waveguide, ans
>> particularly our situation where we have different timbre depending on if
>> the number of samples in the delay line is odd or even. Since we vary the
>> delay time in ms it's kind of a gamble and inconsistent depending on
>> samplerate.
>> Do you think delreadsinc~ could have a chance to be merged into vanilla and
>> if so how?
>> I've outlined some ideas here:
>> https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/1305__;!!Mih3wA!XMhJYxjhME5toHvcGQaK14n4LmNU0RlX-iYx637isdS8y31b1M1Q3joyLE6z$
>> Max
>> On 28.04.21 18:14, Miller Puckette via Pd-list wrote:
>>> On Wed, Apr 28, 2021 at 10:56:58AM -0500, Charles Z Henry wrote:
>>> My 2 cents...
>>> The 4-point interpolation scheme gets radically better if the signal it's
>>> used on is oversampled (error goes down asymptotically by 24 dB for each
>>> doubling of sample rate) - so my own strategy is simply to 4x upsample
>>> everything I send through tabread4~ or delread4~.  This moves the "problem"
>>> to that of designing an upsampling filter, which is much easier than a general
>>> interpolator.
>>> cheers
>>> Miller
>>>> I read through the code in your d_delay.c for the delread_sinc implementation.
>>>> It's a 22-point interpolator--very high quality and it looks like a
>>>> good implementation
>>>> The Hermite spline is the best 4-point cubic interpolator, but the
>>>> point of those polynomial interpolators is just to be cheap, and good
>>>> enough for regular usage.  It doesn't require a table, so it also
>>>> doesn't need as much cache space
>>>> I don't think it's *the* optimal 4-point interpolator.  It's just the
>>>> best cubic polynomial 4-point interpolator.  You could re-use your
>>>> sinc interpolator code for other shorter interpolation kernels, ones
>>>> that are better than cubics but more expensive to calculate.
>>>> At least for me, it's still an open mathematical problem that I've
>>>> come back to, from time to time.  I started to wonder if I could
>>>> expand the error terms in the truncated sinc spectrum in the form of
>>>> 1/w, 1/w^2, 1/w^3, .... and then cancel them out by polynomial
>>>> correctors.  An alternative to windowing the sinc function, this could
>>>> be a more precise way to set the rate of attenuation in the stop-band,
>>>> while still retaining all the smoothness of the sinc shape.
>>>> I get a break from teaching in about 3 weeks.  I'm looking at the math
>>>> right now, and I don't think I can solve it quickly (or maybe at all).
>>>> How short does your sinc interpolator with Blackman-Harris window need
>>>> to be when you start to get the timbre change effect?
>>>> Best,
>>>> Chuck
>>>> On Sun, Apr 25, 2021 at 7:18 PM Max <abonnements at revolwear.com> wrote:
>>>>> Interesting. I've included that in the test patch.
>>>>> It exposes the same samplerate dependent timbre change. So far only the
>>>>> Sinc function solves the issue.
>>>>> On 25.04.21 23:15, Sebastian Shader wrote:
>>>>>> I have a [vdhs~] object in my library that does hermite spline
>>>>>> interpolation for a delay line (like tabread4c~).
>>>>>> https://urldefense.com/v3/__https://github.com/sebshader/shadylib__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQs5HJnxR0$
>>>>>> (also on deken)
>>>>>> I had to re-make delread~ as delread4c~ because delread~s delay lines
>>>>>> are not exposed in the .h files
>>>>>> -seb
>>>>>> -----Original Message-----
>>>>>> From: Max <abonnements at revolwear.com>
>>>>>> To: pd-list at lists.iem.at <pd-list at lists.iem.at>
>>>>>> Sent: Sun, Apr 25, 2021 5:45 am
>>>>>> Subject: [PD] 4-point interpolation changes timbre depending on sample rate
>>>>>> Hi list,
>>>>>> the 4-point interpolation in tabread4~ has been a popular topic in the
>>>>>> past, going back to at least 2008. [1]
>>>>>> A similar issue is in delread4~. In fact a simple resonator changes its
>>>>>> timbre quite drastically by just changing the sample rate of the audio
>>>>>> interface. Attached is a test patch.
>>>>>> The issue becomes audible when choosing an odd delay time and compare
>>>>>> the result between an odd and an even sample rate (e.g. 44.1k vs. 48k).
>>>>>> This is not good. In fact this is a serious defect. Imagine you want to
>>>>>> market a product like a synth plugin (based on libpd) which sounds
>>>>>> different depending on if the daw is opened in 44.1 or 48 kHz.
>>>>>> Cyrille Henry has coded tabread4c~ with a four-point cubic interpolation
>>>>>> in the nusmuk library, but there is no delread4c~ equivalent in nusmuk.
>>>>>> Clemens Wegener has coded delreadsinc~ which implements a
>>>>>> Whittaker???Shannon interpolation (Sinc function). This implementation
>>>>>> does sounds consistent in any sample rate. It also sounds much better at
>>>>>> very slow speeds inside a pitch shifter where delread4~ produces serious
>>>>>> artefacts. The Sinc function requires a larger padding for the
>>>>>> interpolation.
>>>>>> There are a couple of questions regarding on how to contribute this to Pd.
>>>>>> Vanilla objects are currently:
>>>>>> delwrite~ = the sink
>>>>>> delread~ = control rate tap
>>>>>> delread4~ (vd~) = audio rate tap with a four-point interpolation
>>>>>> 1. the code in delwrite~ isn't agnostic towards the interpolation since
>>>>>> it already provides the padding for the 4 point interpolation
>>>>>> 2. if we add more interpolation methods to delread / tabread, the
>>>>>> cleanest way would be to just have one tap object and the interpolation
>>>>>> can be changed by a message and argument to it. currently there are
>>>>>> implementations for the miller 4pt, cubic 4pt and Sinc.
>>>>>> Unfortunately delread4 already carries the 4 from 4-point interpolation
>>>>>> in its name, so probably it would be the best to deprecate that and find
>>>>>> a new name like varidelay~ or so.

More information about the Pd-list mailing list