Hi there,

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~]...

Nau

http://www.pdpatchrepo.info/hurleur/automatedplayhead.jpg

You're correct that [tabread4~] includes interpolation for non-integral values of lookup, and is probably the correct thing to use here, although I'm not sure it solves everything that you're talking about.

Are you intending to loop the audio sample you're playing? If not, then you don't really need to worry about the interpolation points at the beginning and end. If you are, then I think there's an easier way to do it: just extend the size of your table by 2 points (I think?), and copy the contents of the first two data points into those newly-created last two. Then just use your table as before, remembering not to refer to the extra two points in your lookup - just use the original table size, before it was extended. Not 100% sure, but I think that's sufficient to ensure correct interpolation for looping.

Hope that helps with at least some of your queries.

[tabread4~] would be better because it attempts to "guess" the what the sample value would be between to adjacent values. If you use [tabread~], it will just round to the nearest sample, which could result in more distortion/aliasing.

Stutter is right about the guard points at the beginning and end. You only need them if the sample is meant to be played as a loop. Otherwise, don't worry about it. [tabread4~] will just assume the extra points are zero, which would be right for a non-looping sample, anyway.

As far as minimizing the aliasing using upsampling, keep as much in the upsampled subpatch as you need. I would recommend having the automation table look-up in the subpatch as well, but not using [tabplay~]. It will likely just play it back at the upsampled rate, which is probably faster than you wrote it. Instead, you should probably have a [vline~] -> [tabread4~] read the table, and have that running into [tabread$~ $0-sample]. Then lowpass filter it to the [outlet~]. The [hip~] can be outside of it, as it's mainly dealing with low frequencies that the upsampling isn't concerned with.

Yop,

thank you for the answers.
Indeed I want to loop it, and make that with a [phasor~]. [tabplay~] was introduced here for example purpose.

Stutter, I can't understand why you seem not to put an 'extra point' at the beginning of a looping sample. In the very last lines of http://crca.ucsd.edu/~msp/techniques/v0.08/book-html/node28.html it is said that the nth point of the original sample must be copied at position 0. This is why I were proposing to shift the entire table one point to the right.

Nau

You should have that guard point in the beginning as well, and make sure you avoid reading it:

[phasor~]
|
| [r size_in_sample] <-- the original sample size, not including the 3 guards
| |
[*~]
|
[+~ 1]
|
[tabread4~]

(I know that seems kind of obvious, but it gets overlooked.)

As for putting that point in, though, it's kind of a pain because there is no empty index for it. It'd be nice if [soundfiler] had an option to do that for you, but it doesn't. But you don't have to shift it over using a brute-force [until] approach. Instead, you can load the file with [soundfiler] and use its outlet to resize the table three points bigger. Then, use [iem_tab/tab_copy] to shift it over one sample:

[r $0-samplesize]
|
[0 1 $1( <-- copy from index 0, paste starting at index 1
|
[iem_tab/tab_copy $0-sample $0-sample] <-- copy and paste into same table

Then it's just a matter of copying those three guard points.

I should mention, though, that if you leave out those guard points, it's probably not going to be a big deal. It's really more of an issue for reading oscillators.

Thanks.

I usually use this [tab_copy] method, but I thought I had tested that writing a table onto itself wasn't possible. Thank you for pointing to that detail.

Nau

Hi there,

I worked a bit on the antialising implementation in table lookup.
The joined patch shows four implementations of playing an audio file using an audio rate automation of the playing head speed. It's nothing else than a workbench I made when trying to dig into this topic.

The first has no antialiasing (starting point).
The second tries to antialias the final [tabread~], but sounds less good than first.
The third tries to antialias the [rpole~]-based integrator, and sounds even worse.
The fourth one tries to antialias the whole computation scheme in a global way (as previously suggested by Maelstorm), and doesn't sound worse than first.

The patch (sorry, this is heavy) can either use a funkydrummer wav snippet (sorry again, I don't owe the rights so keep it 'for scientific curiosity' purpose ), either use a 1khz sine wave table filled with an [osc~].
I used 'sonic visualizer' to have an eye on the frequency contents. I posted two png images showing comparisons.

'Global' antialiasing shows cleaner spectrograms, but exhibits a strange offset/flip frequency reinforcement with respect to the fundamental and also a 'weird' zone where the spectrum is event cleaner than the original played at unity speed (see far left in the window).

If anyone is in the mood of opening these files and give me a comment, an improvement, an explanation, he is welcome. For instance I wonder if using a single 'final' chebyshev filter would be possible.

Thanks,

Nau

http://www.pdpatchrepo.info/hurleur/antialiased_varispeed_hurleur.zip

Hi there,

I have a more precise question. In the previously uploaded patch I tried to remove the first [lp10_cheb~] from the chain to see what happens, and it seems to give an even better result.

Here is what causes me trouble. In a different context (distortion) lowpassing the upsampled audio input was considered kinda 'mandatory' by Maelstorm (http://puredata.hurleur.com/sujet-5775-1.html). Here the results seem better with only lowpassed output. How the hell ? I imagine this has to do with the intrinsic nature of the audio input file, an audiorate speed automation (the curve can easily seen in http://www.pdpatchrepo.info/hurleur/comparison1.png

Hi there,

I have a more precise question. In the previously uploaded patch I tried to remove the first [lp10_cheb~] from the chain to see what happens, and it seems to give an even better result.

Here is what causes me trouble. In a different context (distortion) lowpassing the upsampled audio input was considered kinda 'mandatory' by Maelstorm (http://puredata.hurleur.com/sujet-5775-1.html). Here the results seem better with only lowpassed output. How the hell ? I imagine this has to do with the intrinsic nature of the audio input file, an audiorate speed automation (the curve can easily seen in http://www.pdpatchrepo.info/hurleur/comparison1.png