nicolas @ uucidl

Openframeworks: C++ for artists

August 29, 2009 by nicolas, tagged programming and art_and_code, filed under commentary

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: Pure Data and its community

August 22, 2009 by nicolas, tagged programming and art_and_code, filed under commentary

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.

Sebastian Oschatz on VVVV

August 14, 2009 by nicolas, tagged programming and art_and_code, filed under commentary

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. ― 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.

Luke Dubois: software for live performances

August 12, 2009 by nicolas, tagged programming and art_and_code, filed under commentary

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.

ART+Code: Golan Levin ― Introduction

August 9, 2009 by nicolas, tagged programming, litteracy and art_and_code, filed under commentary

on software literacy

I’m kicking off a series of summaries and commentaries of the ART+Code conference talks. The conference was organized in Pittsburgh in March 2009. It presented many programming environments, with a focus on how programming tools might help more people, and in particular children learn programming.

ART+Code’s conference-founder Golan Levin is starting up by asking why¹ we should all be programming.

It starts with an observation: we interact with software more and more regularly; be it in appliances, on the internet, or even within administrations or work. As a consequence, software in general has taken an increasingly important place. Computer and software literacy has however not developed as much: while using software is a common activity, writing software is much less so.

In contrast with writing, most people don’t program for self-expression. The population has not made writing software part of everybody’s toolset. Meanwhile, with the exception of Free Software/Opensource, software has become more opaque and challenging than ever: you can’t pick it apart, like you can do with a hardware device.

Software litteracy is generally sought after in order to get a job, and in general for economical reasons.

And despite the pioneers who started writing artistic software in the early days of computer science in 1960 and beyond, software engineers and companies themselves do not acknowledge the existence of such programs.

For example, there is no category for "Artistic" software in Apple’s Application Store. Non-utilitarian or purely artistic software are largely ignored².

Demosceners know this problem too, as there’s no place for demos in the application store either, nor is the population in general aware of them.

This also shows a problem with distribution of such software. The demoscene has historically been a way to answer this: A set of — originally peer to peer, nowadays centralized — traditions and technical mechanisms to distribute purely artistic software.

In the context of the ART+Code conference each talk will show that one programming environments is not often separable from its community.

Programming for one’s own self expression is different from the more traditional view of solving computer science problems, or the "filing" type of applications prevalent nowadays in most companies.

For this reason and since they show no willingness to touch the general public, teaching programming should not be a monopoly of computer science departments³.

¹ talking about literacy, when we say of someone he is literate we do not simply mean he is able to read and write a few administrative letters. There is a certain expectation on the resulting works. The quality of the software we write should remain important even if programming becomes popular.

² save ifart or screensavers. Note that we group most games here amongst utilitarian software, although the boundary with artistic software is not so straightforward to define.

³ the early home computer demoscene played that role in the 80s and 90s in europe. Kids learned programming, motivated by the energy they saw in demos encountered in their use of computers: as they shared programs with one another, they would invariably encounter a demo amongst the pirated game disks. Today’s sanitized, heavily categorized software environment, the advent of the internet and the advent of online gated communities distanced end users from such serendipitous encounters.