I’m having some slight issues with my Unity build, Im on osx. When running in unity, my audio needs to be either the full path “/users…”, or similarly I can use the
SPath chnget “AudioPath”
SAudioFile sprintf “%s/StemDMStrings_44.wav”, Path
SDatL sprintf “%s/CIPIC165l44100.dat”, SPath
SDatR sprintf “%s/CIPIC165r44100.dat”, SPath
(the audio files that the instruments are playing back, and .dat files for the hrtfearly and hrtfreverb opcodes are stored in Assets/Audio in my unity folder.)
My sound will be played when running/play testing in unity, with either method.
However when I build this, with the full path address build the audio will play on the original computer I’ve built the game on, but not a second mac or other machine, rest of the game is running fine.
When i use the chnget “AudioPath” method, sound doesn’t play on either machines. I feel like I’m perhaps making a silly mistake somewhere, any chance you know where I’m messing this up?
Hi Thom. I’ve not actually got around to testing this for standalone builds (I hang my head in shame). There are a few nice plugins that let you print debug info to the screen in standalone mode. If you have time, I’d suggested installing one and checking what paths are returned. You can probably hack the C# code accordingly. Otherwise I can try to give it a whirl on Monday and push a fix.
Hey Rory,
Thanks for the quick reply, I’ll look into the debug plug-ins,
in the mean time, just in case it might help diagnostics
1.I’ve checked the player.log, and the standalone seems to be spitting out errors
like this
“Fallback handler could not load library /Users/thomstc/Desktop/Virtual Installation.app/Contents/Frameworks/MonoEmbedRuntime/osx/CsoundUnity”
and variations like that all related to csound.
2.I checked the Profiler window when building the standalone in developer mode, and it doesn’t seem to be using any of the audio channels at all.
3.If I right click the build to view the package contents, it seems to be missing my audio and dat files, would this be because they are being deemed invalid in compile because they aren’t liked to an AudioClip? Is there a way to force the build to include the Assets/Audio folder?
I’m not sure why it’s not bundling your data. It will however bundle everything that you place in the streaming assets folder. That night be the way to go. Look at the Csound unity source to see how you can easily get the path to that folder. I’ll take a look tomorrow afternoon. I should have a little time then.
hey there - just to give my experience, since i’m one of the few more or less actively using CsoundUnity on this forum - i built my app eventually on Windows, not Mac (i’m using a Vive), but sticking everything under StreamingAssets folder was my solution, since i was loading SF2 files into my project. outside of that i had some settings files i had to manually copy to the Data folder afterwards (PC builds have two files, an executable and a Data folder) in order for them to work properly. you may be able to manually copy files into the folders under your app build, though i imagine if i’d just used StreamingAssets for everything i would have had no issues at all.
I just looked into this now. Scott is right. The best approach is to put everything into the streaming assets folder. I’ve added a new reserved channel called “StreamingAssets” that will retrieve the path to this folder. My simple .csd to test looks like this:
All files open fine now. You can grab the latest CsoundUnity.cs file from here, or you can simply add this line yourself to it:
I guess Unity wraps up all Audio files in its own way, which make their paths inaccessible in standalone builds. The annoying thing about this approach is that you can’t audition sounds as you would from the Audio folder.
If one placed all audio files to be played by Csound into a sub-folder within the audio folder, I could write a script that would automatically copy the contents of
that folder to the streaming data folder when a standalone build is made. The “AudioPath” channel would return “…/Audio/CsoundAudio” when running in editor mode, and “…/StreamingAssets/CsoundAudio” when running in standalone mode. This would means users
still get to treat audio being read by Csound in the same way as any audio
don’t have to do any work with paths when it comes to standalone builds
This looks great, I’ll give it a bash tonight. The streaming assets is a solid work around, I’d tried to do something similar to this last night but couldn’t get it to work, couldn’t get the Application.streamingAssetsPath to pass the relevant information. Think I was just over tired.
I think I should be able to get it sorted. Just having an issue with copying files over from one dir to the other during the build process but I had to leave the office so I couldn’t get it done. I’ll try to finish something tomorrow. In the meantime you have a work around. I hear you completed your research programme. Congrats, no you can spend your time playing with Csound and Unity
I just pushed through some new code which should make life easier. Although everything will still work as it did before, I’d now recommend using a folder called Assets/CsoundFiles to hold all files Csound will be reading. These can be anything from audio files to text files. All files in this folder can be accessed using the CsoundFiles channel, e.g.,
When you create a standalone build of your game, the PreBuildScript.cs will copy all the files from this folder to the StreamingAssets folder. It will also update the CsoundFiles channel so it now points to the new location of the files. If you work with an Assets/CsoundFiles folder you won’t need to do anything when creating a standalone.
I’d like to get Unity to exclude the Assets/CsoundFiles folder when building but I haven’t managed to do that. Although Unity will try to compress everything in this folder when it creates a standalone, we don’t need any of it. It just takes up space. The only solution I found thus far was to create a standalone from the command line. If users are creating scenes with lots and lots of audio files specifically for Csound this would be a better approach.
I’ll update the docs now to reflect this new addition.
[edit] I just realised that the .csd files are in a folder called CsoundFiles too. Anyone have any objections if I changed this folder name to CsoundInstruments?
First, thanks for this excellent CsoundUnity software.
I wanted to reach out with a potentially related issue i am having with deploying a build onto a mac system, and wondering if someone on the forum could help. The symptom is that in the deployed application Csound does not start, and therefore no music/sound. Here is some background
running Unity version 2017.1.1f1 personal, and building to target Mac-standalone
for diagnosis, I’m using the CsoundUnityDemos.unitypackage, but the results with my app are the same
the target MacOS machine does not have Csound installed. This might seem obvious, but the problem does not occur on my dev machine where i do have Csound installed. This problem may not be visible if the system default installation kicks in.
I have applied the most recent version of CsoundUnity.cs as mentioned above. (although I didn’t really expect this to affect shared library loading)
Looking at the Player.Log, Unity appears to be looking for the directory structure:
Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets/
While the actual deployed application seems to have the structure
Contents/Resources/Data/Resources/Resources
I have read that version 2017.1 may have changed the deployment directory structures, and wondering if there is a way to update the Unity build scripts
Finally here’s an excerpt from the Player.Log (there is no difference between running it off a thumb drive)
Fallback handler could not load library /Volumes/TRAVELDRIVE/SampleCsoundBuild.app/Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets/CsoundLib64.framework/CsoundLib64.dylib
Fallback handler could not load library /Volumes/TRAVELDRIVE/SampleCsoundBuild.app/Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets/CsoundLib64.framework/CsoundLib64.so
Fallback handler could not load library /Volumes/TRAVELDRIVE/SampleCsoundBuild.app/Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets/CsoundLib64.framework/CsoundLib64.bundle
Fallback handler could not load library /Volumes/TRAVELDRIVE/SampleCsoundBuild.app/Contents/Frameworks/MonoEmbedRuntime/osx/.//Assets/StreamingAssets/CsoundLib64.framework/CsoundLib64
Fallback handler could not load library
Thanks I’ll take a look. So it works when system-wide Csound is installed in Library/Frameworks, but does not work when it tries to depend on the CsoundLib.framework that ships with CsoundUnity?
It seems to be working Ok for me but I’m using 5.6.0f3 (when did they start using year numbers in the build name, am I so far behind?!). Can you try this simple project. I uninstalled Csound from my machine, and then tried it in Unity; it worked fine. Then I exported as a standalone and ran it; it works fine again. If this doesn’t work for you then something has clearly changed. You could also try installing a free unity add-on from the assets store to let you view the console log in your game. There are a few out there. I find them really useful when problems like this occur.
I will try both of your suggestions and get back to you, probably tomorrow
On the version numbers, I believe that unity has been using year.rev as version spec for about a year now, and that there have indeed been changes to the deployment directory structure
I have one more question for you, if the directories have, in fact, changed should I download source for CsoundUnity and rebuild Csound bundle? Or are the directory specifications elsewhere
I’ll have to update my version of Unity and get back to you. In my case it won’t be until Monday as my Mac is at work. But if I get a chance I’ll update my Windows version and hopefully something emerges from that.
Btw, the directories are set here and here. If you work out what they should be let me know. I really hoped they haven’t made a mess of things for us!
Hi, thanks for this information (and sorry to take so long for getting back)
The behavior of your SimpleTest.unitypackage is identical to the problem i was having yesterday with my code. The issue seems to be looking for a non-existent Contents/Frameworks/MonoEmbedRuntime/osx/lib/Assets/StreamingAssets/ directory
For better or worse, files that i have located in StreamingAssets are loading fine, so let me take a look at the code you referenced in Csound.cs and CsoundBridge.cs and see if minor changes can be made there.
Hi Rory, I don’t have a fix yet, but i just wanted to report that think i’m seeing the same issue on Windows (although i don’t yet have an Editor.Log file to share). The symptoms are the same, there is no audio if deployed on a machine without Csound installed on the system. I will continue to look at this in more detail.
To ask a really newbie question, do you (or anyone else) know how to get the Editor.Log file on Windows 10 for a deployed application? It does not seem to be stored in the \AppData\Local\Unity\Editor directory unless it is being run through the Unity editor (as opposed to a standalone build)
