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 I assume you mean [tabread4~].......?
All possible, except for a 20 minute sample (max 40M samples I think).
So 15 minutes ish mono @44100.
[sfread2~] and [readanysf~] will not load on my windows system.
[xsample~] I don't know.

Forward, backwards, varispeed is all trivial with [phasor~]
this.zip
Interpolation is not dealt with in that patch, nor clicks as the loop re-starts.
Clicks can be dealt with by ducking the volume at x-over points.
fix.zip
or by choosing only to loop at zero crossings (more complex).
Interpolation can be dealt with by writing extra samples.

Do come back here from time to time. It's not really my main interest in Pd, and someone might well just post you the perfect solution.......

David.

Hi GL,

I spent a good 2 solid weeks beating my head against this very issue recently, as I had the same wishlist as you mentioned (variable speed/direction, long buffers with no artifacts, click-free looping). I tried my hand at adapting B.16.long-varispeed.pd, but I couldn't make it work for dramatic speed changes.

My solution was indeed to use tabread4~~ from the iem_dp library. (which, to my knowledge, is not on deken... I had to download it from github & compile from source... here's my post from a while back on the subject)

My looper seems to work, although honestly I'm not sure why—I'd think that the weak link in this case is the precision of the number of samples output by soundfiler, if a very large file is loaded into the table (which can indeed be large if the -maxsize flag is used). I did use the double precision math objects to calculate phasor~~ frequency and tabread~~ read position, but as you can see, the rightmost (dp) inlets/outlets aren't being put to use for most of them. But, nonetheless, it seems clean to my ear!

The windowing to prevent clicks is adjustable, and is in the {pd window} subpatch. I think I read of that idea on this forum, but I can't remember where... apologies to whomever suggested this great idea. I also added some calculations to adjust the window based on current speed of the playback.

double_precision_looper.pd (requires iem_dp library)

If you have a more elegant solution/modification to put those math objects to better use, I'd love to see! I'm also crossing my fingers that someday the developers will decide to take the plunge & go full double precision natively in Pd, but I understand the headaches they're faced with in trying to ensure (most/some/any) backwards compatibility with older externals.

Hi,

Thank you so much for the replies, I hadn’t turn on notifications so took a while to see those.

@whale-av:
The problem is really artifacts produced by tabread4~~ in the “classical” implementation (that of your patches). You won’t notice those with a voice due to complex spectre and dynamics, but they clearly show up on continuous high-pitched drones …
It’s a known (and quite essential) issue, but surprisingly there’s no easy solution to this it seems.

@beep.beep:
Ok, good to know I’m not the only one

I’ve been using Pd-extended for this project, so tabread4~~ comes included.
However, the rest of the iem-db library isn’t. This is rather strange if it’s needed to run tabread4~~ properly ...

I confirm the iem-dp library is neither on deken, nor Pd-extended, nor Purr-data.
I’m trying to avoid compiling for 2 reasons:

• Never done it (and not much of a coder).
• We develop the project on different OSX.

I’m beginning to think there’s no other way, so I guess I’ll have to give it a go … Your patches seem to solve the problem!

UNLESS:

• Someone out there can explain how to use tabread4~~ without other iem-dp objects (phasor~~, add__, etc)?
• Someone knows of a compiled version of iem-dp?
• The problem (artifacts) is solved in a different way in Purr-data?

Many many thanks for your reply, it seems there’s finally light at the end of the tunnel.
Once again, it’s such a core issue I’m surprised there’s no simple solution, and I’m sure many could benefit greatly from one …
Will get back with conclusions when they come around.
Best,

GL

@Gabriel-Lecup If you just want to loop at normal speed then you can use [tabplay~]
It will be sample perfect.
You just have to deal with waveform mismatch at the loop point..... which will cause clicks.
If you want to change the playback speed then you have another problem.
Artefacts are unavoidable. Well I will qualify that. As you reduce the playback speed you have to increase the original sample-rate of the Sample compared to your output sample-rate to avoid them. Half speed... double the sample-rate of the Sample. You cannot do that in Pd as far as I know.

If you cut the playback speed in half. This causes everything to sound an octave lower because the time stretching makes all the soundwaves twice as long, which means their frequencies will be cut in half and thus sound an octave lower.
This leads the problem that every single sample you use needs to be played twice or else there will be gaps (a much worse "artefact"). To avoid this problem you can use [tabread4~], which interpolates intermediate values that it generates using information from the values that ultimately precede and follow it.
If you increase the playback speed then samples are dropped. This unavoidably creates artefacts as well. As you say, with a tone they will be audible.
Filters can help with high frequency ringing, but might already be built into the object.... though probably not, because you can see the ringing in [B04.tabread4.interpolation].pd in the doc folder.

Someone might know whether [tabread4~] (or [tabread4~~] even), uses quadratic or cubic interpolation. Checking the processing overhead might tell you....... https://www.maximalsound.com/mastering/interpolation methods.pdf

You need to add 2 samples to the array for [tabread4~] ((see [tabread4~-help])) to do it's math playing back the whole sample.
I had never thought about it, but 2 zero samples should probably be inserted after a loop point to allow the curve to interpolate to zero. This would also avoid any post Sample clicks. But how?

I assume that [tabread4~~] which seems not to be available to me on windows, uses double precision.
That will give more accuracy for bit depth, but the samples still arrive at the same speed, so I cannot see how it helps you here. 64-bit precision interpolation over 32-bit precision. Audible? I would be very surprised.
If it is working well for the patch that @beep.beep has kindly posted then I can only assume that [tabread4~~] deals automatically with the 2 sample overhang.

David.

@whale-av
Thank you very much for taking the time to detail this.

I can’t use [tabplay~] as the artist wants to use variable speed and reverse playback, as well as nominal speed.

Clicks at loop points aren’t a problem as the files are processed to start and end at zero-crossing.

I understand artefacts (with an “e”, thanks for that) are inevitable when playback speed is different from 1. Using filters to eliminate aliasing when speed >1 sounds like a great solution, I’ll look into this (maybe also upsampling in a subpatch, if it’s not too hard on CPU).

However, it seems tabread4~ generates artefacts at nominal speed too!
I’ve modified your patch and attached an audio file where the artefacts show up clearly: reverseMod.zip

The problem is mentioned (with a possible fix) in examples B.15 and B.16, but I can’t get those to work at highly varying speeds, or reverse playback … I understand this is the reason why IOhannes & co came up with tabread4~~, but I can’t get that implemented neither at the moment …

Sorry I wasn’t clear at the start, I hope this all makes more sense?

Thanks again,
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!!