C4: An opensource creative coding framework for iOS
c4ios.comHey all, I'm the creator of C4. Last week we released a new version of C4 (it's entirely Swift).
Questions / comments / feedback of any kind would be great, and will only help us make the project stronger.
I've scanned the site and am a bit confused: I guess I was expecting something like Processing[1] or the like, but from the example it looks more like a framework with conveniences, dare I say similar to MPWDrawingContext[2][3] though with a slightly different domain.
However, except for a few examples (which look like convenience methods), I don't see anything that tells me what specifically this is for or how my code would benefit.
[2] https://github.com/mpw/MPWDrawingContext
[3] http://blog.metaobject.com/2012/06/pleasant-objective-c-draw...
Hey mpweiher, thanks for the feedback. C4 is definitely similar in nature to Processing, animation / interaction / creative coding. I used to be big into Processing, and drew a lot of inspiration from that project as well as OpenFrameworks.
The cosmos tutorial (www.c4ios.com/cosmos) is an end-to-end tutorial for building an app with C4. We are converting a lot of examples from V1 and are currently building new examples / tutorials, all of which will help with understanding what C4 can do and how it can be used.
We are always looking for improved ways to explain C4 and its benefits. We definitely welcome feedback from the community on how to improve our messaging.
As for MPWDrawingContext, it looks like a nice wrapper around CGContextRef. C4 sets itself apart because it handles interactivity (gestures, etc.) and audio / video. You can draw / animate, and build fully interactive interfaces.
> As for MPWDrawingContext, it looks like a nice wrapper around CGContextRef.
Exactly (for now). It has a clear problem statement (the functionality is great but the API is awful) and then demonstrates how it solves the problem.
> C4 sets itself apart because it handles interactivity (gestures, etc.) and audio / video. > You can draw / animate, and build fully interactive interfaces.
That cannot be what sets C4 apart, because the APIs that C4 is built on top of let you do all of these things.
It's as if I wrote that what sets MPWDrawingContext apart is that it lets you draw beautiful graphics. While it is true that you can draw beautiful graphics with MPWDrawingContext, you can draw those same beautiful graphics with CGContext, so that is not the distinguishing feature. The distinguishing feature is that doing so is just much more painful with CGContext and much more pleasant with MPWDrawingContext.
Framing it this way makes it immediately clear whether you might want to look at MPWDrawingContext (you don't find the CG API very pleasant to use) and helps you evaluate it (looks more pleasant to me, I'll give it a try vs. that looks worse than CG, close the window).
For C4, the first guess is that it's like Processing, but then I see that there's no interactive app, which to me is the key distinguishing feature of Processing. Since you don't currently have an interactive app, my guess would be that you are saying you have libraries that are "Processing-like", is that correct?
I personally always thought those particular libraries were fairly nondescript/generic graphics libraries, so possibly that's what I don't understand and maybe what you might need to explain.
The two examples you have on the home page don't make a very compelling case for the fairly grand claims, width vs. size.width is at best questionable, and CA/UIKit have both implicit and block-based animations that look just as good as the example you give.
> It has a clear problem statement and then demonstrates how it solves the problem.
C4 address many issues across a variety of frameworks, while at the same time tries to make working across those frameworks feel more consistent. This makes a clear problem statement more difficult to nail down, but we’re definitely trying to find that description. For example, in my practice I use C4 for commercial work (building apps for clients), I use it for experiments, I build artworks with it, I teach / lead workshops, I have made print works with it, and a lot more. Describing C4 as a “drawing tool” or “wrapper around UIKit and Core Animation” would do the project disservice because its intention is to be bigger than that.
> That cannot be what sets C4 apart, because the APIs that C4 is built on top of let you do all of these things.
You raised the point about MPWDrawingContext to which my response was aimed, C4 can handle interaction / media / etc. where it seems MPWDC cannot. I fully acknowledge that C4 is built on top of frameworks that handle animation and interaction, and didn’t mean to imply that it sets itself apart from UIKit, Core Animation, etc.
> For C4, the first guess is that it's like Processing
C4 is definitely inspired by Processing and OpenFrameworks, I used both of those projects extensively in the past. I learned immensely from both of them and I hope that C4 will provide the same kinds of opportunities for other people.
> ...but then I see that there's no interactive app, which to me is the key distinguishing feature of Processing. Yes, the app is a fantastic tool for working with Processing, learning the language, exploring examples and building projects. However, you can use Processing outside of its app. Similarly, OpenFrameworks is very Processing-like, yet it doesn’t have an app either, and that doesn’t limit the project.
> Since you don't currently have an interactive app, my guess would be that you are saying you have libraries that are "Processing-like", is that correct?
Yes. But they’re also UIKit, Core Animation and AVFoundation-like as well, so claiming C4 is only Processing-like would be misleading.
> I personally always thought those particular libraries were fairly nondescript/generic graphics libraries, so possibly that's what I don't understand and maybe what you might need to explain.
From a software architecture perspective you might be right, but the purpose of those projects are bigger than their apis / libraries. The point is to enable people who would otherwise be unable to use programming for creative expression, and to promote “software literacy within the visual arts and visual literacy within technology.”
I've long thought that UIKit (and supporting frameworks) need a simplified API. I also believe that the best "bang-for-buck" for developers is learning the platform APIs, not third party wrappers, since that's the most transferable skill. How do you balance those competing interests?
This is a great point. One of our main goals with the project is to keep the api as similar to its underlying language as possible. We did this for the ObjC version, and now for Swift as well, meaning that for anyone learning C4 they’re actually learning Swift. However, there are certain points where simplifying will make changes to the language, and in those cases we’ve taken care to make sure that those changes are both modern and also reduce a lot of overhead for the developer.
Our goal is to have C4 make life easier for people: 1) those who are interested in learning UIKit can start with C4 and dig into its open-source base to gain more transferable skills, 2) those who are not interested in learning UIKit or transferable skills but just want to put something together fast, 3) people who already know UIKit / Core Animation but don’t want to deal with some of the complexity.
I've been taking a different approach for the last few years, building apps in MOAI, which is basically "like Java, but you get to/have to be a native host developer as well".
MOAI is a cross-platform Game-engine/GUI-toolkit designed tot allow pretty fast depiction of games/GUI interfaces, specifically game-like interfaces. It is very easy to get a working game environment, of most of the most common forms, in 20 or 30 lines of code in MOAI, i.e. Pong, jump'n'run, shooter, etc.
On top of that, there are already 3rd-party frameworks which implement some sets of standardized "GUI" basics like sliders and buttons and scrolling scenes, and so on. So its possible to do a common GUI that runs exactly the same on all platforms - i.e. ignore native entirely and boldly forge ones own ecosystem of standards.
Which is actually kind of nice, to be honest.
So I'm wondering about the C4 side of things and your plans to embrace/wrap/extend the GUI world. Will you be a subscriber to the native world - and thus either have to do a lot of native host code (or find some way to make your developer-users responsible for the problem) - or do you think there is a future in non-native/runs-everywhere GUI development beyond that provided 'by the majors'?
I'm going to put C4 on the lab-bench some time in the next few days, looking forward to checking it out ..
Being platform-independent is definitely a major feature that we’ve had discussions about over the last year. Ideally, yes, we want C4 to go beyond simply an API for designing interactions, exploring and building apps for iOS. We’re hopeful – with Swift now being open-source – that it will be ported onto other systems, and if that’s the case then we see a lot of potential for being able to have C4 be part of that movement. How that pans out is still unclear, but even in the shift from ObjC to Swift we’ve started to make attempts to abstract our API in ways that would allow us to make the jump to cross-platform more easily.
I definitely think there’s a future for non-native, but right now the lock on hardware drives the current climate of software development (for mobile). The current animation/media/interaction core of C4 is just a first step towards a lot of other integrations, add ons and components that we want to build out. So, for now I’m a subscriber to native because I think that it’s still a lot of work to build out C4 to something mature and stable for a single platform.
> Looking forward to hearing your experiences with using C4 for the first time.
Are you planning on selling this in the UK? I think you're violating a trademark owned by Channel 4.
C4 is a community-driven open-source project, that has been made through the work of volunteers. We aren't selling the core api in any market. It also has an MIT license so it is free to use for anyone, including in commercial works.
The law will catch anyone who tries to sell services related to the registered trademark.
IANAL, TINLA. AFAIK, trademarks only apply within their market segment so it shouldn't be a problem.
Channel Four have a patent within the computer software subsection of category 9 of the classifications.
> Faster and better.
Got the the site - got a frozen page with the above tagline against gray background for few seconds, then a very choppy video started to play. Couldn't make it past the second pageful, because the page had a massive lag scrolling and it was ultimately unusable.
Perhaps have a lighter version with just the content and no bells or whistles?
This put me off too, although only Firefox has responsiveness issues.
The fade between the 3 background vids in the jumbotron of that landing page works really well in Chrome. I've not seen it done like that before, nice work.
And awfully in Firefox, full UI lag.
I know Firefox's implementation makes this its fault, but come on, it doesn't hurt to test the home page in it.
Thanks for the heads up. Will get on fixing that.
How can they be copyright 2016 when it's not 2016 yet?
Typo. Fixed.
I'm not sure I get the joke involving:
let bananaName = “Jimmy”.banana
It's from the official swift tutorial when they talk about extensions.
Looks pretty neat. I'm not interested in iOS per say, but I have a Macbook, iMac and I'm looking at making animation, interactive stuff on those devices.
After looking at your c4's different github repos, it appears you've started some c4 stuff for OS X as well. I'd be interested in this framework if some resources went into the OS X side as well.
Good digging. We started working on the OSX branch recently. We have a slack channel you can join to ask questions / keep in touch about our progress on that branch.
Everyone is welcome to join: https://join-c4.herokuapp.com
Cool! I'll definitely jump on the channel if I have any questions.
Main copy font should be darker/heavier. I bet Museo Sans of that weight and copy is readable on a Macbook Pro. On this notebook its readability leaves something to be desired.