"downthreading/deferlowing" for/while constructs???
hi everybody,i created a tool in gen~ for copying buffer-data,
using a for/while construct.
when i copy large chunks of data (above about 5seconds),
while running other msp stuff in the background,i get clicks.
looks like the audio processing is overloaded by the for/while construct.
is there any way to defer operations inside a gen~ pather to a lower priority thread?
gen~ works at sample rate, so what you are doing is asking gen to copy loads of samples in just one sample. You could split the "copy" operation across several samples. This would avoid the CPU spike that you are having.
aah!!
so the for/while loop copying lets say 10000 samples from a to b
will be carried out in a time of just 1 sample of the samplerate?
thanks....but puh thats gonna take some coding-time...
yes, for both ;-)
Here's a modified version which copies block of 64 samples:
wa-hooo! (i noticed it took you half an hour (; )
thanks a mille!i needed this so badly for this project i am working on..
https://cycling74.com/project/looppad-64/
to finally get a click-free recording engine (it requires sample-accurate copying of large blocks)..
i posted the gen~ copy-thingy under "tools",do you feel like posting the modified version?i think its quite useful,and the only alternative i found that kind-of works is el.buffet~
Feel free to post the updated version.
How about using mxj but.Op to copy the samples?
first of all,what you did works really really good!
-mxj buf.OP is too slow.what i am working on is a live-looper,it shouldnt take more than 1 second
until a recording is done and the next one can start.if been using a construction with an upsampled poly~ before but it never really worked.this finally does it.yeah.
of course click-free looping can be done in many other ways.i spare you the details how i ended up moving around chunks of data for the "L-64" device.(it does make sense ,anyway)
-i will credit you massively..and i will add a parameter "blocksize" to let the user decide just
how much cpu he wants it to use.i run it now with a blocksize of 1024 samples,which just about works.
(wow this is really really good now,its sampleaccurate AND scalable in terms of cpu usage!)