Download it here. This is the third alpha release as we head toward 2.0. There are many significant changes in 2.0, so be sure to read up on them.

If you find problems, please file a report so that we can fix them.

The big changes since 2.0a2:

• Several Android fixes to handle recent SDK changes by Google. For anyone using Android, you’ll need to install 2.0a3. The Android page on the Wiki has also been updated.
• Fixed a regression in 2.0a2 that prevented serial from working on OS X.
• Tracked down a problem on OS X 10.7 (Lion) where the mode and open menus on the toolbar disappeared immediately.

The full revisions list with the gory details:

PROCESSING 2.0a3 (REV 0202) – 5 November 2011

Some weekend bug fixing and regression repair for the recent alpha releases.

Also several Android fixes to get things working again with more recent
updates from Google. You’ll need to upgrade to this version of Processing
in order to continue using Android mode.

[ environment ]

+ Fix problem with serial not loading on Mac OS X.

+ Fix problem with popup menus on the toolbar disappearing immediately
when used on Mac OS X 10.7 (Lion).
http://code.google.com/p/processing/issues/detail?id=846
http://code.google.com/p/processing/issues/detail?id=887

+ Incorrect tab/line shown for preprocessor errors when more than 2 tabs
http://code.google.com/p/processing/issues/detail?id=873

+ Commenting via menu or shortcut does not set sketch to “need save”
http://code.google.com/p/processing/issues/detail?id=766

+ IDE Export Application button exports applet (fixed in 2.0a2)
http://code.google.com/p/processing/issues/detail?id=863

[ core ]

+ Fix for video frames not showing up in 3D.

+ Rounded rect() does not have a maximum length for corner radius
http://code.google.com/p/processing/issues/detail?id=813

[ android ]

+ Fix libraries when used with Android. Libraries can also specify
an Android version by including an ‘android’ subfolder.
http://code.google.com/p/processing/issues/detail?id=766

+ Fix problem with export menu, keys, toolbar being different.

+ Change default package name a bit.

+ Switch to SDK 8 (Android 2.2) as the minimum that we’re supporting.
This allows us to rely on far more consistent OpenGL implementations.

+ Update the project files for Android SDK Tools Revision 15 (now required)
http://code.google.com/p/processing/issues/detail?id=876

+ Improve launching with the emulator.

+ Remove ‘includeantruntime’ warning during build.

+ “Date could not be parsed” error.
http://code.google.com/p/processing/issues/detail?id=864

A pre-release with a million billion bug fixes and tweaks. Download here (in the pre-releases section of your grocer’s freezer), especially if you’re using Android. If this feller works, we’re hoping to do a stable release called Processing 1.5 sometime in the next few days. If you have issues, please report them on Google Code (not in the forum!)

PROCESSING REV 0195 – 10 April 2011

Bug fixes and several Android updates. Working to close in on a proper
Processing 1.5 release.

This release has several changes to renaming sketches, using Save As,
and how untitled sketches are handled. Please help test!

Note that on the Android side, this release once again requires installation
of the Google APIs. See the Android Wiki page for details.

[ general ]

+ Sketch restarts automatically after pressing stop button on PDE
http://code.google.com/p/processing/issues/detail?id=561

+ ‘unexpected token void’ for any type of error (due to fallback)
http://code.google.com/p/processing/issues/detail?id=551

+ Deal with weird states when closing last editor window on OS X

+ With one sketch open, changing the mode doesn’t close the original editor
http://code.google.com/p/processing/issues/detail?id=569

+ Move library examples to the examples menu
http://dev.processing.org/bugs/show_bug.cgi?id=1278
http://code.google.com/p/processing/issues/detail?id=181

+ Ctrl-slash not working on Linux (fix from pkalauskas, thanks!)
http://code.google.com/p/processing/issues/detail?id=596

+ Update to Java 6u24 for Linux and Windows

+ Export .java source files with applets and applications.
http://code.google.com/p/processing/issues/detail?id=570

+ Reference broken in 0194.
http://code.google.com/p/processing/issues/detail?id=572

+ Other reference tweaks

+ Fix exception spew when clicking between editor windows.

+ Don’t reload sketch on “save as”
http://code.google.com/p/processing/issues/detail?id=62

+ Smooth text on the status bar on Linux.

+ Clear up some issues with focus handling in the editor.

+ Save As/Rename don’t properly set focus
http://code.google.com/p/processing/issues/detail?id=13

+ “No library found” message when using import statements and the code folder
http://code.google.com/p/processing/issues/detail?id=568

+ Remove version number from splash image
http://code.google.com/p/processing/issues/detail?id=324

+ Subfolders in /libraries folder not supported in 0194,
bring them back for toxi and the toxiclibs folks.
http://code.google.com/p/processing/issues/detail?id=578

[ core ]

+ Deal with bad screen updates for sketches running < 60 fps in JAVA2D

+ OPENGL2 record only saves one line in a LINES shape (fix from Andres)
http://code.google.com/p/processing/issues/detail?id=579

+ normal() command commented out in sphere() method
http://code.google.com/p/processing/issues/detail?id=602

+ save() and other pixel operations no longer working with JAVA2D in 0194
http://code.google.com/p/processing/issues/detail?id=594

[ android ]

+ point() doesn’t render in A3D
http://code.google.com/p/processing/issues/detail?id=592

+ Android stuck at “Starting Build”
http://code.google.com/p/processing/issues/detail?id=590

+ Deal with missing android-core.zip (No such file or directory)
http://code.google.com/p/processing/issues/detail?id=577

+ Error messages about “No library found for android.*”

+ When returning to android application, sometimes screen stays black
http://code.google.com/p/processing/issues/detail?id=237

+ Device Killed or Disconnected Error Message with Libraries
http://code.google.com/p/processing/issues/detail?id=565

+ Better error handling when certain SDK components are not installed.

+ Canceling an attempt to find the Android SDK leaves no window open,
or crash when trying to change to Android mode w/ no Android SDK
http://code.google.com/p/processing/issues/detail?id=605

Another wonderful example, more powerful as words than as an image:

Jan Pen, a Dutch economist who died last year, came up with a striking way to picture inequality. Imagine people’s height being proportional to their income, so that someone with an average income is of average height. Now imagine that the entire adult population of America is walking past you in a single hour, in ascending order of income.

The first passers-by, the owners of loss-making businesses, are invisible: their heads are below ground. Then come the jobless and the working poor, who are midgets. After half an hour the strollers are still only waist-high, since America’s median income is only half the mean. It takes nearly 45 minutes before normal-sized people appear. But then, in the final minutes, giants thunder by. With six minutes to go they are 12 feet tall. When the 400 highest earners walk by, right at the end, each is more than two miles tall.

(From The Economist, by way of Eva)

An info graphic from the Boston Globe:

Fathom Information Design is looking for developers and designers. Come join us!

We’re looking for people to join us at Fathom. For all the positions, you’ll be creating work like you see on fathom.info, plus more mobile projects (Android, iOS, JavaScript) and the occasional installation piece. If you’re a developer, design skills are a plus. Or if you’re a designer, same goes for coding.

• Developer – Looking for someone with a strong background in Java, and some C/C++ as well. On Monday this person would be sorting out more advanced aspects of a client project. On Tuesday they would hone the Processing Development Environment, mercilessly crushing bugs. On Wednesday they would refactor critical visualization tools used by brilliant scientists. On Thursday they could put out a fire in another client project without breaking a sweat, and on the fifth day, they would choose what we’re having for Beer Friday. This messiah also might not mind being referred to in the third person.
• Web Developer – In 1996, I used Java for my Computer Graphics 2 homework at Carnegie Mellon. I’ll never forget the look on the face of my professor Paul Heckbert (Graphics Gems IV, Pixar, and now Gigapan — a man who wrote an actual ray tracer in C code that fit on the back of a business card), when he asked me during office hours why this was a good idea. Your professor did the same thing when you told him (or her) that you’d be implementing your final project with JavaScript and Canvas. We need amazing things to happen with HTML, CSS, and JavaScript, and you’re the person to do it.
• Junior Designer – You’ve finished your undergrad design program and feel the need to make beautiful things. Your commute is spent fixing the typography in dreadful subway ads (only in your head, please). You are capable of pixel-level detail work to get mobile apps or a web site just right. And if we’re lucky, you’re so good with color that you’ve been mistaken for an impressionist painter.
• Senior Designer – So all that stuff above that the Junior Designer candidate thinks they can do? You can actually do it. And more important, you have the patience and humility to teach it to others around you. You’re also an asset on group projects, best friends with developers, and adored by clients.

At the moment, we’re only looking for people located in (or willing to relocate to) the Boston area.

Please send résumé or CV, links to relevant work, and cover letter to inquire (at) fathom (dot) info. Please do not write us individually, as that may void your contest entry.

The roof of the Metrodome springs a leak following heavy snow in Minnesota:

I’ve been looking at too many particle and fluid dynamics simulations because it looks fake to me — more like a simulation created by the structural engineers of what would happen if the roof were to collapse — rather than thousands of pounds of honest-to-goodness midwestern snow pummeling the turf seemingly in slow motion. Beautiful.

And another version from a local FOX affiliate in Minnesota:

Hanspeter Pfister, who teaches a perennial information visualization course down the street at Harvard will be doing a two day course through Harvard’s Continuing Education program:

Data Visualization: Conveying Information through Visual Representations

Date: January 12–13, 2011
Time: 9 am to 5 pm
Location: Harvard University
Tuition: $1,900. After December 20: $2,200
Class size is limited.

The amount and complexity of information produced in science, engineering, business, and everyday human activity is increasing at staggering rates. This program introduces you to visual representation methods and techniques that increase the understanding of complex data. Good visual interpretations of data improve comprehension, communication, and decision making.

What you will learn

• How visual representations help in the analysis and understanding of complex data
• How the human visual system processes and perceives images
• How to critique visualizations and identify the design principles used to create them
• Good design practices for visualization
• Various visualization approaches for different data types

Topics covered

• Design principles
• Perception
• Color
• Statistical graphs
• Maps
• Trees and networks
• High-dimensional data
• Visualization tools

Who should enroll

Professionals or academics who need to analyze and present complex information in an easily digestible manner benefit from this program. The program is open to anyone who is interested in the visual analysis of data. You should have a basic knowledge of how to use computers and the Internet.

Other information

You are encouraged to bring a wireless laptop.

Faculty

Hanspeter Pfister is Gordon McKay Professor of the Practice of Computer Science in the School of Engineering and Applied Sciences at Harvard. His research lies at the intersection of visualization, computer graphics, and computer vision. It spans a range of topics, including scientific visualization, point-based graphics, appearance acquisition, GPU computing, and 3D displays. Pfister also offers his semester-long courses online at Harvard Extension School, where he won the Petra T. Shattuck Excellence in Teaching Award in 2009.

Before joining Harvard he worked at Mitsubishi Electric Research Laboratories as an associate director and a senior research scientist. Pfister has a PhD in computer science from the State University of New York at Stony Brook and a master’s in electrical engineering from the Swiss Federal Institute of Technology, Zurich.

Questions?

Contact harvardprofdev@dcemail.harvard.edu.

Should be great!

Number of Processing users, every four weeks, since 2005:

Long version: this is a tally of the number of unique users who run the Processing environment every four weeks, as measured by the number of machines checking for updates.

Of note:

• In spite of the frequently proclaimed “death of Java” or “death of Java on the desktop,” we’re continuing to grow. This isn’t to say that Java on the desktop is undead, but this frustrating contradiction presents a considerable challenge for us… I’ll write more about that soon.
• There’s a considerable (even comical) dip each January, when people decide that the holidays and drinking with their family is more fun than coding (or maybe that’s only my household). Things also tail off during the summer into August. These two trends are amplified due to the number of academic users, however other data I’ve seen (web traffic, etc) suggests that the rest of the world actually operates on something like the academic calendar as well.

About the data:

• This is a very conservative estimate of the number of Processing users out there. Our software is free — we don’t have a lot to gain by inflating the numbers.
• This covers only unique users — we don’t double count the same person in each 4-week period. Otherwise our numbers would be much higher.
• This is not downloads, which are also significantly higher.
• This is every four weeks, not every month. Unless there are 13 months in a year. Wait, how many months are in a year?
• This only covers people who are using the actual Processing Development Environment — no Eclipse users, etc.
• Use of processing.js or spinoff projects are not included.
• This doesn’t include anyone who has disabled checking for updates.
• This doesn’t include anyone not connected to the net.
• The unique ID is stored in the preferences.txt file, so if a single login is used on a machine, that’s counting multiple people. Conversely, if you have multiple machines, you’ll be counted more than once.
• Showing the data by day, week, or year all show the same overall trend.

This is a pretty lame visualization of the numbers, and I’m not even showing other interesting tidbits like what OS, version, and so on are in use. Maybe we can release the data if we can figure out an appropriate way to do so.

Exciting news! The short story is that there’s a new Processing Plug-in for Eclipse, and you can learn about it here.

The long story is that Chris Lonnen contacted me in the spring about applying for the Google Summer of Code (SoC) program, which I promptly missed the deadline for. But we eventually managed to put him to work anyway, via Fathom (our own SoC army of one, with Chris working from afar in western New York) with the task of working on a new editor that we can use to replace the current Processing Development Environment (the PDE).

After some initial work and scoping things out, we settled on the Eclipse RCP as the platform, with the task of first making a plug-in that works in the Eclipse environment (everything in Eclipse is a plug-in), which could then eventually become its own standalone editor to replace the current PDE.

Things are currently incomplete (again, see the Wiki page for more details), but give it a shot, file bugs (tag with Component-Eclipse when filing), and help lend Chris a hand in developing it further. Or if you have questions, be sure to use the forum. Come to think of it, might be time for a new forum section…

…like Karl Gude has, then parking lots start to look like this:

This piece from Niklas Roy made me laugh out loud:

Built with Processing and AVR-GCC.

(Thanks to Golan, who pointed out this link.)

I wasn’t going to post this one, but I can’t get it out of my head. In the image below, the squares marked A and B are the same shade of gray.

The image is from Edward H. Adelson at MIT, and you can find my original source here. More details (proof, etc) on Adelson’s site here, which includes this explanation:

The visual system needs to determine the color of objects in the world. In this case the problem is to determine the gray shade of the checks on the floor. Just measuring the light coming from a surface (the luminance) is not enough: a cast shadow will dim a surface, so that a white surface in shadow may be reflecting less light than a black surface in full light. The visual system uses several tricks to determine where the shadows are and how to compensate for them, in order to determine the shade of gray “paint” that belongs to the surface.

The first trick is based on local contrast. In shadow or not, a check that is lighter than its neighboring checks is probably lighter than average, and vice versa. In the figure, the light check in shadow is surrounded by darker checks. Thus, even though the check is physically dark, it is light when compared to its neighbors. The dark checks outside the shadow, conversely, are surrounded by lighter checks, so they look dark by comparison.

A second trick is based on the fact that shadows often have soft edges, while paint boundaries (like the checks) often have sharp edges. The visual system tends to ignore gradual changes in light level, so that it can determine the color of the surfaces without being misled by shadows. In this figure, the shadow looks like a shadow, both because it is fuzzy and because the shadow casting object is visible.

The “paintness” of the checks is aided by the form of the “X-junctions” formed by 4 abutting checks. This type of junction is usually a signal that all the edges should be interpreted as changes in surface color rather than in terms of shadows or lighting.

As with many so-called illusions, this effect really demonstrates the success rather than the failure of the visual system. The visual system is not very good at being a physical light meter, but that is not its purpose. The important task is to break the image information down into meaningful components, and thereby perceive the nature of the objects in view.

(Like the earlier illusion post, this one’s also from my mother-in-law, who should apparently be writing this blog instead of its current—woefully negligent—author.)

Casey and I are in Chicago this weekend for the Processing+Android conference at UIC, organized by Daniel Sauter. In our excitement over the event, we posted revision 0191 last night (we tried to post from the back of Daniel’s old red Volvo, but Sprint’s network took exception). The release includes several Android-related updates, mostly fixed from Andres Colubri to improve how 3D works. Get the download here:

http://processing.org/download/ (under pre-releases)

Also be sure to keep an eye on the Wiki for Android updates:
http://wiki.processing.org/w/Android

(By the time you read this, there may be newer pre-releases like 0192, or 0193, and so on. Use those instead.)

Release notes for the 0191 update follow. And we’ll be doing a more final release (1.3 or 2.0, depending) once things settle a bit.

Processing Revision 0191 – 30 September 2010

Bug fix release. Contains major fixes to 3D for Android.

[ changes ]

+ Added option to preferences panel to enable/disable smoothing of text inside the editor.

+ Added more anti-aliasing to the Linux interface. Things were downright ugly in places where defaults different from Windows and Mac OS X.

[ bug fixes ]

+ Fix a problem with Linux permissions in the download.
http://code.google.com/p/processing/issues/detail?id=343

+ Fix ‘redo’ command to follow various OS conventions.
http://code.google.com/p/processing/issues/detail?id=363
Linux: ctrl-shift-z, macosx cmd-shift-z, windows ctrl-y
http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
http://developer.apple.com/mac/library/documentation/

+ Remove extraneous console messages on export.

+ When exporting, don’t include a library multiple times.

+ Fixed a problem where no spaces in the size() command caused an error.
http://code.google.com/p/processing/issues/detail?id=390

[ andres 1, android 0 ]

+ Implemented offscreen operations in A3D when FBO extension is not available
http://code.google.com/p/processing/issues/detail?id=300

+ Get OpenGL matrices in A3D when GL_OES_matrix_get extension is not available
http://code.google.com/p/processing/issues/detail?id=286

+ Implemented calculateModelviewInverse() in A3D
http://code.google.com/p/processing/issues/detail?id=287

+ Automatic clear/noClear() switch in A3D
http://code.google.com/p/processing/issues/detail?id=289

+ Fix camera issues in A3D
http://code.google.com/p/processing/issues/detail?id=367

+ Major fixes for type to work properly in 3D (fixes KineticType)
http://code.google.com/p/processing/issues/detail?id=358

+ Lighting and materials testing in A3D
http://code.google.com/p/processing/issues/detail?id=294

+ Generate mipmaps when the GL_OES_generate_mipmaps extension is not available.
http://code.google.com/p/processing/issues/detail?id=288

+ Finish screen pixels/texture operations in A3D
http://code.google.com/p/processing/issues/detail?id=298

+ Fixed a bug in the camera handling. This was a quite urgent issue, since affected pretty much everything. It went unnoticed until now because the math error canceled out with the default camera settings.
http://forum.processing.org/topic/possible-3d-bug

+ Also finished the implementation of the getImpl() method in PImage,  so it initializes the texture of the new image in A3D mode. This makes the CubicVR example to work fine.

[ core ]

+ Fix background(PImage) for OpenGL
http://code.google.com/p/processing/issues/detail?id=336

+ Skip null entries with trim(String[])

+ Fix NaN with PVector.angleBetween
http://code.google.com/p/processing/issues/detail?id=340

+ Fix missing getFloat() method in XML library

+ Make sure that paths are created with saveStream(). (saveStream() wasn’t working when intermediate directories didn’t exist)

+ Make createWriter() use an 8k buffer by default.

I’m really happy to see typographer Matthew Carter receive a well-deserved MacArthur “Genius” Grant. A short video:

Very well put:

I think they’re saying to me, “You’ve done all this work. Well done… Here’s an award, now do more. Do better.” And it’s very nice, at my age, to be told by someone, that “we expect more from you. And here’s the means to help you achieve that.”

And if you’re not familiar with Carter’s name, you know his work: he created both Verdana and Georgia, at least one of which will be found on nearly any web site (the text you’re reading now is Georgia). Microsoft’s commission of these web fonts helped improve design on the web significantly in the mid-to-late 90s. Carter also developed several other important typefaces like Bell Centennial (back in the 70s), the tiny text found in phone books.

A few weeks ago I received a note from Ed Fries, who was interested in a distellamap-style print of his recently-finished Halo 2600.

Halo? Like the Xbox game by Bungie?

Why, yes! Sure enough, he’s written a version of the game for he Atari 2600.

You can play the game here, and if you don’t drown in the awesome (or die from laughing), you can now purchase prints here. Like the other distellamap prints, it shows how the image and code data coexist and interact inside an Atari 2600 cartridge games:

A detail of what it looks like up close:

(And as with the other prints, proceeds are given to charity.)