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
Fascinating! You're correct, it looks like tabread4~~ is included in the zexy library (which is why you can load it in Pd-extended), but it doesn't show up in the Pd help browser for zexy since there is no help patch. (this solves an old mystery for me, as I couldn't figure out how tabread4~~ was the only iem_dp object I could get working, before successfully compiling the rest of the library)

But indeed, that seems like a strange object to include on its own without the other double precision math objects. Maybe there's a simpler way to implement the dp looper that I'm not seeing, but perhaps more likely that tabread4~~ was included in zexy for a different use that didn't need phasor~~ et al.

Not sure whether it'll work for you, but here is the version of iem_dp that I compiled for Mac if you'd like to give it a try:
iem_dp.zip
***I'm running the latest Mac OS 10.13.4, Pd 0.48-1 64-bit, not sure if it will work on older OSes or 32-bit Pd.

If I'm not mistaken, Pd-extended is 32-bit, and also no longer in active development... I would highly recommend migrating to the newest Pd vanilla. Deken makes installing most external libraries easy (which it sounds like you already know how to do), and then you can manually copy iem_dp to your externals directory (in my case, ~/Library/Pd). Be sure to add iem_dp to "Pd libraries to load on startup" in the Pd>Preferences>Startup... menu, then restart Pd to see if it loads for you. (the console will print "iem_dp (R-1.19) library loaded!")

Yes, I got to the same conclusions: there's probably another way to use tabread4~~ without phasor~~ and such, but I'm missing it.

I tried your compiled version on my laptop (osx 10.11.5, Pd 0.48.1) but it doesn't seem to work. I tried with extended too.
I'll check over the weekend with the installation's MacMini, that'll probably work. Tank you, seriously

@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!!