I’ve been trying, together with André Perrotta, to make Marsyas and Open Frameworks (OF) play nicely with each other. The idea is to be able to use Marsyas inside an OF project.
Usually this is done using an OF addon, and Marsyas already provides an experimental ofMarsyas addon in the SVN repository (check it out at here, and some OF examples that use Marsyas here – these locations in the SVN repo may change place in a near future, though, as we probably tidy up the directory structure soon).
However, some problems seem to exist in making Marsyas and OF play nicely together:
- you’ll find that there is a clash between the MACRO define PI in OF and the const variable with the same name (elegantly) defined in the Marsyas namespace (MACROS could not care less about namespaces, and thats one of the reasons why its use should be sparse… and careful). Options to solve this would be to rename PI in Marsyas or in OF to some distinct names. This would imply having to modify all occurrences of PI in one of the libs, essentially creating a fork of the code. A better solution (suggested by Pedro Silva in the Marsyas developers mailing list, is to just do #undef PI after the includes form OF, and just before the includes of Marsyas in your main code).
- OF must be built as a 32 bit lib (at least in OSX 10.6.7) because of some legacy issues with QuickTime. Marsyas is built by default as a 64bit lib, so when you try to mix them together, the refuse to link. So, be sure to compile Marsyas as a static 32bit library (i.e. libmarsyas.a) before including it in an OF project. The way to do so in CMake is to set the CMAKE_OSX_ARCHITECTURES to i386 . Then in the OF Xcode project, you just have to point it to the correct 32bit libmarsyas.a lib, and make sure it also knowns about the corresponding .h headers. In case you wonder how to know if a library is 32 or 64 bit in OSX, have a look here.
- As far as it was possible to understand, the ofMarsyas addon still has some problems (there are some hardcoded paths in some of the #include calls, and ofxThreads still borks in some occasions), and we are in the process of investigating it and will post about our findings ASAP.
We’ll post some additional info (and hopefully more detailed info) soon.