Dear Pd-Users,

Since a few days i am experimenting with this circular buffer. Where is use poke~ and count~ to write to a buffer continously. So far so good. My problem is that when i want to stop to write into that buffer at a certain point, count~ resets it self to zero, which i don't want in every case. It would be nice to have the possibility to stop counting at a certain sample and later on continuing counting from that sample. I tried to use phasor~ for that but it seems to be not as accurate as count~ since the two run out of phase when phasor runs at 1 HZ. I also had issues when overdubbing with poke~ using phasor~ as indexdriver that glitches in audio would start to appear after some overdubbing cycles.

Maybe some one had already had this problem and solved the issue. Would be nice.
Thank you!

Best Moritz

Hi Moritz,

If you really want to use [count~], then I am afraid the solution I know is a bit hacky: this object can take a message [autoreset 0( to turn off autoreset if and only if it was paused by turning off the DSP. That is, if you are willing to turn off the DSP instead of sending a [stop( message to [count~], then that is possible.

Another way of approaching this problem would be to use [line~] in order to generate the loops you want. Have a look on this patch I prepared for you: looping with line~ with stop and pause options.pd

I hope this helps, take care,
Gilberto

I think you can just send the message [44100 1000( without $1, as this message means "go to 44100 from the number you currently are, in 1000 ms". Essentially it is the same thing, and it's maybe even more accurate to exclude $1, as the [snaps~] abstraction is using [metro] (haven't seen inside, but that's the only way to use [snapshot~]) which counts in ms, so you might loose a few samples there.
Still, if you want to retrieve the ramp, you'll need to calculate how many ms are left to get where you want. For this you'll need [timer].

Hi @alexandros, You are right that the $1 is not necessary in that case. And you are probably right about [snaps~] as well, and also about the [timer]. I will have a look on this now and post some results (if I do manage to solve these things).

Take care,
Gilberto

Hi @alexandros, what do you think about this solution here? The only problem I think this may cause is some frames lost due to [avg~], but how else could I activate that [sel 1] after [==~ 44100]? Or more generally, how is the best way of handling the result of signal logic? Any ideas?

I guess looping with [line~] can be problematic...
If you need a specific number of loop you can work around it by send the message [0, 10 10000( for a one second loop and send that to [wrap~], and finally multiply by 44100. This will work for 10 loops, but for an arbitrary number of repetitions, I guess you'll have to work in the control domain.
Good work though

I guess looping with [line~] can be problematic...

Yeah, that seems to be the case. Nevertheless, thanks for the tips for the patch above!