the goal is to come up with a very fast convolution algorithm, in
real-time. i'd like to use pd because it has very useful DSP and the ability to make somewhat of a useable interface. it's not as clean as a GUI done using C++ libraries, but it'll work fine for my purposes. right now my impulse responses are 200 samples long, but later on i need to implement longer floor/wall reflections. add to this head tracking and GEM to display it all in beautiful 3-D. at the moment i'm stuck trying to figure out the DSP details of pd, which puts all the other things on the backburner. i guess that's it. oh yeah on the side i'm sorta working on a project that will be a great demonstration of pd. it'll be aimed at computer science & music academically-oriented people.
i learned just the basics of csound in an electronic music class,
but i think pd is much more useful and can do a better presentation of synthesis to students. that's not exactly my department though; the main thing i'm trying to do is replace expensive hardware DSPs with a good software version. it'll be cool when it's done :) i'll be sure to post it to the list, put it on an ftp, or put it in the external vault.
scott
On Wed, 4 Sep 2002, marius schebella wrote:
scotty, beam me up a little! you can have the convolution process on two given audio wave-files, thats one thing, but also on streaming data. and the fft-windows can be smaller than the samples or bigger (twice as big, if you like.) it is like a reverb: you can wait until the reverberation of a soundfile is finished or just play and play... the first method could make sense if you have very long and complex wavefiles to have a clean special effect without any glitches or loops. the problem with this method is the handling of large files and a lot of cpu is needed. this cannot be done in realtime, because you only can listen to the sound, if the calculation has finished, but of course it can be done in pd... with the other method you split the wave files in slices and convolute always small parts. this is something different. after the convolution they are put together again. hmm, can you explain again, what you want to do, which sounds to use, ...? marius.
----- Original Message ----- From: "J. Scott Hildebrand" jshildebrand@ucdavis.edu To: zmoelnig@iem.at Cc: "J. Scott Hildebrand" jshildebrand@ucdavis.edu; pd-dev@iem.kug.ac.at Sent: Tuesday, September 03, 2002 9:08 PM Subject: Re: [PD-dev] i need some help with this
i wouldn't mind at all to do the convolution with the built-in fftstuff. the only problem is that i don't quite understand how it works. what i need is to input x amount of samples, and get out y amount of output, which should be at least 1.5 times the original amount + padded zeros to equal 2 times the original amount. only then can i write an overlap and add method.
scottOn Sat, 31 Aug 2002 zmoelnig@iem.at wrote:
hi scott !
i really recommend that you read the mail i send you when qou first
posted your
piece of code. i really tried to point out all the faulty pieces of code (especially
the
neveroccuring reset of apple) and i again give you one advice: add debugging code like "post()" to
show you
where the error occurs !
i am not going to do the programming for you (and i hope no one else
will do)
- just read the mails. (it's all in there)
and again: is there any major reason not to do the convolution as an abstraction ? to not use pd's built in fft-routines ?
mfg.cd.sar IOhannes
"640K ought to be enough for anybody." -- Bill Gates, 1981
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
"640K ought to be enough for anybody." -- Bill Gates, 1981