Can openFrameworks do live coding and how


i added some flags to optionally compile OF as a shared library (needed for emscripten) so it might be even easier to setup on the makefiles for 0.9

Build OF as a DLL under windows

@arturo @racarate
that’s both good news. can’t wait to try this out (could be a few weeks though before i have time).



By the way, it’s not necessary to have openFrameworks compiled as a dynamic library


If anyone is curious, here’s my attempt, works with latest OF and it’s Linux-only for now:

Again, thank you @kritzikratzi for sharing notes and sources!



i saw you are getting quite some work done.
i haven’t had a chance to try it out. when you generate the shared libary during runtime, does it contain all of OF?

best, hansi.


Yes, it can call all openFrameworks commands. ofxAddons are working too.

For serialization there are some ways how ofxAddons should be written, like I rewrote my first person camera to support RCC++ by moving all ofAddListener and ofRemoveListener commands to object’s constructor and destructor so that when recompiling happen it would remove old function addresses and add the new ones at runtime. See this thread where Doug helped me out with it.



wohoo, reviving an old thread :slight_smile:

i’ve been using the live coding quite a lot, still the style where i only change a small part of the application but leave the main ofApp untouched.

i used to do (roughly this):

  • compile app in xcode, launch it
  • if runtimeCPP detects a change then create a shared lib that statically links to: openFrameworks.a, rtAudio.a, etc.
  • load shared lib

and here’s the new way:

  • compile app with “-rdynamic” to export all symbols (like ofDrawLine) and launch
  • when a change is detected compile the shared (runtime) part of the application without (!) linking to anything. this gives a ton of linker errors. disable them with clang’s “-undefined dynamic_lookup” flag
  • load the shared library. upon loading all the symbols will resolve into the main application thats already running

the biggest advantages are:

  • a bit faster and smaller shared library
  • library calls (like ofGetMouseX() finally work)

so this help won’t change much if you want to have the entire ofApp reload. but it’s quite neat for having small bits of changeable code (e.g. i’m using it for audio processing).

here is the basic principle in a stripped down C example:

////// main.c

#include <stdio.h>
#include <dlfcn.h>

void exported_callback(){
    printf("Hello from callback!\n");

typedef void (*lib_func)();
int main(int argc, const char *argv[]){
    printf("Hello from main!\n");
    void *handle = dlopen("./libprog.dylib", RTLD_NOW | RTLD_GLOBAL);
    lib_func func = dlsym(handle, "library_function");
    return 0;

////// lib.c

#include <stdio.h>
void exported_callback();

void library_function()
    printf("Hello from library!\n");

////// COMPILE

clang -rdynamic main.c -o prog -ldl
clang -undefined dynamic_lookup --shared -fPIC lib.c -o libprog.dylib

/////// OUTPUT
Hello from main!
Hello from library!
Hello from callback!

the code comes quite directly from here:


Meanwhile in CMake OF :blush::

It also can be done in OSX / Windows since cmake-based OF compiles to shared libraries by default now for better link speed (on Mint 17.3 with gold linker it’s half a second), but currently I’m working on Linux only…


oh, this is really cool.
too busy at the moment, but i really wanna try out the cmake OF.


I tried the same method (with just GLUT instead of openFrameworks) but I noticed that the dylib close function on OSX doesn’t always work the first time. Did you run into that too? My code is here, I ended up calling dlclose() in a loop:


Reviving an old thread again!

I tried to mess with OF live coding myself, educated by this awesome thread.
After trying out different techniques, I came up with an OF app that embeds the Cling interpreter together with an in-app text editor.
This seems to work really well so far, and is very flexible - you can call OF functions, your addons, and interact with the embedding app.

Here’s a video I took:

It turns out to be a really nice tool to experiment with OF and with C++ in general (finally I can try out regex in C++ :smiley_cat:)

Unloading symbols is still a pain, but can overcome by designing differently (with lambdas) and by adding templates for auto naming.

I wrote a small addon -, with only one function, createInterpreter(…), which sets up a Cling interpreter with OF. From there on use Cling itself, which have a very easy and high-level API for executing code.

More important maybe is - the app in the video, which is the best (and only) example on how to setup and use ofxCling.

Currently OS X only but contributions are welcome, it should work on any system that Cling compiles on.

Hope someone is still interested!


Hi, That looks really cool.
I tried to install ClingOFPlayground on my OSX computer but I got the following error.
Any idea what the problem is?


You need an ssh key to clone the submodules:


Query on running the example code of OpenFrameworks.
I am very new to OpenFrameworks platform but experienced in C++ and Linux.
As a part of learning of OF, I have downloaded the latest openframeworks s/w(0.9) and tried to compile the 3D example files but am getting many errors w.r.t openframeworks.
Following are the s/w we are using for openframeworks

  1. Visual Studio 2013
  2. openframeworks 0.9

I have seen somewhere that OF will not work with VS2013.
Pl let me know what are things that are needed to work with OF on VS2013.


Has anyone taken a look at the Jai videos?

You can see how in the last one it’s compiling programs in less than half second. If it’s ever released, OF+Jai could be very cool I think. I think it would enable something very close to live coding.


this looks great!


Jumping back in from the ofxLua angle, I just released loaf (lua, osc, and openFrameworks):

It basically works like Love2d: you run a script or folder with a main.lua and it automatically reloads when the file timestamp is updated (aka saved).

loaf includes bindings for the OF core and ofxOsc, but supports dynamic module loading so addon Lua bindings could be compiled and loaded later on. I did some testing a few years ago which worked, but haven’t gone farther in that regard yet.

This is basically a rewrite of my previous Visual app (now dead) without the live editor and greatly simplified. I decided trying to expand/maintain an OpenGL text editor was becoming a waste of time and have greatly enjoyed using loaf with Sublime over the last couple months to build out some performance work.


I’m working on an app that will be used to control a theater show. At first I hardcoded in C++ all the steps of the show, corresponding to all the events that can occur on stage (light changes, video starts, and so on).

It was pretty tedious to stop the app, change source code, recompile, wait, and launch, rince, repeat.

So, I interfaced my app with Lua. At first I searched for a readymade solution, but they were all too complicated for me (I’ll talk about ofxLUA later), Lua binding with C++ being a real pain in the ass (Lua can’t natively call C++ member methods, only c methods or C++ static ones). I simply coded a central dispatcher (static method), that calls a private non static _dispatcher. The static dispatcher is declared as global “c” function is lua (might be any other name), I call it in Lua with result = c(one_action_code, param1, param2, paramN). Then the c++ dispatcher case switches from the action_code and for each case pops Lua stack and calls c++ methods.

So I get some classes like
myApp which owns a sceneManager instance
sceneManager instance owns several classes instances like oscQLCPlus, oscMillumin, oscAbletonLive, midiAbletonLive, lifxClient
sceneManager owns one instance of LUAScript (the Lua init and dispatcher), and LUAScript which is threaded communicates with the sceneManager with atomic states. LUAScript is friend class of sceneManager and so have access to all of its ressources. And the most important point : LUAScript is interruptible.

I coded the whole LUAScript mechanism in 2 days. It’s not Lua C++ binding state of art, but it works pretty well, it’s very fast and easy to extend. I added a fileWatcher system to detect Lua script changes, who reloads and relaunches the current scene, if any.

Now I have my app running, my global Lua script open with an editor, and as soon as I save it I get it running in 1 second. So it’s quite live coding in OF.

Now, about ofxLUA. Last year I coded a small experimental app on raspberry Pi and used ofxLUA. Combined with the fileWatcher mechanism I was able to have quite instant result. I adapted the OF graphicsExample in LUA and it was running pretty well, even on a PI2. I did not investigated advanced OpenGL stuff or video manipulations or videograbbing but it was ok and running at 20/30 fps. Could have been used for some sort of VJing for 2D effects. Might give better result on a machine with more horsepower.


ofxLua uses luajit on RaspberryPI so it’s pretty quick.