I am not a programmer (although I dabble and can read code decently). However I have lots of experience with Max.
Their new RNBO program looks interesting and I was wondering how doable it would be to construct a plugin for FMOD using RNBO and its C++ conversion feature.
Any insight would be much appreciated
It looks like it should be possible to use the exported RNBO C++ artifacts inside an FMOD plugin.
RNBO::CoreObject, which you could create inside a FMOD_DSP_CREATE_CALLBACK and save to your FMOD_DSP_STATE::plugindata.RNBO::CoreObject inside your FMOD_DSP_RELEASE_CALLBACK.RNBO::CoreObject::prepareToProcess inside FMOD_DSP_RESET_CALLBACK, passing in the sample rate from FMOD_DSP_STATE_FUNCTIONS::getsamplerate and the block size from FMOD_DSP_STATE_FUNCTIONS::getblocksize.RNBO::CoreObject::process from the FMOD_DSP_PROCESS_CALLBACK. SampleValue appears to just be a pointer to an array of doubles, and FMOD_DSP_BUFFER_ARRAY::buffers is a pointer to an array of floats, so you would need to convert FMOD’s float buffer into a double buffer before passing it to RNBO, and then convert the resulting double buffer from RNBO into a float buffer for FMOD to use.getParameterValue/setParameterValue, which you could call from FMOD_DSP_SETPARAM_FLOAT_CALLBACK/FMOD_DSP_GETPARAM_FLOAT_CALLBACK. You would need to declare each parameter in the FMOD_DSP_DESCRIPTION::paramdesc array.rnbo_source.cpp, and a folder called rnbo containing the static RNBO library. There are no other libraries that need to be linked in, so the RNBO patch should be able to run on all of our supported platforms.So, you would still need to write an actual FMOD plugin and link in the RNBO C++ stuff yourself, but it looks like it should be totally doable to wrap an FMOD Plugin around a RNBO patch.
Thank you Jeff for the explainer. Now I need to figure out how to build an FMOD plugin from scratch ahahah
We have two example plugin projects in our Core API examples to help get you started. If your RNBO patch generates audio and you need it to behave like an FMOD instrument, then I would start with the fmod_noise example. If your RNBO patch requires audio input and you are needing something like an FMOD effect then the fmod_gain example would be more appropriate.
I would start by building either of those without any changes to verify everything is setup correctly, then add the RNBO stuff once you’ve got something running in FMOD Studio.
The Core API examples can be found in the FMOD Engine package on our Download page. Please let me know if you run into any issues getting setup.
Very interested in RNBO and FMOD, seems lile it could have a lot of potential. It would be really awesome if there were any tutorials available. Looking forward to hearing more about your progress 
Hey Jeff,
is it possible to wrap free commercial VST dll’s and make them work in FMOD?
Sorry for the delayed response- just got back from GDC.
Maybe with Max you could do something with the vst~ node and export that to the as-of-yet theoretical FMOD RNBO plugin.
Otherwise, it is technically possible to make an FMOD DSP that calls into a vst’s processing functions, but it would be quite involved, and in either case your resulting FMOD DSP could only be run on Windows / Mac.
Thanks Jeff.
Is the compatibility with only desktop platforms true also if I were to make a vst from scratch through RNBO?
RNBO has the option to export source code, which should be portable to any platform, so a plugin made from scratch with RNBO should be able to run anywhere.
Hi Jeff,
I managed to get a generator RNBO plugin to work as an effect plugin in FMOD, but not as a generator like fmod_noise.
I’m not passing in any input to RNBO either way:
_rnboCore->process(nullptr, 0, _audioOutputs, channels, length);
all I did differently was changing the input number to 0 in FMOD_DSP_DESCRIPTION. For some reason, that crashes FMOD Studio when the plugin instrument is played.
It sounds like you are doing everything correctly, and I think I have found your call stack in our crash reporter.
It appears to be crashing when reading the minimum value of a float parameter. Can you please confirm that all of the float parameters you have defined in your FMOD_DSP_PARAMETER_DESC_FLOAT have valid floatdesc min and max values defined?
In the fmod_noise dsp example that would be the 5th argument of the FMOD_DSP_INIT_PARAMDESC_FLOAT call:
FMOD_DSP_INIT_PARAMDESC_FLOAT(
p_level,
"Level",
"dB",
"Gain in dB. -80 to 10. Default = 0",
FMOD_NOISE_PARAM_GAIN_MIN, // possibly null
FMOD_NOISE_PARAM_GAIN_MAX,
FMOD_NOISE_PARAM_GAIN_DEFAULT
);
Otherwise, if you could please send feedback next time you get a crash, I should be able to search for your email address and know definitively that I am looking at the correct incident in our crash reporter.
Glad to see other people taking on the idea.
My work priorities have changed so I might not need to build my plugin anymore. However Id still love to try something in the near future.
just sent the crash report (where can I find it locally? it’s not in the AppData\Local\FMOD Studio\CrashReports folder)
and yes, I have two float parameters. Both of them have the min max set
Thanks for that, I can see it is crashing due to an access violation, 6 frames into your plugin’s process callback. So possibly a nullptr being read, or out of bounds array/memory access.
Provided you have a debug version of the plugin, you should be able to attach a debugger to the FMOD Studio process, put a breakpoint in your process callback, and step through the first process call to see what’s going wrong.
The crash dump should just be in the root directory of “%LOCALAPPDATA%\FMOD Studio”.
@jeff_fmod Thanks for the help! It turns out the code needs to send the signals to some dummy buffer, which only gets allocated in prepareToProcess(), which is hooked up to the Reset callback as you said, and I assumed that it would always be called before it’s played, but it apparent doesn’t (but it did for the effect version??). To fix it, I just needed to explicitly call Reset in Create.