Share, the thesis project of Yannick Assogba in the MIT Media Lab Sociable Media Group, is an interesting idea in coding: it’s basically a peer-to-peer sketchbook for creative code. All of your sketches are synced to everyone else’s sketches, and Share tracks the connections between users.

http://share.media.mit.edu/about

You get more from Share than you would from simply, say, sharing a Subversion repository. Share not only syncs code and changes, but also tracks each time you copy and paste code from elsewhere, so that code snippets borrowed from others can be traced through the people using the system.

Up to 30 people are now invited for an online competition using the tool.

The Share Experiment is an online competition/design-a-thon/hack-a-thon and exhibition that invites 30 participants form to use Share to make new creative works over the course of ten days. The theme of this competition is "Inspired By Pong". Though the final result need not be games, artists/hackers are invited to reinterpret and remix the concept of pong while at the same time being open to reinterpretations and sampling of their own work as it being created. The Share Experiment will run from June 5th - June 14th and we are inviting applications. There will be some prizes awarded to winners (including iPod Touch[es] and Arduino kits) and we have some interesting ideas about mechanics for awarding prizes!

http://share.media.mit.edu/participate (via toxi on Twitter)

What is the Best Way to Share?

It’s a very cool idea, but this does raise some questions about implementation. It’s too bad that Share can’t run as some sort of plug-in; it loses some of the functionality of the bare-bones Processing editor, let alone the capabilities of an IDE like Eclipse or NetBeans. If it used a standard IDE, too, it’d be easier to be “language-agnostic” as the creator suggests. (OpenFrameworks or Flash or Processing, it wouldn’t really matter.)

But as a concept and an experiment, this looks really fascinating. It should be interesting to see how people use the code. And will users in a “competition” do a lot of copying and pasting, or focus mainly on their own work?

Part of the reason I bring up this is that we’re interested on CDM in doing some shared work. “Share” I think would be too limiting; it’s back to the old-fashioned Subversion approach.

So, for instance, we’re organizing a hackday around tangible interfaces in June, the first of what I hope will be many more. We’ll have people working on it in person in New York, but also folks collaborating around the world online. I’ll post more details, but just to kick off the discussion:

http://hackday.noisepages.com

It’s a relatively easy thing for computers to “see” video, but “computer vision” goes a step further, applying a wide range of techniques by which computers can begin to understand and process the content of a video input. These techniques tend toward the primitive, but they can also produce aesthetically beautiful results. The best place to start with computer vision has long been the standard library, OpenCV. A free (as in beer and freedom) library developed by Intel and with ongoing use in a variety of applications, OpenCV is a terrific, C/C++-based tool not just for things like motion tracking, but video processing in general. OpenCV gets a lot of support in the C++-based OpenFrameWorks, but that doesn’t mean Java and Processing have to be left out of the fun. (In fact, I’d still recommend starting with Processing for OpenCV, because other tasks remain easier in Java.)

I expect to have us working a lot with OpenCV over the course of 2009. To get the ball rolling, I’m pleased to welcome guest writer Andy Best, a self-described “Interaction Designer/visualist/musician/general technology tinkerer.”

Andy Best

Before you get started, be sure to grab the library, following the instructions here (and check out the quite-nice, clear examples):
OpenCV library

Note that this will also work with standard Java projects, not just Processing. I’ll also be doing some cross-platform testing on Mac, Windows, and Linux with video processing using this library and GStreamer/GSVideo for Processing.

Here’s Andy:

There’s a ever-expanding scene that appreciates digital motion graphic design and art worldwide, but while the US has the awesome research shindig SIGGRAPH, it’s been tougher for the community around digital motion to come together. MGFest has been working to change that. Its first five years have done a lot to promote the best in motion – see the lovely imagery above — but 2009 is the year it explodes, with a year of events focused regionally. By going from city to city, it’s amplifying the best of the art happening in the corners of our geographically-huge nation. And it’s found an ideal place to start: Chicago.

If you’re nearby, you can get into all the MGFest events (minus the Imagination College workshops) for a ridiculously-tiny $7. That’s seven bucks total – I didn’t leave off the zeroes usually associated with events. (Ahem. TED recession special, anyone?)

mgfest.com [All the latest event details]

There’s quite a lot to cover, but to get things kicked off, here’s a look at what’s coming to Chicago. And, oh yeah, I’ll be part of the festivities, giving a short panel talk Friday, a big set of workshops for Saturday, and performing Sunday evening (Michael Una of CDM will be there, too). More on that soon.

I’m really pleased Create Digital Motion gets the chance to sponsor and cover this series. Stay tuned, as we’ll try to bring as much of this to the rest of the world as we can.

We really do need a new rich Internet platform. We need more seamless platforms that work across operating systems and mobile devices. And, in an issue extremely relevant to this site, we need development tools that make it easier for artists of all kinds to create media software and digital artwork and performance tools. The smarter those platforms, the more amazing artwork and live visuals and VJing you’ll see – scroll through the archives of this site or the Processing exhibition for proof. Small as that market may be, it’s my belief that the artistic, cutting-edge output is what will drive the future of media on digital devices. They call it cutting edge for a reason – it’ll be part of something bigger.

The bad news is, wishing for a better platform doesn’t make JavaFX 1.0, released yesterday, look any better.

JavaFX is a new platform for development, based on Java. It combines a new set of media APIs and graphics rendering engine with a new scripting language (JavaFX Script), and wraps this in a set of integrated development tools and workflows. It still runs on the Java Runtime and can leverage that platform, which is, on paper, a good thing. That means you aren’t closed off from the powers of the Java platform, or even from the existing work done by Java ME.

All of this is great on paper. But Sun has a unique problem. JavaFX isn’t “Too Little, Too Late.” It’s “Too Little, Too Early.” It’s about playing catchup to Flash instead of extending on things Java can do that Flash can’t. And it simply isn’t ready yet. No one in their right mind would call this a finished 1.0 release. It’s an early beta, and the absurdly hyped-up talk from Sun and the Java community could turn the whole thing into a huge disaster.

Worst of all, it does exactly what everyone feared: it makes it even more unclear what Sun’s development plans are for the more-capable conventional, if aging and incomplete, Java APIs. And the whole point of JavaFX, distributing across devices? Tough luck: “1.0” works only on the latest Java 6 for desktop PCs and 64-bit Macs.

The slogan for JavaFX is “Do More.” Yep, that sums it up. For anyone to pay attention, JavaFX needs to Do More.

The short version:

Good:

• Good 2D rendering
• Timelines, animation
• Works with NetBeans, integrated tool for working with artists
• Plays media
• Built on Java

Fine, if not earthshaking. And I will say, go try out the examples: there is promise here, especially if you call is a “Developer Preview” or some such thing. But then we look at the …

Bad:

• 3D not available yet; no roadmap
• Media APIs limited to playback
• Beta bugs and documentation holes in a “1.0” release
• Murky open source plans
• Still waiting on Linux and mobile deployment (mobile promised for spring 2009, but with some details missing)

The creative, visual development platform Processing has undergone what may be one of the longest, strangest betas ever – in a good way. What other “beta” has had tomes written about it, tens of thousands of students studying it (in some large programs, as the basis of their work), rockstar music videos made with it, museum exhibitions, major ads, print graphics, motion graphics – all over the course of a number of years.

Processing.org

Download Processing, and you might be forgiven for thinking this “beta” thing would last forever. Insanely frequent updates only reinforce that idea, as though “beta” really meant “ongoing development.” And after all, the software isn’t like other apps. It’s entirely open source and free. First download it, and you’re presented with what seems like a stripped-down text editor. There’s no real manual, as such: instead, you delve into an elegantly-composed reference to commands, and the real “help” is in the form of folders of example code. Yet this environment is capable of visualizing data, crunching 2D and 3D imagery, video, sound, and via external libraries, anything that you can do with Java – opening it to one of the most-extended platforms around.

But believe it: the beta really has ended. As of Monday, Processing the “beta” is now just Processing. The number scheme has changed, too: it’s just 1.0 now (0162, if you’re still counting, though it will no longer officially be called that).

We’re really pleased on this site that Processing has hit 1.0, not just because of what this tool itself means, but because of the bright future we see for expressive visuals, live visual performance and visual interaction, and the DIY creative movement. Over the coming days and weeks, we’ll have everything from learning materials to interviews to celebrate the launch. Someone somewhere ought to really get some champagne (or considering it’s based on Java, maybe some Irish Coffee). And after years of waiting, coding, learning, artmaking, and an epic development effort by co-creators Ben Fry and Casey Reas, the core developer team, and the wider community, I think this deserves more than just a few hours of attention. Given what Processing has done in beta, it’s almost (wonderfully) terrifying to think what it could do after 1.0.

What’s changed, current users?

If you’re a current user, you’ll want to take a real look at the change log, because the last few weeks of coding have brought more rapid change and bug stomping than any time in recent Processing history. Some highlights: