using SimpleConvolution

16 views
Skip to first unread message

Karsten Gebbert

unread,
May 9, 2012, 6:19:53 PM5/9/12
to UGen++
Hey! I thought I open another subject for this to keep things
uncluttered. So here is a problem I encountered trying to instantiate
a plugin that makes use of the SimpleConvolution UGen:

Renoise LOG> VstPlugs: Trying to instantiate /home/k/lib/vst/
FFTPlug.so
Renoise LOG> VstPlugs: Instantiate FAILED (failed to open the DLL: '/
home/k/lib/vst/FFTPlug.so: undefined symbol:
_ZN4ugen17FFTEngineInternal4ifftEPfRKNS_16_DSPSplitComplexEbb') !!!

So, it looks like DSPSplitComplex is defined in FFTEngineInternal.h
if ..

#if (defined (_WIN32) || defined (_WIN64) || defined(UGEN_IPHONE) ||
defined(UGEN_ANDROID) || defined(LINUX))


.. is true, which it is and ..

#ifndef __VDSP__
typedef struct _DSPSplitComplex {
float * realp;
float * imagp;
} DSPSplitComplex;
#endif

which also applies I believe (I'm assuming this is a fallback for some
data type thats only available on the mac, correct?)

So I wonder how come isn't nowhere to be found and whats a possible
workaround? Any ideas?

cheers!

k

Karsten Gebbert

unread,
May 9, 2012, 6:24:13 PM5/9/12
to UGen++
ah fyi: in order to actually get this to compile I had to make the
following small amendment in UGen.h so the includes get picked up:

inux [master●] % git diff ../../Source/UGen/UGen.h
iff --git a/Source/UGen/UGen.h b/Source/UGen/UGen.h
ndex 3e53cf5..90f9f10 100644
-- a/Source/UGen/UGen.h
++ b/Source/UGen/UGen.h
@ -212,6 +212,11 @@ BEGIN_UGEN_NAMESPACE
#endif
#endif

#ifdef UGEN_CONVOLUTION && defined(LINUX)
#include "convolution/ugen_Convolution.h"
#include "convolution/ugen_SimpleConvolution.h"
#endif

#ifdef UGEN_IPHONE
// include these on the iPhone even if we're using Juce
#include "iphone/ugen_NSUtilities.h"

not entirely sure this is appropriate, but it works for now ;)

On 10 Mai, 00:19, Karsten Gebbert <karsten.gebb...@googlemail.com>
wrote:

Martin Robinson

unread,
May 10, 2012, 2:20:33 AM5/10/12
to uge...@googlegroups.com
Yes DSPSplitComplex is an Apple structure but it is just a wrapper for two pointers to the real/imag parts. Yes that #if looks correct.

Martin

Martin Robinson

unread,
May 10, 2012, 2:31:45 AM5/10/12
to uge...@googlegroups.com
Yes I see. There will need to be a whole bunch of "defined(LINUX)" checks. I'll take a look at your patches.

Thanks!
Martin

Karsten Gebbert

unread,
May 10, 2012, 6:08:01 PM5/10/12
to UGen++
hm what kind of workaround would you suggest here? I'm a bit confused
as to how to circumvent this, since the struct is defined otherwise it
wouldn't build at all.

Martin Robinson

unread,
May 13, 2012, 10:10:54 AM5/13/12
to uge...@googlegroups.com
Ah, OK. Looking at that name-mangled missing symbol it's a function it can't find rather than the structure def:
>> _ZN4ugen17FFTEngineInternal4ifftEPfRKNS_16_DSPSplitComplexEbb

I'm no expert on name mangling especially on different compilers but.. It would be something like:
ugen::FFTEngineInternal::ifft()

The two b's on the end are probably bools so it's likely to be the function:
void ifft(float* const outputBuffer, DSPSplitComplex const& inputBuffer, const bool applyWindow, const bool applyScaling) throw();

..that it can't find. That should be defined in ugen_FFTEngineInternal.cpp and I can't see any #if etc directives that would prevent it from being compiled on Linux..

Does that make sense?

Martin

Martin Robinson

unread,
May 14, 2012, 5:58:17 AM5/14/12
to uge...@googlegroups.com
Yes it is that one using the c++filt tool:
c++filt -n _ZN4ugen17FFTEngineInternal4ifftEPfRKNS_16_DSPSplitComplexEbb

..gives:
ugen::FFTEngineInternal::ifft(float*, ugen::_DSPSplitComplex const&, bool, bool)

Still not sure why it wouldn't be defined in the .o file..

Martin

Karsten Gebbert

unread,
May 15, 2012, 6:04:52 PM5/15/12
to UGen++
yeah, I can see this too. using nm on the binary I get this:

Linux [master●] % nm build/FFTPlug.so | grep
DSP
0000000000529c4b W
_ZN4ugen10MultAndAddERNS_16_DSPSplitComplexES1_S1_i
00000000005299c4 W
_ZN4ugen17FFTEngineInternal3fftERNS_16_DSPSplitComplexEPKf
U
_ZN4ugen17FFTEngineInternal3fftERNS_16_DSPSplitComplexEPKfb
0000000000529ade W
_ZN4ugen17FFTEngineInternal4ifftEPfRKNS_16_DSPSplitComplexE
U
_ZN4ugen17FFTEngineInternal4ifftEPfRKNS_16_DSPSplitComplexEbb

U means undefined, according to the man page. I guess this means the
problems also exists for the fft member.

I've been reading around a bit about this, also because I'm not fluent
in C/C++ yet but it seems this problem occurs because the library
containing the implementation, in this case apples vDSP, is missing?
Or is there something about how to typdef struct that I simply
overlook or don't know? most likely :)

Too tired to go deeper, but will keep digging
k

Karsten Gebbert

unread,
May 15, 2012, 6:23:14 PM5/15/12
to UGen++
ah a more readable output:

U
ugen::FFTEngineInternal::rawToRealImagUnpackedSplit(ugen::Buffer
const&, int, int)
00000000005299c4 W
ugen::FFTEngineInternal::fft(ugen::_DSPSplitComplex&, float
const*)
U
ugen::FFTEngineInternal::fft(ugen::_DSPSplitComplex&, float const*,
bool)
0000000000529ade W ugen::FFTEngineInternal::ifft(float*,
ugen::_DSPSplitComplex const&)
U ugen::FFTEngineInternal::ifft(float*,
ugen::_DSPSplitComplex const&, bool, bool)
0000000000551730 T
ugen::FFTEngine::rawToRealImagUnpackedSplit(ugen::Buffer const&, int,
int)

hmm wait does it have something to do with how the member was
defined?


On 16 Mai, 00:04, Karsten Gebbert <karsten.gebb...@googlemail.com>
wrote:
> yeah, I can see this too. using nm on the bi nary I get this:
Reply all
Reply to author
Forward
0 new messages