nicolas @ uucidl

Eyeo Festival had a few interesting and entertaining talks, however I’d like to bring attention to one in particular.

Eyeo2012 - Nathalie Miebach from Eyeo Festival on Vimeo.

Knowing nothing about the Festival, besides that Robert “Flight404″ Hodgins had done a very likeable presentation there, I watched in succession the talks from Ben Fry, Amanda Cox and Nathalie Miebach.

The three of them deal with data visualisation, however Nathalie Miebach was the only one who concretely address the “elephant in the room” of visualisation, which is that although engrained in data, it is an editorial exercise.

And she does it brilliantly and with great honesty.

Her sculpture and her scores naturally embed performance, play, interpretation and the objectivity of measurements. Sometimes she even juxtaposes measurements with her own subjective records, to create hybrid narrative (and quite colorful) works.

Her concluding remarks, that we must not forget to interact with data by touch, also brings to light that we must not let the Ipad or other tablets hijack the meaning of touch, the way Facebook hijacked the meaning of friendship. Touching is not just about finger impacts. It’s as much if not more about feedback.

Three enthusiastic iconoclasts talk about Openframeworks, or OF.

OF is a software development package with ready-made tools to write interactive, audio-visual programs in the C++ language.

Why C++? The enduring success of this industrial language has provided a great deal of much desired libraries to it. Its success as a system language has also ensured a good baseline performance. The OF project was started to let more people take profit of this situation.

Installations and standalone programs are written in parallel with OF. In its current pre-release state, getting feedback from projects helps defining its core and improving it.

As general philosophy, users are encouraged to improve OF and make it evolve.

Teaching C++ to artists? Are you insane?

C++ made easier could be the unofficial slogan for OF. The tools it offers ‒ APIs ‒ avoid using fancy C++ concepts, and generally try to look like their counterparts in the successful JAVA-based package, Processing.

The authors themselves started with Flash (Fun), Lingo (Poetic) then Java (Learning by decompiling) and ACU, an earlier C++ based library written used internally at the MIT.

And returns on the first OF-based projects say those without a programming background have managed to learn and make use of it.

The main role OF is playing here is to provide wrappers for existing C/C++ libraries. OF hides their guts behind an easier and consistent facade.

OF is organized into two area:

• OF Core
• OF Addons

The OF Core represents the stable part of the wrapper, and OF Addons are libraries supported by third-parties and often quite experimental.

At the time of the talk it can be used in Mac, Windows, Linux and the iphone.¹

Similarities with Processing are numerous: The idea of not focusing on one single type of application, and rather trying to support various types such as installations, standalone programs, mobile phone programs, even print-based projects². The role as a meeting point for a community of creators. The label / brand it carries with it. And also the challenge that its founder face as they integrate a selection of libraries.

A great number of demonstrations is given then during the talk, and we especially like the last few minutes of the talk which concentrated on the community aspects.

The framework in its pre-release state is breathing through its internal forum. This gives the OF team and their users visibility of each other’s projects and encourage collaboration. The question is how to preserve this once OF has been released more widely? The team’s answer has been to organize events, workshops, coding parties in order to build and extend a tradition of collaboration around the OF project.

¹ No word was said on what often happens with multi-platform libraries. The tools offered through its API look the same yet when they are implemented by different libraries on different systems or device, then of course the output cannot be guaranteed to be the same. The supported inputs ‒ for example file formats supported for video content ‒ will also vary, for example.

² As with the examples given in the processing session, there is a strong fascination with giving a concrete manifestation to programs, to let them escape from the computer displays, or even to let the computer disappear. Is it because computers are too profane? Is it because while displays nowadays can be huge and high resolution, they are a limitation of their own?

Hans-Christoph Steiner is yet again presenting a visual programming environment historically related to MAX/MSP: Pure Data.

Compared to his two counterparts (S.Oschatz, L.Dubois) H.C. Steiner shows a great deal of enthusiasm especially in the first half of his presentation.

His live examples are more sophisticated and give a better sense of the usage of PD.

What he communicates on the community itself is different from his counterparts: Sharing programs and distributing them seems more common within the Pure Data community than the VVVV and MAX community. This may be solely due to PD itself being Free Software¹.

One interesting piece of his presentation was a praise and critic of the Free Software concept itself, praising its concept for the right it gives to users and criticising its implementations in that the complexity of software systems and languages nowadays builds a high barrier of entry to any user willing to contribute.

After he’s seen examples such as netpd, a server to share pd patches over the network entirely built in PD itself, his opinion seems to be that visual languages can, on their own be legitimately used to create applications. And that their ease of access let them answer the question of improving software literacy (everybody read and write software) asked in Golan Levin’s introduction.

¹ MAX, VVVV and PD may be almost alike, their users have developed different traditions, and there lies different goals and practices. Analyzing a programming language or environment needs to take into account both its objective qualities and also the traditions of its user base.

Another talk about a MAX related project, this time we have VVVV from Meso. The talk goes into more details about the inner workings and the advantages of such a visual language.

http://vvvv.org/tiki-index.php ― more information.

Vvvv is an application and visual programming language published by MESO, a company cofounded by Sebastian Oschatz. Its creation is justified by Sebastian Oschatz as a reaction to the bland and numerous visualization projects which were thriving at the time in the media art community.

MESO’s business model — since it is a company — requires vvvv’s source code to be proprietary. Although the program is free to download and play with, it must be licensed once set up in a commercial context.

MESO’s three developers choose to make vvvv run solely on windows and directx, ensuring the best and most efficient support for such a small team.

Historical roots: MAX/MSP & Pure Data

The user interacts with a constantly running "patch" of nodes connected together with wires. Each wire define the flow of data between operations (nodes) which have inputs (inlets) and outputs (outlets.)

Programs are defined spatially, and syntax errors are never encountered. A program is reinterpreted as soon as it is changed, and runs constantly, always producing content.

VVVV's specifics

The heart of vvvv is a single processing loop, designed to service realtime video processing. Each nodes stands for a particular state — a complex value — in contrast to the original model used by MAX of nodes as message transformation devices. Mentally, the computation model is not that of "pushing messages to children", rather it is about "querying ascendant nodes about their current state".

Networked patches are also supported from scratch (does MAX do it nowadays?)

Sebastian Oschwatz’ presentation style is didactic and slightly detached, and I clearly dozed off in the middle of his presentation, especially as he plod through the following list of topics he covered:

1. (5:25) program while the program is running — instant feedback is provided. It makes program building enjoyable and almost playful, and very immediate.
2. (12:00) inputs at the top, outputs at the bottom — a general downward flow. The types of layout based rules are common in the MAX family yet sometimes a bit hidden. Pure Data for example has horizontal layout rules.
3. (16:37) naming is optional — naming things scares non-programmers. We would rather say that naming values and operations is hard, not scary.
4. (17:55) states and not events — states can be queried and are mutable, enabling optimizations such as not recomputing any descendants if state has not changed.
5. (20:06) spreads — only one data type is moved between nodes, the 1d array. Meso show its tendency to rename/rebrand concepts.
6. (22:45) no errors — no syntax errors in particular. All nodes are made resilient to input data: numbers or array are not constrained to any domain or size and operations are made then via wrapping (modulo arithmetics)
7. (29:06) boygrouping — synchronization of multiple computers and screens. What a strange name again.
8. (36:30) directx / shading languages — modern 3d hardware is supported, and well.

In a very striking part at the end he presents integration with shading languages, which are interpreted by the graphic card. It is striking because we could not feel but slightly uncomfortable as he proceeded to praise a textual language, manipulated with a plain old decrepit text editor. Especially after having praised a visual language for about 30 minutes.

Why doesn’t vvvv provide a graphical manipulation of HLSL shaders? Why lose the — no error, no syntax to learn — benefits he presented earlier? At least
the sense of immediacy is preserved: a shading program is edited and in an instant automatically uploaded to the graphic card.

At this point we are reminded of Field (OpenEndedGroup) a runtime environment which embraces the textual representation of programs and merges it in a rich graphical environment. It seems that vvvv could logically bridge the two, starting from the other direction.

A MAX/MSP/Jitter showcase by Luke Dubois.

Luke Dubois first tells us how he started using laptops and MAX/MSP in the context of a band – Freight Elevator Quartet, – replacing unreliable analog synthesizers with the cold digital precision of software audio synthesis.

This in itself however raised a question, a challenge that any live laptop performer faces: watching someone play on a laptop is not very exciting and pleasurable.

He qualifies live performances as transparent or opaque: transparency denotes how manifest the source and action of a performance are. A transparent performance clearly links actions and their results. And very often, the performance of operators behind their laptop suffers from a high level of opacity¹.

A laptop – unlike a musical instrument such as a violin – is a profane object. Audience members use it daily to communicate, listen to music, watch movies, compute their taxes or play video games. Its operation in itself raises the doubt that the performance really exists and what it consists of. After all, the performer could very well be checking their mails while an audio file is playing.

In summary, Luke Dubois characterizes a live performances according to:

1. its opacity / transparency
2. how profane / sacred is is perceived

I would add an additional axis to this list. Audio/visual/physical manifestations used throughout a performance have to be in harmony: how "physically consistent" the actions are with their results ; for instance, a great motion should result or respond to an equally powerful sound, and harsch visuals to distorted audio.

To increase transparency of the performance MAX/Jitter enables the laptop performer to manifest himself within other channels (controlling lights, video, even actual objects on stage) than audio only.

Regarding how profane a laptop is perceived:

Unfortunately adding a fruit on the cover of the laptop is not sufficient to make it sacred! In contrast, a violin is from the start made to be used during the "ceremony" and for its enjoyment. And as the doubt is raised that a performance is taking place, it needs to be dealt with with a proof: for example, interactivity with the audience such as letting it alter the visuals used in the performance.

Then as an introduction in the world of MAX, Luke Dubois shows live the typical "Hello, World" of MAX/MSP, a simple automata emitting a sequence of random notes².

At this point we drift off a little bit and his talk is starting to feel aimless, although he does a good job of introducing the basics and advantages (simplicity, enable musicians to program) of MAX and its various applications³.

¹ easily the most interesting topic he covered, in a too short and very superficial way. The problems of building enjoyable and meaningful performances. The problems caused and solved by the introduction of computers and videos in such performances. Those are very important topics to cover when you are interested in the use of code (and thus computers) in these contexts.

² at this point in his talk we were reminded by how our own attempt at generating musical structure from automatas. One big problem with automatas is that they never know when to stop. They always have enough energy to proceed to the next step and will never on their own stop producing whatever it is they were producing. Would introducing the concept of an energy source solve this problem? We doubt this would be sufficient. It seems however necessary, for no process in the world goes on continously and feel natural. (There are counter examples however.. What about the sun? What about rivers?)

³ we liked: his project with a performance artist who was instructed to do a 72 hours performance, in which she was playing the role of a woman preparing off before a date. The 72 hour performance was in the end to be accelerated down to a 72 minutes video. The performance itself thus had to be done as slowly as humanly possible — 60x slower? — The result would be at a realistic speed for the performer, and as a blurry show of colour for the background, as the piece is done outside.