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

[Max]

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

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

delreadsinc~
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.

cordially
Max


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.