something in the way

a tumblog about design + code
Sep 29

Getting Started with Processing for Android


Photo (CC-BY) Kristian D..

Pick up a pen and draw a sketch. There, that was easy – however crude, you can get out an idea. Sketching with paper is still the fastest way for most of us to imagine something. But between that immediacy and the end result, you need prototypes.

The Processing language has long been one of the easiest ways to sketch an idea in code – best after you’ve first put pen to paper, but as an immediate next step (and for ideas you just can’t draw). Built in Java, the creation of Ben Fry and Casey Reas and a broad community of free software makers, it runs on Mac, Windows, and Linux. Via Processing.js, the same API works in a browser via JavaScript. It has inspired the OpenFrameworks project, which uses nearly the same API. Those tools let you intermingle Java, JavaScript, and C++, as they’re written natively in those languages.

Processing now runs just as easily on a mobile platform with Android. You can try it with the free SDK and emulator, but it’s most fun with a device. Using all free software, you can sketch easily on mobile and desktop from one environment, and with only minor modifications, run the same code on a desktop, a browser, and a mobile device.

Translation: with one, elegant API, you can “sketch” visual ideas on screens from an Android phone to a browser to a projection or installation. As a prototyping tool, or for finished projects, that makes it an exceptional, expressive tool for making interactive visuals for screens.

This is a first-draft tutorial, as I make the same presentation in Stockholm at the info-rich Android Only conference. I’m eager to put it out there and find out that people have problems, as I can then improve the documentation. So do give it a try – especially if you’ve got (or can borrow) an Android phone.

Media_httpcreatedigit_upnvf

Processing on Android performs all of the core functions of Processing on desktop – 2D and 3D visuals, data manipulation, images, and type – and you can mix in Android code using the standard Android APIs, right in the same project. Processing controls the screen on which it’s drawing, for now, but you can mix and match everything else, to support multi-touch, sensors, and even NDK code. (I’m using it with Pd for Android, with Pd doing sound and Processing doing visuals.)

I’m assuming basic familiarity with Processing, so if you haven’t tried it out yet, check out the excellent tutorials available online to get rolling.

Install Processing and the Android SDK

Definitely read the latest official instructions:
http://wiki.processing.org/w/Android

Media_httpcreatedigit_eadie

1. Download the latest pre-release version of Processing. Eventually, the standard Processing download will support Android automatically out of the box – very cool. The current stable version doesn’t yet have Android support, however, so for now, you’ll need the latest pre-release build, which includes all the code for the testing release of Processing for desktop and Android. I tested with 0190.

2. Download the Android SDK. For now, you do need to download the SDK for Android separately, which is an extra step – but at least it’s completely free, and runs on any OS. See:
developer.android.com (This step will eventually go away.)

You can put the SDK anywhere you want; just make a note of where you’ve installed it, as you’ll need to point Processing to that location later. Follow the instructions carefully on Google’s site. On Windows, you’ll need to download the USB driver. On Linux, you’ll want to read the complete Developing on a Device instructions, as there are a few short commands you have to enter at the command line because of the way Linux talks to USB devices.

Lastly, even though that SDK is a big download, you’re not done until you download additional components from Google. This allows a single recent version of the SDK – like the 2.2 SDK I tested – to support a variety of older versions for backwards compatibility.

I have Eclipse installed, because it’s a handy tool for developing Processing for desktop and Processing for Android on any OS. Once you’ve installed the Eclipse plug-in for the Android SDK, you can add components from inside Eclipse. Inside that IDE, choose Window > Android SDK and AVD Manager Manager and you’ll get a graphical interface for adding these components (pictured).

You can now also access the same interface from within Processing. Choose Android > Android SDK and AVD Manager.

Media_httpcreatedigit_xpsbg

Media_httpcreatedigit_kioid

For Processing 0190, you need the SDK Platform 2.1, API 7 and Google APIs by Google, Android API 7. (If you’re an Android developer, you’ll probably also select some other components here, as well.) Components are available under the Available Packages.

If for some reason you prefer to use the command line, head to the Windows, Mac, or Linux command line, and follow the commands in the Quick Start under the Android SDK download instructions.

3. Run Processing, and switch to Android Mode. Load the Processing IDE you just installed, and switch to Android Mode.

The first time you do this, you’ll need to direct Processing to your Android SDK. Choose the root directory of the SDK – the directory that contains “add-ons,” “docs,” “platforms,” “tools,” and the like.

Media_httpcreatedigit_cdfua

Media_httpcreatedigit_dbheb

4. Try running a sketch on the emulator. I’m compiling a set of simple sketches you can use with Android, but even many of the basic examples will work out of the box. For fun, you can try sketches like those found in the Examples > Basics folder and some of the other included Processing Examples. They don’t take into account varying screen resolutions, which is a cool feature of Processing for Android, but it’s still fun to watch them run.

It’s simple to run a sketch. Open the sketch you want, go to Android > Android Mode to enable Android Mode for the sketch, and then hit Run. Instead of opening in a window as desktop Processing sketches do, you’ll see an Android emulator appear.

Media_httpcreatedigit_iazwe

Be prepared for the emulator to take … some … time. You’ll spend a long time looking at the load screen. When it does finally load and install, there may still be a delay as you stare at the main screen. You may have to hit run again. You may see error messages saying an application has become unresponsive – don’t worry about that; Android has a low threshold for applications timing out, so while the emulator is loading, just choose “wait.” And because the emulator defaults to a large screen size, it’ll also take up some room on-screen.

Media_httpcreatedigit_gdcmr

It’s just slow, painful, slow, and unreliable. Fortunately, running on the device is near-instantaneous and speedy, so beg or borrow access to one and try the next step.

5. Try running a sketch on a device (if you’ve got one). Running on the emulator is a pain, but running on a device is very quick – even quicker than you might imagine if you’ve come from a background on iOS. (Remember, you’re working with Java, not native code.)

In a clever design feature, to run on the device instead of the emulator, simply choose Present instead of Run. (The quickest way is simply to shift-click the play button.)

So long as you have a device connected with USB, and USB debugging is switched on, and you’ve done the setup correctly above, you’ll see your sketch appear on the device.

Now, that’s more like it.

“But, wait,” you say. “Android devices have all different screen sizes. Augh, fragmentation, fragmentation!”

Fret not: computers have different screen sizes. Projectors have different screen sizes. And Processing on Android can easily adapt to the size of the screen. We won’t need much Android-specific code, but let’s get started with our own Processing sketch and see how it works when you’re preparing for mobile.

Media_httpcreatedigit_cshzh

Try Writing Some Code

Okay, so what does a Processing sketch for Android look like? Here’s a really simple example, just to show off basic drawing, managing different screen sizes, and simple (single) touch. (I’ll leave density for another day; multitouch and other touch events are also possible.)

float sw, sh, touchX, touchY;

void setup() {
  size(screenWidth, screenHeight, A2D);
  println(screenWidth);
  println(screenHeight);
  sw = screenWidth;
  sh = screenHeight;
}

void draw() {
  background(0);
  smooth();
  fill(255);
  noStroke();
  ellipse(sw/2, sh/2, sw/4, sw/4);
  noFill();
  stroke(255,0,0);
  strokeWeight(2);
  ellipse(touchX, touchY, sw/4, sw/4);
}

void mouseDragged() {
  touchX = mouseX;
  touchY = mouseY;
}

Two things to note, in particular:

size(screenWidth, screenHeight, A2D);

(Warning: don’t put variables in that size() command.)

Processing for Android will map the desktop renderer names to either A2D (for 2D graphics) or A3D (for 3D). (I’m using the Android names here, but the other names will work just fine.)

Also, since static pixel sizes don’t make sense on mobile platforms with different screens, you can substitute “screenWidth” or “screenHeight” and get dimensions from the device on which you’re running. (I just used “sw” and “sh” because they’e shorter, and then I can make everything else relative.)

void mouseDragged() {
  touchX = mouseX;
  touchY = mouseY;
}

Here’s the really cool part — touch input works exactly the same way as it does on Processing on a desktop, for relevant mouse commands (nothing involving these strange “buttons” of which you speak). mousePressed, mouseDragged, and mouseX and mouseY all work as expected, so long as you’re satisfied with simple, single touch and don’t need gestures, multitouch, and the like. Don’t be confused by my touchX and touchY variables — those are just to demonstrate that my circle only moves when it’s “dragged” — or your finger slides across the screen. What we have is the beginnings of a drawing app, which I’ll be expanding over coming tutorials.

Here’s the other cool thing: modifying only the references to screenWidth and screenHeight, and the renderer, I can run exactly the same code in Processing on the desktop, or even in Processing.js on a browser.

Media_httpcreatedigit_zdiue

Media_httpcreatedigit_tiefd

Tune in Next Time…

This is not a replacement for the official wiki documentation, so do read that, please.

In coming installments, I’ll share:
1. How to get Processing for Android working inside Eclipse. In short – it works. That makes adding Processing to an existing Android app easy. (Hoping to follow that up with gedit and Ant)
2. More advanced tricks for dealing with screen dimensions and touch.
3. Android-native snippets for connecting sensors.
4. How you can combine sound and visuals with Pd and Processing, both running on Pd.

Other things that are possible to do with Processing for Android (which I’ll cover):

  • Use install custom or installed fonts
  • Data visualization (just as on the desktop version – making this much easier on mobile than in the past)
  • Touch events, relative motion, and key events
  • Force a specific orientation
  • Add security requirements to the manifest (for things like sensors), right from the PDE app – no need to edit a file or go to Eclipse

I also hope to take some notes on what happens here at Android Only.

Processing for Android is still in development, and this is pre-release software. So be prepared to encounter issues. That said, I want to refine this documentation, so please let me know if you encounter issues with my instructions.

Presentation slides

Here’s my presentation from Stockholm:

Processing for Android: Getting Started
View more presentations from peterkirn.

Share what you’re doing…

Noisepages registration is open again as we finish the site. Share what you’re doing, devices you’re testing, or other thoughts:
http://noisepages.com/groups/processing/forum/

Media_httpfeedsfeedbu_htdgz
Media_httpfeedsfeedbu_jfqcv
Dec 15

Teaser: Processing is Coming to Android

The remarkable thing about Processing on Android is that you can use your (desktop) sketchbook development environment as always, then run on the Google emulator or your device.

Google’s open-source Android mobile platform runs on Java. Processing, the elegant coding language for visualization, art, and media, is built in Java. The marriage of the two, therefore, is one we’ve long been anticipating. Processing’s ability to focus on lightweight, portable implementation is a perfect match for the demands of mobile development. For artists and visualists wanting to make handheld devices and tablets more expressive, I have good news: it’s coming. While not fully implemented or ready for widespread testing yet, Processing is in active development on the platform.

Ben Fry, co-creator of Processing, has been hard at work making Processing run on Android. Interestingly, in some ways Android itself vindicates the direction Processing charted years ago. Google made their platform work based on open-source development tools. They removed parts of the Java platform that would have overwhelmed the limited processing power of handhelds – even as a handful of purist Java developers cried foul. Graphics focuses on lightweight 2D and OpenGL drawing output, much in the same way that Processing strips Java to its bare essentials.

Best of all, doing Processing development for Android promises the same streamlined, sketchbook-like production flow that Processing does on desktop. To create Android apps, you simply set Processing to “Android mode.” (Right now, you have to point to Google’s SDK, but that happens only once and may be removed in future versions.) Hit run, and your sketch launches in the Emulator. Plug in an Android device via USB, and it’ll run on your device. Soon, you should have one-click-export of apps in the way that you do Processing desktop apps.

This also suggests some great possibilities for cheap, handheld devices, installations, and reliable portable devices for visual performance. Sure, right now a lot of Android-powered devices require a phone contract and don’t output video, but a lot of devices slated for later this year are media devices with video output and tablets, too.

Processing for Android is an early work-in-progress. If you’re thinking about playing with it and you don’t know what you’re doing, or you have little patience for bugs and wrinkles, you should wait until the waters grow safer. Right now, the team working on testing the port is intended to be limited, although as someone testing it myself, I can say it’s already a lot of fun and holds a lot of promise for the future. OpenGL support is currently not available, but it’s coming – and I’ll say again, if you want to know what Processing’s 3D future looks like, check out the superb GLGraphics library. Anyone who thinks Processing can’t be fast, or do intensive GPU work, or mix HD video (okay, not on Android, but on desktop at least), check out this library. OpenCL should also be possible soon.

http://android.processing.org/

BIG, BIG disclaimers! Please don’t go testing Processing on Android assuming it’ll work out of the box – for the brave ONLY, at least for now. (That should change very, very soon, but I couldn’t keep the news under my hat any longer.) As the disclaimer says (hilariously):

Do not use this code while operating heavy equipment. Do not rely on this code for thesis or diploma work, as you will not graduate. Do not use this code if you’re prone to whining about incomplete software that you download for free.

A number of us have already begun talking about the possibility of adding libraries to connect Processing’s capabilities to Google’s own APIs for the phone, SMS, sensors, and so on. Sound and synthesis via external libraries should also be possible.

I think Processing for Android is the perfect complement to openFrameworks for native code on mobile platforms. Right now, OF has already been used for terrific work on the iPhone. It’s not quite as user-friendly as Processing for Android for a number of reasons, but it has Processing-derived syntax, aesthetics, and philosophy, and it’s also free and open. For a superb guide to developing on the iPhone with OF, plus some links:

http://www.openframeworks.cc/setup/iphone

OF does not appear to be a practical solution for Android development, not least because Android requires apps to be distributed as Java, and uses Java to talk to all the native APIs. But it’s a good option for some of these other devices, and you can run the two alongside one another in Eclipse if you like, more advanced users.

With OF on the iPhone (and presumably other native platforms in future – Nokia N900, anyone?), and Processing for Android, plus tools like Pd and SuperCollider for synthesis (more on that soon), there’s no reason not to go completely open with portable interactive art on mobile devices.

Media_httpfeedsfeedbu_bbcao
Media_httpfeedsfeedbu_bexfy
May 21

Merapi Now Open Source

I am in Adam Flater’s session on Merapi at 360Flex and he has announced that Merapi is now open source. What is Merapi? Merapi allows developers to connect Adobe AIR applications, written in Adobe Flex to connect to Java applications running on the user’s local computer. Where can I get Merapi? http://code.google.com/p/merapi/ What about examples? http://code.google.com/p/merapi-examples/ Merapi Group: http://groups.google.com/group/merapi-project So go get it [...]
Media_httpfeeds2feedb_kjmaz
Media_httpfeeds2feedb_tghfk
Media_httpfeeds2feedb_othja
Media_httpfeeds2feedb_mesam
Media_httpfeeds2feedb_eoeuh
Media_httpfeeds2feedb_gccjd
Media_httpfeeds2feedb_oixxu
Media_httpfeeds2feedb_ojbve
Media_httpfeeds2feedb_huerg
May 12

Touchscreen Particle Drawing, Memo’s MSAFluid Particle Library, and Why Sharing is Good

Interface 27 from CyberPatrolUnit on Vimeo.

There has been a long tradition in live visuals and motion graphics, inherited from many other media, of maintaining a “secret sauce,” or the guarded formula of eleven herbs and spices. Ironically, for all you hear today “DIY” and “open source” in the same sentence, a lot of the motivation for doing something yourself has historically been doing something no one else can. Keep your secrets, and raise your value.

As our friend Bryant Place / CyberPatrolUnit sends over this latest set of live clips from a recent gig, and I browse through the comments, and reflect on the conversations I had last week at OFFF and during and following my own talk there, though, I’m struck.

The world has changed. First off, the Internet isn’t really about secrets. Your value is almost in direct proportion to how much you can share. Connections are forged through links of mutual exchange and good will. It’s not just about sharing your output or getting fans (the MySpace model), but sharing with a network of enthusiasts, and fellow artists. Those are the people from whom you often get real support (artistic, technical, and personal), gigs – and inspiration. (Even if you hate 8-bit music, that community is a really amazing model: their work to support each other and advocate for the whole subgenre has been I think the single biggest ingredient in their viral success.)

The visualist community increasingly itches not only to improve the quality of their own individual work, but everyone around them. A lot of us are in a battle for the future of this whole medium. Some parts of the world are devoid of live visuals, while others have mass-produced club visuals filling the nightlife.

Before I get carried away, the video itself is just the latest from the ongoing Interface 27 series. It employs a touch interface to control abstract visual pictures formed from streams of particles.

The reason I’m pulling back into the larger question is that these visuals are enabled by a library for Processing, a library we’ve seen here previously, developed by Memo Atken:

MSAFluid for processing (and Java)

If you’d rather use openFrameworks, there’s that version, too, as pictured below running blazingly fast:

ofxMSAFluid for openFrameworks

There’s even an ActionScript 3 port, in case you want to code Flash on the beach.

ofxMSAFluid for openFrameworks from Memo Akten on Vimeo.

So, why do I bring this up? Well, the work done on Processing (Ben Fry, Casey Reas, contributors like Karsten Schmidt, and others), on openFrameworks (Zachary Lieberman, Theo Watson, and their own team), and Memo’s own library, based in turn on many other libraries and implementations, was all a big risk.

It’s not an easy thing to put blood, sweat, and tears into open source. None of those people has exactly gotten rich in the process – not even via the ways you’re supposed to profit from open source, doing the lecture circuit and such. But on the other hand, we’re seeing things that would have been otherwise impossible.

And there’s artistic merit, too. Bryant’s work looks different than Memo’s. The library actually takes on a new life as it gets in someone else’s hands. Bryant actually just wrote me:

As for the Interface video - mention how cool it is that people like Memo post code for other VJ’s to tweak and use.  Mention "FaderTouch" - a 100buk touchscreen off ebay that "vjFader" programmed - using a rear projection onto a translucent screen/ touch sensor we were able to use processing in a very intuitive way.

I got the “mention” part down, I guess. ;)

The responsibility is partly ours to make all of this work: file bug reports, fix bugs if you can, document your work, properly credit the people making it, write documentation for projects, and so on. But it’s not hard to see an ideal start to happen:

1. Person x makes a library / framework.

2. Person y build on that library to make their own tool – and contributes it.

3. Artist uses the tool, gives back to the project, goes in a new direction.

4. More and better work spreads, the project grows, the medium grows, and the audience grows.

None of this happens automatically. We all have a lot more work to do. But having stood onstage in front of a few thousand people calling for just this, it’s nice to keep opening my inbox and seeing it happening. We’re seeing the first seeds planted for what could ultimately be a larger ecosystem. Now, I know there’s also a big gap left – Processing doesn’t have nearly enough contributors, bug squashers, or documenters, and it’s one of the biggest projects, so you can imagine what happens when you get upstream to libraries and the like.

Over the coming months, I think we’ll continue to look for opportunities to help structure some of that involvement and to explaining how you can contribute, too. Stay tuned.

In the meantime, go play with some particles.

For more on Bryant, here he is on his current activities:

- I just did Coachella with [Friend of CDM and contributor] Momo, and in the near future, will be heading to Detroit for http://www.myspace.com/detroitmusicfest

I’m not on the website, however, Kero.fm and Derek Michael - two people who essentially helped build the festival from the ground up 10 years ago - are booking me to play with various acts including CLP, Richard Devine, Drumcell, Busy P (which I did a solo VJ set with at Coachella) so I am super excited to be a part for the first time this year.

Here is a cool video from previous Interface 26:

After Detroit - Mutek.

http://www.mutek.org/

There are also some killer podcasts from past Mutek - http://www.mutek.org/podcast

I am going to meet artists, see the latest AV performances, attend workshops.

I’ll be at Mutek, too, so see you there.

Media_httpfeeds2feedb_xfjei
Media_httpfeeds2feedb_ivije
Apr 22

Google O3D: Mind-Blowing Open-Source 3D API in the Browser with JavaScript + OpenGL, DirectX

Wish granted!

Think 3D in the browser will never catch on? Think again. The folks at Google Labs have built an incredible-looking 3D API called O3D. It does just about everything you want, and then some:

  • It’s multi-platform: Mac + Windows + Linux.
  • It can render to both OpenGL and DirectX render pipelines.
  • You can write your own vertex and pixel shaders. You have to use O3D’s own language for doing this, but that actually enhances compatibility, as frustrated shader coders may already know. (See the FAQ)
  • It’s a scene graph, so managing complex 3D scenes isn’t a chore.
  • It has powerful built-in functions like viewports and pickers (plus custom pickers), so you can actually get something up and running in a reasonable time.
  • It has an import workflow with COLLADA, an open standard for 3D assets (and which, incidentally, has support in Google’s own SketchUp).
  • You code in JavaScript, using the powerful V8 engine (developed for Chrome).
  • Gears lets you run offline.

There are already some complaints about “another standard,” but to me, putting together a whole package here and employing other, lower-level standards (JavaScript, COLLADA, OpenGL, DirectX) makes a lot of sense.

http://code.google.com/apis/o3d/

I expect the folks working on Java and JavaFX are busy thinking about the fact that Sun just got bought by Oracle – something I’m hopeful, at least, ensures Sun’s future and is ultimately a good thing. But I hope someone on those teams is starting to get the message: 3D isn’t just something that’d be “nice to have.” It’s essential. And while even most developers likely don’t have a clue about things like custom shaders, having access to customize the graphics pipeline is likewise something ultimately benefits all developers – even if they just wind up relying on someone else’s code. I really do hope this is a priority with the coming development of Java and JavaFX, which could have the power to do these sorts of things. (Heck, Java could even benefit from the code Google just posted.)

On the proprietary side, this to me is a big blow to Microsoft’s WPF and Silverlight and Adobe’s Director. Unlike those products, O3D looks simple, powerful, flexible, open source, and directly programmable with JavaScript.

That’s not to say there aren’t some questions here – and the Java/JavaFX comparison is especially relevant:

  • Another plug-in: You do have to install a plug-in to work with O3D, something that actually isn’t necessary with JavaFX (when it finally does 3D) or right now with JOGL and Java3D.
  • Mobile, or just desktop? My big question I have is what this means for mobile. I’d love to have O3D work with OpenGL ES on, say, Google’s own Android platform.
  • Not Just JavaScript? It would be nice if eventually you could use other languages like Java to program O3D.
  • Sound? Oh, yeah, that. 3D sound is an ideal complement to this sort of scene, and the browser may be a bit constrained in that respect. I’m curious whether O3D might eventually include an audio API. (And yes, that’s where something like Director is still unparalleled.)
  • Making it actually work: Okay, there’s also the fact that I haven’t successfully installed it just yet. Working on that.

(I’ll try to get answers to those questions.)

Oh yeah, and then there are details like the necessity to write your own custom shaders just to add more than one light to a scene – I think this will initially appeal only to folks with some real 3D experience.

But am I excited? Ohhhhh, yes, indeed. O3D itself looks fantastic, and I think this is a sign that 3D times ahead are going to be really fantastic.

And as long as you have the plug-in working and a browser in full-screen mode, you could literally set up an O3D project as a performance / installation tool. O3D visualists? Absolutely. Enjoy.

Media_httpfeeds2feedb_ywscm
Media_httpfeeds2feedb_zhoht
Feb 20

What Adobe Means By “Open” Screens, and a Mobile Open Scorecard

Software is increasingly a medium for artists. That to me raises really deep questions about platforms, and whether you’ll have freedom with the platforms you use. A gig’s a gig, and there’s nothing wrong with using these tools to accomplish jobs. But on the other hand, for the same practical (not even philosophical) reasons, the ability to modify the platform when you push past its capabilities is essential.

The ability to take your creations and run them on a variety of mobile devices - and how much freedom you have with the tools on which they’re built — is a key issue in 2009, as mobile platforms coalesce.

As I see people making amazing artwork with code, and then we have this question of which of our semi-disposable devices will actually be able to run stuff, I think this is as much an artistic question as a technological question. So it’s worth evaluating how three big players are doing at the moment. And this isn’t just to advocate open source for the sake of it: a big question is whether you’ll be able to write code and get it on mobile screens around the world.

Adobe’s Progress: Patchy, But Productive

Adobe has grabbed some headlines - and some skepticism - over their Open Screen Project. As Google did early on with Android, there’s a bounty for developers ($10 million). But it’s the “open” bit that has had some folks scratching their heads. After all, Adobe is one of the world’s biggest vendors of proprietary, boxed software. That’s not a criticism, necessarily, but it may make you wonder what these “open screens” are about.

Via the FAQ, here’s the answer - and a decent overview of where Adobe is so far:

  • Published, unrestricted SWF file format - no SWF license required (that has indeed enabled some open-source SWF/Flash tools)
  • Royalty-free Flash Player and Adobe AIR in the next release
  • Published device porting layer APIs
  • Open-sourcing Flex framework, the Flash Ajax Video Component, BlazeDS, and XMP
  • The ActionScript Virtual Machine for Mozilla Tamarin project, and contributions to Tamarin performance
  • ISO standardization of PDF
  • Card-carrying membership in the Linux Foundation, the Eclipse Foundation, and the SQLite Consortium - which makes good business sense, by the way, since Adobe benefits from those projects

That’s a pretty admirable record. The only problem - and it’s a big one — you don’t see Flash Player and AIR. They may be license-free, but they’re simply not open-source. It’s these players that really make the experience of playing content work. So Adobe means only that they want to open components of this, and make their proprietary players work better on mobile devices. That’s a worthy goal, but it means you’re fundamentally constrained in terms of what Flash and AIR can do.

So, in other words, Adobe actually turns out to be surprisingly open, but the screens themselves? Not so much.

Silverlight: Free Fail

Then again, this does compare very favorably to Microsoft Silverlight. Fewer portions of Silverlight are open in any sense - the Dynamic Language Runtime is, under a license Microsoft made up, as is the XAML format on which Silverlight creations are based. But that doesn’t include any of the meat of what Silverlight is, and it’s a far cry from Adobe’s entirely open specs and Flex framework. Microsoft is working with Novell on an open-source implementation for Mono — good for Linux and Mono developers, but because it is providing access only to a limited group of people, doesn’t really count as open. And Silverlight’s mobile strategy is murky (Windows Mobile, Symbian for now).

The closed nature of Silverlight means it’s not getting adapted as quickly or effectively on different platforms and OSes. In other words, people may just not use it. That’d be no great loss, except that a lot of what’s going into Silverlight is actually very good. And it’s not unfair to expect more of Microsoft. Part of the success of Windows comes from the fact that its APIs are so exhaustively documented. And the fact that the company has made small steps into the open source world demonstrates that at least some of the people who work at this gigantic company do get it. I just get the sense that the old business model dies hard. It’s their loss, given that they do stand to make more money if Silverlight is more popular, via support and tooling.

JavaFX: Getting More Open

The good news is, both Microsoft and Adobe are responding to a competitive marketplace by opening things up, because it makes business sense. The bad news is, Microsoft isn’t doing it very well, and while Adobe is performing reasonably well, the crown jewels are still proprietary.

And that brings us to JavaFX. Sun earns real points here for being way ahead of Adobe and Microsoft on both compatibility and open licensing.

Compatibility: While Adobe pursues a patchwork approach to getting Flash running on different platforms, the just-released JavaFX Mobile runs just about everywhere. Any Java ME device works. Just about any mobile OS should work in theory - Google’s Android, for one, was shown last year.

Openness: Adobe is “openish,” but JavaFX is getting close to being genuinely open. The compiler is open, though, in fairness, so is the Flex framework. The key is that we’re gradually getting additional libraries and APIs. And since JavaFX runs on Java, the platform itself is open. I’m running JavaFX apps right now on Linux using Java SE. There is no “player” as with Flash, but the bottom line is, with JavaFX you can run your creation on open code; with Flash, you run on proprietary code. And that’s not just a semantic point - here on Linux, there are things that just don’t work or don’t work well because Flash is proprietary. Audio and video work better in Java, particularly on Linux, because people have the freedom to fix stuff. (Out of all the “freedoms,” freedom from borked things to me ranks pretty high.)

So, what do you think, CDMers? Any of these platforms appealing?

I hope to check in with the JavaFX folks next week. For arts use, I’d love to see JavaFX, possibly even a JavaFX-ready rendition of Processing for mobile, and OpenFrameWorks on mobile devices. If you have some questions, I’ll try to get answers.

Background:
Adobe Open Screen Project
OpenLaszlo (open rich clients, but apparently no mobile version yet)
Silverlight @ Wikipedia
JavaFX FAQs
OpenJFX Project

Media_httpfeeds2feedb_diiqz
Media_httpfeeds2feedb_ujubc
Dec 30

Christmas Lights, Controlled by Processing

You’ve likely seen impressive sequenced Christmas lights in videos before. Very often, though, these setups use proprietary systems. Here, Processing makes it quick and easy to code lighting effects in a friendly, open-source environment. And, naturally, if you think you might want to do something like this and don’t want to wait for Christmas 2009, I can imagine quite a few other interesting lighting applications.Creator Jack Kern describes the project:

This is my first attempt at a computer controlled light show for our Christmas lights. Everything was DIY including the software which I wrote in Processing (processing.org). Simple wiring using parallel port output to switch some 120v relays. Only 8 channels, 1500w per channel max. Next year I’ll be trying for many more, dimmable, LED’s and DMX control of our RGY lasers!

It’s worth checking out Jack Kern’s projects page for other goodness. Think Java-based games (2D mobile and 3D desktop), a ray tracer, and source C/C++ code. And yet the man still has hobbies.

Big thanks to TJ Pallas on Facebook for the tip. And please, I do actually enjoy keeping in touch with readers on Facebook. (See my page / profile / CDM’s fan page.)

Media_httpfeedproxygo_jfubc
Media_httpfeedproxygo_edgzi

Get Updates

Tags

Archive

2012 (1)
2011 (11)