0
0

Hi FMODders,

I think it is a good thing to have support for loading user developed plugins into fmod, but I am missing an option that would be make more useful more me. The situation: I have my own dsp plugin ready to be used (it works well both in Designer and in the application that I develop), but I do not want to expose it to the curious users in its .dll form.

It would be the better for me if I can include its code in the application’s executable and register it in fmod as an already known dsp unit to enable the events created by the Designer to use it (as far as I know the .fev files refer to the user plugins by their names). Of course, in the Designer I use the .dll itself that has perfectly the same code as the one built into the previously mentioned executable.

I have already tried to call the System::createDSP() function to solve this problem, but I had to realize creating user dsp units by this function is not the same method as loading them from plugins by System::loadPlugin(). That made me sad :(

Will you implement a “register” method for me (and for anyone interested in something like that) to create & use plugins inside the executable?

Thank you in advance.

  • You must to post comments
0
0

How is createDSP not the same? You have to call createDSPByIndex after you load a plugin so you’re almost taking the same code path. Let me know if you’re thinking of something else.

  • You must to post comments
0
0

Hi Brett,

Okay, let’s make it clear. Sorry for my presentation, I think it would be better to start it over.

I have an effect, let’s call it "non-fmod effect". I have compiled a separate .dll from it (let’s call it "nonfmod_effect.dll") for fmod designer. It is needed to construct events those use this effect visually.

Everything is okay then, but it should be known in the executable, too. The common (and usual) way is to load this .dll by System::loadPlugin(). I do not want to do this, because I do not want to expose this .dll for the public. So, I experienced that when I create this "non-fmod effect" by System::createDSP(), it doesn’t count as plugin for events loaded from .fev files. Actually, I have to use this member function to create this "something like a plugin" because I have the cloned version of create, reset, read, release etc. present in the .dll as normal C-functions in the executable.

The rough skeleton of the code compiled into the executable and to a .dll file:

[code:7wj2dd02]
FMOD_DSP_DESCRIPTION nonfmod_effect_desc = {
dspname, (dspvmaj << 16) + dspvmin, 0, dspcreate, dsprelease, dspreset, dspread, dspseek,
dspparameters, dspparam, dspsetparam, dspgetparam, 0, 0, 0,
};

...

FMOD_RESULT F_CALLBACK dspcreate( FMOD_DSP_STATE * dsp ) { ... }
FMOD_RESULT F_CALLBACK dsprelease( FMOD_DSP_STATE * dsp ) { ... }
FMOD_RESULT F_CALLBACK dspreset( FMOD_DSP_STATE * dsp ) { ... }
...
[/code:7wj2dd02]

and the plugin version of it also includes this:

[code:7wj2dd02]

ifdef __cplusplus

extern "C" {

endif

F_DECLSPEC F_DLLEXPORT FMOD_DSP_DESCRIPTION * F_API FMODGetDSPDescription( void ) {
return &nonfmod_effect_desc;
}

ifdef __cplusplus

}

endif

[/code:7wj2dd02]

Here is a code snippet (event system is not initialized):

[code:7wj2dd02]
FMOD_PLUGINTYPE type = FMOD_PLUGINTYPE_DSP;
res = fmod_system->getNumPlugins(type, &numplugins);
res = fmod_system->createDSP(nonfmod_effect_desc, &my_dsp);
res = fmod_system->getNumPlugins(type, &numplugins);
[/code:7wj2dd02]

First, numplugin’s value is ab. 16 (indicates that standard fmod plugins are loaded). Second, it still not changes, so it does not count as a plugin. But then, when I initialize the event system by

[code:7wj2dd02]
res = fmod_eventsystem->init(EFFECTS_MAX, FMOD_INIT_NORMAL, NULL);
[/code:7wj2dd02]

and try to load the events using this plugin by

[code:7wj2dd02]
res = fmod_eventsystem->load("sound.fev", NULL, NULL);
[/code:7wj2dd02]

this "plugin" could be not found, of course. Hence it is disabled. If I do the same by calling loadPlugin, like

[code:7wj2dd02]
FMOD_PLUGINTYPE type = FMOD_PLUGINTYPE_DSP;
res = fmod_system->getNumPlugins(type, &numplugins);
res = fmod_system->loadPlugin("nonfmod_effect.dll", NULL, NULL);
res = fmod_system->getNumPlugins(type, &numplugins);
[/code:7wj2dd02]

it is gracefully loaded (numplugins increases), but this is not what I wanted. Instead of this, I think I would need a function to register'' oradd” an internally defined DSP to the list of applicable plugins. Something like that:

[code:7wj2dd02]
FMOD_PLUGINTYPE type = FMOD_PLUGINTYPE_DSP;
res = fmod_system->getNumPlugins(type, &numplugins);
res = fmod_system->createPlugin(nonfmod_effect_desc, NULL, NULL);
res = fmod_system->getNumPlugins(type, &numplugins);
[/code:7wj2dd02]

where the value of numplugins increases, of couse.

That’s all :)

  • You must to post comments
0
0

Well, what are my chances?

  • You must to post comments
0
0

That is pretty unlikely. If fmod designer uses an internal effect, it uses createDSPByType with a hardcoded list of effects.

If it uses a dll, it uses the filename described by fmod designer and passes that to System::loadPlugin

There is nowhere in the low level api that even lets you create a dsp by name, so I guess you’re talking about registering it in the event api and passing in the dsp you’ve created. I’m not sure that is a really useful function just to hide a dll. You could do that in other ways maybe by just renaming the file as one of your data files, instead of myplugin.dll call it blah.dat.

  • You must to post comments
0
0

Acually one place it might be useful is for non pc consoles, that don’t support plugins, so it might be worth considering, just not right now.

  • You must to post comments
0
0

Thanks :)

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.