-
Notifications
You must be signed in to change notification settings - Fork 239
FAQ
Most answers can be found on the troubleshooting page, or in the reference for the function or library that you're using. Please read them!
The software is free to download and use. Just visit the download page.
We think it's important to have Processing freely available, rather than selling it under some godawful yearly contract update scheme. To that end, we encourage people to spread the word and refer them to processing.org.
Double click the Processing application (on Linux, type ./processing).
Select something from File → Examples. Hit the Run button (which looks like the play button on a VCR or tape deck). Lather, rinse, repeat as necessary.
More information on using the Processing “environment” is can be found in this section of the reference.
For a more detailed overview, check the Getting Started tutorial. A number of books have been written to help, too.
And again, if you run into trouble, check out the troubleshooting page.
To learn the Processing language, we recommend you try a few of the built-in examples, and check out the reference. A group of diverse books have been written to help people with different goals and skill levels.
When using the examples (or trying someone else's code), if you run across a function that you're not familiar with, highlight the word, and right-click (ctrl-click on macOS), and select Find in Reference from the pop-up menu to open the reference page for that keyword. This can be helpful for understanding how programs work.
If you're stuck or want to talk about your work, head over to the forum section of the site to find open minds and helpful peers.
Read the revisions file that's included with the download (or use that link to read the online version). Things change between releases, and something may have broken your code, or your code may be using something unsupported, which no longer behaves.
The code may be using syntax from an older release of Processing. Information about updating your code can be found at the changes page that covers the differences between version 4 and version 3 and earlier.
Also check revisions.md, which covers incremental differences between each release that we post (4.0, 4.0.1, etc).
We release versions for macOS, Windows, and Linux.
More detailed information for the specific platforms can be found in the Supported Platforms section.
The Processing development environment is released as open source under the GPL. The export libraries (also known as core) are released under an LGPL license, which means they can be used as a library and included in your project without you having to open up your code (though we encourage people to share anyway).
If you make changes to core, those updates should be made available. More information about the GNU Public License can be found at here.
The source code for the software can be found at https://github.com/processing/processing4.
The source code for 3.x and earlier is stored in another Gitub repository.
We need help! Having shared all the code and made it available for free, doesn't it just make you want to pitch in and help? We have too much work to do and can't keep up with things. We love to see bug fixes, new libraries, etc. If you're interested, contact us via the Forum section of the site.
Processing also relies on (and is indebted to) other open projects, namely:
- the jEdit Syntax package, which is public domain
- the ECJ and JDT tools from the Eclipse project, which uses the Eclipse license
- the Java Native Access (JNA) project, released under the Apache License
-
launch4j is used to create Windows application (both
processing.exeand for the Export to Application command) - a fork of appbundler which itself is a fork of Oracle's Java Application Bundler
- …and probably a few others, let us know if we're missing something.
We like it when people include a “Built with Processing” note with a link back to the site, since it helps create interest and brings in more people to the project. We don't/can't/shouldn't require it, but it makes us happy because the project is free and this is one way you can help give back to us.
You can distribute your sketches all you want, and commercial projects are just fine too, however we place no warranty on the software (see the download page for the license shenanigans).
An "alpha" release means we're still breaking things. A "beta" release means that the API is locked up for the final, but not all the bugs are necessarily worked out. Beta also means that we think it's stable enough for day-to-day use, and clearly better than the previous release.
Releases prior to 1.0 were numbered with four digits. Revision 0069 was the last alpha release, revision 0085 was the first "beta" release, and revision 0161 was the last beta. Under the old numbering system, release 1.0 is 0162. With the 2.0 series, we've mostly dispensed with using the revision numbers to avoid confusion. In 4.0, we jumped from revision 0270 to 1270 to have a clear break between the two, and because we weren't certain whether we'd have to continue 3.x development in parallel. Version 4.0 will be revision 1285, the 286th release of the software.
At their core, computers are processing machines. They modify, move, and combine symbols at a low level to construct higher level representations. Our software allows people to control these actions and representations through writing their own programs. The project also focuses on the “process” of creation rather than end results. The design of the software supports and encourages sketching and the website presents fragments of projects and exposes the concepts behind finished software.
“Proce55ing” is the spelling we originally used for the URL of the web site, because "Processing" was already taken. Even though it's a combination of numbers and letters, it was always pronounced “processing.” Since then, we saved our pennies, had a can drive, and used the funds to acquire the processing.org domain name. As a result we are no longer using the name “Proce55ing.”
We often shortened the name “Processing” to “p5” in the early days. The name lives on with the p5.js project.
We think most “integrated development environments” (Microsoft Visual Studio, Xcode, Eclipse, etc.) tend to be overkill for the type of audience we're targeting with Processing. For this reason, we've introduced the sketchbook which is a more lightweight way to organize projects. As trained designers, we'd like the process of coding to be a lot more like sketching. The sketchbook setup, and the idea of just sitting down and writing code (without having to write two pages to set up a graphics context, thread, etc.) is a step towards that goal.
The idea of just writing a short piece of code that runs very easily (via a little run button) is a direct descendant of John Maeda's work in Design By Numbers, and our experiences maintaining it. Other languages and environments have done similar, but in our case, the concept is drawn from DBN. See below for more about the relationship to DBN.
We didn't set out to make the ultimate language for visual programming, we set out to make something that was:
- A sketchbook for our own work, simplifying the majority of tasks that we undertake,
- A teaching environment for that kind of process, and
- A point of transition to more complicated or difficult languages like full-blown Java or C++ (a gateway drug to more geekier and more difficult things)
At the intersection of these points is a tradeoff between speed and simplicity of use. i.e. if we didn't care about speed, Python, Ruby or many other scripting languages would make far more sense (especially for the simplicity and education aspect of it). If we didn't care about transition to more advanced languages, we'd get rid of the C-style (well, Algol, really) syntax. etc etc.
Java makes a nice starting point for a sketching language because it's far more forgiving than C++ and also allows users to export sketches for distribution across many different platforms. When we got started in 2001, most people were using it to build applets that ran on the web, which was important to the early growth of the project.
Processing is not intended as the ultimate environment or language (in fact, the language is just Java, but with a new graphics and utility API along with some simplifications). Fundamentally, Processing just assembles our experience in building things, and trying to simplifies the parts that we felt should be easier.
Processing code is converted to straight Java code (using the "preprocessor") when you hit the Run button. This also makes it possible to embed other Java code in your sketches, or use the core.jar file from the Processing distribution to develop your own sketches with other environments.
The main rule when using Java code: You cannot use most of the AWT or Swing (which is built on the AWT), because it will interfere with the graphics model. If you want to add scroll bars and buttons to your projects, you should make them using Processing code, or embed your Processing applet inside another Swing or AWT application (see below). Even if they appear to work, such sketches will usually break when you try to run on other operating systems or other versions of Java.
Since we can't really support anything and everything that you might want to do when interfacing with Java or using core.jar inside a Java environment, use the forum and find/ask questions that are related to using Processing to interface with regular Java code.
Also note that when using the Processing API or libraries outside the PDE, the headaches of the Java CLASSPATH and PATH (and in Java 17, the “modules path”) return, and using libraries gets much nastier. These are some of the headaches that we try to hide in the Processing environment, things that separate Processing from straight Java coding. We feel that it is important to put the good stuff at the surface, and that those details don't teach students much anyway (and they annoy advanced users too).
Processing is a descendant of the Design By Numbers (DBN) project and other initiatives at the Aesthetics + Computation Group (ACG). DBN is a simplified programming language that was developed to teach the structure and interpretation of software in a visual manner. Design By Numbers was created by John Maeda and accompanied a book of the same name. While at the ACG, Ben and Casey were involved in the development and maintenance of the DBN software and courseware, and that experience provided the basis for the Processing project.
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.
At the time (between 1998-2000), work at the ACG was usually developed via sketches written in Java and later moved to applications written in C++ using OpenGL. We were interested in melding the idea of "sketching" in code with the pedagogical aspect of DBN. Development of Processing began formally in the Spring of 2001 with discussions between Casey and Ben about API and feature set, and the first few versions of Processing (releases 0001, 0003, and 0005) were used in August 2001 at a workshop at Musashino Art University in Japan.
After you double-click Processing, it will connect to the network to check the site for updates. This is helpful so that we can keep people aware of the frequent updates to Processing.
During this process, the software sends a random number that identifies yours as a unique machine (but sends no personal information to us). This really helps us get a general idea of how many people are using the software, which is very important for things like writing grants so that we can keep Processing free.
Starting with Processing 3.0, the software also sends a list of what Libraries, Modes, and Tools that you have installed. We added this because of the difficulty we had while working on 3.0 because we had no information about what Libraries, Modes, and Tools were installed most commonly across the hundreds of thousands of people who use Processing. We wanted to figure out where to concentrate what little volunteer time we had toward helping authors of contributions to get them updated, or knowing when we might need to pick up the slack if an author had disappeared.
Bottom line, the information is used for no other purpose. Before this addition, we had erred on the side of collecting too little information (compared with essentially every other piece of software or web site you might use), but it was a major error because it hurt our ability to better understand the community and make our decisions based on what people were doing.
During the 4.0 release process, those stats were invaluable, and used extensively to help us prioritize compatibility and guide our testing. You can see the statistics at https://download.processing.org/stats/ or read more about them on the Usage Statistics page.
If the network connection causes you trouble, or if you're exceptionally paranoid uncomfortable with sharing the list of things you've installed using the Contribution Manager (the dialog box that shows up when you do Manage Libraries… or Manage Modes…, it can be shut off inside the Preferences window.
Shutting off the update checks also means that the Contribution Manager will not work, because it will not be able to… check for updates. This means that you will need to manually install Libraries, Modes, and Tools.