I'm playing a sample with an automation curve that gives the index for reading an audio sample. (see attached image with a LFOed line, slight 'groove'). This allows me to "scratch" a sample drawing the automation curve. The index values are not integers, but it seems not to be a problem for [tabread~].
I imagine that when the index 'jumps' between non-adjacent values it can create aliasing. Months ago I learned on this forum how to 'encapsulate' the pd object that creates nonlinearities (for example a [tanh~] within a disto patch, see http://puredata.hurleur.com/sujet-5775-better-sounding-guitar-distortion-beyond-clip-tanh) into an upsampled subpatch with 10th order chebyshev lowpass filtering in order to prevent aliasing when automation is a bit 'wild'.
But in this patch I can't figure out how to do such a thing. Any idea ?
(Of course I'm talking about sound quality of (sometimes brutally) time-streched audio, but I'm simply curious )
I think that I could use [tabread4~], but stupidly I never did it seriously yet.
First of all because interpolation benefits are mysterious to me. I guess that it is only interesting when index values are non integers, in such a manner that it 'recomputes' the waveform using 'normal' integer indexation. Am I right ? Does this operation moderates aliasing in some way ?
Secondly I think I'd need to find an automated way to add a value in front and two at the end to make any selection within my automation '4-pt interpolation compliant'. The only way I see is copying the entire selection to a second table, re-write it to the original one, shifted one sample to the right, and then write three values. This is rather 'brute force', don't you think ?
Third, the 'big patch' that I'm working on computes the exact length of the sample once played with playhead automation. This way I know what is then length of the 'scratched audio'. It's not an issue for me, but I'm curious to test if the 'scratched audio' will always have the same length with a [tabread4~]...