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.

a (not very elegant) solution in pd vanilla could be the
use of 2 readsf~ objects, the 2nd with an offset which has the length of
the transition. when the 2nd readsf reaches the end, it is time to crossfade.

and there might be an object in extended to get the filesize without loading
the entire audio into in array. (system? shell?)

fexpr-filters need an insane amount of cpu. cpole~/czero~ based ones are much
more efficient. examples of how to get the pole/zero positions
from coefficients can be found in the rj-lib, mmb-master (biquad)
and in my own instruments.

the other output of vcf~ is also a lowpass.

you are probably recording the note-off velocity, which
should b 0. you could use [moses] to filter the 0s.

if you have a given tempo and a fixed (maximum) length,
recording to tables is fine. otherwise, if you want to use midi
more like an audio looper, you could assemble messages from
your recorded midi-notes, and use a qlist for playback.
(i have done this in my qlist-recorder). not that well suited for
recording twenty minutes of knob twiddling, but works
fine for shorter sequences.

metros can take float values as tempo, and are (i think at least)
sample-accurate. a [metro 500] and [metro 500.333] start to drift,
two [metro 500.333] not. it can not go faster than 1 ms though.

you could also use [bang~] and do your calculations at samplerate
or below. (within blocks >=64 samples though...)

just a few things:
there are no (not the usual) 'types' in pd, just numbers.
'int' is just a rounded (truncated) 'float', and thus [t i b] gives an error-message,
and outputs a float anyway. use [t f b] instead.
dont even try to format comments . (or use a new comment object, if you
really need a manual line-break.)
for globals which you need in several subpatches, you could use
and [r foo] as 'wireless connections'. and if you do not want to
detect a range, but a specific (int) nr, you can use a
[select 0 1 2 3...] instead of a "[moses]-cascade" (like in makechord)

there is/was a pd-vst plugin: http://puredata.info/downloads/pdvst
i think the pd version used there is rather outdated, an it was quite difficult to
use/install and only worked as a vst instrument or effect, i don't remember which.

with libpd though, it should be quite easy to make a pd-vst plugin, and
i wonder why this (apparently) has not happened yet.

update: i was wrong here. it is not (yet) easy to make a vst plugin with libpd, since it can not use multiple instances. it might be possible to make a plugin as a kind of bridge, communicating with an instance of pd running seperately, but that is
probably far from 'easy'...

i use tabplay~ with 88 tables and about 250 mb samples
of piano sounds and 24 voices without any problems.
(it takes about 3 seconds to load though). the cpu load is
hardly noticeable. i suspect the pitchshift is more likely the reason
for any overload, or perhaps very low memory, on a mobile
device for example. (pd stores all sample as 32 bit float
internally)

playing with readsf~ should work, but it might be necessary to
preload the beginnings of the samples into memory,
and crossfade after the first 64 ms or so. this might be worth the
effort if you want to quickly switch between sounds in a huge library,
without any interruptions of audio output.

http://en.wikipedia.org/wiki/Dataflow_programming

this kind of pianoroll is rather easy to make: basically use some (16, 32,whatever)
vradios and connect these to [float]s or [tabwrites], and use a counter and a select to play the stored float values, or a table and a counter + tabread
(like in the video). you could also use a table/array directly,
or sliders instead of vradios. you can change the line thickness in an array
to 3 pixel, but afaik only by using an text editor to change the last nr in the
#x coords... line to 1. for more sophisticated sequencers i would recommend data structures. there is a 'proof of concept'-pinaoroll on my website.

that is right, but you can do whatever you like (64->until,...) on the 64sample
(or bigger) buffer you get at bang~.