But where does this libnative.so come from? Did it ship with Csound at one point?
CsoundUnity Package (UPM) development
I donāt know, it was inside Hectorās working package
I went through a few earlier Csound releases and I donāt see this library at all. I wonder did @virtualHC code it himself?
Itās here:
https://docs.unity3d.com/uploads/Examples/AndroidNativePlugin.zip
Probably he has modified the lib
Ah Ok. And when you drop that one in it doesnāt work?
It finds libcsoundandroid but crashes on the spout and spin calls. So it could point at a different version of the lib, maybe
This is with the latest CsoundAndroid libs? Iām a little confused because at one point you said Unity didnāt recognise those libraries?
If I leave the libnative.so in the Android folder, csoundandroid is found, it works but we have a crash with getspin and getspout, with the old and the newest .so files itās the same.
If I remove libnative.so it doesnāt build, saying it cannot find libcsoundandroid
Ok, that makes things a little clearer. Iāll ask on the Csound listā¦
Hi @giovannibedetti. Can you try calling csoundGetSpout() and csoundGetSpin(), just to make sure they also cause an issue? Also, Steven was wondering is this crash happens on a standard Android based phone? I guess we should try to see if itās an Occulus Quest issueā¦
Iāll try! maybe on monday, moving things around these days 
The crash happens also on a standard android phone (samsung j7 android 7)
Btw, Victor just added a really useful csoundSetOpcodeDir() API method. Csound was struggling to find the plugin opcodes on OSX when Csound is bundled into the Unity package. Now we can simply call this before creating Csound. Perfect.
1 Like
Tried GetSpin, Out Of Memory!
2020/06/22 11:43:53.951 21316 21367 Error Unity OutOfMemoryException: Out of memory
2020/06/22 11:43:53.951 21316 21367 Error Unity at (wrapper managed-to-native) System.Object.__icall_wrapper_ves_icall_array_new_specific(intptr,int)
2020/06/22 11:43:53.951 21316 21367 Error Unity at CsoundUnityBridge.GetSpin () [0x00014] in /Users/gb/CSOUND/GIT/CsoundUnityPackage/CsoundUnityPackage_DevelopmentProject/Packages/CsoundUnity/Runtime/CsoundUnityBridge.cs:490
2020/06/22 11:43:53.951 21316 21367 Error Unity at CsoundUnity.GetSpin () [0x00001] in /Users/gb/CSOUND/GIT/CsoundUnityPackage/CsoundUnityPackage_DevelopmentProject/Packages/CsoundUnity/Runtime/CsoundUnity.cs:693
2020/06/22 11:43:53.951 21316 21367 Error Unity at TestCsound.Start () [0x0000d] in /Users/gb/CSOUND/GIT/CsoundUnityPackage/CsoundUnityPackage_DevelopmentProject/Assets/TestCsound.cs:23
Steven was pretty busy the last time I asked. I will reach out again in a few days. Iām taking a few days off myself at the moment. It was a crazy few months! I should get back to it later in the week 
No hurry, I was just very curious to make it work on my new Quest
Enjoy your days off!
1 Like
I am doing some profiling on the Editor with a big csd (our friend ToneZ) and I can confirm that the performance drop is insane while moving any slider, have a look at these screenshots:
So the more control channels, the more the performance drops.
Also notice the memory increase.
All of these GC.Alloc could be a boxing/unboxing issue, but I donāt know how to tackle it.
Any ideas?
EDIT:
The drop happens also when just scrolling the inspector with mouse wheel:
Is DrawChannelControllers() being called continuously? It looks like all controls in m_channelControllers are being checked all the time? If there are 100s of controls, this is going to be very slow right? Is it not possible to register a callback for each controls, that will only be triggered when it has changed?
Yes it is called as soon as there is any interaction with CsoundUnity in the Editor (even just moving the mouse when the CsoundUnity inspector is visible)
I will try to look for ways to reduce the calls. Didnāt find anything yet.
One trick could be creating inspector foldable sections from Cabbage groupboxes, but we should rethink a bit the parsing code.
Yikes. Thatās going to get extremely slow for a .csd like this one.
I hope we find a better solution than this. Iāve done some reading myself and I canāt see any way of registering callbacks for these EditorGUI controls. On the other hands, it looks like callbacks can be registered for on-screen UI components 
Would it make more sense to have an in-game user interface that can be quickly enabled/disabled?
What I read around is that this behaviour is expected with inspectors with lots of controls.
I think we have to transition to the new UIElements ( New feature in 2018.3), but then we lose the backwards compatibility.
From the Unity forum, in a post by a Unity guy:
The plan with UIElements, the framework (including UI Builder), is to become the main UI framework for Unity, for both runtime and Editor. However, UGUI and IMGUI, the older Unity UI frameworks, will not be deprecated anytime soon and will continue to be maintained.
Iāll do some tests soon!