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

Max abonnements at revolwear.com
Tue Apr 27 18:17:53 CEST 2021

I've opened an issue and would welcome discussion here or on github:

On 26.04.21 02:18, Max 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://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>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list