I'm trying to implement overlap inside an external I'm writing, so that I can apply FFT to files I read from the disk (otherwise I would just let Pd do its magic with [block~] and [inlet~]).
To understand the underlying workings of [inlet~], I have created a subpatch with [block~ 256 2], and I'm connecting the [inlet~] of this subpatch to a [print~]. On the parent patch, I'm creating an integer ramp with [line~], by computing the duration of the ramp from 0 to 256 like this: (1000 / sampling rate) * 256.
What confuses me is that the output of print is not identical every time. I'm banging the message [0, 256 $1( - where $1 is the output of the computation for the [line~] duration - and then I'm banging [print~], with [t b b]. Sometimes [print~] prints 256 for 128 times, and then it prints an integer ramp from 0 to 127, and other times it prints 256 for 192 times, and then an integer ramp from 0 to 63.
What I want to do is simulate in C what is happening inside a subpatch with overlap and windowing (with a Hanning window), before a signal is sent to an [rfft~].
In the I03.resynthesis.pd patch, I read that the "block~ object specifies vector size of 512 and overlap four. This window now computes blocks of 512 samples at intervals of 128 samples computed on the parent patch."
And also that "The inlet~ now re-uses 3/4 of the previous block, along with the 128 new samples."
I can't get my head around this to even write some pseudo-code. Can someone help me out understand and code this?
On 10/18/23 13:51, Alexandros Drymonitis wrote:
OK. Well, actually, that's what I'm doing, I'm using mayer_realfft(), but I didn't realize it is declared in m_pd.h and that I can use it straight away. I now removed the line that included d_fft_fftsg.c and the object still works. Thanks for pointing it out. I would still be grateful if someone can read the code in my previous message (just ignore the third line: #include "pd_fft.h") and see if the analysis and resynthesis is done as it should be.
On 10/18/23 13:11, IOhannes m zmoelnig wrote:
On 10/18/23 08:41, Alexandros Drymonitis wrote:
OK, it's using the d_fft_fftsg.c file instead, if not compiled with the FFTW3 library then. Got that. I made this little external, and it seems to work (with a fixed FFT size, but I don't really care for now), still I'm including the code here. I'd be grateful if someone can take a look and verify it's OK.
I have copied the d_fft_fftsg.c file to the directory of my external and renamed it to pd_fft.h, which I'm including in my file (I commented out
do not do that.
you are breeding symbol clashes and what not.
otoh, 'mayer_fft()' and friends are exported by Pd anyhow (and are declared in m_pd.h), so you can just use them.
dgfs,ma IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev