Cabbage Logo
Back to Cabbage Site

CsoundUnity Package (UPM) development

#521

I’m OK with things being limited to 2018.3 or newer. What do you think, if it provides better performance and more options, then I think it’s a good option. On the other hand, I hadn’t even heard about UIElements until I read your message :rofl:

#522

I also asked to an Editor expert and he said there’s no way to improve things with the current implementation, he said this is a known problem with inspectors with lots of controls.
He also suggested using UIElements.

This could be interesting since in the future the same code (it’s something like xml+css) could be working also in the scene, not only in the editor.

I’ll have a look!

#523

That sounds nice! Let me know how it goes.

1 Like
#524

Hi guys, I’m back to prototyping some VR instruments, working on a sort of chime-like note trigger for a single synth.
I’m getting a tonne of clipping when I’ve got 3-4 SendScores triggering at the same time, like the volume is doubling each time, whereas when I play the same synth in cabbage, it sort of normalises regardless of the number of voices. Is there something obvious I’m missing to stop that happening?

EDIT: it does help a lot turning the Audio Source volume way down, but it’s also very quiet now!

#525

That’s strange!
Send me the scripts, I’ll have a look later!

#526

Sure, it’s basically just an index picking up collisions from the array of 16 and triggering a new SendScore each time.

public void TriggerNote(int collisionID)
{
    csu.SendScoreEvent($"i{instr} 0 0.1 {midiNote[collisionID]} {velocity}");
}

I’ve also realised that it’s hitting some nasty CPU limitations when I trigger loads simultaneously. See video: https://youtu.be/67EgHQ9z3_c

EDIT: I’m using oscbnk_synth.csd (214.9 KB)

#527

The video is private!
There shouldn’t be any problem calling the SendScoreEvent method multiple times in the same frame…
Maybe @rorywalsh knows what could be the problem?
I’ll do some tests and let you know!

EDIT: are you sure the same instrument and note is not called at the same time? For sure this could multiply the overall volume, and also require more cpu power.
Try adding some interval between calls of the same instrument and note, or filter the collisionIDs somehow.
Are you using CollisionEnter?
Maybe you could wait for a collision exit (a bool should be enough) before allowing sending a new note.

#528

Oops! should see it now.

#529

Very cool.
What’s the cpu usage If you comment the SendScoreEvent line?

#530

haha… yep that was it :sweat_smile: my bad! it was triggering 3 nearby orb notes PLUS the collider orb twice per collision.

so when I was hitting all of them into each other there were probably around 50-80 SendScores a second. oops!

thanks :wink:

#531

Ok great!
I was trying to press the SendScore button in the inspector as faster as I could but it doesn’t go above 50% cpu usage in my old mac.
But sometimes i had some click.
I’ll try with a loop now.
Notice you could also have had lots of warning messages in the console if the volumes gets too high (when above 10, volume should be between 0 and 1)!
That would slow down things a lot. But that’s intended, it’s something you’d want to know so you have to notice there’s some problem :wink:

#532

Ehi @rorywalsh, do you any news on the Set/GetSpinSample issue on Android? Is this happening also outside of Unity? Should I open an issue on Github, maybe? Or ask on Csound slack channel?

EDIT: Of course first thing to do would be making sure we’re using the right libs. I’ll dig deeper in the next days!

#533

If it happens outside of Unity then I think we can start to ask on the Csound channels. It’s hardly some kind of permission issue? I haven’ done much Android development before, but I do recall having to give the application permission to access things in a manifest file of some sort.

#534

Yes a closer look at the manifest is worth a try, good spot!
I should try calling the methods in a clean android project and see what happens.

#535

Btw, I think we can remove the testing of Csound in a separate process and instead use this instead. We can simply call it just before compiling Csound. It might slow things down a little but if it prevents crashes from happening I think it’s a small price to pay…

#536

That’s great! Do we have to wait for a new Csound release?

#537

On Windows we can grab the latest dev build from AppVeyor. I can prepare a new package for OSX, but it will take me some time as I’m still not really back at work yet :laughing: I’m concerned this might not be a thorough as the way we were doing it but it’s probably best to use what is provided in the Csound framework than hack our own solutions!

#538

Of course we should stick to the official Csound builds.
And maybe find a way to auto update the referenced libs on the CsoundUnity package when a new official build is added? Or is it better to do it manually?
If you have any clues I’m all ears!

#539

If we plan to use the github repo as the package then I think we will need to do it manually. If on the other hand we were to prepare an actual package for download, we could automatically include the latest versions. I don’t think it’s a big deal to do it manually for now.

#540

Yes, maybe some work is needed on the Android side, since the libs are not enough to make it work.
I’ll try to understand what Hector did to link the libs correctly.