Time Accuracy and Latency Compensation

You are doing that wrong...

As first , only chance that player and loop would stay in sync

would be if you set count~ maximum to file length in samples.

I see that what you posted originates from one of my example patches.

The latency in there means something else :

to compensate I/O latency of audio hardware,

so that one can overdub precisely.

If you want to have playback of audio file as master,

then use sync out of whatever player you use

to run loop recorder.

I don't totally get what you mean here. I did borrow your patch - all I'm trying to do here is to record a loop into a buffer and have it play back in time with the loop I'm recording. In practice the length would be undetermined but in the version I linked here I'm using a known length (drumLoop.aif) so I have an understanding of how far of it is.

My logic with the recording into the buffer in the right was that I can get an idea of how much delay there is between recording and an actual file, but that practicality of that is a pure guess.

Can you expand more on the latency compensation you use in that example?
In this version it starts out of phase and goes dramatically out of phase after about 50 iterations of the loop. I understand probably I need to correct it, but I'm not sure where you're getting the value of 480 and 51 from. I tried using the sample rate and vector size from the settings (and variations of these numbers) but it doesn't really help me

this is the important guts of your player

before overdubbing understand single dub

sample length should be dynamic (change for different size files) and accurate

using [snapshot] without a number never works for me

you have a lot of hard coded numbers that should be dynamic (especially the compensation-latency)

that patch is a nightmare (the stuff added beyond Source Audio original)

The added stuff is just a very quick way of getting it to record into the buffer once and loop. It's a very quick sketch to test timings.
I understand the image you linked, I was doing some testing with timing accuracies but I found count to be pretty useless.

Ultimately the length of the recording would be unknown - which as far as I can tell is what source is doing with the 1323000 value in the patch. In the image you linked, what value are you using for the compensation? This is essentially what I'm asking for and can't find an answer for anywhere

This is what I'm trying to do - the count~ duration seems to always be off, but I can't figure out how I'm supposed to correct it. In Source Audio's example it's close but I can't figure out which values to correct with.

What compensation are you talking about ?

your recording length is not unknown at all.

it should be as long as that drum loop.

so you don't need to measure anything, just tell

count to go from 0 to length of that drum loop.

If you use bang to get current count~ time, then you need to add vector size

because you are switching from non signal to signal world.

That all has nothing to do with latency compensation I used in that patch.

what I used is needed to play recorded audio from external source in advance,

otherwise it would lag for latency time , and one would not overdub preciselly.

Latency for internal playback recorded into buffer is not needed at all.

what value are you using for the compensation?

that's my sample rate 48000 - so 1000 * 48 compensation would be one second

I adjusted manually when I was testing using laptop microphone and a latency problem

when I plug in external mic or bass through interface no latency

//

also just pressing where you said press start doesn't work at all

just a buzzing sound

//

im getting my samples like this

recorders built in RNBO so I can't share them right now

I'm trying to record a loop and have it play back immediately.

you need to figure out how to stop recorder and start player at the same time

no need for testing with sound file

Ok, what I mean is the drum loop is a proxy for literally any recorded buffer. I'm testing with the drum loop because I know how long it should be, meaning I have a rough idea of how inaccurate the timing is.

What I'm trying to do is this -

Where the subpatcher "some_kind_of_timing_solution" is whatever allows me to record and playback something that stays in time with the input. In the patch I shared above I was using the drumloop as a trigger because I knew how long it was, and it's very easy to tell if drums are in time with themselves, but I don't want to actually use a fixed duration.

In the image I shared above, I was illustrating timing attempts I've made but none of them are actually in time - they gradually phase out so that there's about 20ms of delay after about 10 repetitions or so. This made me realise I need to do some kind of compensation for the latency between recording and playing back. I realised that the recorded length and the actual length of the samples were also different, which is what led me to Source Audio's patch.

Which is what I'm asking - how do I make up for this, or what am I doing wrong that is generating this? Would the delays disappear if I do everything in the signal realm? I tried an example from Graham Wakefield in gen but the same problem occurs.