hey guys!

okay, I am using readanysf~ extension to open sound files. I created a looper abstraction.
Then I have created several loopers in a patch. Each looper has an inlet which allows to start playback and stop playback.

Let's say I have two samples: hihats and base drum. Both were recorded at 130 bpm and saved to wav files. In order to sync them on other software I would use something to trigger those files at the same time and they would be in perfect sync forever.

In this patch I've done the same thing - notice the play all button. So I load these two files into two loopers and then trigger them with play all. First 4-5 rounds loops are in sync, but then they begin to go out of sync.

The interesting thing is that if you load same file into different loopers and trigger them - they will NEVER go out of sync.

So I was wondering if I am missing something, maybe some inner workings of Pd which make audio files go out of sync.

Patch attached. Open TapeLoops16.pd

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

Luigi,

i'd be pretty much certain that even though your files are the same BPM, there will be a small variation in the total length. Unless you cut each file at exactly the same length (or multiples of powers of 2 of that length) then the small variations in file size will gradually set them out of sync.

Preferably you need to find another way to loop your files, or else some way to send a master trigger to re-sync ever few bars.

Also, looking at your patch, you often have a lot of patch cords coming to or going from individual objects. Your patches will become a lot clearer and more easily expandable if you start using [send] and [receive] pairs to cut down on the number of patch cords going everywhere. This might sound a bit like your mum saying "go clean your room up", but it honestly helps a LOT, especially with bigger projects, if you can keep your patches a bit tidier. You'll probably figure this out for yourself as time goes by, but if you get into good habits now, you'll progress more quickly with pd.

Hey mod! Thanks for replying!

1. My samples are of same length or of multiple length. In other loopers (like SooperLooper) I could trigger those same exact loops and they would play in sync for hours.

2. readanysf~ claims sample precise looping.

3. What can you suggest as another way of looping files? Apart from re-triggering them?

4. sends and receives - absolutely! I agree. Will do this.

i make my loopers with [vline~] and [tabread4~]. This means you need to load the loops into a table first, but you have complete control over how the loop is played.

i don't have readanysf~ compiled here, so i don't know how it works, but i just checked 'sooperlooper' and it DOES seem to have some syncing mechanism:

http://www.essej.net/sooperlooper/doc_sync.html

It does. To test I turn it off. And same loops that worked for minutes without any sync mechanism in SL (just by manual simultaneous trigger) go out of sync within several seconds in Pd.
Also - some loops in Pd do not seem to go out of sync.

Can it be that Pd uses less precise loop process or maybe more precise?

Cleaned it up. No more zillion wires anymore! Everything packed neatly.

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

it's the looper abstraction that you need to clean up

Oops!
Well, the main file was full of wires, admit it Now it is much cleaner. I will work on the looper abstraction too now.

I have to say that my interest in sync at the moment is theoretical. Another problem I have with this patch is that occasionally readanysf will start playing a file with a click. Anything I can optimize in that department?

clicks can be caused by:

(1) inconsistencies in the waveform: so, if your final sample bit has a value of 0.8, and then your fist sample bit has a value of -0.3, then you have a sudden jump of amplitude 1.1 when you do the loop. Generally for looping, you want both the start and end points of the loop to be at 0, or at least at the same value.

(2) some process has momentarily overloaded the CPU and caused the DSP to falter. In PD, you will often get this when you load audio files into an array, for example. The best workaround is to load audiofiles before turning on the DSP
If you are instantly retriggering up to 16 audio loops, you may also create a bottleneck that causes such a glitch.

(3) problems with object code.: Even the builtin vanilla pd objects still have quite a few bugs, but at least they are generally quite well tested and maintained by a team of developers. When you use externals, then the reliabilty of the objects you are using is much harder to know. I'm not sure how reliable readanysf~ is, but i wouldn't bet my house on it working properly all the time.

@Louigi said:

Oops!
the main file was full of wires, admit it Now it is much cleaner.

yes! have a cookie

(2) This seems to be the problem. For instance, I get much more clicks when the window of Pd is minimized or hidden by other windows. Maybe like a graphics problem? Also, this bottleneck could be the case. Is it the amount of streams Pd can process? Sometimes I get clicks when two files play almost instantly. I am trying to tweak some settings, but so far not too much success there.

i'd hazard a guess that your trouble comes from the code of [readanysf~]. I don't know how it performs its loop function, but it may not be very efficient, particularly when playing back many files at once.

that said, the builtin vanilla pd [readsf~] is not so good either.

the only sure way i know to play lots of files at one time is to read them into arrays with [soundfiler] and then playback with [tabplay~] , [tabread4~], etc

pd's gui is also very slow and extremely clunky, so if you are triggering multiple bang objects and other gui objects every time you loop, it may also be contributing to your troubles. make sure you only use gui objects when absolutely necessary, use as few as possible, and try to make sure you don't update too many of them while audio is running.

(although, i just looked at your patch again, and it doesn't seem like that's too much of an issue here)

i reckon your problem is readanysf~

see, it reads the file directly from your hard disk. you'll see much better performance if you write the audio files into memory first, by putting them in a

Ah! If it reads from hard disk I'd say its not good!
Are you sure this is what it does?

I wonder if it can be forced to use memory. Maybe I can read a file into a table and then redirect that table into readanysf?

you can loop quite easily without using [readanysf~]

use [soundfiler] to load your array,

and then a [line~] or [vline~] or [phasor~] to set the playback position
(that way you can vary the rate of playback (ie, speed)),
finally [tabread4~] to playback the table.

or if you don't need varispeed playback, then a simple [tabplay~] will work just as well.

just do a search of this forum for 'sample looper' or something like that. there are HEAPS of them to look at.

Here - on the screenshot you can see the route message. readanysf seems to output the amount of cache used.

http://aug.ment.org/readanysf/index.php

Doesn't it mean it reads from memory?

just a small buffer as far as i can see. but really, i don't know about readanysf~