Sorry, I only just realised that you made some edits to your post. I only get notifications on replies.
I’m kind of stuck in other things right now, but if you keep working away on this so that it works fine for Android and Windows I can jump on board and help with the OSX issues?
No problem!
I finally made some advancements on Windows, now it works on editor too, thanks to the advice of a generous coder from the Unity forum. It was just a folder structure problem!
I also created an XCode project to build a .bundle of Csound for macOS, it should work, but I cannot build it because I have no developer account
If you can build it, I can send it to you so that we can have a try with a .bundle instead of a .framework.
Ok, hang on though, why do we need to build a bundle? I’m a little hesitant to involve building binaries unless absolutely necessary as it makes the project much harder to maintain. I don’t like the idea of maintaining a custom build of Csound either. I’ve been down that road before, and it’s a real pain. Sorry, for being so slow on the uptake here, but can you explain why do we need to build a plugin?
macOS plug-ins
You can deploy macOS plug-ins as bundles or…
But it also states:
You must build your plug-in as a universal binary that contains 64-bit architectures. Alternatively, you can provide separate dylib files.
I don’t have enough experience on macOS to know clearly what to do.
To test the repo it is sufficient to open the TestScene. You should hear a 440 sine tone on Play.
It works when built on Windows and Android too (the Hector scripts are there)
What I am going to do now is create a way to load examples from the package. And maybe avoid using the StreamingAssets folder to contain the CsoundFiles?
But this is for native Unity plugins, not external 3rd party libraries?
But we’re not building any plugins in this instance? We are simply putting together a variety of c# scripts and packing them all together?
Great. I’ll try now on OSX and see if I can help at all.
For now, on Windows, is the streaming assets folder only needed now for the .csd files? From your package structure it look likes Csound now sits inside a runtime folder and no longer needs to be in StreamingAssets? If so, nice work
No luck here. I’m getting quite a lot of missing script errors? It can’t even find CsoundUnity in the example scene? Should there not be a Scripts folder somewhere?
Ok this answers a lot of my questions, I’m not familiar with macOS frameworks, and assumed it was a native plugin, since it has an executable (CsoundLib64) and dylibs inside the .framework (that Unity treats simply as a folder)
Of course! No plugin building
Yes now the StreamingAssets is needed to contain the csd files, scripts and libraries sit inside the Csound Unity package
What version of Unity are you on? It should work without any other script or file except of the TestCsound.csd file in the StreamingAssets folder. If needed I can send you a zip of the macOS project, but it’s the same you can find on GitHub!
Can you see a folder Csound Unity inside the Packages, in the Unity Editor?
Might be best to send me the zip as I’m missing files. Btw, I’m using a version older than yours, but I don’t think it should make a difference. It’s 2019.2.11f
Looks like I’ll need to install the latest version of Unity after all. I’m getting an error about this packages being serialized with a newer version than the one I have. It would be nice to be able to avoid that. Otherwise we force everyone to use the same version we do…?
Yes they changed something from 2019.2 to 2019.3, but I was able to recreate the library editing the manifest.json file inside the Packages folder. The ugui package seems to create problems. I’m removing it from the git repo.
Package Manager: Added support for Asset Store packages in the Package Manager UI with the new My Assets filter.
Package Manager: Added the ability to add a package from a tarball in the Package Manager window.
Package Manager: Asset Store packages are now visible in the Package Manager UI through the new My Assets filter.
Package Manager: Enabled UI support for Git package installation in the Package Manager window.
Theoretically the package should be portable until 2017.2 (when Package Manager came across).
Before that version, it could be shipped like it is right now, the changes in the code should be very little.
I’m set up now. I can run this scene in the editor without Csound installed. So is the problem when one tries to export a build? I didn’t have time to try that. I have to leave this for a bit but I will check back in later
It works because it grabs the installed Csound!
If you try to rename the CsoundLib64.framework inside Library/Frameworks you will have the DllNotFoundException.
At least this is true for me on 10.13.3
BTW I’ll create a repo with just the package, with no Unity project, so distributing should be simpler.
Don’t tell me
I don’t know… don’t touch it if it works!
Don’t worry if you have no time right now. I’m really happy to help with this project, it was on my todo list for a long time. I now have time for another week to complete the Android demos.
I’ll let you know!
EDIT: did you try closing Unity after renaming the CsoundLib64.framework? I suspect it hasn’t been unloaded
Click Add. The package will be imported in your project! (Close the Package Manager window or it seems to do nothing)
Right now the csd files still have to be inside:
So I have it running with the included Csound, when I run in the editor. And I don’t need a streaming assets folder for the Csound files. But when I export as a standalone build I get nothing. What’s odd is I don’t even get any errors in my console log? Strange…
[edit] it’s not all that strange in fact, considering nothing of the CsoundUnity package is bundled into the resulting TestScene.app. Is there some kind of magic command to get Unity to include Package stuff in the export standalone?
[edit] enabling dev build helps me at least see the problem, which is obviously that it can’t find Csound…