Maybe I'm opening a can of worms, but I could imagine tabread etc taking an argument to specify which algorithm to use among a (small) list of those available. The current algorithm would be the default so as not to break existing patches. :)

I'm no expert, but if there are a known set of tried-and-true approaches, maybe they could added through a simple API. This is sort of how I refactored the soundfile type handling in the (as yet unmerged) soundfile object update branch: https://github.com/pure-data/pure-data/blob/0061a083e85ba2548668825b693a72fdf98ceef3/src/d_soundfile.h#L47

On May 3, 2021, at 3:37 PM, pd-list-request@lists.iem.at wrote:

Message: 2
Date: Mon, 3 May 2021 15:24:10 +0200
From: Clemens Wegener <clemens@chair.audio>
To: Charles Z Henry <czhenry@gmail.com>
Cc: Pd-List <pd-list@lists.iem.at>
Subject: Re: [PD] 4-point interpolation changes timbre depending on
sample rate
Message-ID: <B6FDFF69-EE54-4F59-8234-5A53D086229C@chair.audio>
Content-Type: text/plain; charset="utf-8"

I think now would be a good place to pause the implementation and discuss 
if there is a need for this kind of algorithm in the PD community. 

We saw some use cases for the Whittaker-Shannon interpolation where
we gain in quality and/or speed. Namely waveguides and pitch shifters. 

Is there anything else, where we would like to use this interpolation kernel?
Like in general resampling?
In the tabread~ for sample playback?
Are there really quality or speed issues that we could solve there?

For our use case the code I submitted is good enough. But I would be happy 
to spend more time optimizing if there is a need / a broad use of that algorithm.
In that case we need another restructuring and some help from somebody
who is very proficient in writing pd source code. :)

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com