You can keep using the FMOD_FX.cpp source code, you only need to replace the function posted above.
Cabbage FMOD Android .so support
Ah, I changed it now, but it’s easy to switch.
I changed string to std::string as it wasn’t recognised.
There is now an error:
error : member access into incomplete type 'CSOUND' (aka 'CSOUND_')
Visual Studio says the type of pointer to an incomplete class (CSOUND_) isn’t allowed.
I think you need to use the AndroidCsound class. Change this line:
to:
AndroidCsound* csound;
Then this line:
to:
csound = new AndroidCsound();
You will probably get some error, for example in these API method:
csoundCreateMessageBuffer(csound, 0);
So just replace the csound there with csound->GetCsound() which will return the underlying struct. Also, I think you should be including CsoundAndroid.hpp rather than desktop version. That header should be in the CsoundAndroid pacakge in the JNI folder. But I guess try with the standard version first, and if that doesn’t work try the Android one. Sorry I can’t be more definitive about this. It is so long since I did any Csound Android stuff that I’m kind of clutching at straws a little.
No problem, I’m very happy you’re helping me with this!
For adding AndroidCsound I had to add the android header but keep the other as well. And all your straw clutchings have been right so far :). I added the ->Get whenever there was the error.
This builds also fine 
The build also gets accepted when implementing in unity (the plugin is recognised).
I thought maybe if it gets loaded, it would maybe trigger already somehow, but there has to be an event probably.
So I tried compiling it as a .dll too, which now gives new linker errors, most definitely because of csound android. So I try to revert those androidcsound changes back, which again doesn’t work with those pointers here.
csoundReturnCode = csound->CompileCsdText(csdText.c_str());
csound->Start();
Unfortunately I’m just not able to work out how to change the code here to make it work…
Does it compile?
You can probably wrap the different code in #ifdefs which should save you some hassle when switching back and forth. Do you see any
#ifdef Android
in the sample Android plugin source code?
That makes a lot of sense ^^’. But there isn’t a android plugin source code, it’s identical for both. Those have no mentioning of Android.
Yes, when i just had the androidcsound without changing it back, it compiles but doesn’t build. With the changes it doesn’t compile because of those two errors.
I also had to comment out quite a lot dirent.h and dlfcn.h aren’t found so i just commented out everything which had to do with finding the csd file…
Ah sorry ofc there are other plugins for android. I’m just so focussed on effects.
That’s fine as these methods won’t be needed.
Can you post the errors? Maybe also check the CMake files to see if they define any Android defs. It’s not a big issue, but would make building easier.
I looked into other plugins of the Android API and found no mentionings of a separate android treatment.
Those are the errors I’m getting now when changing back to CSOUND_.
(Usage of an undefined type CSOUND_) See declaration of CSOUND_.
1>D:\FMOD_API_271\FMOD Studio API Windows\api\core\examples\plugins\fmod_gain.cpp(482,27): error C2027: Verwendung des undefinierten Typs "CSOUND_"
1>C:\Program Files\Csound6_x64\include\csound\csound.h(467): message : Siehe Deklaration von "CSOUND_"
1>D:\FMOD_API_271\FMOD Studio API Windows\api\core\examples\plugins\fmod_gain.cpp(484,8): error C2027: Verwendung des undefinierten Typs "CSOUND_"
1>C:\Program Files\Csound6_x64\include\csound\csound.h(467): message : Siehe Deklaration von "CSOUND_"
When I had it back with AndroidCsound, the errors in building were those linker errors:
fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundInitialize" in Funktion ""public: int __cdecl FMODCsound::CompileCsound(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >)" (?CompileCsound@FMODCsound@@QEAAHV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)".
1>fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundCreate" in Funktion ""public: __cdecl AndroidCsound::AndroidCsound(bool)" (??0AndroidCsound@@QEAA@_N@Z)".
1>fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundLoadPlugins" in Funktion ""public: virtual int __cdecl Csound::LoadPlugins(char const *)" (?LoadPlugins@Csound@@UEAAHPEBD@Z)".
1>fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundDestroy" in Funktion ""public: virtual __cdecl AndroidCsound::~AndroidCsound(void)" (??1AndroidCsound@@UEAA@XZ)".
1>fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundGetVersion" in Funktion ""public: virtual int __cdecl Csound::GetVersion(void)" (?GetVersion@Csound@@UEAAHXZ)".
1>fmod_gain.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol "csoundGetAPIVersion" in Funktion ""public: virtual int __cdecl Csound::GetAPIVersion(void)" (?GetAPIVersion@Csound@@UEAAHXZ)".
… and so on.
It should be CSOUND, not CSOUND_
They are most likely caused because the system can’t find the Csound android library. Are you are using Cmake to generate the VS projects, or are you manually editing VS projects to get things working?
I don’t know about the difference between CSOUND and CSOUND_, it’s declared correctly above. So it has to do with the pointer which worked great when switching to AndroidCsound.
I was using the API VS projects for easily building the .dll and another project which is setup with this android tegra extension where I don’t even find out how excactly it’s working. Toolchain is clang and it maybe doesn’t use cmake and just the ndk? I’m painfully unaware what is really happening under the hood…
I’m a bit short in time today, so I’ll check tomorrow again. Thank you so much for your patience.
No worries, let me know when you get a chance to return to it.
I believe the CSOUND_ struct is private and should never be accessed directly. Always use CSOUND. Did you add the Csound android .so to your build in the Project settings?
Success!
Did other things and came back to it this evening.
Linking so files doesn’t work, but I rewrote those two lines:
csoundReturnCode = csound->CompileCsdText(csdText.c_str());
csound->Start();
to
csoundReturnCode = csoundCompileCsdText(csound, csdText.c_str());
csoundStart(csound);
This gave another linker issue. So I linked csound64.lib from the windows binaries and yes it builds and works inside fmod. Unfortunately it probably gets triggered over and over again so that the cpu quickly spikes to 100%. On the quest everything loads fine. I have no sound though but the cpu also rises until the app just crashes. But that’s probably because I’m going with the fx cpp file, which is probably updated differently?
But another step works! Now onto reading the csd files…
1 Like
I’m stuck again…
The build on android works fine. dlfcn (and dirent) is built in with the android ndk when using the tegra integration, but with the .dll I have no luck. I tried installing dlfcn but it’s not recognising the dl_open command. Do you maybe have a tip?
It’s because of DL_info and dladdr, which are using this package and I think it’s needed to dermine the filename somehow based on the own dll filename?
To be honest I’ve no idea how a .dll would ever work on Android. 
Ah it’s just so I can test the same plugin with fmodstudio or am I missing something?
The .so works fine for now, but to actually test it, i would have to have the .dll counterpart to be able to make an fmod event.
It’s now just this stupid linux/windows incompatibilty which is easily solvable if I’d knew how to make this loading code…
Or maybe I’m overlooking something and you’re already further ^^’
So my current problem is to just build your .cpp to a .dll …
I’ll figure it out somehow.
For testpurposes, I manually entered the csdfile location. This builds fine and also shows up in fmod studio but the gui isn’t updated and just shows a volume-meter.
Which totally makes sense… because all the cabbage stuff isn’t handled… sorry for being slow ^^’
But it works so far with this custom csd-path-workaround.
What game engine are you using? If you are using Unity, you need to create an Android build in Unity. This should include .so versions of the various windows dlls that you have been using. You’ll see an Android folder that contains all 3rd party plugins. There shouldn’t be any dlls in there.
You don’t have to do that, there is a dll here.
What you need to do is produce a .so from the same source which the FMOD interface can load on Android. When you have this .so it should probably go into your Unity project’s relevant folder. Than when you create your Android game Unity should bundle all the relevant pieces together. I assume you have included some scripts that call the FMOD engine within your game?