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
4 Jan
4 Jan
11:07 p.m.
On Sun, Jan 4, 2015 at 4:30 PM, Aurélien Leblond <blablack(a)gmail.com> wrote:
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!
C99 is a *C* language standard, not a C++ language standard. There seems to
be some confusion here over what language the code you're trying to compile
really is.
Is it C? Then C99 is appropriate but need a few tweaks. c++11 would not be
appropriate.
Is it C++? Then C++11 is an option but is also relatively new, and so may
or may not be appropriate. C99 is not appropriate for C++ code.
11:16 p.m.
On 4 Jan 2015 22:06, "Paul Davis" <paul(a)linuxaudiosystems.com> wrote:
> 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
to be some
confusion here over what language the code you're trying to
compile really is.
The language I'm using is c++, and the standard I have been using so far is
c++11
But I still have this problem with complex numbers, the c++11 and porting
the vocoder from Alsa Modular Synth.
On Sun, Jan 4, 2015 at 4:30 PM, Aurélien Leblond <blablack(a)gmail.com>
wrote:
- 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!
C99 is a *C* language standard, not a C++ language standard. There seems
Is it C? Then C99 is appropriate but need a few tweaks. c++11 would not
be
appropriate.
Is it C++? Then C++11 is an option but is also relatively new, and so may
or may
not be appropriate. C99 is not appropriate for C++ code.
11:19 p.m.
On Sun, Jan 4, 2015 at 4:30 PM, Aurélien Leblond <blablack(a)gmail.com>
wrote:
As
far as I can tell, you're passing the -std=c99 flags to a C++ compiler.
Make your build-system use a C compiler for said C file (generally renaming
the extension to .c instead of .cpp/.cxx is enough).
Also ensure you're passing the flags to CFLAGS and not CXXFLAGS.
Hope that fixes the warnings! Cheers, -Harry
--
http://www.openavproductions.com
> - 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!
11:43 p.m.
On Sun, Jan 04, 2015 at 10:16:05PM +0000, Aurélien Leblond wrote:
But I still have this problem with complex numbers,
the c++11 and porting
the vocoder from Alsa Modular Synth.
FFTW is a *C* library. The complex type it uses is either its own
(and array of two floats or doubles), or the C99 one if you include
the right header. C++11 doesn't accept either.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
11:37 p.m.
On Sun, Jan 04, 2015 at 09:30:16PM +0000, Aurélien Leblond wrote:
You don't modify anything fundamental when changing the FFT
to single precision float. And the modifications required can
be automated quite easily in case you ever need to repeat them.
Tschuss,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Would you know how this is handled in AMS (being c++
as well)?
Just look at the source code...
AMS includes <complex.h> before <fftw3.h>, and it compiles
without even a warning. Of course it doesn't use -std=c++11.
So just put the DSP code in a separate file and compile it
without that option.
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".
3640
days inactive
3640
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (
participants (4)
)
-
Aurélien Leblond -
Fons Adriaensen -
Harry van Haaren -
Paul Davis
-
Aurélien Leblond
-
Fons Adriaensen
-
Harry van Haaren
-
Paul Davis