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

[Dan Wilcox]

(If we go into development details, this discussion could be moved to pd-dev.)

> On May 4, 2021, at 10:54 AM, Clemens Wegener <clemens at chair.audio> wrote:
> 
> I also think it makes sense to specify arguments to tabread~ (or delread~) to specify the interpolation.
> 
> Dan you are suggesting an api like this to manage code size and structuring.
> I see, because when we put everything into the tabread~ (or delread~) class with just flags from arguments/messages, it would get hard to maintain.

Exactly. Hacking away and cramming everything in the existing class starts to get unweidly and harder to extend/maintain.

> E.g. for tabread:
> So we would create a header „d_array.h" with the function declarations?

Possibly. I did this approach because I wanted to split out the file type implementations and there were a number of helper functions as well. In this case, if the api is relatively small and self-contained, a header is probably not necessary.

> Should every interpolation type have its own function declaration or do we override for different types?

No override.

I'd say there would just need to be a way to pass the array and samples to/from the algorithm, so that would be formalized via function which each implementation can do separately. Then choosing the algorithm just changes which function pointers are called. In the sound file update, the soundfile type is a struct and each implementation sets the function pointers and registers itself on setup (at the bottom of each type implementation file). I used this pattern as it is a common C approach and used through out the Pd sources, as far as I can tell, although I would not say I am a C master having started with C++ & object-orientation.

> (A bit like an abstract class, but I don’t know how this works in C)
> The definitions would still go into „d_array.c“?

That was my approach with the soundfile update. The sound file implementations are in separate files ala d_soundfile_aiff.c.. In this case, I imagine the algorithms are not as complicated, so maybe they can all go in one file such as d_array_inter.c (aka interpolation), etc.

> Refactoring and testing this could take quite some time...

Yup. My approach was to start only by refactoring the existing code and separating it without changing anything major. Once that was working, then I started updates and bug fixes. It was maybe 1 month of work with help form others in testing, but I don't think this will take nearly as long.

>> Am 2021-05-04 um 04:35 schrieb Alexandre Torres Porres <porres at gmail.com <mailto:porres at gmail.com>>:
>> 
>> Em seg., 3 de mai. de 2021 às 12:52, Dan Wilcox <danomatika at gmail.com <mailto:danomatika at gmail.com>> escreveu:
>> 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 had suggested the same! ;) 
>> _______________________________________________
>> 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>
> 

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210504/bf8cd33f/attachment-0001.htm>