Cabbage Logo
Back to Cabbage Site

Opcodes not getting linked correctly at runtime (CsoundUnity, macOS)

Hiya guys, so I’ve been chatting to Rory about this and he recommended I post here, so I’m having this issue with using Plugin opcodes in CsoundUnity, on windows it’s all fine, but on OSX it seems to be having trouble finding the plugin ops. I did some experimentation, and if you change line 62 in CsoundUnityBridge to
Csound6.NativeMethods.csoundSetGlobalEnv("OPCODE6DIR64", "/absolutePathToOpcodes64");
it loads them, so at some point in that function call it looks like the path is going wrong, obviously I can’t use absolute paths as a fix, wondering if anyone else had experienced this or found anything with it!
(I’m testing with libfluidOpcodes.dylib)

Yes this is known (also on Windows there are problems loading plugins).
This should be solved using the new API setOpcodeDir:

I’m having a look. The path should be correct, it’s created like this:

var opcodePath = Path.GetFullPath(Path.Combine(csoundDir, "CsoundLib64.framework/Resources/Opcodes64")); 

where csoundDir is:

string dataPath = Path.GetFullPath(Path.Combine("Packages", packageName, "Runtime"));

        dataPath = Path.Combine(dataPath, "Win64"); // Csound plugin libraries in Windows Editor
        dataPath = Path.Combine(dataPath, "macOS");

What I don’t like is that the GetFullPath method is called twice, but can this be the problem?

1 Like

Sorry for the delay in me testing this my mac harddrive just went (again) so i’m having to make a ubuntu drive to get the important files off it and then reinstall OSX, waiting to test over teamviewer!

The API is not in the macOS .framework yet, we should use a newest one…
Notice there are still problems when building, the .framework isn’t copied at all in the final macOS .app

A new build for Csound can be found here for OSX, note this is extremely minimal!

I tried to update the .framework in Unity, it’s Importing Assets since 15 minutes, I think it’s stuck in some weird loop with the Resources link!

Ok, good to know. I wonder can we simply copy over the relevant binaries into the existing package?

What’s really strange is that trying to load opcodes using the command line flag --opcode-lib= also fails. I can’t see why that is. For example, the following fails to find libfluidOpcodes:

-n --opcode-lib=/Users/walshr/Documents/libfluidOpcodes.dylib
sr 	= 	44100 
ksmps 	= 	64
nchnls 	= 	2
0dbfs	=	1 

giEngine fluidEngine

the example works outside of CsoundUnity as well, because on Windows it looks in Runtime/Windows for plugin dlls, could it be that it automatically prepends something to the opcode-lib path?

On this I was getting the same, was trying the version of CsoundLib64.framework I installed via homebrew and it crashed every time I tried to open it…

On Windows one can set opcode dir using system envs. Syl, did you test that new build of Csound from the command line? If so, does the opcode-dir command line flag work there?

So just getting back to this, exposing csoundSetOpcodedir from the dll, and making a static function in CsoundUnity bridge to interface with it, then calling it from the screenshot in CsoundUnity.Awake() SEEMS to work on windows (lets me use fluidEngine without shouting at me provided its in the Win64 dir), about to test it on another system to make sure it wasn’t a fluke

Nice one. Hopefully it works Ok for you on other systems.

Is the SetEnvironmentVariable call specifically for opcodes or is it a v bad idea to comment it out?

To be honest, I can’t remember. It might be for the Csound library? @giovannibedetti? Do you remember? I can’t recall how Unity knows that it should look in the runtime folder in the package?

Instant crash hahahhahahah AAAAAAAA

Ok, better leave that in then! :laughing:

it apparently crashes instantly regardless of that line on the system hahah

Probably that part about the EnvironmentVariable should be removed, because for example on Android it doesn’t make sense.
The libs in the folder Plugins should be enough, we have to understand why they are not loaded for macOS (probably because it’s not a .bundle) and Android. Still we haven’t tried on iOS.
I asked some questions on the unity forum, someone added an answer recently that seems useful.
But please, tell me: which was the branch we were using recently? dev2 or develop? :sweat_smile:
There could be a chance that I’ll have some time to work on it in 2-3 weeks, and also that CsoundUnity will be used in a big AR project (so iOS and Android) starting next year!
So it has to be in good shape!! :crossed_fingers:

I think the develop branch is the one that we’ve been pushing to. :+1: Your project sounds interesting. Do you have any more details?