Category Archives: Uncategorized

TouchDesigner | Instancing Examples

Four years ago I started collecting examples on working with instances. What started as a rough collection of ideas has turned into a collection of over 40 different examples. In this revised set of techniques the format and presentation has also changed.Initially the user had to mouse around networks and look for readmes to learn about the examples. In this new version all examples can be explored through a purpose built UI:

Explorer screen shot

This new starting point allows the developer to quickly jump between examples without needing to open the TouchDesigner network. The interface is re-designed with three primary interaction regions in mind: The Navigator, The Readme, and The Liveview.

The Navigator

The Navigator organizes examples into sensible groupings. These high level containers can be collapsed by clicking on their heading. Each example also includes a button to jump to the example, or to open a TouchDesigner network view of the example. This allows you to both see the example rendered and see how it was built all at the same time.

The Navigator Pane

The Readme

The Readme pane has a short description of what you’re seeing. This set of documentation is intended to go along with each specific example and includes discussion about the particular techniques employed. Using the globe network icon on the Navigator will open the readme in your browser if you’d like a slightly larger window for reading through the documentation.

Right now there’s a small display bug on macOS that prevents the scroll bar from working correctly – that’s okay, you can always use the globe icon to open the readme in your default browser instead. You can follow along with the bug report if you’re a mac user here.

The Readme Pane

The Liveview

The Liveview let’s you see the output render from the network at a glance — making it easy to determine if this technique is one that you’d like to learn more about.

The Liveview Pane

Jump to Network

In addition to exploring the examples through the viewer, there’s also a button to open the network view for the example. This lets you jump immediately into the network and see how the instances were set-up.

The Explorer and an open network view

This project has been a labor of love to collect, organize, and compile materials for other passionate developers and educators. I’m hoping that enthusiasts, instructors, and creative developers alike will find this useful and interesting both as a tool and as a reference. 

Github: Clone the GitHub Repo

Happy Programming!

❤️ Thanks ❤️

…to Zoe Sandoval for their tireless work editing, play testing, and making all of these examples better. If it wasn’t for their handwork, and attention to detail this tool wouldn’t be nearly as complete or well constructed.

… to Ian Shelanskey for his passion and encouragement to keep making examples, and craft collect them into a single unified example.

… to Michael Walczyk for his mentorship, guidance, and constant enthusiasm. I would have been lost in the GLSL wilderness without Mike, and I always appreciate when I can ask him some crazy question about rendering and mathematics.

… to Elburz Sorkhabi and everyone at The Interactive Immersive HQ. Many of you were kind enough to test and look through these examples before posting this. The engagement and hunger for learning TouchDesigner in that community continues to inspire me, and is a reminder about why these kinds of examples are useful and important to share.

… to the Derivative Team for their toolkit that never stops being fun to use, and for their thoughtful feedback and support through building out this collection. From combing through the forum, to late night conversations with Greg and Ben I wouldn’t have gotten this far without them.

A Conversation with Robert Erdös

Recently I had the great honor of participating in Robert Erdös’s recent project TOP Players. Robert is currently working with Les Ateliers Nomad – you can see some of their work on Facebook. During the roller coaster of stay at home orders, and social distancing Robert’s been interviewing TouchDesigner developers and artists and has put together a casual format for having real conversations about work, artistry, and one’s ever evolving practice.

From Contraption:

The first series of “TOP Players” recordings is focused on revealing the people behind the TouchDesigner community video tutorials, people who showed great generosity and skill in helping others find their way. 

One of the primary goals of these conversations is for users to gain access to the most valuable resources that lead to their success in the interactive world.

The 2020 Lockdown has offered me a unique opportunity to reach these wonderful people and try to share a perspective on their distinctive personalities and amazing work skills.

It was a joy to talk with Robert, and I’d encourage you to both checkout the page he made for this talk, and to follow along with the conversations he’s having with other artists and developers. You can learn more about Robert by checking out his instagram,, or Les Ateliers Nomad.

Follow Robert on

Les Ateliers Nomad on Facebook

A Conversation with Cocolab

Zoe and I were recently invited to participate in an open conversation about “Making the Best of our Current Situation with the Power of Creativity” hosted by Cocolab. Cocolab is a creative studio based out of Mexico City doing work of all scales – from intimate experiences, to enormous projection events they’ve done it all. Like all of us, they’re working to understand how to navigate this strange time, and have been hosting an ongoing series of talks that explore how we might understand and navigate this changing world. Our conversation was moderated by the ever charismatic and playful Elburz Sorkhabi.

You can see our talk at the facebook link below, and if you’re interested in listening in future conversations you should check out their Instagram feed for the next artist and date.

Learn more about MIR

TouchDesigner | Start-up Configuration with Environment Variables

Environment Variables

Environment Variables can be a handy way of passing in information to Touch without setting up a complicated file opening process. Some approaches benefit from using external files to indicate configuration, and at other times setting an environment variable is a better approach. One caution here is that working with Environment Variables can be invisible to the user – so in some cases while this is highly convenient, it can make trouble shooting slightly more complicated. A consideration for working around this challenge would be to set your environment variable at start programmatically. On Windows you might use a .bat or .cmd file. You can do the same operations with Python – of course this requires that you have Python installed on your machine, but it does provide for handy cross platform solution that’s easier to read.

The bit that’s worth thinking about is if you’re going to be running on systems with multiple GPUs. On those systems you have to set your GPU affinity at start. Derivative recommends doing this with a .bat or .cmd file. The trick for us here is that our schema of using a separate python file to indicate our indication will break – in the case of using a system with multiple GPUs, you likely want those two networks configured slightly differently. We can address this by using environment variables instead of a stand alone .json file. Depending on your workflow you might want to move this direction generally, but it’s a little more advanced than we have time to cover in this workshop.

At the 2019 TouchDesigner Summit in Montreal, Zoe and I are going to talk through a number of pieces about large system design and architecture. There’s always more to cover than there are hours in a day, and this little tid-bit, while very handy isn’t one that we have a lot of time to talk about at the workshop. Instead, I thought it would be handy to can leave this little reference here so you can come back to this part when you’re ready to push a little harder on start-up configuration. The big idea is that rather than using that outputlist.json file to tell us how to configure our project, we can instead use environment variables. Touch will read environment variables that are called before the application starts with the Python syntax:


We’d have to re-arrange a little logic in our project, but once we did that we’d be able to set our project’s configuration from another script at start-up. You could do this either with a .cmd script or with Python script. For the more advanced users, if you have another watcher application keeping tabs on your Touch project you’d want to add a mechanism to set an environment variable before starting the target application.

Here’s a quick run down of what this might look like if you’re running a batch script or a python script.

Setting environment variables in a windows batch script

:: echo
:: Display messages on screen, turn command-echoing on or off.
:: "%~dp0"
:: The %~dp0 (that's a zero) variable when referenced within a Windows batch file will expand to
:: the drive letter and path of that batch file. The variables %0-%9 refer to the command line
:: parameters of the batch file. %1-%9 refer to command line arguments after the batch file name.
:: %0 refers to the batch file itself.
:: as a note this CMD or BAT needs to run as admin in order to work correctly
@echo off
set STARTUP=controller
timeout /t 1
start "%programfiles%\derivative\touchdesigner099\bin\touchdesigner099.exe" "%~dp0\your-toe-file-name.toe"
set STARTUP=node
timeout /t 1
start "%programfiles%\derivative\touchdesigner099\bin\touchdesigner099.exe" "%~dp0\your-toe-file-name.toe"
view raw env-var-example.cmd hosted with ❤ by GitHub
Sample Batch Script

Looking closer a the syntax here, we can see that we point to the directory where our TouchDesigner executable is located (the appliaction we want to use), and then point to the file we want to open. But, what is %~dp0?! A little browsing through stack overflow can help illustrate what’s going on here:

The %~dp0 Variable

The %~dp0 (that’s a zero) variable when referenced within a Windows batch file will expand to the drive letter and path of that batch file.

The variables %0-%9 refer to the command line parameters of the batch file. %1-%9 refer to command line arguments after the batch file name. %0 refers to the batch file itself.

If you follow the percent character (%) with a tilde character (~), you can insert a modifier(s) before the parameter number to alter the way the variable is expanded. The d modifier expands to the drive letter and the p modifier expands to the path of the parameter.

Example: Let’s say you have a directory on C: called bat_files, and in that directory is a file called example.bat. In this case, %~dp0 (combining the d and p modifiers) will expand to C:\bat_files.

Read the Thread on stackoverflow

In other words, that little bit says that file we want to open is at the same location as the script we’re running.

Setting environment variables with Python

import os
toe_file = 'path\\to\\your\\file.toe'
# set environment variable
toe_env_var = 'controller'
os.environ['STARTUP'] = toe_env_var
print("startting file with {}".format(toe_env_var))
# set environment variable
toe_env_var = 'node'
os.environ['STARTUP'] = toe_env_var
print("startting file with {}".format(toe_env_var))
Simple Python Script to set Env Vars

Learn More about Environment Variables

TouchDesigner | Hue Control

a tox for controlling phillips hue devices
clone or download from github

matthew ragan
zoe sandoval

TouchDesigner Version

  • 099 2018.26750

OS Support

  • Windows 10
  • macOS



Philips Hue smart lights are intended to be used in homes / studios. The devices come in many varieties – individual lamps, outdoor lights, LED strip lights, etc. These are synchronized by communicating with an additional device called a Bridge. A single Bridge can control up to 50 lights. There are many stand alone applications to drive Hue Lights, and this repo aims to provide some additional control by exposing those controls through TouchDesigner. In order to do this, we use the phuelibrary. There is some additional set-up required in order to use an external library, though hopefully much of this is now streamlined.

This TOX provides global control for all lights, or individual control for single lights.


This module module has some additional requirements in the from of dependencies, as well as some set-up requirements for working with hue devices. To begin we need to ensure that we’ve collected all of the requisite external dependencies

Install Python3

Ensure that you’ve installed a Python 3.5+ variety.

Installing Dependencies for Windows Users

For Window’s users a convenience script is provided here:
In order for this to operate correctly, right click and run this .cmd file as an Administrator. This should first ensure that your python package manager is updated, and that your additional python modules are added to a newly created directory in your project dependencies\python.

Installing Dependencies for macOS Users

For Mac users a convenience script is provided here:
In order for this to operate correctly, open a terminal window and drag the file above into the command line. Press return / Enter to run the bash script. This should first ensure that your python package manager is updated, and that your additional python modules are added to a newly created directory in your project dependencies\python.

Connecting to the Hue Bridge

Before being able to control lights you’ll need to ensure that you can connect to your Hue Bridge. You’ll need to know the IP address for your Hue Bridge. You can locate this IP address by looking at the Hue app on your phone, or by setting your Bridge to have an assigned IP on your router.

You’ll need to enter the IP address of your Hue Bridge onto the component itself, and then press the large center button on the Hue Bridge. After doing this you’ll need to pulse the Set-up Individual Lights button on the base_hueControl TOX.


Hue Admin

Set-up Individual Lights

This parameter will retrieve the dictionary of lights that are currently configured on the Hue Bridge. This will then loop through all of the lights provided by the Bridge and create unique parameters for each light. Specifically it will create pars for:

  • Color
  • Brightness
  • Transition Time
  • Power
  • Pulse to Update

This gives the user the ability to control each light individual – constructing parameters for each light currently configured on a given bridge.

Bridge IP

The IP address for the Hue Bridge – this is used for communicating with the lights by way of the Hue Bridge.

Use Threads

Python operations can sometimes be blocking – meaning that it causes touch to stop responding. By moving to threaded approach we can achieve a result where we can ensure that we don’t totally stall. Lights can sometimes run slightly out of sequence when using threads, though in some cases this is well worth the fact that touch wont completely stall.

All Lights

All Color

This color will be sent to all lights – you can think of this as a global color control. Color is expressed as normalized range of 0-1, with red, green, and blue channels.

All Brightness

Similar to color, this is the brightness control for all lights. This is expressed in a range of 0-1.

All Trans Time

This is the time between the issued command the settings sent to the light. This is expressed in seconds. If you enter a value of 0, the instructions will be sent immediately, though this often produces results that are stuttered.

All Power

This is the power command, the equivalent of “on” and “off”.

Update All

After changing the settings for lights, you use this pulse button to send commands to the lights. This ensures that you can set the parameters before issuing a command to the lights.

Individual Lights

Update by Settings

This pulse button is on the top of the Individual Lighting control page. Unlike a global control, this will send instructions for the configuration of lights based on what’s set ont this page – this in effect lets you send unique settings to each light.

Light n Name

This is a read only parameter that is the Name for a given light that the user has configured in one of the Hue Apps.

Light n Color

The color to send to a given light. Color is expressed as normalized range of 0-1, with red, green, and blue channels.

Light n Brightness

Similar to color, this is the brightness control a given light. This is expressed in a range of 0-1.

Light n Trans Time

This is the time between the issued command the settings sent to the light. This is expressed in seconds. If you enter a value of 0, the instructions will be sent immediately.

Light n Power

This is the power command, the equivalent of “on” and “off”.

Update n Light

After changing the settings for a given light, you use this pulse button to send commands to the light. This ensures that you can set the parameters before issuing a command.


Inspired by the work of:

zoe sandoval
forum inspiration

TouchDesigner | Working Styles | Git

Recently when I was teaching at LDi 2017 a participant asked if I might take some time to document how we use git in our projects at Obscura. Version control isn’t always a sexy topic, but it is a vital piece of our pipeline and process, and one well worth considering if you’re moving away from being a lone developer on projects. It’s also worth getting a handle on version control approaches if you’re looking to join a software team in general.

A Blanket Disclaimer

Git is complicated… ask anyone that’s used git. XKCD has my favorite description of working with git on a regular basis:

Which is to say that I’m not a git expert, often have issues of my own, and have certainly done the dance of copying my flies to somewhere else to ensure that I don’t loose all of my work. I don’t mean to suggest that you shouldn’t use git – you should – but rather that like all things that are new or different to you, this one comes with its own set of challenges. Okay okay… so why should I use it then Matt?! We’ll see below what makes it so powerful, and when it comes to working in teams this far outpaces any other approach – but you have to be patient, thoughtful, and considerate.

What is Git?

Okay so what is git again?

According to Wikipedia:

Git (/ɡɪt/[7]) is a version control system for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for source code management in software development,[8] but it can be used to keep track of changes in any set of files. As a distributed revision control system it is aimed at speed,[9] data integrity,[10] and support for distributed, non-linear workflows.[11]

Uhhhh… say what now?

Many of you, dear readers, are probably landing here because you’re curious about how this works with TouchDesigner. In Touch, the default behavior is that everytime you save a file you get a new version – project.1.toe, project.2.toe, project.3.toe, and on and on and on. The idea of version control is similar except that it allows you to avoid the process of having additional files – you only ever have one version of your file, but you can reach back in time and find other versions. Similar to Apple’s TimeMachine idea, or Dropbox’s version retrieval. You only ever see one file in your directory, but if you realize that you need a previous one, you can reach back and fetch it.

To achieve this, git uses the convention of a commit. When you’re ready to add something to your history, you commit your changes. That is, when you have a version of your file that you want to hold onto, you specifically choose to commit it to your history along with a message about what changed. If you’re working on a team this is great – it means you can see the history of every commit, and what another developer had to say about what they were doing and why they made the change. Git also helps you differentiate between versions – in text based files you can call a command to see exactly what changed between versions and who made that change.

More than that, git also lets you build branches of your project. Let’s say you’re working on an installation. It’s working great, but you want to be able to try out some other ideas or work on some updates for the project. You don’t want to make this change to the project file that’s running, and you don’t want to you don’t want to interrupt the installation’s operation. Moving to another branch lets you work in a parallel project with all of the same file names where you can make all the changes you want, and then decide when to roll that into your actual project.

This becomes especially interesting when you’re working with multiple people. Once you’re working on a large project it often becomes important to have several folks contributing… git helps organize this distributed work, and keep you from overwriting one another’s contributions.

Further, using something like bitbucket or github means that your project is hosted on an outside server – so even if you’re machine gives up the ghost, your work isn’t interrupted.

Challenges in using TouchDesigner and Git

At this point you might be sold on the idea of using git.

YAY! Welcome to the git party!

Before you get too excited, there are some important issues to consider when it comes to using git with TouchDesigner.

  • Most Touch files are binary – what does that mean Matt? Well, it means that unlike a .py or .json, or .py file, your toe or tox file is actually made up of hex strings that are difficult to parse outside of the context of Touch. That makes them very difficult to diff – that is, to tell what’s different between committed versions.
  • Toe Files are whole projects – a toe file holds a whole project, which is great, but makes collaborating very difficult. Part of the beauty of git is that multiple people can work together at the same time without overwriting one another’s changes. That doesn’t make a whole lot of sense if you can’t see what’s different inside of a toe file, and if the whole project is stuck inside of a single file.
  • Using git means learning shell commands or a tool to use git – If you’re going to use git, you’ll have to learn some shell commands, or learn another tool that interfaces with git (github has a great desktop tool). That’s not terrible, but it’s not the same as using something like dropbox box or google drive.

Our Solution

Okay… so how do we make this work then?

Well, first things first, you start by thinking about toxes for your modules / component work-spaces, and your start externalizing your scripts. That’s a big change in workflow for lots of folks, and if you’re not ready for that change that’s okay. if you’re working on big projects, however, and working with other people now is the time to level up. Let’s look at a simple project build so we can see how this might work in practice.

First we need to set up our git project. I’m going to use github – it’s free to use the public version, and it’s got one of the best desktop utilities. Git has a great tutorial for their app so I’m not going to cover that here, instead we’ll look at how the shell commands work.

For starters, you’ll want to install git, I’m also going to use git bash instead of just windows command line (it’s a little easier to read, though you can use either), so if you want to follow along you’ll want to make sure that you hit that checkbox when you install.

There are lots of ways to start a new repo, but I’m going to start mine from my github account. Once I create an account, I’ll need to use the plus button in the top right corner of the page to create a new repo, then choose my settings for it:


Once I’ve created my repo online, I need to clone this to my computer. Cloning my repository means that I’m going to create a local copy where I can make and track changes, and commit to my online repo. To do this, I need to first navigate to where I want my project to live. I’ve created a dummy directory called example on my D:\ drive:


Here in this directory, I’m going to right click and choose “git bash here” to open up a git bash terminal at this directory location.


In our git bash terminal we’ll enter our first clone commands. We’ll first need to copy the URL from the clone drop down menu on the web-page:


Let’s copy that ULR to our clipboard. Next we’ll use the git clone command in our git terminal window to start our cloning process. Here’s our command:

git clone

Here’s what it looks like in our terminal window:


Alright! Now we have our git project cloned into our windows directory:


From here on in we need to make sure that our git terminal is inside of our newly added directory. We can repeat the same step we used earlier – navigate into the directory, right click, and open a git bash here; or we can navigate there in our terminal window. Let’s do this right from our existing terminal window. We’ll need to change our directory to touch_git_example, the name of the newly cloned repo. We can do this with the command:

cd touch_git_example/


Now we’re ready to start working! Let’s start by creating a new folder called toxes. All of our toxes are going to go into this directory:


Next let’s open Touch and save a project file in the root of our directory. I’m going to call mine touch_git_example.toe:


Inside of Touch I’m going to start by getting rid of my project component in the root, and I’m going to create a new base that’s called base_project:


Next I’m going to set up a few more things. Inside of base_project I’m going to create a few elements:

  • container_display – this will be the display elements for my project
  • base_com – this will hold the communication elements for my project

Next I need to externalize these elements. To do this,  we right click on them and choose “Save Component tox…” from the drop down menu:


I’m going to save both of these elements in the toxes directory:


Now we need to make sure both of these components point to their external tox files. We can do this by going to the common page and locating opening our toxes in the external tox parameter field. We also want to make sure that we turn off the “Save Backup of External” parameter:


Notice that these are relative, not absolute paths – this is VERY IMPORTANT. We want our paths to be relative to our project directory. This will help ensure that our externalization process doesn’t break when we move to another computer.

Finally we need to save both of our toxes one more time, and save our project one more time.

YIKES! That’s a lot of steps… what did we do exactly here Matt?

Well, first we set up our project and saved our toe file. Then we created some components that we want in our project, but that we want to be able to edit independently of one another (com and display). After we saved them both the first time we had to point them back to their external files so they open correctly. We saved them a second time to make sure that relative path parameter was saved with our toxes. Finally, we saved the whole project again to make sure that our toxes with external paths were correctly set up in the toe file.

Whew… okay, why?!

Well, at this point, unless we add another component in our base_project layer, we never save our toe file again – we only save the toxes. This also means that the work can be split up… one developer can work in base_com, and another in container_display and they won’t over-write one another’s work. Keep in mind, if we add another component in base_project we’ll need to save the toe file; we’ll also need to change the toe file if we make changes to the project (like the perform window, project settings, and the like).

Let’s go back to our git window to see how we commit all of this to git.

Back in our terminal we can add all of our new elements at once with:

git add -A


This adds all of our files as tracked elements that we’ll now keep an eye one. Next we need to commit these changes. Let’s also add a message so we know what we did:

git commit -m "Our initial commit with toe file and two components"


At this point our changes are committed, and we’re ready to push them back up to our github repo. We can do this with a push command:

git push



Now we can head back over to github to see our project:


Better yet, if we click on the commits link we’ll see our entry history of contributions:


At this point it’s time to start working. Now as you work you can create snap shots to return to. That process usually looks first adding your files with git add, then commiting your files with a log message using git commit, finally you push your changes with git push. You can retrieve the work that other team members have done with git pull.

You’ll also notice that with a history of our changes it means we can move back to any of those snapshot moments in our project. If you’ve ever had a time when you made a change that broke everything… and couldn’t figure out how to undo that change, version control is for you. This lets you move back in time to find a working version of the single module that you changed rather than breaking out in a cold sweat of pure panic.

You can also externalize scripts, glsl, channel data, geometry data, and and and. Generally speaking, you don’t put assets in your repo. Git LFS (Large File Storage) helps with some of that, but for the most part you don’t want to fill up a repo with video. We sometimes will put in a single calibration frame, but it’s important to be very careful when adding large files to your repo as that can make for big headaches.

At Obscura we built out a save process that automates a lot of the above. We also make our repos mirror our touch structure. This means that if we know where an element is in touch, we know where it is in our repo.

Like all things, there is a TON more to learn on this front, but hopefully this gives you some ideas about where to get started with a version control system and working across machines and with other developers.

Happy programming everyone!

TouchDesigner | Email | Project Perspective

I do my best to talk with lots of folks using Touch, and sometimes I get questions about my approach and perspective on projects from students approaching their thesis project.  The exchange below comes from an email series between me and @desn.joshmichael.


What ways do you find interacting with audio interesting?

Audio isn’t really my wheelhouse, so this one is a little hard for me. What I can say is that I always love working with folks who love sound, and are compelled by its nature. I like working with audio engineers and artists because they see the world differently than I do, which always makes for interesting conversations and typically pushes boundaries. One of my favorite collaborations looked at how we could use video to mix sound through an array of 40+ overhead channels. Video was our gain control, so the shape of the video drove the mix of the audio. Neither the sound artist or myself could have gotten there without the other.

All that aside, I think the bigger question here is what makes interacting with audio interesting to you? At the end of the day that’s what really matters, not what I say or anyone else. What drives you to work with audio, and what do you find most compelling about it?

What role do you think audio plays in an immersive experience?

It can play lots of roles – it can be place making, or provide subtext, or context, or motivation. It can drive action, compel participants or audience members to linger and reflect, or motivate action and decision. Like any medium it can be used to great effect for many purposes. Again, it comes back to questions about what you want it to do. If it can be anything, what do you want to shape it into?

It’s easy to think of an artistic form as having a particular fixed role – it’s much more challenging to consider that the form is role-less; that its purpose is shaped by the designer / artist / engineer – conjured and manipulated in ways both unexpected and familiar. A question actors always confront is to consider the opposite intention of their character. The words in a script seem to indicate that Mary loves Paul… but what if she hates him? What if she despises Paul, but still says loving words to him? What does that do to Paul? What does the audience see and feel? Do they even have to know that Mary hates him, or is it enough that the actor knows?

Ask yourself what role you think audio should play – then ask yourself what would happen if you tried to make it do the opposite thing.

For the general public, what type of audio-visual experiences have you seen success with?

I’ve seen all manner of things succeed that should have failed, and things that should have failed succeed. Worrying about what will or won’t work is to evaluate the art while making it – don’t do that. Make work that’s compelling and interesting to you. After the dust settles you can take time to evaluate what could have been differently, what was missing, what you needed more or less of. I’ve seen so many artists fall into the trap of being critic and designer at the same time – consider what’s compelling to you, reduce it to its most essential ideas and work from there.

What types of practical applications do you think an immersive audio-visual experience could have?

Questions about practicality are always frustrating to me – they aim to reduce an expressive medium into something that can be a commodity, something to be marketed and sold. There are lots of ways to chase this question, but I almost always end up feeling miserable thinking about them. A brilliant actor I once knew used to say that an actor’s goal should be to do nothing more than to change the way people in the audience breathed. If you can make someone hold their breath in anticipation, or sigh in relief, or snort uncontrollably – you’ve done your job as an actor. As a video artist I try to think the same way. If I can make something that inspires someone to stop and linger – to pull out their phone and Instagram something, that’s success.

That might not seem practical, but for a marketing campaign maybe it is – we live in a strange time, a time when it’s often enough if you’re able to just disrupt the regularity of peoples lives, to interrupt and disrupt the regularly scheduled monotony and inspire a moment of reflection and observation.

How do you feel about audio-visual generation as the sole experience? Should there be more to it?

Do you think all immersive experiences need a message or greater purpose to be interesting? Why / Why not?

One of the most important lessons I learned in my grad program was to question if an installation / experience needed to be diegetic (explained) or not. Some experiences (educational, informational, etc) lend themselves to diegesis, others don’t. For the most part, I prefer art that isn’t. I like to trust that the viewer / audience is the epicenter of meaning making, and to trust that a human will strive to construct a narrative and meaning even if I don’t supply one.

Humans are largely biological pattern recognition machines – we strive to make programs to recognize patterns, and we thrive in situations where pattern recognition is important; we even often find patterns in data that doesn’t lend itself to actual patterns (see confirmation bias and any number of fallacies formal and informal). An observer will make meaning in the meaningless. That may be discouraging, but it’s also tremendously freeing. Make the art that’s interesting to you, and know that your audience will weave their own story around what they’re seeing… regardless of whether or not you help them get there.

Any other advice for a beginner in designing an entire experience for the first time?

Learn and use a version tracking system.

I remember my grandmother telling me that my eyes were bigger than my stomach when I was a young. That’s a colloquial way of saying that you’ve bitten off more than you can chew – that you’ve taken more food than you can eat… though I don’t know that I really understood that until I was older. One of the hard lessons I’ve learned is that it’s easy to love all of your ideas, to say “yes and” to all of the permutations of an idea. When you’re brainstorming and dreaming that’s very important – but it’s also tremendously important to revisit those ideas and reduce them to their most basic ingredients. Time and again I see artists fall into the trap of making something that tries to do everything – and they end up with something that’s generally mediocre and flat.

If you can, resist that urge.

Chase an idea to its most basic representation; cut away all the fluff and bullshit and find the thing that’s really interesting and focus on that. Cultivate your laser focus and aim to execute a small idea with precision and excellence… then encourage that idea to grow. Iterate before you abandon an idea, and iterate even when you don’t like some of the things you’re doing. Find the patience to keep exploring an idea even when you feel like it’s exhausted and boring – push though that stuck feeling, and stay attentive.

Learn and use a version tracking system.

With enough time you can make anything with anything – that’s great, but don’t fall into the trap of believing that you have to reinvent the wheel.

Be attentive to details. I can’t tell you how many times I’ve gotten lost in code trying to solve a problem that was really a bad cable, or trash connector. Cultivate a debugging and troubleshooting routine that will help you identify where a problem lies.

Think through your decisions before you commit to them – make good system diagrams, map out your work flow, make a careful and measured plan before you start coding yourself into a corner.

Unit test. Explore an idea or code based solution in isolation before you wrap it into your project – there’s no worse feeling than having to work around your own kludges.

Learn and use a version tracking system.

Play the long game – when I started my grad program I knew that everything I blogged about was eventually going to be a part of a larger portfolio piece. So before I even knew what my thesis was going to be, I knew that I had to keep writing to feed the larger project. Find ways to integrate elements of other assignments / shows / installations / explorations into your thesis. If you can, find a way to tie everything back to your larger thesis project – think about all the component pieces you’ll need for your thesis and figure out how to work on those pieces in other assignments or classes. I can’t tell you how many people I’ve seen spread themselves across all manner of disparate projects only to realize too late that none of what they’ve done is applicable to the work they really want to do.

Comment your code. You’ll thank yourself a thousand times over for keeping notes, even if they’re bad ones. Any breadcrumb is better than nothing when you’re trying to figure out what your 3 AM over caffeinated and tipsy self was trying to make work.

Don’t play it safe. If you have to choose between a bold and dangerous move and tepid one, choose the dangerous option. Experiences that result in strong feelings from participants – even if they’re negative feelings – are more useful as a critique than tepid ones. Strong responses are easier to read, interpret, and course correct from than bland reactions.

Finally – remember that failure is an option when you’re in school. When a client has payed you a ton of money for a project you’ve got lots of pressure to successfully execute an idea, which means that you’ll likely have to compromise on some artistic element. As a student it’s okay if something goes completely wrong, or is awful in every way. Your journey and process is as valuable and important as what you make – that’s hard to find out in art for trade world; so be bold and own your failures – they’re as valuable as your successes and will probably teach you much more in the long run.

No, but really – Learn and use a version tracking system.