[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