Oh it looks like you were right!
It is as simple as that, so we can get rid of the CSOUND_PARAMS completely
And it works!
CsoundUnity 3.4.1 (uhm I don’t remember why I never published this as a version but I just made hotfixes on the master branch) with this patch will land soon. I will do some more testing on Android first.
In the 3.5.0 version I will add the option for the user to choose if overriding the sample rate or not.
Unfortunately there are not only good news: I can confirm the Editor Crash on Windows if you have a Csound version installed on the system that is different from the one used in CsoundUnity.
I don’t know how this can be possible (maybe plugin linking fails?), but it means that the dll is looking for stuff in the system path.
=================================================================
Managed Stacktrace:
=================================================================
at <unknown> <0xffffffff>
at NativeMethods:csoundCreate <0x000e3>
at CsoundUnityBridge:.ctor <0x00242>
at CsoundUnity:Awake <0x0081a>
at System.Object:runtime_invoke_void__this__ <0x00187>
=================================================================
Received signal SIGSEGV
I have 6.18.1 installed on the system, instead on the 3.4.0 CsoundUnity package we’re using 6.18.
If I update the dll in the package to 6.18.1 I don’t have the crash.
If I uninstall Csound from the system completely, I don’t have the crash and the Unity editor still produces Csound output as expected.
Victor told me there are no relevant changes between 6.18 and 6.18.1 but this behaviour confuses me.
This call we have in the bridge doesn’t make any difference apparently
if (Application.platform == RuntimePlatform.WindowsPlayer)
Csound6.NativeMethods.csoundSetOpcodedir(".");
Any idea?