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

Syl_Morrison · 22 July 2020 15:53

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)

giovannibedetti · 22 July 2020 16:21

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

github.com

csound/csound/blob/f56f9ce02000b7a1e385245ddeeb543d84df9a6c/include/csound.h#L682


 * explicitly unless you need to avoid default initilization that sets
 * signal handlers and atexit() callbacks.
 * Return value is zero on success, positive if initialisation was
 * done already, and negative on error.
 */
PUBLIC int csoundInitialize(int flags);


/**
 * Sets an opcodedir override for csoundCreate()
 */
PUBLIC void csoundSetOpcodedir(const char *s);


/**
 * Creates an instance of Csound.  Returns an opaque pointer that
 * must be passed to most Csound API functions.  The hostData
 * parameter can be NULL, or it can be a pointer to any sort of
 * data; this pointer can be accessed from the Csound instance
 * that is passed to callback routines.
 */
PUBLIC CSOUND *csoundCreate(void *hostData);

EDIT:
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"));

#if UNITY_EDITOR_WIN || UNITY_STANDALONE_WIN
        dataPath = Path.Combine(dataPath, "Win64"); // Csound plugin libraries in Windows Editor
#elif UNITY_EDITOR_OSX || UNITY_STANDALONE_OSX
        dataPath = Path.Combine(dataPath, "macOS");
#endif

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

Syl_Morrison · 22 July 2020 17:29

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!

giovannibedetti · 22 July 2020 18:21

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

rorywalsh · 22 July 2020 18:31

A new build for Csound can be found here for OSX, note this is extremely minimal!
https://dev.azure.com/rorywalsh/Csound/_build/results?buildId=693&view=results

giovannibedetti · 22 July 2020 19:08

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!

rorywalsh · 22 July 2020 19:12

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

rorywalsh · 22 July 2020 19:20

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:

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

giEngine fluidEngine

Syl_Morrison · 22 July 2020 19:52

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?

Syl_Morrison · 22 July 2020 19:53

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…

rorywalsh · 22 July 2020 21:30

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?

Syl_Morrison · 29 October 2020 19:19

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

rorywalsh · 29 October 2020 19:20

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

Syl_Morrison · 29 October 2020 19:22

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

rorywalsh · 29 October 2020 19:23

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?

Syl_Morrison · 29 October 2020 19:40

Instant crash hahahhahahah AAAAAAAA

rorywalsh · 29 October 2020 19:43

Ok, better leave that in then!

Syl_Morrison · 29 October 2020 19:43

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

giovannibedetti · 29 October 2020 22:05

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?
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!!

rorywalsh · 29 October 2020 22:28

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