Continuous recording buffer

[Paul Jones]

I'm wanting to make a live tool for a mate Charlie, he wants to be able to
play live then freeze, reverse and go forward at variable speeds using a
control peddle. Now doing this with a recording buffer on loop is quite
simple I think, use grain buf n PV_Play etc.

However I don't want the buffer to over write, I want it to be continuous
recording not looping.
I would like to add frames and remove frames as its recording, so if buffer
= 5 secs and recording reaches that threshold instead of looping back on
itself it deletes frames older that 5 secs and adds new ones.

I've read a couple of posts on this and I'm none the wiser on how to achieve
this.

I've thought of having one massive buffer and just indexing the most recent
5 secs, however the strain this will put on the cpu and ram considering the
other things going on may be a problem.

Thanks for any help

Paul



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Continuous-recording-buffer-tp7604845.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Paul Jones]

to answer my own question in case someone is looking for the answer in the
future.

Does anyone know how to do this for FFT data? At present I'm compiling a 5
second snipet from an audio recording on loop by chopping at the point of
record and glueing it back together in order, if I do this with the FFT
buffer it causes chaos.

WARNING: There is a mismatch between the PV databuffer you are using and
this instance of PV_PlayBuf
FFT size of databuf: 1.582515
FFT size of current process: 1024.000000

Any ideas?

(
var frames,hops,abuf,fbuf;
frames = 1024; hops = 0.5;
~abuf = Buffer.alloc(s,5*s.sampleRate);
~fbuf = Buffer.alloc(s,5.calcPVRecSize(frames,hops));

SynthDef(\record,{
|in,abuf,fbuf,trig=0,trig2=0|
var input,fftbuf,recbuf,lbuf,pos;

lbuf = LocalBuf.new(1024);
input = SoundIn.ar(in);

recbuf = RecordBuf.ar(input,abuf);
pos = Phasor.ar(0,1/SampleRate.ir,0,5);
fftbuf=FFT(lbuf,input,0.25,1);
fftbuf = PV_RecordBuf(fftbuf,fbuf,0,1,1,0.5,1);
SendReply.kr(trig, '/on' ,pos);
SendReply.kr(trig2, '/off' );


}
).send(s);


)

~test = Synth(\record,[\in,0,\abuf,~abuf,\fbuf,~fbuf]);
~test.set(\trig,1);

(var on,off,copy1,copy2;
~copy1=Buffer.alloc(s,5*s.sampleRate);
~on = OSCresponderNode(s.addr, '/on', { arg time, responder, msg;
[time, responder, msg].postln;

~abuf.copyData(~copy1,0,msg[3]*s.sampleRate, (5-msg[3])*s.sampleRate);

~abuf.copyData(~copy1,(5-msg[3])*s.sampleRate,0,msg[3]*s.sampleRate);

}).add;
~off = OSCresponderNode(s.addr, '/off', { arg time, responder, msg;
[time, responder, msg].postln;


}).add;
)
~copy1.play
~on.free;
~off.free;

~abuf.play




--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Continuous-recording-buffer-tp7604845p7604853.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[James Harkins]

Post by Paul Jones
to answer my own question in case someone is looking for the answer in the
future.
Does anyone know how to do this for FFT data? At present I'm compiling a 5
second snipet from an audio recording on loop by chopping at the point of
record and glueing it back together in order, if I do this with the FFT
buffer it causes chaos.
WARNING: There is a mismatch between the PV databuffer you are using and
this instance of PV_PlayBuf
FFT size of databuf: 1.582515
FFT size of current process: 1024.000000

Well, this is a playback problem, but you didn't post the playback code, so
the best anybody could do is a guess.

Anyway, a PV record buffer begins with three values: frame size, window
type and hop size. I might have the order wrong. 1.582515 is not a valid
FFT frame size, so I have to suppose that this value is coming from a
buffer other than the one you used with PV_RecordBuf. That is, most likely
you're providing the wrong buffer to PV_PlayBuf.

hjh

[James Harkins]

Post by James Harkins
Well, this is a playback problem, but you didn't post the playback code, so
the best anybody could do is a guess.

Oh, it just hit me... another possible cause. This one is more probable.

If you want to reorder the data in a PV buffer, you have to preserve
the buffer's format.

FS = frame size:

Samples 0-2: PV metadata (frame size, window type and hop)

(0 * FS + 3) .. (FS+2): first FFT frame
(1 * FS + 3) .. (2 * FS + 2): second frame
(2 * FS + 3) .. (3 * FS + 2): third frame

... and so on.

When you're copying the data into a new buffer, first copy samples 0-2
from the source into 0-2 in the target buffer. That's completely
non-negotiable. If you copied part of an FFT frame into these
positions, that would explain the error that you got.

Then, make sure you keep the FFT frames intact. If the frame number is
i, then each frame represents a window of the original audio beginning
at i * FS * hop / sample_rate seconds. If you want to start off by
copying half a second, starting at 1.25 seconds, the frame index would
be

i * FS * hop / SR = s
i = s / (FS * hop / SR)
i = s * SR / (FS * hop)

1.25 * 44100 / (1024 * 0.5) = 107.666015625 // starting index
0.5 * 44100 / (1024 * 0.5) = 43.06640625 // # frames to copy

... which you would then have to round to the nearest integer. The
range of samples to copy would then be (108 * 1024 + 3) .. ((108 + 43)
* 1024 + 2).

Untested, so I can't rule out the possibility of a math error here. I
think this is right, though.

hjh

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[adam4]

you could try sooperlooper and see if it does what you want - you can
reverse loops and do multispeed (2x 4x etc), not sure it's continuously
variable though



--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Continuous-recording-buffer-tp7604845p7604879.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/

[Paul Jones]

Thanks for the tips James, won't be working on it till Friday next week, will
let you know if it works.

Re sooperlooper , Nah not what we need, going to do all manner of processing
to it. The above code does what need. But thanks for the tip.

Paul





--
View this message in context: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Continuous-recording-buffer-tp7604845p7604886.html
Sent from the SuperCollider Users New (Use this!!!!) mailing list archive at Nabble.com.

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/