Cabbage Logo
Back to Cabbage Site

[CsoundUnity] Loading UDOs

#1

In the current version of CsoundUnity (3.4), Csound UDOs are not easy to use, if they are on an external file and not in the csd.
To be able to load a .udo file, the user has to do a very boring process of:

  • place the .udo file in the StreamingAssets folder or in the Resources folder
  • starting the scene with the CsoundUnity GameObject deactivated, with the INCDIR environment setting pointing to the PersistentDataPath
  • copy the .udo file with a script in the PersistentDataPath (if using the Resources folder it has to be renamed to .txt to be able to use Resources.Load)
  • once this copy is done, finally activate the CsoundUnity GameObject so that when Csound is started the above .udo can be found.

I’m hoping to simplify this process so I’m asking for suggestions:
how would you expect it to work?

We can’t assume Csound will have access to the folder where the UDOs are saved, once the application is built.

CsoundUnity users, have your say!

#2

yes, this is tedious. would injecting the UDO into the orchestra using compileOrc work? if we have access to the UDO code, we can inject it into each orc? that way only CsoundUnity would need to know where to look for the files, and not Csound? just a thought…

#3

I was thinking about something similar. Since we are using csoundCompileCsdText we can basically modify the passed string before it is compiled, and add the content of the UDOs before the existing instruments.
Or as you suggest, compiling the UDO code with compileOrc would be even cleaner.
I only have a concern: in both options I think I should get rid of the line(s) that include the .udo in the csd:

#include "my_udos.udo"

otherwise the csd won’t compile.
That means that the csd string I have serialized won’t be anymore exactly the same as the original csd, and so all the checks for file changes won’t be working.
However what I can do is looking for those lines and commenting/deleting them later, when the CsoundUnityBridge is created (so before the csd will be compiled). So this is not a big concern really, I think it will work and be quite quick to implement!

And what about the possible user interface for this in the CsoundUnity inspector?
Maybe no interface at all?
So when a csd is dragged into the slot it searches for #include lines, and if there are it looks for those udos files in the same folder of the csd, and if there are it saves them for later? If those udos are not found it could display an import warning.
Or do we need a more “visual” way of importing udos maybe from other locations too?

I think that having no interface for now is fine, first of all it would be nice to explore this loading mechanism :slight_smile:
Soon I will!

#4

I think this is Ok for now. Let’s see if this approach works first without messing up other things. :+1: