Plugin Multiple Callbacks on Create, Release, and SetDataParameter

FMOD Engine
1

Hi, I’m developing a plugin and I don’t know why when I load one instance on studio, I debug my code and it calls create, setDataParameter and release multiple times (about 10), and this crashes my flow.

I made a blank project, using only 1 event, with 1 track, and instancing my plugin on pre-fader, also setting max-instances of that event to 1 (just for try), but it continues to call create a lot of times.

Can you tell me what’s happening with those callbacks?

Thanks

2

I have a similar issue where its not calling the creation callback on creating a user defined DSP with either System::createDSP() or System::createDSPByPlugin() (Core API)… A fix for these issues would be nice.

3

The worst part is for setDataParameter, because I have a bunch of data reading there, and every time I move another setFloatParameter knob I have on the plugin, the setDataParameter is calling and it tries to load again all the info.

It seems like every change on a parameter affects to all callbacks. Also creation and destruction has problems about it as @Sunkin351 says.

4

Are you able to share the code you are using? Or a small version that reproduces the issue?

5

If you are fine with debugging C# code in Visual Studio, I’ll be glad to give you the code I use to reproduce it not calling the creation callback…

It leaves the plugin state uninitialized causing a debug assertion on line 33, or a NullReferenceException on line 47. (Or on line 253, due to the multi-threaded environment setup within FMOD.)

Though to be fair, I just ported the C++ example to C#, so you’d probably get the same problems there.

Edit: I even put a breakpoint in the Creation Callback to make sure it wasn’t being called on DSP creation.

6

You may need to check the C# wrapper, I was able to use our C# wrapper and get a custom DSP create callback triggered from a very basic example.

using UnityEngine;

public class CustomDSP : MonoBehaviour
{
    FMOD.DSP_CREATECALLBACK createCallback = new FMOD.DSP_CREATECALLBACK(MyDSPCreate);

    private void Start()
    {
        CreateCustomDSP();
    }

    public void CreateCustomDSP()
    {
        FMOD.DSP_DESCRIPTION dspDesc = new FMOD.DSP_DESCRIPTION()
        {
            version = 1,
            create = createCallback,
        };

        FMOD.RESULT result = FMODUnity.RuntimeManager.CoreSystem.createDSP(ref dspDesc, out FMOD.DSP dsp);
        Debug.Log("createDSP : " + result);
    }

    public static FMOD.RESULT MyDSPCreate(ref FMOD.DSP_STATE state)
    {
        Debug.Log("MyDSPCreate Callback");
        return FMOD.RESULT.OK;
    }
}
7

I wrote the C# wrapper I’m using… FmodAudio. Much research went into its construction. If you wanna check my work, by all means. Me and OP both have similar issues with FMOD dsp callbacks.

8

At this point I have not been able to reproduce the issue with or without our C# wrapper.

If anyone can provide a test project that reproduces the issue I can look into this further.

9

Newest patch seems to have fixed it. Though, one issue remains. FMOD_DSP_STATE::instance is invalid by the time FMOD_DSP_DESCRIPTION::release is called? Why’s this?

10

The instance should always be valid, is it possible you are overwriting it at all?

11

I am not. The handle is as it always was on my end.

Another small detail: Is the FMOD_DSP_DESCRIPTION::release callback decoupled at all from FMOD_DSP_Release()? In my wrapper, I’m releasing a resource right after but that resource is needed from the callback… (In short, my resource is unavailable by the time the callback is called…)

Edit: That could be why the handle is invalid by the time the callback is called.

12

Calling FMOD_DSP_Release will cause the release callback set in the FMOD_DSP_DESCRIPTION to be called, at which point the instance will still be valid.

13

FMOD_DSP_GetUserData() reported it was invalid by that time. (And previous calls to the method from other callbacks worked fine, so…)

14

Was this ever addressed?

15

Any attempt to reproduce the issue has failed.

16

In the end, I was able to get everything working, and find out an important piece of information regarding DSP release/destruction. The release callback is decoupled from FMOD_DSP_Release() and is called at some later point in time. Not knowing this caused me some issues. But all is well.

17

I have a similar issue where the Create callback is called whenever I change any parameter. To make sure it’s not just happening in my own plugin project, I simply added

FMOD_DSP_LOG(dsp_state, FMOD_DEBUG_LEVEL_LOG, "Create_Callback", "Create_Callback is just called");

to FMOD_Gain_dspcreate() in the example fmod_gain project, and it’s doing the same thing.
Here’s the logs that I’ve been getting whenever I move the gain knob.

23:42:30 Macro: Set Gain [#2 times]
23:42:30 fmod_gain.cpp(212), Create_Callback(): Create_Callback is just called
23:42:30 fmod_bank_loader.cpp(125), Manager::readBank(): fileversion = 141, compatVersion = 140 (oldest = 44, newest = 141)
23:42:30 Macro: Set Gain
23:42:30 fmod_gain.cpp(212), Create_Callback(): Create_Callback is just called
23:42:30 fmod_bank_loader.cpp(125), Manager::readBank(): fileversion = 141, compatVersion = 140 (oldest = 44, newest = 141)
23:42:30 Macro: Set Gain [#3 times]
23:42:30 fmod_gain.cpp(212), Create_Callback(): Create_Callback is just called
23:42:30 fmod_bank_loader.cpp(125), Manager::readBank(): fileversion = 141, compatVersion = 140 (oldest = 44, newest = 141)
18

I have not been able to reproduce this myself, although if you are using Live Update then the Studio API might be instantiating the DSP each time it’s touched.