Hi Connor,
I noticed that you are still struggling with implementing the fftw lib.
I did not read all your posts in this thread in detail, but maybe my
implementation of fftw, can be of help to you.
I have recently implemented the fftw in a VST-plugin (using JUCE API).
Here is where I implement
Hey guys,
So i’ve used a typedef struct for the FFT stuff, accessing the fftbuffer with
- notation in the callback (learning lots!).
Can anyone confirm that this makes sense? It’s compiling fine, still crashing
though.
typedef struct _FFTW3{
double *fftbuffer;
int
Just realised how ridiculous my last post sounded. Mass confusion. Please
ignore. Cheers, Connor.
On 18 Jun 2015, at 18:15, Connor Gettel connorget...@me.com wrote:
Hello Everyone,
Ross, Bjorn, Danny, Richard and Bogac, Thank you for your insightful feedback
and advice with my project.
Hello Everyone,
Ross, Bjorn, Danny, Richard and Bogac, Thank you for your insightful feedback
and advice with my project. I haven’t had time to look over all the material
just yet, but i surely will over the next couple days. I’ve hit a bit wall with
one specific part of the code, this mainly
Hi Connor.
At first look when you do
in = malloc(sizeof(double));
you are allocating memory only for one double, so when you do fftbuffer++
it would access uninitialised memory.
Cant you just use the inputBuffer data buffer as the fftbuffer instead of
coying it ? If not you can just do the
Calling malloc in the callback shouldn't cause a crash on most platforms.
The problem you have is a bit more subtle and has to do with how pointers
are interpreted. If I understand what you're doing, there are a few
problems:
- in/userData isn't big enough.
oops, hit send before I was ready.
Calling malloc in the callback shouldn't cause a crash on most platforms.
The problem you have is a bit more subtle. If I understand what you're
doing, there are a few problems:
- userData isn't big enough. You want something like this (not in you
callback):
Hey Bjorn, Connor,
On 12/06/2015 1:27 AM, Bjorn Roche wrote:
The important thing is to do anything that might take an unbounded
amount of time outside your callback. For a simple FFT, the rule of
thumb might bethat all setup takes place outside the callback. For
example, as long as you do all
Dear Phil,
Just wanted to say thanks for your thorough response. It was very helpful and
raised a few questions.
When you mention driving graphic’s displays, did you mean software or hardware?
The project i’m working at the moment is based on a raspberry pi, FFT is all
conducted there, output
Ross and Conner,
It's absolutely true that each callback must respond in a certain amount of
time. The maximum execution time of each callback is something you need to
consider. Ross' language is more precise, but maybe some arm-wavy examples
will help:
- If each callback does the same amount of
When setting up the audio callback for PortAudio you can give it a void* to
some data. Set up the fft plan and set the fft object as the void*.
In the callback you can use a cast to get the fft object from the void*
Good luck
Sent from my iPhone
On 11 Jun 2015, at 16:20, Connor Gettel
If it is purely for graphic display, the interesting aspect coding-wise
will be timing, so that the display coincides closely enough with the
audio it represents. In this regard, the update rate for a running
display rarely needs to be more than 60 fps, and can often be slower -
so you would
Hello Connor,
If you just wanted to do a quick FFT and then using the spectrum to control
synthesis, then I would recommend staying in the callback. If you are doing
overlap-add then set framesPerBuffer to half your window size and combine
the current buffer with the previous buffer to feed into
You may find this article useful:
http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing
It deals with the things to do and not to do when processing audio in
realtime using callbacks.
Athos
On 11 June 2015 at 16:20, Connor Gettel connorget...@me.com wrote:
14 matches
Mail list logo
