I just posted a thread for discussion on the Processing Github repo:
Thoughts on PVector and data exchange between Processing geometry libraries.

For a while now I’ve been frustrated by the lack of universal and portable data structures for vector and geometry data in Processing. Using PVector sounds nice in theory, but the reality is that geometry libraries like Hemesh, Toxiclibs, Geomerative and Modelbuilder all rely on their own custom representations of vector and mesh data. The result is incompatible data structures with few if any methods for universal data exchange. Worse, PVector is largely ignored and almost never seen “in the wild”

There are many good reasons for this proliferation of incompatible code, most significantly developer preference and the overall focus and internal logic of any given library. But having had the occasional pleasure of integrating both Toxiclibs and Hemesh with my own Modelbuilder, it strikes me that a standard interface would benefit both developers and users. Translating UVec3 objects to Toxiclibs’ Vec3D isn’t all that difficult, but it is tedious. And going beyond simple passing of vector data to more ambitious structures like meshes with per-vertex shading is a headache.

My proposal would be a minimal Java interface (called PVertex, perhaps) representing vertex data (x,y,z + ARGB color + UV texture coordinates). Custom vector classes would implement this interface, guaranteeing interopability but leaving developers free to choose any further implementation details. An interace should be minimally intrusive, but would be very helpful in encouraging geometry data exhcange. (In an ideal world I’d also love to see a minimal mesh container interface (PMesh?) represented by a PVertex array plus an integer array of vertex ID triplets. But, hey, I’m a dreamer.)

If any of this piques your interest, I suggest you go follow (and maybe participate in) the GitHub thread. Karsten Schmidt and Frederik Vanhoutte have already given some valuable feedback. Ultimately, this isn’t so much a discussion about the Processing core as it is an attempt to get library coders to agree on some minimal conventions.

Marius Watz: Catenary Madness (Flickr sketches / Code on OpenProcessing.org)

In case you noticed the Flickr image flood last week of a series of fairly wild-looking sketches titled “Catenary Madness”, I just got around to posting that code on OpenProcessing.org, it even has a few bells and whistles on it: catenary_mwTweak03.

The origin of this series was very random, the original impetus being a very nice catenary curve sketch by Dominik Strzelec. Dominik used Toxiclibs to model a surface of interconnected springs (a piece of billowing fabric, essentially) with gravity and relaxation constraints making things interesting. The way it was set up the simulation reproduced the famous catenary curve effect (although with an actual surface rather than just chains).

The catenary curve is a geometrical gem famously simulated and used as a form-generating process by the very pre-digital architect Gaudi:

Wikipedia: Catenary Curve In physics and geometry, the catenary is the curve that an idealized hanging chain or cable assumes under its own weight when supported only at its ends.

The curve has a U-like shape, superficially similar in appearance to a parabola (though mathematically quite different). It also appears in the design of certain types of arches and as a cross section of the catenoid—the shape assumed by a soap film bounded by two parallel circular rings.

I rarely if ever use “proper” simulation of processes physics, chemical processes or artifical intelligence in my work, but I was intrigued by the organic mesh structure produced by the simulation. Downloading Dominik’s code and predictably scaling up the complexity of the mesh and forces involved quickly made me realize that I have been missing out (although I do remain skeptical of algorithms that can be easily reproduced.) The tipping point came when I applied per-vertex color shading haxxoring, the graphic craziness that ensued had me lost for hours…

The posted code is just one of many sketches exploring the system. I did end up converting up the mesh and color logic to Modelbuilder since I’m less familiar with Toxiclibs, but I chose to post a version using Toxiclibs since it’s closer to the original code. The posted example has very random colors, producing palettes that I would consider unacceptable 80% of the time. The principles of mapping a 1D color list to a 2D color mesh was the focus of interest, rather than the actual colors themselves.

For a more complete index of the Catenary Madness sketches, see Flickr:
http://flickr.com/photos/watz/tags/catenarymadness/

After a string of workshops in New York I’m happy to announce that I’ll be doing my first round of private workshops in Europe. (Well, technically Scandinavia, but close enough.)

I’m bringing some Processing love to Norway in the form of a 2-day workshop on Generative Visuals in Processing. The workshop will take place on the weekend of April 13+14, which is only a few weeks away so get in touch if you’re interested in taking part. Details and prices are listed below.

• Saturday, April 13: Introduction to Processing and Generative Art
  Participants will be introduced to basic Processing syntax through a series of code examples designed to illustrate key Processing and Java concepts, giving a first taste of the power of generative visuals. We will then apply what we’ve learned by designing a generative system from the ground up, applying minor tweaks and code “remixes” to produce a variety of possible outputs.

  Topics: How to describe principles of composition and animation as computational logic. Basic Processing / Java syntax (including object-oriented code.) Practical techniques for generating pseudo-random color palettes and the use of GUI controls to explore possible permutations of a parametric form system. Finally, we will also learn to use Processing to generate professional output for use in print (as PDF vector or ultra-highres raster) or video (Quicktime video in HD and even 4k.)

• Sunday, April 14: Generative Art, Advanced Topics
  Day #2 will deal with advanced computational techniques and how to describe complex geometry in code. Our test case will be the re-creation of some classic (and not-so-classic) generative algorithms, breaking down the underlying logic and learning some principles of 2D+3D geometry in the process.

  We will see how vectors can be used to describe motion and structures in space, before moving on to useful abstractions like vertex lists and polygon meshes that allow us to use the same principles on a larger scale. And since data is all-important in all things code, one of our test cases will be to read data from a CSV file and find different ways to map it to a visual structure.

  Since computational geometry is traditionally math-heavy an important objective will be to outsource the heavy lifting to a geometry library so we can focus on the fun parts. We’ll be using Modelbuilder to handle most of our computational geometry needs. It defines a code workflow that simplifies common geometry tasks like generating polygon meshes and provides simple solutions to well-known code challenges that tend to come up in project after project.

  Bonus track: A (brief) look at Processing.js and its potential to bring the power of Processing back to the web.

  Topics: 2D and 3D geometry as a product of generative processes, including how to simplify and overcome some common challenges. Practical real-world uses for vectors, vertex lists and other data structures, whether for realtime rendering or 3D printing etc. Parsing data from CSV and finding suitable visual mappings. Advanced parametric modeling: Export/import of parameter data, on-demand realtime model regeneration in response to interactive parameter manipulation. Processing.js and exporting sketches to the web.

Price and booking: NOK 1500 is the regular price for both days, reducted to NOK 1200 for students and artists (that’s approx. EUR 200 / 162). I’m happy to take bookings for only one of the days (at NOK 900 / 750), but be advised that I need to give priority to participants who want to attend both days. Depending on the level of interest I may not be able to confirm single-day bookings until the week of the workshop.

To book your spot on the workshop please email info@mariuswatz.com with your name, address and cell phone #. You will be sent a PayPal URL where you can complete your payment, participation is confirmed once payment is completed.

Dates & times: Saturday and Sunday April 13+14, 10:00-17:00. This includes one hour for lunch (not included) and a possibility of extending somewhat beyond the official end time if so desired. There will be an optional informal social event Saturday evening.

Venue: I am partnering with local superstars Bengler, who have gracefully offered us the use of their offices conveniently located close to the popular Grünerløkka area of Oslo. I will send out an email with directions and a map to confirmed participants the week of the workshop.

The workshop should be helpful for beginners looking to learn about Processing and “creative code” but also for experienced coders interested in expanding their area of knowledge. A working understanding of code is a definite advantage, but Day #1 is designed to be possible to follow even without previous programming experience. Advanced coders will find the basic syntax easy but should still learn some new helpful techniques dealing with visuals and animation.

Day #2 introduces advanced concepts that are essential to generative systems and “creative code” but which can be a challenge to follow step-by-step in code. The underlying logic and general principles discussed should nevertheless e helpful for anyone interested in how code can be used to explore new types of forms and creative expressions.

Suggested preparations: Read the Introduction and Chapter 1: Vectors sections of Dan Shiffman’s excellent Nature of Code book. You can also read through the sample PDF of Ben Fry & Casey Reas: Learning Processing (better yet, buy it.) The sample PDF will give you an idea of Processing as a tool as well as insight into the basic syntax. Download Processing and run through the examples.

To prepare for Day #2 I suggest you download Modelbuilder-0020 and run the examples included with the library (some of which require ControlP5 to run.) Also see the Modelbuilder collection of sketches on OpenProcessing.org for examples.

New minor version of Modelbuilder: Modelbuilder-0020, consisting mostly of minor fixes but with one piece of good news: Prompted by the disappearance of Shiffman’s MovieMaker library from Processing 2.0b I decided to look into alternative media export libraries. The result is UMovieMaker, a MovieMaker replacement for Quicktime export.

UMovieMaker uses the Monte Media Library by Werner Randelshofer, and is packaged as a separately downloadable sub-lib. Look at the included examples for syntax, it only replicates a subset of MovieMaker’s functionality but so far it has gotten the job done in my own projects. Let me know if you encounter any bugs.

Since I still use 1.5.1 for most projects I have also separated the Modelbuilder code base into 1.5.1-compatible, 2.0b-compatible and universal source folders. I’m not providing a 1.5.1-compatible build for now, but you can download the GitHub repo to get the code. If I get enough requests for a 1.5.1 version I can easily provide one.

• Minor code fixes, additions
• Separated code specific to Processing 1.5.1 and Processing 2.0b series to separate directories for convenience. “src-universal” contains code that works with both code bases. I still use 1.5.1 for production and will keep maintaining a 1.5.1-compatible code base until 2.0 is stable.
• New sub-library: UMovieMaker, a hack replacement for Shiffman’s MovieMaker that will work with Processing 2.0b. The library uses uses the Monte Media Library (http://www.randelshofer.ch/monte/) by Werner Randelshofer and can write Quicktime without being dependent on QTJava.zip. See included examples.

Modelbuilder-0020 has been exported based on this code and briefly tested with Processing 2.0b8.

Downloads: Modelbuilder-0020 / UMovieMaker-001

Update: In my eagerness to announce these workshops I made a scheduling error, incorrectly thinking the dates would be March 15+16 rather than 16+17. As a result I need to move one of the workshops to the weekend before, and since the Intro workshop should happen before the Advanced the new dates will be:

• Saturday March 9: Introduction to Processing and Generative Art
• Saturday March 16: Generative Art, Advanced Topics

Sorry for the confusion! On the plus side the Intro workshop might now be a smaller group which should make it nice and intimate.

I haven’t done any workshops in New York since November, so I have decided to offer my Intro and Advanced Generative Art workshops back-to-back the weekend of March 16+17 on consecutive weekends, Saturday March 9 and Saturday March 17.

The venue will be my apartment in comfortable Park Slope, Brooklyn. As usual I have 8 spots available for each workshop, they do tend to reach capacity so get in touch sooner rather than later. Reservation is by email and your spot is confirmed once I receive payment via PayPal.

The workshops will be taught using the most recent Processing 2.0 beta version (2.0b8 as of this moment), and as usual I will be using my own Modelbuilder library as a toolkit for solving the tasks we look. Familiarizing yourself with Processing 2.0 and Modelbuilder would be good preparation.

Make sure to download Modelbuilder-0019 and Control-P5 2.0.4, then run through the provided examples. Check OpenProcessing.org for more Modelbuilder examples.

Note about dataviz: I know there is a lot of interest in data vizualization and I do get asked about that frequently in workshops. I can’t promise to cover data in detail since it’s a pretty big topic.

If you’re specifically looking for data techniques I would recommend looking at the excellent workshops series taught by my friend Jer Thorp. He currently offers two such workshops, titled “Processing and Data Visualization” and “Archive, Text, & Character(s)”.

I’ve updated the README for Modelbuilder on Github. It clarifies some issues regarding Processing 2.0 beta and the fact that unlekkerLib has been discontinued. Here is the full update:

Modelbuilder is a computational geometry library for Processing designed to help with parametric and generative modeling, while eliminitating complex and tedious tasks whenever possible.

Modelbuilder provides a set of object-oriented data structures and workflow metaphors (UVertexList define edges, UGeometry is used to generate and modify polygon meshes). The logic used is the familiar beginShape() / endShape() mechanism, optimized and abstracted to eliminate the need for tedious iteration through lists of vertices and faces etc.

Modelbuilder was first released in 2011 as part of my artist-in-residence project with Makerbot Industries, and the library is thus somewhat biased towards digital fabrication (3D printing, laser cutting etc.) My design priority has always been ease of coding rather than maximum realtime performance, but the library still has plenty of useful tools for realtime applications.

Users of my old library unlekkerLib should note that Modelbuilder replaces that library. Having both libraries installed will produce unresolvable conflicts. Modelbuilder does offers most of the same functionality, although with significant API changes. If there was something in unlekkerLib you need I suggest you open an issue on Modelbuilder and I will try to accommodate you.

The code base in src is Processing 2.0b7 compatible, the compiled library is modelbuilder v0019 (not tested on Processing 2.0b8).

I’m still finding some issues using 2.0 for my own projects, so I will maintain code for 1.5.1 for a while longer. See see src-0151-compatible.

Somewhat limited in scope at its inception (i.e. 3D printing,) the library has since proven valuable as a teaching tool, especially for the shorter independent workshops I teach in New York. Consequently Modelbuilder has expanded in scope and become the code equivalent of a Swiss Army Knife, containing tools I find useful but hopefully avoiding outright feature bloat.

Some examples of secondary functions:

• Color palette generation (UColorTool)
• File saving and parsing (UIO, UDataText, UFileNode and ULogUtil)
• FFT code with automatic damping and peak following for use in animation and sound-responsive applications.

With the final jump to Processing 2.0 I plan to do some much needed house-cleaning, making the code a little more consistent and changing some of the underlying design. This will likely come at the cost of some loss of backwards compatibility. Eggs and omelettes, etc.

Marius Watz, Feb 2013

Screenshot: UTimerDemo.pde

I just posted a demo of the unlekker.util.UTimer class in Modelbuilder on OpenProcessing.org. The example was created for a recent workshop, but I figured it might be worth sharing since UTimer is not exactly well-documented in the current Modelbuilder.

Basically, the demo shows how UTimer can be used to to animate individual objects as well as global behaviors according to a global timeline. The demo is nothing special in terms of visuals, but the underlying methodology can be very useful when creating animations that unfold over a given time interval (especially for rendered videos etc.) Since Processing lacks a timeline metaphor it’s sometimes necessary to simulate one, and while UTimer is by no means a particularly complex piece of code it does present one option.

UTimer allows you to control timed behavior where a local time t=[0..1] is calculated from a global time T=[0..1]. By specifying a UTimer instance with a local start time (tStart) and local duration (tDur) so that (tStart+tDur)<1, the current local time can be calculated using UTimer.update(globalT). If local time < 0 the object is not active yet, if local time >1 the object is “dead”.

A typical use case would be to have multiple objects appearing at various times, animating for a given interval and then “dying”. That is exactly the behavior demonstrated by the sample I’ve posted.

One drawback of the way UTimer currently works is that it only works with fractional time and not actual frame counts. That makes it easy to describe actions as a fraction of total time, but if the actual duration of an animation is changed the local rate of change will scale accordingly. Sometimes that’s appropriate, but there are cases one might want to specify duration in terms of absolute frame count so that rate of change (or duration of a behavior) is kept constant. That’s especially true when working with constant frame rates.

A workaround would be to calculate local duration (tDur) as a fraction of total frame count. I.e. if total frame count is 2000 and a local behavior should occur over 300 frames tDur = 300/2000 = 0.15. It is worth noting, however, that the fractional logic can allow you to produce quick motion previews at a reduced frame rate. If a given animation is supposed to be 60 seconds long, a video exported at 5 fps can give a good idea of motion as long as you correctly calculate the global T and export the video with the correct frame rate.

This kind of preview can be done automatically if only fractional time is used, simply change the number of total frames and set the frame rate accordingly.

After a bit of a break I have scheduled two more Intro and Advanced Generative Art workshops. Dates are November 10 (intro) and November 17 (advanced).

As usual I have 8 spots available for each workshop, possibly only 6 if I decide to do them at home in my comfy Park Slope apartment. (Nod to Kitchen Table Coders…)

See the workshop page for details and to sign up, hope to see you there!

USound04Cylinder example from sound-responsive visuals workshop last weekend, see code below

I’ve just announced two more NYC workshops for the weekend of September 8+9:

• Sep 8: Sound-responsive visuals in Processing
• Sep 9: 3D printing and Parametric modeling in Processing

It’s currently looking like my busy Fall schedule will mean that I’ll be doing less of these workshops over the next few months, so if you have any interest in taking one of them this might be a good time.

The first sound-responsive visuals workshop happened last weekend and was a lot of fun. Here are some of the key elements we looked at:

• As it turns out, Minim’s FFT.logAverages() method (which divides the FFT into logarithmic averages) give a far more useful result than the raw spectrum data on their own. Using that as our starting point we built a FFT helper class to act as our source material.
• Since our focus in looking at the sound data is to turn it into a useful parameter for driving visuals, I demonstrated a series of data modulating strategies that give us greater control over the sound input.
• Adding temporal damping of the FFT data (interpolating between old and new values) allows us to control the rate of signal change, which is crucial to make the sound-driven animation match the perceived tempo of the sound space.
• Finally, we used a simple envelope shaper (a 1D Bezier interpolation) to de-emphasize the lower part of the spectrum. Bass tends to be over-represented in the FFT data, so to get a better distribution we can simply tone down the low end of the FFT by multiplying each data point with a modifier dictated by the shaper function. Initially we also scaled up the top end, but that produced noise and artificially high values, so in the end we kept the shaper function within the [0..1] range.

See the attached Processing sketch for an example that we went through in detail. The libraries in the “libraries” folder must be copied to your Processing libraries folder before running.

Download: USound04Cylinder.zip (includes Modelbuilder and ControlP5 0.5.4, requires Minim)

Alexander Rishaug & Marius Watz, live audiovisual performance (visuals built with Processing.) For additional documentation see Vimeo and Flickr.

Update: This workshop is now sold out, but I will be doing it again in September. Feel free to sign up to the workshop mailing list to receive updates when they get announced. In the meantime there are still spots on the Intro and Advanced Topics workshops this weekend!

I have just announced a completely new workshop for August 25th: Sound-responsive visuals in Processing. Several people have asked if I would do such a workshop, so I figured it’s about time.

The core of the workshop will be learning a set of simple yet powerful strategies for mapping sound data to visual elements, focusing on how to design systems that take into account how humans experience sound. Where computers see an endless deluge of 16-bit air pressure measurements, human audiences perceive emotional parameters like tone color, rhythm and temporal evolution of sound. The creation of a good sound-responsive system may invariably start with audio processing and data manipulation, but finding a visual strategy that is capable of expressing the subtle time-based qualities of sound is by far the biggest challenge.

In case you are curious about the data strategies we will use to work with a live sound input: Digital signal processing is a vast and complex field, often requiring serious math to work its magic. Choosing simplicity and flexibility over technical genius we will rely on three tried-and-tested techniques: Spectral analysis (FFT), peak following (to keep the input signal predictable or to manipulate it for our own purposes) and temporal dampening (to control the rate of change in the sound data so that we can keep visual changes consistent with how the sound is developing, instead of jerking rapidly in response to the rapidly changing digital audio signal.)

Hope to see some of you at this workshop, I anticipate having a smallish group of people which allows for easier interaction and dialogue between participants. Bring your MIDI controllers, your fuzz boxes and above all your headphones. This should be fun!