I'm trying to create an external to test if I can embed [rfft~] and [rifft~] in one object. This is just a test to see if I can get this right, before I implement this to another external. I'm stripping what I think is necessary from Pd's source code, but I already get the error in the subject line.
The FFTW3 library is used by Pd, and it is #included in the d_fft_fftw.c file. I have compiled Pd myself, and no such error occurred, so, this file must be somewhere in my system. Any idea how to solve this?
On 10/17/23 08:31, Alexandros Drymonitis wrote:
The FFTW3 library is used by Pd
it's not.
, and it is #included in the d_fft_fftw.c file. I have compiled Pd myself, and no such error occurred, so, this
Pd *could* use FFTW3, but you have to be very explicit if you want to build Pd with FFTW3 (install fftw3 *and* configure Pd with `--enable-fftw`)
so in virtually all cases it uses the mayer-fft (which is built into Pd, so doesn't require any external dependencies).
file must be somewhere in my system. Any idea how to solve this?
install the fftw3 library (and headers).
gfmadsr IOhannes
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 the line that includes the m_private_utils.h file, as I got an error saying that this is a private file). All this external is trying to do is an FFT analysis and resynthesis, as it is done in the ASCII patch below:
``` [inlet~] | ________[tabreceive~ hann] [*~ ] | [rfft~] | | [rifft~] | ________[tabreceive~ hann] [*~ ] | ________[normalize_val (1 / (fft_size * 3 / 2) ( [*~ ] | [outlet~] ```
And here's the code:
``` #include <m_pd.h> #include <stdlib.h> #include "pd_fft.h"
#define FFTSIZE 1024
static t_class *myfft_tilde_class;
typedef struct _myfft_tilde { t_object obj; t_float f; t_outlet *x_out; t_sample *x_hann; t_float x_normalize; } t_myfft_tilde;
static void make_hann(t_myfft_tilde *x) { int i; float twopi = 2. * 3.14159; x->x_hann = (t_float *)getbytes(FFTSIZE*sizeof(t_float)); for (i = 0; i < FFTSIZE; i++) { x->x_hann[i] = (cos(((float)i/(float)FFTSIZE)*twopi) * -0.5) + 0.5; } }
t_int *myfft_tilde_perform(t_int *w) { int i; t_myfft_tilde *x = (t_myfft_tilde *)(w[1]); t_sample *in = (t_sample *)(w[2]); t_sample *out = (t_sample *)(w[3]); int n = (int)(w[4]);
for (i = 0; i < n; i++) in[i] *= x->x_hann[i]; mayer_realfft(n, in); mayer_realifft(n, in); for (i = 0; i < n; i++) out[i] = (in[i] * x->x_hann[i]) * x->x_normalize;
return (w+5); }
void myfft_tilde_dsp(t_myfft_tilde *x, t_signal **sp) { dsp_add(myfft_tilde_perform, 4, x, sp[0]->s_vec, sp[1]->s_vec, (t_int)sp[0]->s_n); }
void *myfft_tilde_new(t_symbol *s) { t_myfft_tilde *x = (t_myfft_tilde *)pd_new(myfft_tilde_class);
outlet_new(&x->obj, &s_signal);
make_hann(x);
x->x_normalize = 1.0 / ((1024.0 * 3.0) / 2.0);
return (void *)x; }
void myfft_tilde_free(t_myfft_tilde *x) { outlet_free(x->x_out); free(x->x_hann); }
void myfft_tilde_setup(void) { myfft_tilde_class = class_new(gensym("myfft~"), (t_newmethod)myfft_tilde_new, (t_method)myfft_tilde_free, sizeof(t_myfft_tilde), CLASS_DEFAULT, 0, 0); class_addmethod(myfft_tilde_class, (t_method)myfft_tilde_dsp, gensym("dsp"), 0); CLASS_MAINSIGNALIN(myfft_tilde_class, t_myfft_tilde, f); } ```
On 10/17/23 10:00, IOhannes m zmoelnig wrote:
On 10/17/23 08:31, Alexandros Drymonitis wrote:
The FFTW3 library is used by Pd
it's not.
, and it is #included in the d_fft_fftw.c file. I have compiled Pd myself, and no such error occurred, so, this
Pd *could* use FFTW3, but you have to be very explicit if you want to build Pd with FFTW3 (install fftw3 *and* configure Pd with `--enable-fftw`)
so in virtually all cases it uses the mayer-fft (which is built into Pd, so doesn't require any external dependencies).
file must be somewhere in my system. Any idea how to solve this?
install the fftw3 library (and headers).
gfmadsr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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
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
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
-
Alexandros Drymonitis -
IOhannes m zmoelnig