[PD-dev] Trying to understand how overlap works (was: Re: myfft~.c:2:10: fatal error: fftw3.h: No such file or directory)

[Alexandros Drymonitis]

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 at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev