After lots of attempts and trial and errors, I finally got Spectrum working with FMOD 5, except for one issue:
The following call fails when running on 32bit:
If CallFunction(*FModExDLL, “FMOD_ChannelGroup_AddDSP”, *hMasterChannelGroup, #FMOD_CHANNELCONTROL_DSP_HEAD, *FMOD_hDSP, 0) = 0
Invalid memory access. (write error at address 0)
Parameters look good, passing some pointers for the last parameter (which is optional) does not work either.
Anyone any idea
Ok. Updated a bit for backward compatibility. Now the FFT works fine with fmod 5 / studio lowlevel api:
1.01.00 up to 1.09.06 on 64bit
1.01.00 up to 1.03.26 (the latest from 1.03) on 32bit
The crash happens with 1.04.00 and later on 32bit.
BTW, for some reason after setting the FFT parameters, the first calls for spectrum data returns spectrum data with 0 channels / window size of 0 (and crashes when trying to access the data)
BTW, When paused (single song loaded), my player still shows the latest spectrum… an issue similar to older FMOD Ex versions.
Hi, Have you got a line of C++ or C that shows your issue? I’m not sure what your callfunction is, or even the language.
The fft dsp has to run in the mixer (which ticks every 10ms or so) so if you try and retrieve data immediately it will not have any data.
If you pause a node that is a parent of the fft dsp, then it will not process that dsp.
You should have the dsp higher up in the hierarchy in that case, so it is not deactivated.
Hi, Have you got a line of C++ or C that shows your issue? I’m not sure what your callfunction is, or even the language.
It’s written in PureBasic. callfunction is used to call the function within the dll. I load the fmod dll dynamically, so my Player can handle errors trying to load the dll, and give some more usefull information. Useful as the Player supports different sound systems / layers. But a bit more coding.
Guess in C/C++ it should be something like:
If (FMOD_ChannelGroup_AddDSP(hMasterChannelGroup, FMOD_CHANNELCONTROL_DSP_HEAD, FMOD_hDSP, NULL) = FMOD_OK)
as I said, the code runs with older 32bit FMOD Versions, and all 64bit FMOD Versions.
The fft dsp has to run in the mixer (which ticks every 10ms or so) so if you try and retrieve data immediately it will not have any data.
Makes sense. Wish I knew when writing / debugging my code. And lot’s of other things I wish I knew back then.
If you pause a node that is a parent of the fft dsp, then it will not process that dsp.
Actually, I only pause the song, not the Master channel group, or any DSP stuff. It’s not a issue, just looks a bit odd.
can you reproduce this issue in C? Its very likely its the purebasic wrapper that’s at fault.
The song being caused can make sense, if its the only signal in the whole system. The stopped song makes the tree go ‘idle’ and the fft probably stopped processing. It should really be cooling down and setting everything to zero, if it encounters an idle signal, so that’s something we can look into.
Ok. Somehow managed to get the example working with codeblocks. C/C++ is such a disaster 
Once including the DSP init stuff, the compiler complained about incorrect number of parameter… yeha!
At least I mustn’t post my c/c++ code
the API once was (e.g. 1.01.03)
FMOD_RESULT FMOD_ChannelGroup_AddDSP(
FMOD_CHANNELGROUP * channelgroup,
int index,
FMOD_DSP * dsp,
FMOD_DSPCONNECTION ** dspconnection
);
and changed to (latest versions)
FMOD_RESULT FMOD_ChannelGroup_AddDSP(
FMOD_CHANNELGROUP *channelgroup,
int index,
FMOD_DSP *dsp
);
oO. Looks good so far, just gotta find out with which FMOD version the API changed, so I can handle it properly for all versions.
Many thanks for your time and help.
that would do it. with 1.xx.yy format, only .yy versions are API compatible. xx versions can have API changes, which are listed in revision.txt