CsoundUnity Package (UPM) development

rorywalsh · 21 May 2020 08:33

I’m totally bogged down at the moment, so if you had a chance that would be great. I could then just follow your lead with any other examples that use samples.

So do you think the use of CsoundCopyTableIn() will address the memory problems?

Also, we should really find a way of stopping Unity from crashing each time Csound presents a problem. In Cabbage I run a simple command line program in a separate thread before I start execution of Csound in Cabbage. A problem in the test run will stop Cabbage from trying to run the instrument. It’s not 100% perfect, but better than an entire session being ripped down. Do you think something like this might work? Tables seems to be the biggest culprit of crashes. I would hate for any designers to lose their work because of crashes in Csound…

giovannibedetti · 21 May 2020 09:00

Good point.
We can add something like this in the CsoundFileWatcher!
If a problem is detected, set a flag in CsoundUnity that doesn’t start Csound.
Link me to your Cabbage code that does this check, I’ll try to port it in C#.
I think I’ll be free this afternoon!

rorywalsh · 21 May 2020 09:03

I just do something as simple as this:

github.com

rorywalsh/cabbage/blob/master/Source/Application/CabbageMainComponent.cpp#L1798-L1827


int CabbageMainComponent::testFileForErrors (String file)

{

    //this method will start a Csound process and test it for i-time errors and possible infinite loops.

    //It only runs 16 k-cycles, so it will not be able to detect perf-time hangs

    ChildProcess process;

    const String applicationDir = File::getSpecialLocation (File::currentExecutableFile).getParentDirectory().getFullPathName();

    const String processName = applicationDir + "/CsoundTest";



    if (File (processName).existsAsFile())

    {

        const String output = process.readAllProcessOutput();



        process.start (processName + " " + file);

        process.waitForProcessToFinish(400);



        const int exitCode = process.getExitCode();



        if (exitCode == 1)

        {

            process.start ("csound " + file);

This file has been truncated. show original

As I said, it’s not perfect, but anything that stops Csound from pulling down Unity is worth it!

giovannibedetti · 21 May 2020 09:05

OK I’ll look into it!

rorywalsh · 21 May 2020 10:44

Let me know when you get a chance to update the table stuff. I will give it a go when I get a chance.

giovannibedetti · 21 May 2020 10:56

It’s done I’ll push it!
EDIT It’s there!
I am a little busy this morning, but in the afternoon I can look into the Sequencer demo if you haven’t in the meantime!

rorywalsh · 21 May 2020 10:59

Thanks @giovannibedetti. I just did a hard reset of the dev2 branch, but there are no examples in the Packages folder? No biggy, just letting you know. I won’t have time this afternoon to write anything either. I’m still doing corrections. But they are for a sound design module, so at least I get to play a lot of games while I’m marking them!

giovannibedetti · 21 May 2020 11:10

No, the examples are now in a folder Samples~
I had a global gitignore that was ignoring *~ so I had to get rid of it.
I had to move the samples there or the import via package manager wasn’t working.
So the development of the Samples has to be done in another project (with the latest CsoundUnityPackage imported via git), and then the whole folder copied in the Samples~ folder of the dev2 repo, and the json updated.
EDIT: we probably should automate this in the future with git

That’s great!
(maybe you’ll find there new ideas for CsoundUnity samples)
Have fun

rorywalsh · 22 May 2020 14:21

Hi @giovannibedetti. I’m just trying this out now. Am I right in assuming that if I want to add a demo I need to:

Build the demo in my main project’s Assets folder
Copy (through via the OS) the entire folder when done, to the ~Samples/ folder within our CsoundUnityPackage
Update the json file
Commit

And if I want to modify a sample, I should copy it from the @Samples folder to my main Assets folder, and then follow the steps above when it is complete?

work on a demo scene I should copy it from the ~samples into my main project assets. Then when I’m happy with

giovannibedetti · 22 May 2020 15:24

Yes exactly, be sure to copy the meta files!

giovannibedetti · 22 May 2020 15:27

In the case you want to modify a sample, you can import it through the package manager, then the same as above

rorywalsh · 22 May 2020 18:49

Btw, I pushed some code to run Csound in a separate process and test for errors:

github.com

rorywalsh/CsoundUnity/blob/dev2/Editor/CsoundFileWatcher.cs#L100-L123


static int TestCsoundForErrors(string file)

{

    var csoundProcess = new System.Diagnostics.Process

    {

        StartInfo = new System.Diagnostics.ProcessStartInfo

        {

            FileName = "csound.exe",

            Arguments = file,

            UseShellExecute = false,

            RedirectStandardOutput = true,

            CreateNoWindow = true

        }

    };



    csoundProcess.Start();

    while (!csoundProcess.StandardOutput.EndOfStream)

    {

        string line = csoundProcess.StandardOutput.ReadLine();

        Debug.Log(line);// do something with line

    }

This file has been truncated. show original

It’s window only for now but it seems to work Ok. But I think there is still something weird going on with the file watcher?

giovannibedetti · 23 May 2020 09:30

It’s possible, I assume you have restored the three lines to activate it?
I think there is something missing (file gets deleted or renamed) and also some problem with the _lastAsset field of CsoundUnity. To debug everything properly we should look at every serialized property of CsoundUnity and see if they behave correctly. Also we should do something on Csound startup: if I import a sample scene the filepath of the csd remains what the file path was at the time of the last commit. It doesnt have consequences since csound compiles the code but it’s indeed wrong!
EDIT: this morning I woke up with the solution on this, instead of using the asset path we must use the GUID of the asset, and pass the path to the FileWatcher with this:
https://docs.unity3d.com/ScriptReference/AssetDatabase.GUIDToAssetPath.html
The fact that I use the filePath for scanning HAS consequences, it looks for a file that exists in my computer but for sure doesnt’t exist in the computer of everyone else!
I’ll fix this when I can!!

rorywalsh · 23 May 2020 20:43

Yes, that was one of things I noticed. I had to manually edit the Unity project file in VS Code to fix the path. But I knew you were aware of this. Great that you found a solution.

giovannibedetti · 26 May 2020 17:00

Today I finally had some time to work on those problems.
I already pushed an update, please test it!
Now the csd asset is identified by its GUID, the fileWatcher should work, and also the TestCsound process should work (Windows only, not tested)
Lots of cleaning and fields hiding, but everything should work as before.
Let me know!

rorywalsh · 26 May 2020 19:27

That’s great. I’m still swamped down with corrections, but will hopefully get back to this soon

giovannibedetti · 27 May 2020 08:34

Today I was thinking of adding a save/load preset feature, but the preset of the Unity inspector already works perfectly!
I’ll start working at some example while waiting for bugs to come at light

rorywalsh · 27 May 2020 09:06

Great. Yeah, I think the Unity inspector handles things fine now. Probably best leave it at that. One less thing for us to maintain

Alex_Emile · 1 June 2020 14:59

Hi guys, I’m getting issues when attempting to build from my windows to my mac.

I get the .app over there, and when I open it get the error:

“DllNotFoundException: CsoundLib64.framework/CsoundLib64”

I’ve got my CsoundLib64.framework in the StreamingAssets folder and tried moving around with no luck.

Also, I noticed something weird when monitoring the log as it’s being streamed on my windows, it’s looking for the Opcodes path on my desktop?

giovannibedetti · 1 June 2020 15:13

Yes for now builds on macOS aren’t working because the framework is not copied.
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 xcode project frameworks.

Regarding the path, that is where we are looking for opcodes on macOS, and it depends on the location of the project or the executable.
Also the environment path is something to correct soon!