0.9.1 Release Candidate 1

Hi all,

0.9.1 is almost ready. As we’ve been doing lately we’ve prepated a release candidate for public testing.

It would be great if people could download the zips for the platforms they use and see if they notice any issues.

This is a minor version with only fixes so it should be totally compatible with 0.9.0

You can download the files for every platform from:


Since this is a small release there’ll probably be only one RC and there should be a final release sometime by the end of next week.

Thank you for helping test the 0.9.1 release!


I’ve just tried out a project that is currently working on 0.9.0 but it is broken in 0.9.1, it does not start and gives me this error

libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: recursive_mutex lock failed: Invalid argument

Should i open an issue on github?

that’s strange, have you tried to clean and recompile the project?

Yes, it is happening also after cleaning up the build.

Guys, just wanted to say thank you for developing OpenFrameworks. Unfortunately my programming skills are at level when I am happy if any example/addon is successfully built :slight_smile: But I will be glad to contribute to OF in the future.

I am currently using OF from GitHub (master branch), and one thing i noticed after migrating my projects from 0.8.4 is that my FireWire camera is not working anymore. isFrameNew() just never happen. I am using the standard ofVideoGrabber. Working with XCode on OSX 10.10

Not sure what is the reason. FW camera i use is unibrain Fire-i. If I use integrated laptop camera - it works fine.

So if my issue is relevant and you need more details - let me know.

@edapx could you tell us what OS and IDE you are using? Do any of the examples give you that error?

@theo, I’m cleaning up a bit the app containing the code generating the error, trying to isolate it.
I’m on Mac 10.11, Xcode 7.2

Hi, it looks like high resolution display support may have broken somewhere. If I enable “High Resolution Capable” in the plist settings ofGetWidth() returns 2x the actual width of the app where as in previous versions it returned 1x.

Xcode 7.1.1 OSX 10.10.5

1 Like

@gonzzza in 0.9.0 we switched from quicktime which was deprecated and wouldn’t work with 64bits anyway to av foundation which probably doesn’t support fireware cameras anymore. in any case if you are using a fireware camera is probably best to use the fireware (iee1394) directly. ofxLibdc is one of the addons that has support for this kind of cameras. not sure if anyone has a version that is up to date with 0.9 though

@edapx the error seems lto happen because a mutex is trying to be locked more than once which throws and exception since the mutexes are recursive. can you debug the application and check where the crash is happening?

I’m still investigating. In the setup method I’ve a call to a method that generates a mesh. I’m also using ofxGui, with 2 listeners on 2 sliders, both of the 2 listeners goes to re-generate the mesh when the value is changed. The thing is that these 2 listeners are triggered also when the app starts. In OF 0.9.0 this was not a problem, but in 0.9.1 it is. I’ve cleaned up my app, removing all the thing that are not used and pushed it here https://github.com/edap/Lsystem/tree/error

@braitsch - I believe that was also the case in 0.9.0
Have you been using 0.9.0 with HiDPI? or 0.8.4?

but when you run the application under xcode doesn’t the debugger stop on a specific line?

@arturo it stops at line 24 of openFrameworks/3d/ofNode.cpp. It is not the GUI, I’ve removed it and the error it is still happening.

@theo I’ve been using 0.9.0 since the pre-releases so it looks like something’s changed between 0.9.0 & 0.9.1.

Here’s what I get in a new project (default settings) with high resolution capable enabled in both 0.9.0 & 0.9.1


ofGetWidth() -> 1024
ofGetScreenWidth() -> 2880


ofGetWidth() -> 2048
ofGetScreenWidth() -> 2880

can you post some code that has the problem?

@arturo was it referred to me or to braitsch? the code is here https://github.com/edap/Lsystem/tree/error, the entry point is the build method in the LSystem class. I will also have a look tomorrow

@edapx the problem is that you are using push_back to push elements into the vector which will move things in memory so when you set a node as another’s parent but then push back the previous address for that node becomes invalid. an easy way to solve this is to use a vector of shared_ptr instead of directly ofNode which will alocate the nodes in the heap and even if the vector grows the nodes won’t move from where they are

@braitsch - I believe that was a change that was made intentionally as a start towards getting retina better supported in OS X. On iOS this is how things behave - (if you enable retina you get a window with twice as many pixels).

The reason it is different between 0.9.0 and 0.9.1 is that in 0.9.0 the screen width was actually not getting reported correctly.

as an experiment if you try drawing a circle at (1024, 0) in 0.9.0 and in 0.9.1 they should both draw in the top middle of the screen as the screen size isn’t different between 0.9 and 0.9.1 but the width was not being reported correctly for retina enabled apps.

I hope that explains it.

Right now for retina you have to handle the scaling etc yourself - (we just give you a bigger frame buffer)
For 0.10.0 we should aim to have the ability to have the retina scale passed through to the renderer so it requires no changes on the user’s end.

actually @braitsch - please ignore that last message, this is actually a bug which I think I introduced trying to solve another issue.

thanks for reporting this.
I’ll work on a fix.

fyi - we’ll be doing a bunch of work on Retina for 0.10.0 - so things might change a bit with how it works ( right now you get a smaller window when requesting retina )