Category Archives: Uncategorized

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:

git_repo_setup

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:

repo_location

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.

git_bash

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:

git_source.PNG

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 https://github.com/raganmd/touch_git_example.git

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

git_clone

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

git_clone_complete.PNG

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/

change_dir.PNG

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:

new_dir

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:

project_save.PNG

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:

project_base.PNG

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:

save_comp

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

comps_in_dir.PNG

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:

toxes_from_dir.PNG

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

git_add_A.PNG

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"

git_commit.PNG

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

git_push.PNG

NICE WORK!

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

github_first_push.PNG

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

commit_logt

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.

scriptDAT | Tips and Tricks | TouchDesigner

If you spend lots of time setting up parameters in your UI elements and want a faster way to use a set of presets to populate some parameters, then the Script DAT might be just what you’re looking for.

Let’s look at a fast simple example that might have you re-thinking how to quickly set up pars in a project. Keep in mind that this won’t work in every situation, but it might work for an awful lot of them and in ways that you might not have expected.

To get started let us imagine that we have a simple set-up where we have a UI element and a display element. We want a fast way to quickly update their parameters. For the sake of this example let’s imagine that we do not need any fancy scaling or changes on the fly. This is going to be used on a set of displays where we know exactly how they’re going to display. We might think about using storage to set and pull parameters, but you might be hesitant to use too much python for those bits and bobs. Okay, so exports it is… they’re a little more cumbersome to set up, but they are much faster – fine.

Sigh.

I guess we need to start setting up an export table, or a constant CHOP and dragging and dropping all over creation. Before you do that though, take a closer look that is the majesty of the Script DAT:

The Script DAT runs a script each time the DAT cooks and can build/modify the output table based in the optional input tables. The Script DAT is created with a docked (attached) DAT that contains three Python methods: cook, onPulse, and setupParameters. The cook method is run each time the Script DAT cooks. The setupParameters method is run whenever the Setup Parameter button on the Script page is pressed. The onPulse method is run whenever a custom pulse parameter is pushed.

Maybe we can use the Script DAT to make an export table for us with just a little bit of python.

We can start by putting a few things into storage. Let’s create a new dictionary but follow some simple rules:

  • The keys in this dictionary are going to be operator names or paths
  • Each operator is itself a key for another dictionary
  • The keys of that dictionary must be proper parameter names
  • The values associated with these keys need to be legal entries for parameters

Okay, with these rules in mind let’s see what we can do. Open up a new project, in project1 let’s create two new containers:

  • container_ui
  • continer_led_display

Add a new text DAT and create a simple dictionary to put into storage, and let’s follow the rules we described above:

Alright, so far so good. Now let’s add a Script DAT.

We’re going to use our Script DAT to look at our stored vals and create an export table on the fly for whatever is in the storage dictionary “attr” – easy.

Let’s edit our Script DAT to have the following contents:

Finally, let’s turn on the green export flag at the bottom of our Script DAT:

script_dat.PNG

And just like that we’ve set-up an auto-export system. Now every time we update our dictionary run our script to put the contents into storage we’ll automatically push those changes to an export table.

Looking for an example to pull apart – head over to github and download a simple example to look over.

Cellular Noise

A post shared by Matthew Ragan (@raganmd) on

 

A post shared by Matthew Ragan (@raganmd) on

 

Practice your vertex shaders

A post shared by Matthew Ragan (@raganmd) on

 

A post shared by Matthew Ragan (@raganmd) on

 

A post shared by Matthew Ragan (@raganmd) on

 

A post shared by Matthew Ragan (@raganmd) on

 

A post shared by Matthew Ragan (@raganmd) on