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

[Max]

Hi Chuck,

Clemens isn't on the list (yet), he sent me some measurements he made in 
response to your post.

All at 48kHz.

https://cloud.yuca.biz/s/WZseAmBQm9z6NdL

he says he can't hear a difference with 10 samples cutoff at pi and 14 
samples cutoff at 0.85*pi
It sounds better than than delread4~ from 6 samples cutoff at pi upwards.

greetings,
Max & Clemens



On 28.04.21 17:56, Charles Z Henry wrote:
> 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://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
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>