Visualisation of Live Code by Alex McLean (Goldsmiths), Dave Griffiths (FoAM), Nick Collins (University of Sussex) and Geraint Wiggins (Goldsmiths) — Abstract: In this paper we outline the issues surrounding live coding which is projected for an audience, and in this context, approaches to code visualisation. This includes natural language parsing techniques, using geometrical properties of space in language semantics, representation of execution flow in live coding environments, code as visual data and computer games as live coding environments. We will also touch on the unifying perceptual basis behind symbols, graphics, movement and sound.

1. Introduction

Live coding, the improvisation of video and/or music using computer language, has developed into an active field of research and arts practice over the last decade (Wang and Cook; 2004; Ward et al.; 2004; Collins et al.; 2003). Live coding is made possible by dynamic language interpreters, which allow algorithms to run while they are being modified, taking on changes without any break in the audio or visual output generated by the code. The development of software becomes part of the art in a very real sense; at the beginning of a typical live coded performance there is no code and no audiovisual output, but the output grows in complexity with the code.

A frequent criticism of computer music is the lack of performance, where an artist hides behind their laptop screen, and the audience is unable to see any activity that might ground their experience of the music (Cascone; 2003). Solutions continue to be explored, with many researchers focussing on developing tangible interfaces which bring the computer closer to a traditional instrument. However, a live coding tradition has developed taking the straightforward approach of projecting whatever is on the artist’s screen: the code, moving cursors, the debugging output… The audience is then able to see the human movements and code structures behind an improvisation.

This tradition of projecting screens is itself open to criticism; the audience members may feel distracted, or perhaps even excluded by the projection of code written in language they do not necessarily understand. The alternative of showing nothing, hiding behind a laptop screen, is felt to be untenable, but perhaps more should be understood about the practice of projecting code. Watching the articulations of a live guitarist may enhance the experience of a listener who does not play a musical instrument themselves. Can a live coder elucidate the more abstract thinking gestures of their practice? The search is on for ways of visualising code development that allows non-programmers to enhance their enjoyment and understanding of a live coded piece.

2. Perceiving code

Generally, a programmer cannot work with their eyes closed; a programmer’s text editor is a visual interface1. Text editors have gained many features over the last few decades, to the point where we no longer call them text editors but Interactive Development Environments (IDEs). The visual presentation of code has developed its own aesthetic; colour is used to highlight syntax, fonts have been designed for code (e.g. ProFont, proggy), and visual tools for navigating around tree-like code structures. Nonetheless computation is fundamentally about symbol manipulation, and the composition of symbols lies at the heart of every IDE. When our eyes saccade across code, the shapes on the screen are categorised into these symbols, and we perceive them as the tokens (words) and statements (sentences) making up our program. The computer interprets code as a one dimensional string of discrete symbols, but humans perceive it as symbols within a spatial scene. Expert programmers may be able to chunk larger blocks of code as meaningful entities; less experienced live code audiences may become stuck on small details, but an elaborate dance of spatial change to code is evident over time.

Our perception of source code is aided not only by spatial organisation, but also by colour highlighting, in-line documentation and the well chosen names given to abstractions and data structures. These features are collectively known as secondary syntax2, being that ignored by the interpreter but of benefit to programmers in understanding and organising their code. A challenge to those pushing the boundaries of programming language design is to find ways of taking what is normally secondary syntax as primary. For example the ColorForth language uses colour as primary syntax, replacing the need for punctuation. Even more radically, the instruction set of the Piet language illustrated in Figure 2 is formed by first order colour relationships within a two dimensional grid; instructions include directional modifiers so that control flow travels in two dimensions. Piet, among many other esoteric languages, is inspired by the two dimensional syntax of Befunge shown in Fig. 1, a textual language where arrow-like characters change the direction of control flow. Some languages bordering on mainstream, such as Haskell and to a lesser extent Python have a syntax that takes two dimensional arrangement into account when grouping statements, although this is otherwise unusual.

Secondary syntax is of great importance to human understanding, despite being ignored by the computer interpreter. Without spatial layout and elements of natural language a program would be next to unreadable by humans. Humans live an embodied existence in a spatial environment, and while we are perfectly able to perform computation, our spatial ability still supports such thought processes (Gärdenfors; 2000). As a result source code, as Human Computer Interface, is a half-way mixture of geometrical relations and symbolic structures. This is true even of the ‘patcher’ dataflow languages in common use in the digital arts (Puckette; 1988), such as Max and PureData. Patcher languages are often described as ‘visual’, but in fact all the functions are defined textually, and the visual arrangement is purely secondary syntax 3.

Visualisation of code may either act as secondary syntax in order to enhance code comprehension for human viewers, or go further as primary syntax to enhance meaning for both humans and computers. The latter is of particular interest, as to some extent it requires making models of human perception the basis of computer language.

2.1. Morphology of Sound, Shape and Symbols

TurTan is a geometric visual live coding language introduced by Gallardo et al. (2008), using the technology of the Reactable (Jordà et al.; 2007). The functions of the language are manipulated as physical blocks that are placed on a tabletop interface, with nearest neighbours forming a sequence, and relative angle mapping to the function’s parameter. The functions describe turtle graphics operations, and the resulting recursive forms are continuously updated on the table surface display.

TurTan inspired a system by Alex McLean and introduced here, with the working title of Acid Sketching. In Acid Sketching, a sound is specified simply by drawing a shape, where morphological measurements are mapped to parameters of an acid bassline synthesiser. The area of a shape is mapped to pitch, its regularity (perimeter length vs area) mapped to envelope modulation, and relative angle of central axis mapped to resonance. Several such shapes are drawn in an arrangement, where a minimum spanning tree of their centroids is taken as a polyphonic sequence, where distance equals relative time. Feedback may be projected back on to the drawing surface, so shapes flash red as they are triggered. A static figure would not make this clearer, however illustrative video is available online at http://yaxu.org/acid-sketching/.

While Acid Sketching and TurTan are far from what is typically understood as live coding, both lead us to challenge understanding of the role of symbols, shape and geometry in computation. Investigating how such concrete forms of interaction could be married with the abstractions of general, Turing complete programming languages could be an interesting research topic itself.

Critically connected to live coding engagement with time-based media, is the time-based revelation of code itself. For electroacoustic music, Pierre Schaeffer’s theories of sound timbre have been further dynamised into the time-variant sonic gestures of Denis Smalley’s spectromorphology (Landy; 2007). For live coding, we might analogously dub ’codeomorphology’ as the changing shape of code over time. Examples include the accumulating code revisions referenced on the edge of ChucK language Audicle documents, or SuperCollider’s ‘History’ class to document a live code performance. More visual representations of change over time would include accessible visualisations of programmer activity. Metrics might be displayed to characterise changes per second, from coarse keystroke counts to the depth of parse tree disruption; this brings us to self-evaluating performances, and coder re-coding of their very visualisations…

3. Visual experiments in live code

This section serves to introduce four novel visual/geometric live coding systems by Dave Griffiths, namely Scheme Bricks, Betablocker, Al-Jazari and Daisy Chain, along with some of the systems which inspired them. All of these languages were constructed within Fluxus, a game engine designed for live coding performances and experiments and available under a free (GPL) license from http://www.pawfal.org/fluxus/.

3.1. Execution flow and operational events

vv < <
2
^ v<
v13v4
^ ^
> >?> ?>5^
v v
v97v6
v v<
8
. > > ^
^<
Figure 1: A pseudo-random number generator written in the two-dimensional language Befunge.

Figure 2: Source code written in the Piet language with two dimensional, colour syntax. Prints out the text “Hello, world!”. Image © Thomas Schoch 2006. Used under the Creative Commons BY-SA 2.5 license.

Figure 3: Core war runtime display, showing visualisation of process memory shared between the players.

Figure 4: A live edit in the Betablocker environment, selecting an instruction from a wheel of possibilities.

Figure 5: The robots of Al-Jazari, each with a thought bubble containing a program, live coded with a gamepad.

Figure 6: SchemeBricks, a lisp environment using colour instead of parenthesis, and flashes as a cue for control flow.

Figure 7: A section of a Daisy Chain program.

Computation is a metaphorical movement, where algorithmic processes operate on data (which can include the algorithms themselves) in memory in the discrete time steps of the CPU. Ways of visualising memory as it is changed have been developed for conventional debuggers, particularly in microcontroller applications where memory is small enough to be viewed in its entirety. More novel visualisations also exist, such as Tierra, an artificial life simulation where code evolves in a Darwinian competition which can only be appreciated when viewed as such, or Core War (Fig. 3), a game where player/programmers write code which fight over memory address space.

Live coding has the unique opportunity to visualise the movement of an underlying process while it is being formed. This helps an audience appreciate a live coding performance in a more meaningful way – as it bridges the gap between an abstract description of a process (the code) and process itself (the generated pattern of movement through memory). Betablocker (Fig. 4) is a raw visualisation of an imaginary 8-bit processor operating in 256 bytes of memory. This brightly coloured live coding environment is operated by writing assembly code with a gamepad. The processes are visualised while they operate on the memory addresses and trigger sound events. Processes are able to modify themselves and each other, resulting in highly dynamic relationships which are challenging to control.

A more traditional method of programming is employed in Scheme Bricks (Fig. 6), a geometric interface for constructing Scheme programs. Scheme Bricks takes advantage of the isomorphism of code and data in the Scheme programming language, and is inspired by the Scratch language designed for use by children (Resnick et al.; 2009). Scheme Bricks allows you to drag, drop and plug together programs rather than typing. This has some potential side effects; in a performance situation, it is impossible to have a mismatched parenthesis error, as is common in other lisp-like languages. It is quicker to change the overall structure of the program as sections can be removed and reinserted easily by drag/drop actions. Unwanted sections are pulled out of the program and set aside rather than being deleted, and accumulate around the program as ‘spare parts’ which are often later ‘recycled’ by being pulled back into another section.

Scheme Bricks uses visual feedback to relate sound events to the code; the instruction which triggered a sound event flashes as the sound is played. This minimal approach to process visualisation makes the relationship between sound and code structure clearer than Betablocker’s more complete visualisation, and is useful for the performer to immediately locate the code generating a particular sound event.

Daisy Chain (Fig. 7) is an attempt to embrace less rigid structures while maintaining enough of a computational basis to qualify as a live coding performance. It follows a processing system based on Petri nets (Petri; 1966), where executable instruction tokens move around a directed graph. Daisy Chain programs create and modify the graph topologies that they inhabit, producing sounds as a side effect of the computation. The look of the performance was designed to be as far from conventional programming as possible, hand animated flowers and drawn instruction symbols moving around graphs constrained by spring models.

The nodes of a Daisy Chain graph have a fixed lifetime, which was introduced in order to counter a common problem with live coding where the audience watching and performer concentrating on programming tend to perceive time differently. Daisy Chain prevents musical structures from persisting too long, keeping the performance moving forward at a rate the performer can control beforehand.

3.2. Computation in game worlds

Code has a long tradition of use in games as a gameplay mechanic, an early example being Core War developed in the mid 1980s and discussed above in §3.1. More recent games such as Carnage Heart and Marionette Handler are mainstream games for the Playstation which employ programming environments using icons. These programs are used to control robots which battle it out in large virtual arenas. Popular game titles such as Little Big Planet allow the player to construct machines as part of game worlds, complex enough to support Turing complete computation. Kodu, a research project at Microsoft goes even further, as an end-user games programming environment on the XBox.

Al-Jazari is a deliberate attempt to fuse games and live coding performances. It was designed to use a similar visual process to BetaBlocker, but this time mediated through the actions of robotic agents moving around a 3D world, triggering sounds as they do so (Fig. 5). The use of visual agents following commands rather than abstract processes is intended to make the performance more immediately understandable for the audience. Al Jazari has been expanded as an art installation, audience participatory performance and recently as a facebook game – with the aim to increase the accessibility of live coding to the point where anyone can become a live coder.

4. Conclusion

Visualisation is central to live coding. In this article, we have confronted how code is perceived by performers and audiences, and in what ways visual elements contribute to the primary syntax and semantics of a programming language meant for live coding. Consideration of visual elements of code have also become essential as live coding has formed the basis of virtual game worlds. We have introduced a number of novel systems, presented here as explorations of these themes. Visualisation of live code however remains under-investigated in terms of the psychology of programming; while Blackwell and Collins (2005) lead the way into HCI, evaluation protocols are yet to be adapted and applied to experience of live coded performances. This is however fertile ground for practice based research, and we anticipate the changing shapes of code over time, a codeomorphology at timescales from individual performances to lifetimes of artistic and technological development.

Bibliography

[1] Blackwell, A. and Collins, N. (2005). The programming language as a musical instrument. In Proceedings of PPIG05. University of Sussex.

[2] Cascone, K. (2003). Grain, sequence, system (three levels of reception in the performance of laptop music). In Kleiner, M. S. and Szepanski, A., editors, Soundcultures. Suhrkamp.

[3] Collins, N., McLean, A., Rohrhuber, J., and Ward, A. (2003). Live coding in laptop performance. Organised Sound, 8(03):321–330.

[4] Gallardo, D., Julià, C. F., and Jordà, S. (2008). Turtan: a tangible programming language for creative exploration. In Third annual IEEE international workshop on horizontal human-computer systems (TABLETOP).

[5] Gärdenfors, P. (2000). Conceptual Spaces: The Geometry of Thought. The MIT Press.

[6] Jordà, S., Geiger, G., Alonso, M., and Kaltenbrunner, M. (2007). The reactable: Exploring the synergy between live music performance and tabletop tangible interfaces. In Proc. Intl. Conf. Tangible and Embedded Interaction (TEI07).

[7] Landy, L. (2007). Understanding the Art of Sound Organization. The MIT Press.

[8] Petri, C. A. (1966). Communication with automata. Technical report, Applied Data Research Inc.

[9] Puckette, M. (1988). The patcher. In Proceedings of International Computer Music Conference.

[10] Resnick, M., Maloney, J., Hernández, A. M., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., and Kafai, Y. (2009). Scratch: programming for all. Commun. ACM, 52(11):60–67.

[11] Wang, G. and Cook, P. R. (2004). On-the-fly programming: using code as an expressive musical instrument. In NIME ’04: Proceedings of the 2004 conference on New interfaces for musical expression, pages 138–143, Singapore, Singapore. National University of Singapore.

[12] Ward, A., Rohrhuber, J., Olofsson, F., McLean, A., Griffiths, D., Collins, N., and Alexander, A. (2004). Live algorithm programming and a temporary organisation for its promotion. In Goriunova, O. and Shulgin, A., editors, read_me — Software Art and Cultures.

Footnotes

1. A counter-example would be programming interfaces for the blind, which employ speech synthesis.
2. The term ‘secondary syntax’ is problematic. Firstly, secondary syntax is only secondary relative to the computer interpreter, and not the human. Secondly, secondary syntax is not syntax in any clear sense; indeed spatial relationships are the basis of semantic meaning as understood in the field of cognitive linguistics. However as secondary syntax is the standard term used in the field of Human Computer Interaction (HCI) we persist with using it here.
3. In Max, left-right position alters execution order, although relying upon this is discouraged in favour of the ‘trigger’ object.

Analogous invites proposals for presentation at Analogous Interactions events for the International Computer Music Conference, taking place at Stony Brook University, in association with New York University, and the Electronic Music Foundation of New York City. Works should explore the intersection of computer music and emergent phenomena — including, but not limited to, generative sound- and video-works, performative ecologies and installations, live-coding and musical improvisation, reality-based games and social experiments, biomedical hacking and new technology, artificial intelligence and chaordic systems. Works should be “nondeterministic”, having an unpredictable and/or live element, and should be appropriate for a performance, an installation, or a social event. (Both works-in-progress and finished works will be considered.)

Visit here to submit work for ICMC 2010. Applicants may submit more than one work, however, a separate proposal must be made for each. Select “Analogous Interactions” for AI-related works. The deadline for submissions is December 31, 2009.

Submissions must include the following

* Title of Work.
* Artist(s) Contact Information.
* Topic Area: Select “Analogous Interactions”.
* Project Keywords.
* Project Abstract.
* PDF file containing:
* Type of work: Choose from “Performance”, “Installation”, or “Social Activity”.
* An Artist Biography (250-word maximum).
* An Artist Statement (250-word maximum).
* A Project Description (350-word maximum).
* Detailed Technical Specifications (100-word maximum).
* Zipped folder containing three appropriate excerpts and/or other samples of the work to be presented (MP3-formatted audio files, MP4-formatted video files, and/or PDF schematics).

(Visit here to view the official ICMC Call for Works. Visit here for information regarding the International Computer Music Conference. Please direct all eligibility questions and other ICMC- or AI-related inquiries to Marie [at] AnalogousProjects.org.)

ABOUT ANALOGOUS PROJECTS

Complexity theory is not new to art or to our culture. It migrated from computer science and biology to economics and art and, with the advent of the world wide web, it invaded our collective subconscious. Analogous seeks to support complexity-driven art and artists playing under this conceptual umbrella of “Interaction Art”. Progress occurs by metaphor and analogy: Their hope is (by bringing together people and projects irrespective of media and genre) to enable philosophical crosstalk. Analogous events and performances have been reviewed in The Wire, Make Magazine, Time Out New York, and The Village Voice. They received a Village Voice Best-of-NYC Award in October 2008 for “Best Arts Organization Centered Around Recycling”.

ABOUT THE ICMA

The International Computer Music Association is an international affiliation of individuals and institutions involved in the technical, creative, and performance aspects of computer music. The ICMA serves composers, engineers, researchers, and musicians who are interested in the integration of music and technology.

Two performers, one singing and one processing, create a dense pallet of sound and imagery derived entirely from voice.

Luke DuBois and Lesley Flanigan explore the modality of voice through live sound and video. Performing an especially dark and lovely set for pre-Halloween, this will be one show not to miss. Listen to an excerpt: here.

Live Coding Duet - ‘bang’ from Scott Hewitt on Vimeo.

Live coding is a new direction in electronic music and video, and is starting to get somewhere interesting. Live coders expose and rewire the innards of software while it generates improvised music and/or visuals. All code manipulation is projected for your pleasure.

As part of the din collective fest from thursday til saturday, the TOPLAP UK collective will live code beautiful music in the main bar in shunt lounge from 10pm until the early hours. There’ll be a lot of other nice music happening around shunt from 8pm. The line up will include: Thor Magnusson, Yeeking, Cane toad orchestra, Michele Pasin, MCLD, Slub, Jaganyax.

Shunt is the system of caverns through a passageway from Joiner Street, between London bridge tube and railway station.

More info: http://toplap.org/uk/

Live coding is inclusive and accessible to all. Many live coding environments can be downloaded and used for free, with documentation and examples to get you started and friendly on-line communities to help when you get problems. Popular live coding software includes supercollider, ChucK, impromptu and fluxus. Live patching is live coding with graph-based languages such as the venerable pure-data. It’s also possible to livecode with a gamepad, e.g. with the robot oriented Al-Jazari.

– Haskell hackery by yaxu of slub

Transfer — an evening of beautiful experiments in music from humans and computers as part of the knowledge futures conference :: microfolk, brainjazz, robotic theramin cabaret and livecoding :: October 16, 2009; 7:00 - 10:00 pm :: Goldsmiths Great Hall, New Cross, London.

Featuring: Leafcutter John :: Leafcutter John’s experimental approach to music, including handmade synthesis algorithms, contact microphones and handmade interfaces like his “electric breasts” beloved him to a crowd more used to industrial techno through his chaotic Planet Mu releases. More recently though his love of folk music has shown in his recorded work, his 2006 album finding his guitar and his voice between electronic forests. It’s not clear what he’s going to do for Transfer, but it’ll be chosen from one of the broadest sonic pallets in London.

Finn Peters Quartet :: Finn Peters (sax / flute / fx), Matthew Yee-king (SuperCollider), Oren Marshall (tuba / fx) and Tom Skinner (drums / synths / fx) will play prototypical versions of tracks from the forthcoming ‘Music of the Mind’ album which features music generated, modulated and inspired by the activity of the brain. As usual, you can also expect some noisy, wild card improvisations.

Spacedog (the Angliss sisters and Clara 2.0) Spacedog present Electroplasm: space songs, torch songs and death ballads with theremin, vocals and musical automata.

Slub: Slub are three live coders who have made software to make music to drink beer to for the last nine years. Slub sound emerges from slub software; melodic and chordal studies, generative experiments and beat processes. Process-based sonic improvisations; live generative music using hand crafted and live coded apps, scripts, l-systems, daisy chains and traffic simulations in networked synchrony. With roots in UK electronica and tech culture, slub build their own software environments for creating music in realtime. Only custom composition and DSP software is used. Everything you hear is formed by human minds.

A Goldsmiths Digital Studios event as part of the LCACE inside out festival, with support from Sound and Music, the Sound Practice Research centre, TOPLAP UK and the PRS Foundation.

Blank Pages #8 with Stefan Tiedje - Renaud Rubiano - Barreiro Servando - João Pais - Duan Wasi - Dominik Tresowski :: September 6, 2009; 5:00 - 6:00 pm :: NK - Elsen str 52 - Berlin.

The Blank Pages Performance is an improvisation involving live coding, where the participants are musicians and instrument makers at the same time. The performances are never prepared and the participants do not necessarily know each other. Each participant has a station on which he creates a sound making program in real time using Pure Data or MaxMSP. These programming environments allow them to write and modify their code while continuing to produce sound and/or video. There is no computer connection between the stations: only listening to each other allows the participants to play together- the quality of the music produced is based on this central idea and it is each performer’s responsibility to listen as much as possible. This, the score, and the four points below are what guides the musician/programmers through the Blank Pages Performance.

1. The performance lasts one hour. This is the length redeemed sufficient to construct and develop a dialogue between the performers.

2. Each participant must use one of two programming languages written by Miller Puckette ; Pure Data or Max MSP. These programming environments were conceived for the real time creation and processing of data, sound and video.

3. The musician/programmers must begin the performance with a blank programming page. They are therefore set in a situation of pure improvisation since even there instrument is non-existent at the beginning of the set.

4. It is strictly forbidden to load or save a file during the entire session.

Live coding is a new direction in electronic music and video, and is starting to get somewhere interesting. Live coders expose and rewire the innards of software while it generates improvised music and/or visuals. All code manipulation is projected for your pleasure.

Day of the Triffords from Andrew Sorensen on Vimeo.

Haskell hackery by yaxu of slub

Live coded VJing from fluxus creator Dave Griffiths, also of slub.

Live coding is inclusive and accessible to all. Many live coding environments can be downloaded and used for free, with documentation and examples to get you started and friendly on-line communities to help when you get problems. Popular live coding software includes supercollider, ChucK, impromptu and fluxus. Live patching is live coding with graph-based languages such as the venerable pure-data. It’s also possible to livecode with a gamepad, e.g. with the robot oriented Al-Jazari.

Source: TOPLAP.

Puredata, or just Pd, is an open source tool for multimedia programming. Because of its open source nature, much of its development result from a community effort of developers worldwide. Some centers do have more people engaged, like the places that held the two previous conventions. The first convention took place in Graz, Austria, in 2004. The second happened in Montreal, Canada, in 2007. It is a great satisfaction that we continue this event by bringing it to yet another continent, with the intent to promote the formation of an important group of developers locally. In fact, in may of 2008, we had a national convention in Brazil, which followed the same format of the previous international conventions, and worked as a first gathering to organize this international event. The format includes the show of artistic works, academic works, discussion regarding the interests of the comm! unity, and diverse courses.

We invite artists, producers, developers and further enthusiasts of the open source tool Puredata to send works and projects alike in the following categories:

A) Art Festival: (Art Installations, Concerts, Performances & Audiovisual Presentations).
B) Mini-Courses & Workshops.
C) Paper Sessions/Posters.
D) Round Tables & Discussions.

Applicants are invited to submit in multiple categories, especially if related (example: paper + artwork) - not that this will favor in the selection process.

Please note we are looking for a diverse collection of works, hence there might be a selection among several similar proposals (and more unique and original ones might have some advantage).

Let us know if you have an institution support that may cover travel expenses, we are looking for partnerships to help with funds.

Possible (yet to be properly officialized) Locations & Partnerships:

- MIS, Sao Paulo’s Museum of Image & Sound.
- PUC, School of Multimedia & Design.
- SESC-SP, Sao Paulo.

Promotional Support:
- CCSL (FOSS Competence Center)

Acceptance notice: APRIL 10, 2009!
Here is the address to send works & questions to: pdcon09 [at] estudiolivre.org

Addresses of the Official webpage for news updates & more info: http://convention.puredata.info :: http://estudiolivre.org/pdcon09 .

Proposals for the Art Festival

Performances, Concerts, Audiovisual Presentations & Art Installations (audio And/Or Visual): As it is the general concept of the event, we long for the discussion regarding the aesthetics and politics of Free / Open Source Software Culture & technology. In such context, we welcome all forms of works related to audio and/or visual, including real-time interactive works, improvisations, Live electronics/ instrumental/ electroacoustic mixes, Sound installations, Performances, Network art, Robotics, Software Art and Interdisciplinary works.

Demonstrations and General Info about Artistic works can be submitted online in Portuguese, Spanish, or English. Please, specify the necessary materials so we can do our best to provide them.

If language is a part of the artwork, the festival is open to any idiom, although subtitles in English should be provided when applicable.

We look for art installations that adopted Puredata in its development. Nevertheless, at the last extent, we are open for works realized under the context of Puredata (using puredata in some part of the process) as well as open source tools.

We are looking for partners to help us with tickets. Any suggestion is welcome.

Note for ART-INSTALLATIONS (Audio And/Or Visual): In order to avoid dependence on travel funds from the event, it would be nice to have some works installed without the need for the artist(s) to be on-site. This also implies that such works should be technically simple.

Call for Posters/Papers: Abstracts and papers may be submitted in English. The works will be organized in categories depending on what we receive. At first, we contemplate a greater distinction into 3 categories: Technical, Artistic and Theoretical.

The topics are generally open to the usage of Puredata in interactive art production/research, the philosophy and social aspect of Free Open Source Culture, and scientific research. Some possible themes could include:

- Programming Puredata externals
- Puredata versus Max/MSP
- Puredata versus SuperCollider, CSound, Processing and alike
- Hacking Puredata
- Future Projections for Puredata
- Hacktivist culture
- OpenContent and Creative Commons versus Intellectual Property forms
- Finding an Art Historical context for Open-Source Software Art
- Sampling and Plunderphonics as artistic strategies
- Computer-Supported Cooperative Work
- Networking
- Live Coding
- Philosophy, Culture and Sociology of Open Source Software and Open Works
- Aesthetics of New Media/New Technology Art
- Using Puredata in Science/Research & Artistic Works: (Digital Signal Processing, Generative Works, Artificial Intelligence/Life & Computer-Aided Work in General, User Interfaces - Human computer interaction/Virtual reality interaction -, Realtime Performance, Auditory/Visual perception and cognition, Acoustics/Psychoacoustics Modeling, Sound Synthesis, Timbre & Sound Models, Biological and medical uses of Puredata.

And so on…

Check Submission of Works for Poster & Paper guidelines.

If you wish to send a Poster, the limit is 4 pages, other works are limited to 6 pages.

SUBMISSION OF WORKS: Round Table and Discussions should be proposed on the puredata list to be discussed and decided upon previously by the community and participants in general.

The rest needs to be sent through our online system, with the provided Paper Template And Forms. Check here for news and links. Questions about it must be sent to figocris [at] gmail.com.

Poster Guidelines: 120cm height x 90cm wide

Papers are limited to 6 pages and must be submitted as PDFs.

If you wish to send a Poster, please send a short Paper limited to 4 pages.

We are studying the possibility of publishing the works online (both papers & Posters) in digital/hypertextual format s well as in a printed version with DVD-ROM.

Composer/performer Joan La Barbara writes: “I’ll be performing my works Shimmer and ROTHKO with live video projection by Kurt Ralske. Shimmer explores impossible sounds, sounds inside the mind, and the exploration of the creative process in real-time. ROTHKO, monochromatic and densely layered, was inspired by the paintings in the Rothko Chapel in Houston.” Kurt Ralske’s video projections mix pre-selected images with live capture/live modified ones, using his own specialized software to allow La Barbara’s live voice and sonic atmospheres to modulate the visuals.

Fluxus reads live audio, midi or OSC network messages which can be used as a source of animation data for realtime performances or installations. Keyboard or mouse input can also be read for games development, and a physics engine is included for realtime simulations of rigid body dynamics.

The built in scheme code editor runs on top of the renderer (see screenshots), which means you can edit the scripts while they are running. As well as making live coding possible, it’s also gives you a very fast feedback way of experimenting or learning about graphics and animation. The core graphics and synthesis engine is written in C++ for speed, and it’s high level language is PLT Scheme, chosen for creative flexibility.

You may also be interested in an experimental video texture extension for fluxus available here.

Tutorial Movies: There are a series of tutorial livecoding movies, to give you some ideas about livecoding strategies using Scheme and fluxus. See the fluxus secrets page.