groovebox2 (the groovebox2b example) has a load of about 23 percent on my 3.2 ghz haswell i5 using integrated gfx. depending on the fx selected. i can load 6 instances of this patch before i get audio-dropouts (at about 95 percent cpu-load)

while there is probably not much that can be done regarding the gui (it is updated at 1/16 step rate), it should be possible to save cpu by replacing the bandlimited oscillators with simpler ones, and using less, or different fx.
(the xy-one uses quite a lot cpu) and maybe using a simpler reverb. and of course using multithreading/pd~
which would require a bit of work though...

i suppose you are using the 1st groovebox (groovebox1r4)? it uses filters based on fexpr~ which are very demanding, you could try to replace these wirh other filters (pole/zero based, or even vcf~). another problem is the large gui with many elements. you can try to avoid gui redraws as much as possible. or you could try to build something friendlier (cpu-wise) using my modular groovebox2.

"Every single cycle wavform is made of 2048 points"

tabread4~ needs 3 points more. (see tabread4~ help-patch)

probably the right outlet of vcf~

it is probably too much for the rpi, at least for the rpi1. to throw out the oversampling, you can remove the block object in all 7 "stps_oscs", and all objects between the vcf-out and the outlet (connect the vcf right lowpass out directly to the outlet). i believe that should suffice even for the rpi1. if not, you could try to replace the rev3 with a cheaper reverb...

and i'm not exactly sure if the 'classic mandelbrot-set series' yields any musically interesting results, but
i am quite sure that it only produces usable results for carefully chosen values of c (on the border of the mandelbrot set where it neither converges nor diverges, at least not so quick...).

maybe simple real-valued recursive functions are more fun. the idea is to blow up a value (multiplying, adding constants, whatever), then wrap it to a range, and feed it to the next iteration. like the classic gingerbreadman, hopalong etc. fractals. linke in the attached example. fractalmelody.pd

i don't understand why the iterations are 'hardcoded'. wouldn't it be simpler to just send the output of the expr to its input (via [float] and bang (and maybe [until]) and shouldn't the numbers be complex ones? that would be something like next_zr=(zr * zr) - (zi * zi) + cr and next_zi=2 * zr * zi + ci for the typical mandelbrot set series. (afair...)

it looks like this is caused by certain 2d operations not supported (accelerated) by the graphics-card driver.
this happens here with the opensource radeon driver, as well as on a mac-mini (running ubuntu)
with the nouveau driver.
it is worse, the larger the window is.
proprietary fglrx runs fine (concerning this issue...), opensource intel too.

you can use 'add' and 'add2' (many of these) to add messages to a qlist. i have made a little
recorder/player using qlists, it is in my instrument-collection at my homepage.

you dont have to use shell or something like that in extended, there is filesize, or fsize, which outputs the size of a file in bytes. if you know the samplerate, bit-depth
and header-size, it is easy to calculate the length of the audiofile.

if you want audio in tables (without dropouts while loading big files),
you can use readsf~ in a reblocked subpatch, http://puredata.hurleur.com/viewtopic.php?pid=5387#p5387
and you could split huge audiofiles into multiple tables, to avoid the problems with float precision. but i dont think its worth the effort.