Answered
0
0

Following some advice I received in a previous post I’ve taken a look at the GetUserData() method. I tried adding a call to that function in the fmod_noise plugin example. I had to add fmodL64_vc.lib as an additional library dependency, without it I kept getting “unresolved externals” errors regarding DSP::GetUserData(). After building and running, FMOD Studio no longer sees the noise plugin. I noticed that none of the other plugin projects link to this lib, so I’m guessing that is not how I should have resolved that build error? Any ideas?

  • You must to post comments
Best Answer
0
0

Thanks for your reply. pluginData will not work for me in this case. Let me explain. I’m dynamically creating a list of plugins by populating a vector of FMOD_DSP_DESCRIPTION structs in my FMODGetPluginDescriptionList() method. At this point my interface knows nothing about my plugin data. What I would like to do is set a unique string at this stage, in each of my descriptors, that I can retrieve in any of their callbacks.

There are hacky ways I can do it. For example I can create a global vector of strings that I populate in FMODGetPluginDescriptionList(). I could then set a unique index as the descriptors version number which I can then access in my callback to ensure I find the right string in the vector. But it’s rather crude. Any other ideas?

Btw, this question was a follow up to this one:
http://www.fmod.org/questions/question/question-regarding-multiple-plugins-in-one-dll/

  • Brett Paterson

    If you want to follow that advice you’d have to use a 2nd copy of FMOD that lives in the same directory as your plugin, as the failure you experienced is probably a failure to load the fmod dll at plugin load time, that linking the fmodL64_vc.lib is causing.

  • Rory

    Thanks Brett. I tried this out. I copied all the fmod dlls I could to my plugin dir but it’s still not seen by fmod studio. I tried some other DSP methods, they all result in the same problem. I see none of the plugin examples use them either. Could any of you guys confirm this is actually possible by modifying the fmod_noise example. For example, even GetInfo causes my plugin to become invalid:

    char name[1024];
    FMOD_DSP *fmod_dsp = (FMOD_DSP *)dsp_state->instance;
    FMOD_DSP_GetInfo(fmod_dsp, name, 0, 0, 0, 0);

    What’s more is my proposed hack won’t work either because I can’t access any FMOD descriptors in my callback functions.

  • Brett Paterson

    It does work, but you have to remember to check the logging console in studio (under window menu) if there’s an error.

    Typically using a 64bit version of FMOD studio and building a 32bit plugin would be the first problem.
    Next linking to fmod logging version import lib, and using the release dll would mean it would fail as well.

    To be sure, I copy fmod64_vc.lib and fmod64.dll into the plugins folder.
    Next I link my plugin to the .lib in that folder.
    Next I copy the linked dll into the same plugin folder.
    As long as they’re both 64bit it will load, and getUserData or getInfo works without a problem. I used it in the create and process callback.

  • Rory

    Thanks Brett. It turns out that trying to run my plugin from its build folder doesn’t work for some reason. But, if I throw it in the fmod plugins dir all works as expected. Clearly there was a library conflict somewhere. THanks again, that’s another hurdle out of the way!

  • You must to post comments
2
0

If you want to store your own data so you can access it from any callback, then you use FMOD_DSP_STATE::plugindata. This is what the noise plugin example does.

DSP::setUserData is data set by the user, not for use within the plugin.
You can use FMOD_DSP_STATE::instance to get this sort of data if the DSP is statically created and linked within your executable, because the code is there.

If you are in a DLL environment, then you need the code to be linked in, but if the dll tries to load fmodL64.dll and fails then it will most likely fail to load as a plugin. Its generally not a great idea to try and access FMOD through a dll interface, are you just after the ability to store your own data (ie plugindata) or you really want what the user set from the application? That’s not a typical use case. The setParameter interface is used to pass data from the user to the plugin, not setUserData.

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.