Hello forum!

First post here, not all that new to Pd.

Basically, I noticed nasty artifacts using phasor~ to read a buffer with tabread4~, and not just on large files. It seems like a known issue, and fixes/workarounds appear over the years in different threads.

However, I am not able to find a clear up-to-date solution to do this:
Nominal + variable + negative (reverse) playback speed
No artifacts
Long audio samples (20min)
Looping on/off with no clicks
Read from buffer OR disk (either is fine, buffer is better)

My best guess at the moment is to combine the Pd example B.16.long-varispeed.pd with the tabread~~ object, but I’m having trouble implementing this.
So:
Does someone have a working example using tabread4~~?
Can this include reverse playback of a sound file?
Is there a better solution out there, such as (not limited to): moonlib/sfread2~, readanysf~, xsample~, …

Thanks in advance for your help.
I’m sure this is something many of us would be interested to clear up.
Cheers,

GL

@Gabriel-Lecup Tried everything for half a day...... and research for another half..... and got nowhere.
[tabread4~~] seems to be the same as [tabread4~] with a signal-rate onset inlet.

[tabread4~] actually has a 64-bit onset inlet, but that is not the problem.
See B15.tabread4~-onset.pd

The problem is the interpolation..... "how on earth do you interpolate white noise..".
Long discussion here..... https://lists.puredata.info/pipermail/pd-list/2016-03/113770.html
and here.... https://www.mail-archive.com/pd-list@iem.at/msg19521.html

I have not tried yet with [tabread4c~] at 88200........ but I am not hopeful.
If you have the possibility of receiving the different tones from your artist separately..... and processing them individually in parallel before combining, then maybe you would have more luck.

The only solution otherwise might be........ analogue.........

tabread4c~.zip

You can use [line~] instead of [phasor~] of course....... but I am not sure how the varispeed could work.
Forwards, backwards, any speed yes...... varying the speed...?
Will it make any difference to the artefacts.........?
No.
David.

@whale-av said:

https://lists.puredata.info/pipermail/pd-list/2016-03/113770.html

Yes, this issue is quite essential and poorly documented …
I was aware of both discussions you mention, and couldn’t find a solution there: just confirm the problem.

You’re probably right it’s due to the interpolation, the fact it appears even at nominal speed makes it a mystery.
The onset solution seems to work, both with data and signal onset.
The hard part is to implement them …
I still have hope installing the iem-dp library.

You’re right tabread4c~ doesn’t solve the issue neither.
I’ll probably end up having different samplers do different things: one for fixed speed (no artefacts, read from disk, etc) and one for varying speed.

I’ll keep you updated if I find more clues somewhere.
Thanks for your support

GL

Ok, I give up … at least for now.

I really hope someone someday can come up with a proper off-the-shelf solution easy to implement (Vanilla?).

In the meantime, I’ll go for 2 seperate samplers depending on the use-case:
One for the varispeed but artefacts, another with fixed speed but no artefacts.

If any of you come to conclusions, I’d be glad to share the info I’ve found on the subject.

I want to point to this older release of a working Pd version with double precision made by Katja Vetter. I used it for the audio-side of long videoplayback.

@Johnny-Mauser Yes...... She was always ahead of the curve (pun intended....... )
and then, probably because of her work, double precision onset was already in [tabread4~] in Pd-extended....
David.

hi there, made an abstraction based on B.16.long-varispeed.pd. It should fit all your needs, variable speed and reverse playback, no artifacts with very long soundfiles as far as my humble ears can tell. and it comes with a nice little gui.. sfplayer.zip
also on github: https://github.com/solipd/AudioLab
you'll need pd-0.49 or higher to run it.
cheers

@beep.beep @beep.beep hello, quick question (hope you see this, looks like this was a long time ago!) Can you pls explain what the [cos~] object is doing here? Is it itself creating the window? I mean is it creating the window function itself? Thx for any answer in advance!

@yealace Hi there, I believe I found this technique in one of @Maelstorm’s patches & adapted it, so I’m a bit fuzzy on the math.

But yes, [cos~] plays a part in creating the window. It’s fed by the same [phasor~] that is driving [tabread4~] (the audio table playback), and generating a slice of the positive part of the sin function ([phasor~] -> [cos~] is equivalent to [sin~]) which is being amplified & clipped to shape the window.

I made a quick attempt to add some calculations that make the length of the window consistent at any playback speed (for example, 25ms fade in / fade out at either end, regardless of whether you’re playing the loop at 0.5x speed or 4x speed). It kinda works but is definitely not accurate at all loop sizes & speeds, so anyone who wants to improve on it is most welcome to do so!

Here's a vanilla version of the patch I posted earlier in this thread, which should be easier to get working if you're just interested in the windowing part:
single_precision_looper.pd

@beep.beep awesome thanks and looking forward to checking out this patch with your additions!!