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.

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.