Hi, I'm pretty new to pd, and there is the thing:
I'm trying to create some dynamic looper that loops a recording over and over and having some trouble with latency/delay between tabwrite~ and tabplay~.

1. I prepare the table in advance with dynamic resizing and naming so it will be ready to record when i tell it to.
2. I have in the background some sort of metronome patch (for tempo) that bangs to the track patch when to start the recording (the "track" patch is ready in advance and waits to a bang to start the record), metronome still plays.
3. The metronome bangs in the right time to the track patch
4. I am recording with tabwrite~ the number of samples that is pre-calculated in step 1. (I am recording the beats from the metronome to hear it play back without delay)
5. the tabwrite~ ends the recording when the number of samples are all full and bangs right away to tabplay~.

here is the problem. when it plays the recording it can be noticed that there is a delay between the record playback and the metronome patch that ticks. this delay stays with the same margin over the loop.

I want to know how you handle this issue? or what can be the issue?

what cam to my mind is few options:

1. start playing tabplay~ before (with offset of the latency) tabwrite~ finishes (is it even possible?)
2. hang (make some delay) the metronome patch with the latency offset (seems like not right thing to do)
3. I read about something with buffers that must be divided by 64 samples to be precise, do you have any information about it?

I can provide my patchs but they are a little bit messy because I use them in IOS application.

thanks so much!

@dimagimburg You don't need to use [tabplay~].
You can just use a [delwrite~] and read its output with [delread~].....
There should then be virtually zero latency in your patch. The latency will be at the dac adc conversions as you say, and will depend upon how ios deals with that.
The delay problems you have are between the metronome and [tabplay~] and should be gone with [delwrite~].

Here is a patch that should do the same thing. Written for Pd Extended though, so some objects will be missing maybe....(limiter, etc.)... maybe not.
loop.zip
It shows anyway the use of [delwrite~]..
I use it with an external sound-card. The audio is then processed through a second patch with another external soundcard and a digital desk (dac-adc-dac-adc-dac-adc) with about 6ms of delay (= 2metres of air)....
David.

hello, as David says you can use a feedback delay line. However, if you do want to use tabplay there is a solution:
simplelooper.pd

as you say you need to make sure that the samples are in multiples of 64 though when I was making this I forgot that metro and delay now can be set in samples

edit: the reason is that objects actually only get messages every 64 samples, so when a dsp object that has sub-sample accuracy like vline~ or vsnapshot~ gets messages it has to record the clock times when they got the messages and then check for them in the dsp routine.

tabwrite~ and tabplay~ do not work like this though

wow guys, thank you both for the super fast reply. will try it tonight and update if it worked for.

I've made a looper for chapter 9 of my book "Digital Electornics for Musicians", using Pd and Arduino. The code is open source so you can take a look at it. It's here https://github.com/Apress/digital-electronics-for-musicians

@whale-av i just thought about it a little bit (didn't try it yet thoough) but isn't the delwrite~ object adds more delay to what I have now? from the help window of delwrite~/delread~ I didn't understand much the need. (i only saw someone on youtube that creates delay effect which is obviously not what i search for). again, I'll try it later tonight.

@dimagimburg Hello again.... I don't know... we haven't seen your patch yet!
[delwrite~ 20000] will create a delay line in ram 20 seconds long. [delread~ 10000] will tap into it at the 10 second mark......
Once you know the maximum loop you will need you can set [delwrite~] for that and save some ram usage, although it is not usually necessary nowadays. The read point for [delread~] (its argument) is the time of the delay (tap) and can be set dynamically. Feed it back to the input of [delwrite~] and you have a looper. Very simple....... looper.pd

David.

here are some more examples of using this delay line technique in abstractions (requires pd 0.48)
srepeater~-help.pd
srepeater~.pd

Okay guys I didn't manage to fix my latency problem, that probably because i cant explain myself clearly. I am providing you my example of the issue. to reproduce it please leave you mic and speakers close enough to record the metronome ticks (my laptop mic and speakers are close enough). please bang the top left controls for the example i provided in the order from left to right:
120 a bpm -> 2 s beats -> 4 s bars -> mentronomeOn -> lenght 8000 -> s is_preparing_for_recording.

this should start the metronome tick and cycle tself with number of beats and bars. when the cycle starts over again and is_preparing_for_recording flag is banged it should start recording the sounds of the metronome for one cycle (in this example 8seconds). then it should play back what ive recorded. you can clearly hear the delay between the still running metronome to the playback. this is something i want to fix. can you please help me?

zip is provided Archive.zip

thak you so much!

@dimagimburg You might find that there are adjustments possible for your computer soundcard.... and if so there will be some help with latency on Google.
The Pd audio settings will help if your soundcard is capable. Generally very low latency is only possible in windows with Asio. OSX has low latency built in.
A built in sound card might not be asio capable.
Leave the buffer (Block size) at 64 and reduce the Delay (msec) setting in Pd as low as possible. If you cannot save the setting, or Pd audio hangs then increase the delay again. Sometimes Pd gets permanently stuck. If that happens open this patch.....
fix.pd
save the audio settings, re-open Pd and try again with the best (lowest) setting you managed the last time.
Zero latency is impossible, but a few milliseconds will be inaudible.
David.