I also need help understanding this thread correctly. To understand this thread, I slightly changed the first codes of this thread. I realised there were glitches in the sound produced by evaluating the codes below, and I could not understand why they occurred. Could it be explained? You could hear the glitches at around 6.5 seconds and 13 seconds in the linked sound file of each code.
Thank you for that @jordan
Okay so RecordBuf not returning ~b1.bufnum seems to be one part of the problem…
I meant ~bTest as input for the Ndef’s RecordBuf instead of ~b1 as declared…
When I evaluate your code, I still got the issue that ~bTest is being played. When I out-comment the ~bTest line I get my signal from SoundIn.ar(~bus0); - but with those clicks in it like @prko described…
Maybe its from the fact that the allocated 0.2 seconds buffer is not “not windowed”?
One way to proceed here is to build up from the absolute minimum functionality, step-by-step. At the point where it breaks, that’s where the problem is.
var input = SoundIn.ar(0); // or other source; mind feedback!
var recorder = RecordBuf.ar(input, b, loop: 1);
var player = PlayBuf.ar(1, b.bufnum <! A2K.kr(recorder),
rate: 1 // I have a reason for this, at first
(player * 0.6).dup
I found here the first gotcha – b.bufnum is not audio rate, while recorderis audio rate. This causes <! to behave incorrectly.
But even after fixing that, it’s still broken – there is a click at every loop point.
So RecordBuf / PlayBuf may be a non-starter.
var input = SoundIn.ar(0);
var phase = Phasor.ar(0, 1, 0, b.numFrames);
var recorder = BufWr.ar(input, b, phase);
var player = BufRd.ar(1, b, phase <! recorder);
(player * 0.6).dup
This version is completely smooth. So, better to start with this approach and abandon RecordBuf / PlayBuf.
The next problem you will run into is: playing back at rate = 0.97 while recording at rate = 1 will also click every time the playback head crosses the record head. You can’t transparently drift further and further back into the past, infinitely. So you might have to rethink what you mean by rate: 0.97.
The deal with rate: 0.97 or in my final case rate: -0.5.midiratio (which is of course unprecise because of non-linear frequency distribution) is to playback a signal/instrument but slighty pitchshifted…
I tried dozens of pitch-shifting possiblities in SuperCollider but this approach just sounds the best - if there weren’t those clicks…
For short periods of time, you could avoid clicks by using a longer buffer. But it isn’t possible to do indefinitely. Memory is finite, so the buffer size must be finite, meaning that there is a finite amount of time before the playback and record heads cross. You could reduce the clicking by crossfading two players, but there will inevitably be a temporal discontinuity in the result. This is unavoidable – you cannot have playback keep going further and further back into the past forever. Eventually you have to have a temporal edit point, or just stop.
If that’s not acceptable, then a granular approach would be your best bet.