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

Max abonnements at revolwear.com
Mon Apr 26 02:18:04 CEST 2021

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://github.com/sebshader/shadylib
> (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.
> [1] Review of tabread4~ threads in the archive
> https://lists.puredata.info/pipermail/pd-list/2019-06/125391.html 
> <https://lists.puredata.info/pipermail/pd-list/2019-06/125391.html>
> [2] https://github.com/chairaudio/pure-data/tree/feature/delreadsinc 
> <https://github.com/chairaudio/pure-data/tree/feature/delreadsinc>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list 
> <https://lists.puredata.info/listinfo/pd-list>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: interpolation-comparison-3way.pd
Type: text/x-puredata
Size: 3862 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210426/51dc3dd8/attachment.bin>

More information about the Pd-list mailing list