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?
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.
2 Likes
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/
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.
1 Like
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.
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.
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!