I’m considering using openFrameworks for my newer version of glitchSequencer (a MIDI application) which is currently written in Processing. I’ve only spent a few hours playing around with the openFrameworks demos and I’ve read some of the documentation. I’m looking for possible problems before I start porting over the code.
I’m considering dropping MIDI support and moving to a pure OSC approach, so MIDI won’t be an issue anymore. I’m also hoping to use audio playback - something that Java isn’t good at.
I’ve read a little about timing and openFrameworks, and I think that timing in C++ will be a lot better than Java’s timing, so I don’t see that as a stumbling block.
My questions are:
I noticed that the graphics demo applications pause when you drag the window. My application will need to run continuously. Is this tricky to do? Processing, by default, wouldn’t pause when you drag around the application window, but I did have to do some multi-threaded stuff for my timing code.
I use openframeworks for a project mainly based on midi. I use ofxMidi for midi input and output and it works perfectly. However I didn’t yet test system exclusive messages.
For the timing I use a POCO timer. (poco is a library used by openframeworks). It works very well and is very precise. When I move the window, the display freeze but midi work unchanged. It will slow down a little on a slow computer but only if I move the window very wildly around.
My programs work on Windows Xp, Windows Vista, Mac OS X Tiger and Mac OS X Leopard. I don’t have actually a Linux installed.
oF is intended to be completely transparently cross-platform. that means, if you can do it on one platform then (in theory) you can do it on any other platform. in practise i have never had problems running code written on OSX under Windows or under Linux, as long as i have kept inside the functions that oF provides.
as far as timing goes: this could be related to GLUT (oF’s default window manager). if this is a problem, it is possible to use a different window manager to replace GLUT, by extending the ofAppBaseWindow. if you search around the forums, there should be some examples that do that – i know people have made Cocoa windows on OSX, and used this to build OSX screensavers.
the freeze in draw while moving the window are because everything in draw can be not get called in case the window is minimized, behind another window, and surely while moving it around, but the rest of the app keeps running the same. also sound (both soundplayer and soundstream) use their own thread so it shouldn’t be a problem.
if you’re using mac or linux the timer, the functions ofGetElapsedTimeMillis and ofGetSystemTime are already high precission timers (microseconds although they return milliseconds)
Thanks for all your responses! I really appreciate it. Excellent feedback. I’ll continue porting my code over to openFrameworks. I’m really excited because I’m finally making headway on adopting a more “MVC” approach for the entire application. So far it’s wonderful!