More bug fixes, and one new treat for OS X users. Hopefully we’re about set
to call this one 1.2. Please test and report any issues you find.

[ additions ]

+ On Mac OS X, you’re no longer required to have a sketch window open at
all times. This will make the application feel more Mac-like–a little
more elegant and trendy and smug with superiority.

+ Added a warning to the Linux version to tell users that they should be
using the official version of Java from Sun if they’re not.
http://wiki.processing.org/w/Supported_Platforms#Linux
There isn’t a perfect way to detect whether Sun Java is in use,
so please let us know how it works or if you have a better idea.

[ fixes ]

+ “Unexpected token” error when creating classes with recent pre-releases.
http://code.google.com/p/processing/issues/detail?id=292

+ Prevent horizontal scroll offset from disappearing.
Thanks to Christian Thiemann for the fix.
http://code.google.com/p/processing/issues/detail?id=280
http://code.google.com/p/processing/issues/detail?id=10

+ Fix NullPointerException when making a new sketch on non-English systems.
http://code.google.com/p/processing/issues/detail?id=283

+ Fixed a problem when using command-line arguments with exported sketches
on Windows. Thanks to davbol for the fix.
http://code.google.com/p/processing/issues/detail?id=303

+ Added requestFocusInWindow() call to replace Apple’s broken requestFocus(),
which should return the previous behavior of sketches getting focus
immediately when loaded in a web browser.
http://code.google.com/p/processing/issues/detail?id=279

+ Add getDocumentBase() version of createInput() for Internet Explorer.
Without this, sketches will crash when trying to find files on a web server
that are not in the exported .jar file. This fix is only for IE. Yay IE!

[ mixed bag ]

Android SDK requirement is now API 7 (Android 2.1), because Google has deprecated API 6 (2.0.1).

More Linux PDF fixes from Matthias Breuer. Thanks!

PDF library matrix not reset between frames. (Fixed in 0185.)
http://dev.processing.org/bugs/show_bug.cgi?id=1227

Updated the URLs opened by the software to reflect the new site layout.
http://code.google.com/p/processing/issues/detail?id=278

Updated the included examples with recent changes.

Processing Discussion Forum
The forum is the place where things begin and discussions are held. It’s a place for the exchange of ideas and knowledge. We’re excited to start fresh (a little late spring cleaning) so we’re not porting over the previous content or user accounts. The previous two Processing forums (one for the software from beta to 1.0 and one for the alpha software) will be archived as HTML pages and will remain available. The Processing community has held some amazing discussions over the years and we want that knowledge to remain publicly available.

Processing Wiki
The wiki holds the technical documentation and community-generated code examples and tutorials. The best discussions from the forum will hopefully be edited and documented on the wiki as examples and tutorials for easy reference and updates.

Processing Blog
The blog is for announcements from the Processing developers. It’s a one-way communication channel used for new releases and changes to the software. The announcements that used to be made through the Processing Discourse Forum will now go through the blog.

Processing on Google Code
This is the active resource for the SVN code repository, source browsing, and bug tracking. All bugs reports and suggestions for the software will now be handled through this site.

The main Processing website will remain the place for the exhibition, code reference, tutorials, and the software download. The main website is the public face of the project, while the work and innovation happens on the forum and wiki.

PROCESSING 0185 – 20 June 2010

Primarily a bug fix release. The biggest change are a couple tweaks for problems caused by Apple’s Update 2 for Java on OS X, so this should make Processing usable on Macs again.

[ bug fixes ]

+ Fix for Apple bug that caused an assertion failure when requestFocus() was called in some situations. This was causing the PDE to become unusable for opening sketches, and focus highlighting was no longer happening.
http://code.google.com/p/processing/issues/detail?id=258
http://dev.processing.org/bugs/show_bug.cgi?id=1564
http://dev.processing.org/bugs/show_bug.cgi?id=1569

+ Fixed two bugs with fonts created with specific charsets.

+ Fix from jdf for PImage(java.awt.Image img) and ARGB images. The method “public PImage(java.awt.Image)” was setting the format to RGB (even if ARGB)

+ Large number of beginShape(POINTS) not rendering correctly on first frame
http://dev.processing.org/bugs/show_bug.cgi?id=1572

+ Fix for PDF library and createFont() on Linux, thanks to Matthias Breuer.
http://dev.processing.org/bugs/show_bug.cgi?id=1566

+ Fix from takachin for a problem with full-width space with Japanese IME.
http://dev.processing.org/bugs/show_bug.cgi?id=1531

+ Reset matrix for the PDF library in-between frames also added begin/endDraw between frames
http://dev.processing.org/bugs/show_bug.cgi?id=1227

[ additions ]

+ Add the changes for “Copy as HTML” to replace the “Copy for Discourse” function, now that we’ve shut down the old YaBB discourse board.
http://code.google.com/p/processing/issues/detail?id=271

+ Option to disable re-opening sketches when you start Processing. The default will stay the same, but if you don’t like the feature, alter your preferences.txt file to change:
last.sketch.restore=true
to the following:
last.sketch.restore=false
The issue was originally filed here:
http://dev.processing.org/bugs/show_bug.cgi?id=1501
http://code.google.com/p/processing/issues/detail?id=245
However the main problem with this is that due to other errors, the wrong sketches are being opened, sketches are sometimes forgotten, or windows are opened concurrently on top of one another, creating a bad situation:
http://code.google.com/p/processing/issues/detail?id=177
http://code.google.com/p/processing/issues/detail?id=179
Those bugs are not yet fixed, but will be addressed in future releases.

+ Option to change the default naming of sketches via preferences.txt.
First, you can change the prefix, which defaults to:
editor.untitled.prefix=sketch_
And the suffix is handled using dates. The current default (since 1.0) is:
editor.untitled.suffix=MMMdd
Or if you want to switch back to the old (six digit) style, you could use:
editor.untitled.suffix=yyMMdd
http://dev.processing.org/bugs/show_bug.cgi?id=1091

+ Updated bundled JRE/tools to 6u20 for Windows and Linux

+ Several SVG fixes and additions, including some tweaks from PhiLho. These changes will be documented in a future release once the API changes are complete.

+ Added option to launch a sketch directly w/ linux. Thanks to Larry Kyrala.
http://dev.processing.org/bugs/show_bug.cgi?id=1549

+ Pass actual exceptions from InvocationTargetException in registered methods, which improves how exceptions are reported with libraries.

+ Added loading.gif to the js version of the applet loader. Not sure if this is actually working or not, but it’s there.

[ android ]

+ Added permissions for INTERNET and WRITE_EXTERNAL_STORAGE to the default AndroidManifest.xml file. This will be addressed in greater detail here:
http://code.google.com/p/processing/issues/detail?id=275
And with the implementation of code signing here:
http://code.google.com/p/processing/issues/detail?id=222

+ Lots of work happening underneath with regards to Android, more updates soon as things start evening out a bit.

+ Defaulting to a WVGA screen for the default Processing AVD.

Has a couple nice visual touches that prevent it from looking like YAHSVPOQUFOTI (yet another highly-stylized visualization piece of questionable utility found on the internet). Also cool to see it was built with Processing.js.

Visit the course website
Visit the course exhibition at OpenProcessing

Here’s a partial list of projects that impressed me:

Project 6: Play
Michael, Ola, Matthew, Thomas, Mayura, Hugo, Grace, Gina

Project 5: Transform(er)
Ola, Michael, Heather, Jimena

Project 4: Narrate
Gina, Michael, Patricia, Mayura, Adrienne,

Project 3: Collage
Jimena, Heather, Michael, Grace, Mimi

Project 2: Respond
Ola, Grace, Heather, Michael, Ryan, Matthew

Project 1: Draw
Brianna, Ola, Hugo. Michael, Alexander, Matthew

I changed the assignments significantly from the previous version of the class and anytime that happens, there are some hits and misses. I feel good about the hits and I have clear ideas about how to improve the project briefs that were less successful. In the spirit of information exchange and self-critique, here are my thoughts:

Project 6: Play
The decision to limit the visual elements to 2 lines and 2 circles was a good move. The students focused more on the interactivity than in the past when they could spend more time creating elaborate graphics. Future: limit the project to 4 elements total rather then 2 lines, 2 circles. Each of the elements can be a circle, line, or rectangle.

Project 5: Transform(er)
This was the first time for this assignment and the brief didn’t lead to the kind of learning that I had intended. For many students it became an illustration project with very simple moving components. Future: Rename the project to something like “Transform(er) SuperMega” and turn it into a branding/logo/ID design project (can be earnest or a parody). Restrict all graphics to Processing geometry to encourage maximum formal flexibility. Instead of using mouseX as the input, use controlP5 library and have around three scrollbars change different parameters such as width, height, color, quantity, etc. Make a presentation of generative ID design (Karsten, Gadget OK!). This might be a good time to introduce bezierVertex(), curveVertex(), sin(), cos().

Project 4: Narrate
I think Alice in Wonderland was a great text to select, but not enough of the class read it closely, leading to generic narratives: “Oh no! Alice is being attacked by the cards.” The source material is amazing, it should be used. I think it’s important to formerly review the early steps of the process on this project, they should spend at least a week working on the story and images before starting the program. The decision for everyone to use the same story as the starting point was good. Future: Be a stickler for the diagrams and paper prototype, find another appropriate text with illustrations, constrain the text in the software to found elements within the  story. This leads off the Collage project well.

Project 3: Collage
Future: Too many of the projects were slight variations of the sample code, so explain the project is about setting up relations between elements, not simple giving them random values.

Project 2: Respond
This was the first time for the “eye” exercise and I was happy with the results. Future: encourage more variation (there were too many generic cartoon eyes), encourage more fluid response.

Project 1: Draw
This quarter, I limited the graphic elements to point(), line(), triangle(), quad(), rect(), ellipse(), and arc() and this was a good decision. I removed curve() and bezier() as options and didn’t discuss them in class. In the past working with bezier() was extremely frustrating to students and I don’t want to start them off frustrated. (Working with Bezier curves directly with coordinates is not pleasant for anyone.) I also made it clear that only integer numbers should be used as parameters to the drawing functions. Future: need to emphasize comments as a way to organize the code, emphasize variables.

Also, starting in Fall 2009, we started hosting the class at OpenProcessing.org. This has been great; Sinan has my sincere gratitude for creating a wonderful system.

I’ve taught for ten years now, but I’ve not written about my teaching or curriculum ideas. I’ve written extensively (too much?) about Processing, but not specifically how I use it in classes at UCLA and workshops elsewhere. This post is a start.

To throw a few more thoughts in…
I’ve been thinking more lately about how tools used for education are often different from tools used by professionals/experts. I think there’s substance to writing about how Processing relates specifically to education. How it fosters sharing information, how it limits the initial technical complexity of programming but details can be revealed to provide more flexibility in time (the training wheels come off to reveal a new experience), and how it is also simple at the core to give learners the experience of doing things the long way before they move to a higher-level library to give the same result with less effort. These factors encourage exploration, reduce frustration, and can lead to a deeper understanding of the software medium.

I was at Netscape (or maybe at Sun?) when they renamed their “LiveScript” language to “JavaScript” (because Java was the it-language at the time) and I’d avoided it for a long time. His talk points out a series of things to avoid from the JavaScript syntax, in fact I think I enjoyed the explanation of the “Bad Parts” a bit more. By clearing out a few things, the whole starts making more sense. But it’s an interesting discussion for people scratching their head about this incredibly pervasive language found in web browsers, and rapidly becoming more exciting as support for Canvas and WebGL evolve.

You can download the release at android.processing.org, which (as you might guess) is the eventual home of the Android version of Processing. The Android support is very incomplete, as you can see from the warnings on the page.

But ignore for a moment that it says “Android”, the download is hosted there because at the moment, most of my energy is focused on the Android extensions. While the build also includes the incomplete Android tools (just pretend they aren’t there, unless you’re willing to read all the caveats on that page), there are many bug fixes for the regular Java version of Processing in the download too. It’s been a couple months since I’ve done a proper release, so there’s a backlog of fixed bugs and things I’ve been adding.

I’m posting the pre-release because so many things have changed, and I don’t want to do a 1.1 release, followed by an immediate 1.1.1. So please test! Then again, it’s taken me so long to explain the situation that I should have just posted it as 1.1.

And by the time you read this, it’ll probably be release 0177, or 0178, or…

For the first time, we’re selling Processing t-shirts. Profits will fund Processing development. We’ve partnered with Wire & Twine to make this happen. The shirts are hand screened in Oxford, OH, the home of the Processing 1.0 launch in November 2008. The shirts are available for pre-order on a navy American Apparel 100% cotton. Order by November 30th to get your shirt by December 25th. Shirts will begin production on November 30th and ship no later than December 14th.

We have two styles: the BEAUTY, and the BEAST. The BEAUTY shirt features a network image created with the code written for the Processing web header and the cover of the Reas/Fry book. The setup() and draw() functions from this code appears on The BEAST tee. The BEAST shirt features a diagram of the iconic Processing Development Environment and a piece of the code used to create The BEAUTY tee.

A more complete description can be found on the video page over at Vimeo.

For people reading the site because they’re interested in visualization (I guess that’s all of you, except for mom, who is just trying to figure out what I’m up to), some inside baseball:

On the interaction side, the main objective here was to make it easy to move around the interface as quickly as possible. The rows are shown in succession so that the interface can teach itself, but we also provide a reset button so that you can return to the starting point. Once the rows are visible, though, it’s easy to move laterally and make changes to the settings (swapping between age ranges, for instance).

One irony of making the data accessible this way is that most users — after looking up their own numbers — will then try as many different possibilities, in a quick hunt for the extremes. How high do the percentages go? If I select bizarre values, what happens at the edges? Normally, you don’t have to spend as much time on these 1% cases, and it would be alright for things to be a little weird when truly odd values are entered (300 lb. people who are 4′ tall, smokers, and age 75 and over). But in this case, a lot more time has to be spent making sure things work. So while most of the time the percentages at the top are in the 5-15% range, I had to write code so that when one category shoots up to 50%, the other bars in the chart scale down in proportion.

Another aspect of the interface is the body mass index calculator. Normally a BMI chart looks something like this, a large two-dimensional plot that would otherwise use up half of the interface. By using a little interaction, we can make a simpler chart that dynamically updates itself based on the current height or weight settings. Also, because the ranges have (mathematically) hard edges, we’re showing that upper and lower bound of the range so that it’s more apparent. Otherwise, a 5′8″ person steps from 164 to 165 lbs to find themselves suddenly overweight. In reality, the boundaries are more fuzzy, which would be taken into account by a doctor. But with the software, we instead have to be clear about the way the logic is working.

(Note that the height and weight are only used to calculate a BMI range — it’s not pulling individuals from the database who are 5′8″ and 160 lbs, it’s pulling people from the “normal” BMI range.)

For the statistically (or at least numerically) inclined, there are also some interesting quirks that can be found, like a situation or two where health risk would be expected to go up, but in fact they go down (I’ll leave you to find them yourself). This is not a bug. We’re not doing any sort of complex math here to evaluate actual risk, the software is just a matching game with individuals in the database. These cases in particular show up when there are only a few thousand individuals, say 2,000 out of the full 6 million records. The number of people in these edge cases is practically a rounding error, which means that we can’t make sound conclusions with them. As armchair doctor-scientist, it’s also interesting to speculate as to what might be happening in such cases, and how other factors may come into play.

Have fun!

John Maeda

In 2001, when I was a young MIT faculty member overseeing the Media Lab Aesthetics and Computation Group, two students came up with an idea that would become an award-winning piece of software called Processing—which I am often credited with having a hand in conceiving. Processing, a programming language and development environment that makes sophisticated animations and other graphical effects accessible to people with relatively little programming experience, is today one of the few open-source challengers to Flash graphics on the Web. The truth is that I almost stifled the nascent project’s development, because I couldn’t see the need it would fill. Luckily, Ben Fry and Casey Reas absolutely ignored my opinion. And good for them: the teacher, after all, isn’t always right.

To give him more credit (not that he needs it, but maybe because I’m bad with compliments), John’s objection had much to do with the fact that Processing was explicitly an evolutionary, as opposed to revolutionary, step in how coding was done. That’s why it was never the focus of my Masters or Ph.D. work, and instead has nearly always been a side project. And more importantly, for students in his research group, he usually forced us away from whatever came naturally for us. Those of us for whom creating tools was “easy,” he forced us to make less practical things. For those who were comfortable making art, he steered them toward creating tools. In the end, we all learned more that way.

Tiny Sketch is an open challenge to artists and programmers to create the most compelling creative work possible with the programming language Processing using 200 characters or less.

…building on the proud traditions of obfuscated code contests and the demo scene. The contest runs through September 13 and is sponsored by Rhizome and OpenProcessing.

Having designed Processing to do one thing or another, several of the submissions made me laugh out loud for ways their authors managed to introduce new quirks. For instance, consider the createFont() function. Usually it looks something like this:

PFont f = createFont("Helvetica", 12);

If the “Helvetica” font is not installed, it silently winds up using a default font. So somebody clever figured out that if you just leave the font name blank, it’s an easy way to get a default font, and not burn several characters of the limit:

PFont f = createFont("", 12);

Another, by Kyle McDonald, throws an exception as a way to produce text to plot on screen. (It’s also a bit of an inside joke—on us, perhaps—because it’s a ubiquitous error message resulting from a change that was made since earlier releases of Processing.)

One of the most interesting bits is seeing how these ideas propagate into later sketches that are produced. Since the font hack appeared (not sure who did it first, let me know if you do), everyone else is now using that method for producing text. Obviously art/design/coding projects are always the result of other influences, but it’s rare that you get to see ideas exchanged in such a direct fashion.

And judging from some of the jagged edges in the submissions, I’m gonna change the smooth() to just s() for the next release of Processing, so that more people will use it in the next competition.

For myself and Ben Fry, DBN was the catalyst for Processing. Here’s an except from an essay we wrote in 2008:

Released by John Maeda in 1999, Design By Numbers (DBN) had the most direct impact on Processing. (In fact, it’s fair to say that there would be no Processing without DBN.) This minimalist language was created to be accessible to designers and artists and it works very well to introduce ideas of programming to that audience. Two other innovative ideas were integrated in DBN. First, the programming environment could be embedded into a web page so that it could be access for free, by anyone with a Web connection. Second, a web-based courseware application was integrated into the software to allow students to upload their assignments to a server where the public could see their work and look at their source code.

Processing’s emphasis on teaching came from our experience working with Prof. Maeda on DBN. We were so impressed with how quickly a beginner could start writing programs. Initially, we were interested in melding the idea of “sketching” in code with the pedagogical aspect of DBN. While working on DBN, Ben developed several experimental versions that included other programming languages (Python and Scheme) and drawing features (color, changing the window size, magnification, movie recording, and even OpenGL support), but it was clear that these did not make sense for the DBN project because they interfered with Maeda’s intention of a simplified programming language and environment.

Because it was written for the network, it can still be used today by simply visiting the URL. This makes it simple to test drive. First, glance at the brief introduction, then check it out.

The Chrome Experiments site was launched today to feature the JavaScript potential of the new Google Chrome Web browser. A few of the projects, including my contribution called Twitch, use Processing.js. Processing.js is John Resig’s port of the 2D parts of Processing to JavaScript using the Canvas element. I developed my entire project in Processing and then basically cut and pasted it into an HTML file. And there it was, Processing code running inside a browser without a plugin. Twitch was featured at Technology Review today in the post Browser Coders Make Chrome Shine.

Here are a few developing thoughts about Chrome and Twitch:

- Chrome and its fast JavaScript capability offers a glimpse of a Web without proprietary plug-ins. This allows the code (programs) to run directly in the browser rather than loading, for example, the Shockwave Player (from Adobe) or Java (from Sun). This makes it possible to create visually exciting and interesting works without using proprietary tools (in the case of Flash) and works that are accessible to more people (in the case of Java, because many people don’t have the plug-in). This is how innovation on the Web happened back in the mid-1990s; everyone was always looking at how people did things by looking at their HTML code. It made innovation happen quickly. With Flash and Java programs, you don’t have access to the code.

- The piece I created, Twitch, focuses on the genre of one-button games. This is a game that is played with a minimal interface (just one button) and is easy to figure out. I worked to create nine complementary pieces. First, you figure out the controls and then you figure out what to do, without instructions and in a short time. It’s a light piece, meant for enjoyment.

- Technically, I think the greatest innovation of Chrome is launching each Window or Tab as a separate process. If you try to run Twitch on Firefox it starts to slow down as more windows open. Each mini-game competes for the same resources from the computer’s processor. In Chrome, because each window runs separately, the frame rate remains high.

The ART AND CODE workshops and symposium at Carnegie Mellon wrapped up today. It was an amazing event organized by Golan Levin. It was a pleasure to see old friends from vvvv, Max/MSP/Jitter, openFrameworks, Pure Data, and to meet the creators of Scratch and Hackety Hack. There were nine separate Processing workshops sessions, two from myself, Ben Fry, Ira Greenberg, and three from Dan Shiffman. The topics ranged from a “patient” introduction (me), to a focus on information visualization (Fry), advanced techniques (Shiffman), and a session for educators (Greenberg). As a result of conversations and presentations, I’m very excited about Scratch and Ruby for their potential to teach programming in alternative ways and in alternative contexts. (I’m a little late to get on that train, but better now than even later.) The presentations will hopefully be archived online and the event was intensely tweeted.

And, we made some exciting decisions about the future of Processing during the concurrent Oxford Project 3 event. Andres Colubri made great progress.

Why Pittsburgh? We’re going to participate in the ART AND CODE symposium and workshops, organized by Golan Levin:

Art and Code is a symposium on programming environments for artists, young people, and the rest of us. The event takes place the weekend of March 7-9, 2009 on the campus of Carnegie Mellon University in Pittsburgh, PA. It features hands-on workshops and a conference showcase for eight different creative toolkits — programming languages made by artists, for artists.

This is a very exciting event with fascinating, emerging programming environments presented through workshops and lectures:

Alice, Hackety Hack, Max/MSP/Jitter, openFrameworks, Processing, Scratch, vvvv.

Giant Eagle Auditorium, here we come.