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://github.com/pure-data/pure-data/issues/1305
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 <abonneme...@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 <abonneme...@revolwear.com>
To: pd-list@lists.iem.at <pd-list@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://urldefense.com/v3/__https://lists.puredata.info/pipermail/pd-list/2019-06/125391.html__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsx32PNF8$
<https://urldefense.com/v3/__https://lists.puredata.info/pipermail/pd-list/2019-06/125391.html__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsx32PNF8$
>
[2]
https://urldefense.com/v3/__https://github.com/chairaudio/pure-data/tree/feature/delreadsinc__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQs9PZY2Zx$
<https://urldefense.com/v3/__https://github.com/chairaudio/pure-data/tree/feature/delreadsinc__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQs9PZY2Zx$
>
_______________________________________________
Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list
UNSUBSCRIBE and account-management ->
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsyoult3i$
<https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsyoult3i$
>
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsyoult3i$
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!X_0yWoTK9_e2FJ67U92nwUpVsf4J8D52RrtLxDbQec742PCPmHmQsyoult3i$
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
