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?