yo, ignore me, if i am saying something absolutely stupid and unrelated, but isn't that exactly, what [pix_sig2pix~] and its counterpart [pix_pix2sig~] do? of course you still would have to [pix_texture] first in order to transfer the data to the gpu and then afterwards [pix_snap] it to bring it back from gpu to a pix.
audioIn~ | [pix_sig2pix~] | [pix_texture] | [doSomeStuff] | [pix_snap] | [pix_pix2sig~] | audioOut~
from my experience, doing just all this transfers is pretty slow (especially [pix_snap], as others already mentioned)
roman
On Sat, 2007-11-10 at 13:59 -0500, vade wrote:
Max MSP/Jitter has bridge objects that convert from audio rate to
matrices and back, which would be needed in PD land to readback from
the GPU, and convert to an audio rate signal. Thats how this is done.
Otherwise i have no idea how you would implement souch a patch.On Nov 10, 2007, at 8:55 AM, Georg Holzmann wrote:
Hallo!
it is true that the gpu is unused most of the time and could be
used to do fast calculations, but the main output for graphicscards is the screen and reading back into ram can be slow. (of course "slow" is a relative term). I also see a problem in the different formats for
audio and images. most graphics cards are optimized for vec4 processings (4 parallel color channels). and audio...Well, there are already quite some papers/software for audio
processing on the gpu (see e.g. http://www.gpgpu.org/cgi-bin/blosxom.cgi/Audio%20and%20Signal%20Processing/i...) .But AFAIK nobody did this with pd up to now ...
LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de