Improved ofxFFGLPlugin working with OF080 and shaders

Hi friends,

I improved a little my previous modifications of ofxFFGLPlugin, getting rid of the ugly “testApp” class (it has nothing ugly in itself but my way of using it in this project was bad). Now there is one single class (pluginApp) that inherits from the original plugin and everything lives in there.

There is a hook that lets you do something when parameters change (pluginApp::onParameterChanged) and support for shaders, either to be loaded from source files on disk on runtime or embedded in code (see shaders.h).

The project is for XCode 5 on OSX, and it has a post-build script that copies support files in the build “data” directory and then the whole bundle to Arena vfx dir, to speed up the build-test-debug cycle. There is a little OSX-only code at the setup() method, it is used to gather the complete path of the bundle when loaded by host and load support files (only a sample font in this example).

It should work on windows too with a few minor modifications, it would be interesting if someone wanted to give it a try.

The whole thing is a bit of a hack, and may be it should be reviewed from ground up… but I lack both the time and the knowledge to do it properly, so this is what I can offer. Use it at your risk :wink:

At the moment there is not a github fork for this code, but you can easily download it here

the ofxFFGLPlugin folder has to be copied in “addons” directory in the OF installation, the FFGL_Example_modifiedDM (that you of course can rename at your wish) goes into “myApps”.

I successfully used this to build 4 plugins for Resolume Arena plus the included example, and would be happy to know that someone else is trying and may be improving it (there still is much to do :smiley: )

Hi, I have ben playing with this and it is great, thanks for the hard work.

When I build the plugins with resolume avenue it is fine, however I am trying to use a different host and the host crashes when loading the plugins (not when initialising but on startup it scans the directory and crashes on the loop below getting the parameter names. Here is the function from the developer of the other host. I really dont have any idea on how to solve this, if you have any tips let me know.

This is from the developer

My call looks like this

I get the pluginInfo struct like so

PluginInfoStruct* pluginInfo = CallFreeFrameProc(mPluginProc, FF_GETINFO, NULL, 0).PISvalue;

Then I check all the capabilities. Then I get the number of parameters

mFFParameterCount = CallFreeFrameProc(mPluginProc, FF_GETNUMPARAMETERS, NULL, (DWORD) pluginInfo).ivalue;

and loop through to get the param names

for (UInt32 i=0; i<mFFParameterCount; i++) {
   // get the param name and clean it up
   const char* pluginParamName = CallFreeFrameProc(mPluginProc, FF_GETPARAMETERNAME, (DWORD) i, (DWORD) pluginInfo).svalue;

The crash happens in your function


I’ll look at it later when I get home, but if you want you can investigate what’s happening with the debugger. You can attach XCode debugger to the host application and set your breakpoints in your code. They will work as usual when the plugin is loaded and called.

I had to change the original FFGL behavior there because of a bug (or so it seems) in Arena when it reads parameter names. At first sight it seems to me that your host is doing the same things Arena does…

What application is the host you are using? Would it be free to test if I wanted to try it?

Hi, the version of the host application is under development and I cannot give it to you. Any tutorials you can link me to on attaching the xcode debugger to the app? I tried making a debug version of the plugin but I dont see anything in the console and I know how to use breakpoints but not on a plugin.

the version of the host application is under development and I cannot give it to you

OK, I’ll try to help anyway if I can. I do not have XCode here (using Kubuntu right now) but as far as I can remember the task is easy enough. Of course you have to build a debug versione of the plugin (I link it to a debug version of OpenFrameworks lib too but this is not mandatory if you are not interested to see what happens inside it). Then you set your breakpoints as usual in your code, run your host app and from debug menu choose “Attach to process” or something like that. You should have a list of currently active processes, just pick the one you need (that will be your host app).

After that you can load the plugin, and when host will call functions from your plugin the breakpoints will be activated as needed. It really is easier done than said, just try it. If you want to debug something happening during application startup (as may be the case with plugin loading and probing) it is possible to specify the application name in “attach to process” menu, then XCode will wait for that app to be launched to start debugging.

I found the whole mechanism very useful and smooth, usually works without a glitch.

I didn’t have the time to put this code on github, but may be it could be a good idea.

Cheers for the hint. I have the debug process working very smoothly- although I dont know what is wrong exactly at least I can see what is going on.



@fresla any news about this? I’m trying to make the plugin work with visual studio on windows too, so may be this could be interesting for you and your friend developer… have a look at this post

I had some other things to get on with so I shelved it for a while. I was debugging but I could not find where the error was I think I need to work wit the developer but he says he implemented the FFGL in his software by the book. I don’t get errors from the FFGL test software from the SDK or from avenue when I use plugins made from this addon, so it seems to be pointing to the host I was testing on, however all other FFGL plugins I can find load into this software also. If you have a windows FFGL I can send it to him to see if it works…

This looks weird but there must be a reason for this behaviour. The only thing I had to change at the basic FFGL level is the storage of parameters names. The old code (iirc) used a static copy of the plugin that got reused among different calls from host (it makes many when probing for plugin capabilities, number and type of parameters etc), in mine a new object is created every time and then destroyed. It should not be a problem for the host (besides a negligible increase in load time) but may be yours is keeping a pointer to an old object that is no longer valid… if you don’t experience crashes on plugin side this may very well be the case (I guess that a crash in the plugin code would be trivial to spot with the debugger, if you did not it means you got no crashes).

I have a semi-working plugin for windows, meaning that it works fine with the FFGLhost test program that comes with FFGL but Arena refuses to load it). If you want to give it a try there is a link to an experimental version here

would be interesting to see what happens