I too noticed some glitches sometimes, but I feel it could be something by the editor!
I’ll profile tomorrow to see what I can discover.
But we should test in build and see if they happen there too.
BTW do you know I never did a test build? neither desktop nor mobile? 
CsoundUnity Package (UPM) development
Never have I, well not with this version… 
Ok I’ll start testing on builds!
I made a build for macOS.
I had to remove the async method GetOpcodeListAsync(), even with preprocessor directives it wasn’t building.
Without it it worked.
But!
The Csound framework is still not copied in the app. So there’s still need for some postprocess action to copy that into the build.
I think that if we can we should do a test with a .bundle, instead of a .framework.
Unity docs talk explicitly about bundles, and not frameworks:
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. For further information on loose C++ plug-ins see documentation on C++ source code plugins for IL2CPP.To create the bundle project with XCode, open XCode 11 and select File > New > Project
, then navigate to macOS > Framework & Library > Bundle . For more information on working with XCode see Apple’s documentation on XCode.You must build your plug-in as a universal binary that contains 64-bit architectures. Alternatively, you can provide separate dylib files. If you are using C++ ( .cpp ) or Objective-C ( .mm ) to implement the plug-in then you must make sure you declare the functions with C linkage to avoid name mangling issues.
Interestingly we are in the “Alternatively” section, since we provide separate dylib files. But then why Unity is not copying those??
But apart from this problem, the CsoundUnityChild is working, and so also no need to copy csds around!
I’ll do more tests later on macOS.
Now I’ll try to build on Windows!
Are you getting any clicks or dropouts in your audio when you test the Child stuff? I have a simple scene where I move between two children, and I’m getting a audio issues…
No audio issue in build, except from a little noise on start (plays abruptly without any fade)
Didn’t try moving anything, though
I’m trying hard to keep things in their appropriate threads, but my child audio channels don’t update when I update my .csd file? Is that simply because FileWatcher is disabled?
Yes better to stick to this thread
Yes! Restore it decommenting the three lines in CsoundFileWatcher constructor
Look here, maybe it’s better using Time.realTimeSinceStartup
I think the dspTime is only updated at the start of each audio buffer, which might explains the jumps? But a quick test shows me that the master and children are perfectly in sync.
I’m going to add a few more sources now and see if the audio gets much worse. I’m having to use a BT speaker, I wonder is that an issue?
In editor BT works, I use BT headphones, in build it should, but for example on Android it doesn’t
This thread is somewhat funny, they have a similar problem:
https://forum.unity.com/threads/clarification-on-the-unity-dsp-timestamp.678118/
Trying your sample, first problem is that the csd asset is not saved! I thought this was working 
It’s missing from the json?
Ok I added it. Another issue is that also scripts lose their references! Looking into this
Unfortunately I hear audio issues too, very ugly!
It’s the doppler effect that causes the problems! Setting it to zero solves entirely!
(i did some more tests)
Ah good spot! At least that’s something to work with…
About the build issue on macOS.
Thanks to ceberman I know that copying the .framework at the right position does the trick, so for now we have to copy the CsoundLib64.framework in the .app at: Contents/Frameworks/MonoEnbedRuntime/osx/
and renaming it libCsoundLib64.framework
This is not the case when user is generating an XCode project: in that case the framework has to be added in the project frameworks
Hope to find some easy way to do this in a PostProcessBuild script!
And hope it’s not something like this:
https://forum.unity.com/threads/postprocessbuildplayer-build-options-frameworks.141657/#post-979493
The closer we get here the more frustrating I grow about the fact that it’s so easy to kill Unity if one has an issue in their Csound code 
It’s pretty brutal…
Yes it’s sadly true!
I was thinking we could add some check in the OnAudioFilterRead that warns the user if the sample is far above 1.0, to avoid exploding ears 
That doesn’t bother me too much. (oh btw, we have to be very careful that we use 0dbfs to scale all our samples, I don’t think we are doing this in all our audio methods?).
What really gets me is that as soon as I try to access a table, or a value from a table that doesn’t exist, Unity crashes hard.
Yes, maybe we could add some check on the methods that use pointers, but I really don’t know how! Of course checking for a zero pointer could be easy, but of course it’s not enough!
