4 Jan
2015
4 Jan
'15
10:30 p.m.
> Well all the plugins in ams.lv2 are coded in c++
and are compiled with the
> c++11 standard.
> But when ported the FFT Vocoder, it only compiles when using the c99
> standard.
C and C++ complex types are not compatible for C++,
not even if
they have the same binary representation as they will have for
all modern C++ compilers.
You can probably fix some of these errors (at least
the first
one) by including <complex.h> (not <complex>) before <fftw3.h>.
This will make fftw use the C native complex type
instead of
its own. This will allow float to complex assignment for
example.
If you really want a 'pure' C++ version you
will need to
reinterpret_cast whenever you use a function that expects
or returns a C++ complex. It won't make your code any more
readable.
IMHO the C++ complex type (a template class trying to
hide
its implementation) is completely useless and a real PITA,
and a good example of the pedantic attitude that is typical
of the C++ crowd.
Nobody with even just a minimal knowledge of scientific
computing would want to hide the implementation of complex
types - almost all classical algorithms (e.g. the FFT)
depend on it being cartesian.
What would you advise?
As far as I can see I have 2 options:
- Port the code to the c++11 standard - but you seem to think that's a bad idea
- Compile this plugin with C99 - that's the solution I have in the git
at the moment but I get the warning "cc1plus: warning: command line
option ‘-std=c99’ is valid for C/ObjC but not for C++ [enabled by
default]" and call me pedantic but I don't like warnings!
Would you know how this is handled in AMS (being c++ as well)?
I did check the code but I can't figure it out and I would like to
stay as close as possible to the actual Alsa Modular Code so it's
easier when futur modifications are applied to the code.
A second source of problems with the vocoder is the
mixing
of floats and doubles. There is no good reason to use a
double FFT here.
I actually did notice that, but again I don't want to "correct" it in
ams-lv2 because my aim here is to port "as-is".
I made the mistake of adapting the code when I ported the first set of
plugins but realised that was a mistake for maintenance when syncing
with changes in ams