CsoundUnity on MacOS

[ceberman]

Hi, Very happy to see all the activity on CsoundUnity/Android and looking forward to it. I wanted to see if there had been any work on MacOS recently, and verification of builds on Mojave or later.

I have just recently returned to doing builds on MacOS and I’m experiencing some issues that I didn’t have about a year ago. As I understand it, there are at least two important things that have changed in the environment since that time. The symptoms are related to trying to package an application build independent of Unity, which requires that the app work without Csound being installed on the system. I used to be able to place a copy of CsoundLib64.framework under Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets. That no longer works, I’ve spent quite a bit of time testing alternative (setting environment variables DYLD_PRINT_APIS=true DYLD_PRINT_LIBRARIES=true MONO_LOG_LEVEL=debug) to see what directories are being attempted by mono and MacOS

Unity/mono: (2019.1.14f and up), have upgraded .NET from 2.5 to 4.x and this changes mono’s behavior quite a bit.

MacOS: Mojave and beyond: One can no longer set the DYLD environment variables due to SIP (Systems Integrity Protection)

I’m continuing to work on it, but any pointers would be super-appreciated

[rorywalsh]

Thanks @ceberman, happy to have you back on board!

I’ve been using CsoundUnity on OSX of late but
bundling games as standalone is not something I’ve done there in a long time. I will take a look when I get a chance. Let me know if you get anywhere with, I’ll do the same.

[giovannibedetti]

Hi @ceberman!
I just did a build with the latest CsoundUnity code for macOS on High Sierra (10.13.3) and it works, but of course I have Csound installed.
Maybe package the app with a Csound installer would be a simple way?

[rorywalsh]

That would do trick, but it’s not as elegant. I’m sure we’ll find a solution.

[ceberman]

Thank you both for getting back to me so quickly, great to know that you’re thinking about it

The failure semantics I’m concerned about have to do with packaging an executable for others to use without having to install Csound.

MacOS 10.14 (Mojave) and up (I haven’t even tried the latest Catalina) really restrict the way the system uses shared libraries with SIP

I’m also in the process of working through some specific inconsistencies in both the way the CsoundLib64.framework file Is deployed in the build process in addition to the Path used for the shared library. I’m also seeing that if the OPCODE6DIR64 environment variable is not set in CsoundUnityBridge havoc occurs as well

Btw, it’s working fine for me on Windows (although I have to deploy libraries by hand for a stand-alone non-editor build) and still using the Android version from Henry which works well other than my sample rate/tuning problems with soundfont

I’ll get back with more findings and hopefully a procedure for hand-wiring a build (which I also had to do in previous versions

[ceberman]

In case this would be useful to anyone else, this is to summarize the hacks I’ve done to get a CsoundUnity application working when there is no system version of Csound installed. This is relevant if one is packaging the application for use on end-user computers that are not already running Csound. (You can simulate de-installing by renaming the /Library/Frameworks/CsoundLib64.framework file)

This is anything but elegant, I suspect that the robust solution (across platforms) would be to create a Unity Assembly Definition (asmdef) but I haven’t yet tried it (https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html)

Current environment:

• MacOS 10.14.6 (Mojave)
• Unity 2019.1.14f
• .NET 4.x (configured in Build Settings)
• Csound 6.0 (somewhat out of date)

Code change in CsoundCsharp.cs
elif UNITY_EDITOR_OSX || UNITY_STANDALONE_OSX
// removed the initial slash to make the reference relative
internal const string _dllVersion = “Assets/StreamingAssets/CsoundLib64.framework/CsoundLib64”;
internal const string _dllVersionCsUnity = “CsoundUnity”;
#endif

For standalone application (after running a build)

1. create directory tree in .app/Contents/Frameworks (after right clicking on .app file and selecting “Show Package Contents”):
   Contents/Frameworks/MonoEmbedRuntime/osx/libAssets/StreamingAssets
2. copy CsoundLib64.framework from Assets/StreamingAssets to the new directory

For Editor to work in this environment

1. create directory under /Library/ScriptAssemblies/libAssets/StreamingAssets
2. copy CsoundLib64.framework from Assets/StreamingAssets to the new directory

[ceberman]

One quick correction since the forum editor ate everything in my intended angle brackets

Application Step 1: should be yourAppFile.app/Contents …

Editor Step 1: should be yourProjectDirectory/Library …

Hope this helps as an interim step

[giovannibedetti]

+1 on Assembly Definitions:
I’m not sure they will solve the macOS build problem completely, but proper asmdef and namespaces will guarantee faster compilation times, add consistency and usability to the package.
Another small suggestion is to enclose all the CSoundUnity files inside a folder (maybe trying to avoid using the StreamingAssets folder), and do what is needed towards the creation of a package that can be loaded from git: Installing from a Git URL, using the Unity Package Manager

[rorywalsh]

@ceberman

This is anything but elegant, I suspect that the robust solution (across platforms) would be to create a Unity Assembly Definition (asmdef) but I haven’t yet tried it

Sounds like a good option. Unfortuntely, I’ve zero experience in this area too Thanks for these guidelines, they are super useful.

@giovannibedetti

I’m not sure they will solve the macOS build problem completely, but proper asmdef and namespaces will guarantee faster compilation times, add consistency and usability to the package.

@giovannibedetti

Another small suggestion is to enclose all the CSoundUnity files inside a folder (maybe trying to avoid using the StreamingAssets folder),

We need the StreamingAssets folder to contain Csound. And because of this, we also need to put copies of the .csd files there too. I guess we could probably avoid having to copy the .csd files there, but this was the simplest way to do it from the get go.

@giovannibedetti

and do what is needed towards the creation of a package that can be loaded from git: Installing from a Git URL, using the Unity Package Manager

The install from git option looks great. I didn’t know this was possible.

[rorywalsh]

@ceberman, what is your github username? I’d like to credit you with contributions to the project…

I updated the source and removed those forwards slashes as you suggested…

[rorywalsh]

@ceberman

For standalone application (after running a build)

1. create directory tree in .app/Contents/Frameworks (after right clicking on .app file and selecting “Show Package Contents”):
   Contents/Frameworks/MonoEmbedRuntime/osx/libAssets/StreamingAssets
2. copy CsoundLib64.framework from Assets/StreamingAssets to the new directory

I wonder could we run a post build script to do this?

[giovannibedetti]

@giovannibedetti

Another small suggestion is to enclose all the CSoundUnity files inside a folder (maybe trying to avoid using the StreamingAssets folder),

I’m writing this because when I used this wonderful package to create a generative wind system for a big VR project we were developing, my boss didn’t want to use it in the end, and told me to bounce the csd to an audiofile. This because he didn’t like the structure of the folders and the fact that there was a lot of files inside the StreamingAssets folder.
The folder structure we used was the same as the namespaces created.
I can help a bit with asmdefs, usually it is a pain to add them when the code is already there.

What about dividing the csound native functions by modules like in the Csound API?

[rorywalsh]

@giovannibedetti

my boss didn’t want to use it in the end, and told me to bounce the csd to an audiofile.

What a shame!

@giovannibedetti

This because he didn’t like the structure of the folders and the fact that there was a lot of files inside the StreamingAssets folder.

You guys have more experience with Unity than I. Can we somehow include Csound into the main source tree? The problem is that when Unity builds a standalone is does all sorts of compressing. The last time I tried I couldn’t get it to work. But that’s not to say it can’t be done. Note also, that the only file you realy need in streaming assets is csound64.dll. I’ve included the entire list of plugins dlls in the examples, but they are not needed. On OSX it’s a little more involved, but one only needs the framework.

@giovannibedetti

What about dividing the csound native functions by modules like in the Csound API?

I think I would rather have them all under the one namespace. It makes it easy to reuse code from other systems. For example, I can quite quickly reuse my JS code in Unity with only a few small tweaks.

[giovannibedetti]

I think what you did with Cabbage is something incredible, and finding this Csound package for Unity was such a joy for me!! I think the Csound community should be very proud of your work, no shame at all!!
I’m not really an expert with dlls and native code, but I’ll do what I can to make this package become the reference for generative audio on Unity!

[ceberman]

Hi Rory,

That would surely be an honor…thank you.

My github name is the same as on the forum: ceberman

[rorywalsh]

@ceberman

ceberman

Done

[giovannibedetti]

Csound Unity package development started!

(I still experienced some problems with Android + macOS so I decided to start again from scratch)
Hope to have good news soon!

[rorywalsh]

Oh nice. Let us know when you need some help testing! This is a big step forward for the project

[giovannibedetti]

I was just writing a post about some advancements: I have sound in macOS editor!
I tried to build for macOS and Android, they build, but the libs aren’t copied
Unfortunately there’s no clear documentation about including libraries in Unity Packages, I’ll write a post on the Unity forum asking for help!

EDIT:
Today I have no more sound in the editor on macOS
I always get a DllNotFoundException.
[EDIT OF THE EDIT:
it was because Unity was using the system installed Csound framework, which yesterday I renamed (as suggested by @ceberman) to test the build and see if it can work without it. So for now I need Csound installed to hear sound ]

I am going to try on Windows later, I saw that the .dll was exported in the Xcode project I generated with Unity 2019.3.7f1.

I found that on macOS the Unity docs suggest having a .bundle:

Building plug-ins for desktop platforms

macOS plug-ins
You can deploy macOS plug-ins as bundles or, if you are using IL2CPP, loose C++ files which you can use [DllImport(“__Internal”)] syntax to invoke.

What are the steps to produce a .bundle for Csound on macOS instead of the .framework we have?
Do you think it will solve my problems?

THIRD EDIT:
According to this answer on Stack Overflow when the CsoundLib64.framework has been built it could have been configured to use an install path of /Users/<user>/Library/Frameworks/, so we must change this with:
$ install_name_tool -id @executable_path/../Frameworks/CsoundLib64.framework/Csound64Lib <your_path>/CsoundLib64.framework/CsoundLib64
[4th EDIT]
I tried rebuilding Csound for macOS but I couldn’t change the path in any way, so changing the install path must be done with install_name_tool, I’m still not sure if this is needed to make everything work.

Another thing I discovered is that Unity cannot reference Native plugins in Assembly definitions through the inspector, I should find another way to do it. Still investigating.
[4th EDIT] It should be automatically referenced!

For now it seems that the only way to have a working build on macOS is to put the libs inside StreamingAssets folder, as it is copied ‘as is’ in the build.
[4th EDIT]
For sure we can write a post build script, but the Library folder contains just cached data and we cannot assume the folder will always ‘survive’ in the unity project

[giovannibedetti]

I have created a repository so that you can have a look!
It still has the problems on editor, works in build for Windows and Android, no luck on macOS yet.

giovannibedetti/CsoundUnityPackage

I am going to add a Package Resources folder to contain the examples in the form of a unitypackage (like for example TextMeshPro is doing), to separate it from the library code. I’ll add some methods to permit the user to load the examples via Editor.