And [tabread4] and [tabread4~] do Lagrange 4-point interpolation.

If it has to be exact, this helps: https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect

And [cyclone/wave~] has more implemented, such as cúbic, spline, Hermite

@oid Have even dumber version - 6 instead of 9 object - 1/3 enhancement in brutalist/ minimalist matrix.]]
Interpolation-scale.pd

An efficient binaural spatializer

The "binauralModeled-ircam" object is a pure-vanilla implementation of the binaural model created at IRCAM.. An example of its capabilities can be found at this page.

The object is found at my repository: https://github.com/andresbrocco/binauralModeled-pd

Main concept

Basically, it applies ITD and approximates the HRTF to a series of biquad filters, whose coefficients are avaliable here.

Sample Rate limitation: those coefficients work for audio at 44100Hz only!

Space interpolation

There is no interpolation in space (between datapoints): the chosen set of coefficients for the HRTF is the closest datapoint to the given azimuth and elevation (by euclidean distance).

Time interpolation

There is interpolation in time (so that a moving source sound smooth): two binauralModels run concurrently, and the transition is made by alternating which one to use (previous/current). That transition occurs in 20ms, whenever a new location is received.

Interface

You can control the Azimuth and Elevation through the interface, or pass them as argument to the first inlet.

Performace

Obs.: If the Azimuth and elevation does not match exactly the coordinates of a point in the dataset of HRTFs, the object will perform a search by distance, which is not optimal. Therefore, if this object is embedded in a higher level application and you are concerned about performance, you should implement a k-d tree search in order to find the exact datapoint before passing it to the "binauralModeled-ircam" object.

Ah, maybe this statement is obvious, but: it only works with headphones!

@Aliam.Sigsaly [switch~] is vanilla but just add the appropriate [declare] and your patches will work with most all flavors of pd. Your [> 0] -> [+ 1] -> [gate 2] and [sel 0 1] can be done more efficiently with just a [moses] and a couple [t b f]s. I also used [value] for the numbers to be interpolated between which makes things neater and allows you to use [send] to set the value. The issue with sliders are that they quantize to pixels, this is not much of an issue if your numbers are close together like in your example but if your number are 1, 2, 984 you start noticing issues, but often still good enough for the job.

Interpolation.pd
Edit: Also, if you rework the equation so $f5 is $f1 you get a bit more efficiency since it saves a type conversion and also makes things a little neater, fewer objects. Forgot to do that in my rework.

Hi.
this patch is rather for Plugdata, since Pd imo does not have gate, tough u can use else/router, which is the same.

As a tribute to Omar I've shared a patch using his interpolation technique and update it on 3 values.
There was discussion on this topic on FB too (also deleted, tough) and consensus was, that value offset created when adding nother interpolation is caused by imprecision of slider. I found it is not EDIT "completely" true,
Slider in Plugdata is pretty precise.
It is - obviously - cause by leaving the smallest step value in previous approximation, which distorts the final result.
Solution is to send "0" to not used part, when interpolating other value..
EDIT: *Tough as mentioned, despite 6 digits are pretty fine (enough for DIY fine-tuning in DAW, without noticeable side-fxs. W/out this there was offset even 1/3 of step - 0.02-4 cca, now it is in 0.5 Hz range - beyond vst synth resolution), but this is definitely not the best suited approach for 12 decimals scala-like Pro fine-tuning etc.. that wont fly

BTW there should be probably even more elaborate solution, for more values - like using append+scale... if someone would like to beat the efficiency (make it dumber)) contest..

Happy patching.

Scale version is - obviously - in comments sesction..

https://www.dropbox.com/scl/fi/s1wncx9eytc50sukzwris/Interpolation.pd?rlkey=utcp4cd7dder4jpuduggkomji&dl=0

@seb-harmonik.ar

please try this help file:
https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-of-an-array-for-4-point-interpolation-of-tabread4-ect

The Lagrange interpolation uses n-1, n, n+1 and n+2 for interpolation at sample n+frac.

The only way without harsh artifacts with such a small array of 32 samples + 3 guardpoints = 35 (sample 0 to 34)
is reading it from sample 1 to 32
reading the sine wave only and using the guard points (0, 33, 34) for interpolation.
As patched above.

Looking again into

else\Live-Electronics-Tutorial\Part.07-Sampling.Delay.Granulation\27-Sampling(buffer)\3.Interpolation

Yes, the read-points are clipped. But that clipping causes a discontinuity of the sine.

It gets less obvious and even non-perceivable with higher resolution samples, because the artifacts become more silent and phasor~'s frequency running it, stays the same.

B04.tabread4.interpolation.pd is using [+~ 1] instead of the [1( into the right inlet of [tabread4~] :

@dfkettle yes, you have to add them. This is for less artifacts only. And only if you playback at different speed and/or samplerate tabread4~ would be needed. For original speed, you can playback with tabread~ or tabplay~ without any interpolation, sample by sample.

I did not open your uploads.

EDIT: here is an abstraction for it https://forum.pdpatchrepo.info/topic/14301/add-delete-guard-points-to-a-table-for-4-point-interpolation-of-tabread4-ect

I see, all kinds of precision errors in every stage. Didn't know [vline~] was calculating in double-precision. Thank you!

And didn't see your 2nd edit:

@seb-harmonik.ar said:

edit2: personally I use my own sine tables if I want really clean sine waves because the ones pd uses internally still sound a bit gritty to me sometimes, I think they use 512 points and I usually end up using tables that use 2048 or 4096 points

Here is a rather messy patch comparing different tables and interpolations I started to make a while ago, maybe worth sharing here:

Bigger tables are more robust against precision errors (offset) of their driving inputs.
With offset, [cyclone/cycle~] has same few artefacts for smaller as for bigger arrays (hmm..might be a bug I did?).
[osc~] is the cheapest sine.
[cyclone/cycle~] has non-expected costs with different interpolations.
My linear interpolation is different than cyclone's in results and very expensive (due to vanilla patching!?).
At an offset above [+~ 1023], with [cos~] and 512-point-table called $0-cos-GOOD, there is a sudden increase of artefacts .(due to bit-depth!!?)

puresine.zip

There might be bugs. Sorry for the mess, too boring cleaning up this time.

@whale-av Woah, thanks David! I started another version where I parboil the position vector at audio rate before delegating to control rate thinking that that might distribute the work a little better, but it's currently broken. I was also wondering if I could push more into audio rate if I used cyclone/poke~ and vline~ to do the interpolation, and maybe rpole~ to help with the averaging, but I'm not seeing a way in if there is one.

The thing that surprised me about ipoke~ is that it is doing linear interpolation. I always assumed that it was doing 4 point polynomial interpolation, and I wonder if that might be more hi-fi.

Anyway, I'm again grateful for the diversion. I finally booked my flight for this Friday and upgraded to the version with more leg room and free drinks

@whale-av I can't find any example of anyone using [interp 1( or [overdub 1(, but I can see that different functions are called depending on the value of those flags. It doesn't make sense to me that anyone would want to turn off interpolation because that's the whole point of ipoke~ when the indexing signal is faster that the sample rate. Your tape echo patch just assumes ipoke~ will interpolate, correct? And it also assumes that the signal overwrites the old recording, right?

Edit: Oh I see, bang looks like it requests the array to redraw itself. And now I also see that when the ipoke object is initialized, interpolation is on and overdubbing is off by default. Questions answered. And that means that if I can just understand what he's doing in that one method, I'll have reverse-engineered the only behavior I've ever seen used. Yay.

Edit 2: I'm learning a little French along the way. "valeur_entree" = "input value" and "index_tampon" = "buffer index".
I is a ignorant American.