- Cinder is more "C++y", i.e. more use of templates, boost, etc... openFrameworks opts for more "C with classes" approach, which makes it resemble processing a bit more.
- Cinder uses system libs, openFrameworks tends to use third party libs that it wraps into its own API. This puts Cinder closer to the OS on windows/mac, but means that oF has linux support.
From personal view, it seems like more agencies use Cinder while more independant devs use openframeworks, but that really doesn't say anything of the frameworks themselves, more the communities.
So "creative coding" is programming graphics, music, etc., right? Is it just me or is that something of an inappropriate term? To me it brings to mind, you know, creative code, clever programming tricks, perl poetry, and the like. Shouldn't we call this multi-media programming or something more specific?
Very common in the digital arts communities. Basically, it's a signifier of "framework that gets you to pretty/shiny/beepy/pokey the quickest". So, you usually have a VERY stripped down interface of setup/update/render functions that allow you to do an interactive task quickly.
If that seems limiting, that's because it is. The thing to realize is that you're /supposed/ to be limited in the outcome of your program. Usually in creative coding frameworks, you're just trying to make a program that does a single thing, but needs graphics/sound/interactivity. Limiting the interface down to what you need means you can program with the end interactive situation in mind.
This tends to mean creative frameworks eschew quite a bit of software engineering practices in deference to ease/speed, which can cause software developers coming into these frameworks to think they're, well, crap. But, the single use practicality does make it nice versus trying to implement this stuff in something like a full on game engine.
I got started with programming back in the 1970s doing "creative coding", although we didn't call it that. It is a very different environment with very different set of standards. I did all sorts of multi-media work and even got into motion picture effects in the late '80s, early '90s.
One thing about these types of projects, mistakes, errors, and even plain old bad practices, things that are anathema in most coding domains, often can produce not only useful, but spectacular results. Especially in things like particle systems; but I've seen really cool moves generated by errors in easing functions in 'tweening code as well.
Sometimes when I'm bored by the results of a carefully planned piece, I've been known to purposefully try and break things a bit.
Edit: These days I play around with Processing quite a bit. I took a look at Cinder a year or so ago, and while it looked cool, it's a _lot_ more work to mess around with. I'd have to get a lot more serious to play around with it. But if I came up with something really cool with Processing, I might very well want to port or rework it with Cinder for the obvious speed and interactivity performance.
Speaking as someone who develops addons for these, it's much easier to take my C libraries and wrap them for cinder/openframeworks, then it is to either JNI or create an IPC layer (usually via OSC, http://www.opensoundcontrol.org) into processing, too. Yay laziness. :)
Much in the same way that Processing can be compiled to work on Android, Cinder can be compiled to work on IPhones & Ipads.
Also, I think Cinder has a bit more of a direct approach to OpenGL, whereas Processing has built up a simplified layer on top of JOGL to make doing the more common things easier.
I attended various talks by Ben & Casey at Eyeo, and they mentioned the new 2.0 series of Processing including a lot of great new OpenGL improvements by Andres and others, and that the new GL framework shows performance near OF. In another talk, Ben mentioned prototyping something in Processing, and then porting it to OF for speed.
I'd say that in general we'll see this all matter less and less, what with more GPU type stuff happening, and with the advancements in the JIT and code translation in general.
even if Processing 2.0 does make perfect use of the GPU that distinction only covers the render phase. Calculating collisions for a large number of objects will still be significantly faster in C++. So like nearly every situation in software, it all depends what you're trying to do.
For computation-heavy apps, probably. For others it'd probably come down to something at the framework level, such as the efficiency of the OpenGL bindings or event/callback infrastructure.
I tried it a few years ago, but I had a hard time getting into it. (Back then, ) its documentation failed past the obvious first examples, which meant that the authors basically assumed you already knew everything about how to write realtime 3d graphics on modern hardware and recent OpenGL versions.
I'd assume that if I already knew all of that, I would've probably made some own code for it before, so wouldn't need Cinder for anything. Compared to Processing, Cinder's entry-barrier is orders of magnitude higher.
Some major differences:
- Cinder is more "C++y", i.e. more use of templates, boost, etc... openFrameworks opts for more "C with classes" approach, which makes it resemble processing a bit more.
- Cinder uses system libs, openFrameworks tends to use third party libs that it wraps into its own API. This puts Cinder closer to the OS on windows/mac, but means that oF has linux support.
From personal view, it seems like more agencies use Cinder while more independant devs use openframeworks, but that really doesn't say anything of the frameworks themselves, more the communities.