Professional TouchDesigner Workflow & Architecture

Why is TouchDesigner workflow important?

I’ve written previously about the different ways of developing large-scale TouchDesigner projects and different architectural choices you can make on large-scale TouchDesigner projects. Both of those were aimed at improving the general development workflow for TouchDesigner users while giving intermediate users some tricks for managing larger projects. Without some self-reflection on your workflow and some time spent improving your processes, projects can quickly spiral out of control and become a nightmare to work on with others.

After writing those I’ve come to formalize the three core concepts that drive professional project architecture. These core concepts can be used on all sized projects no matter what type of installation it is. Let’s dive in.

Standardize

Standardization is the first step to controlling the chaos of TouchDesigner projects. It covers many aspects of a project, from simple to complex forms of standardization. I can tell you from personal experiences over many years of development that standardization makes even the most complex projects a breeze to deal with. Never again will you forget where things are or forget the name of some obscure operator. Never again will you have to explain some weird wiring structure or network arrangement to someone else, because they will just get it. So what are some things you can do to begin standardizing your projects?

• Name important operators (such as inputs, outputs, scripts) the same name if they appear in multiple networks. Example OUT for all your outputs, START for all your start scripts, etc.
• Use a common structure for organizing your project features. For example, put all communication related features in a component call COMM and all generative content features in a component called GEN

A big element of standardization is to try to introduce reflection into your process, so that every time you finish a project where you’ve tried to use these core concepts, you can look back at the whole thing and figure out what worked well and what didn’t. You can carry forward the pieces that worked into your next project and try to fix the things that didn’t by trying something else. If you rinse and repeat this process, you’ll naturally be introducing standardization into your architecture.

Compartmentalize

We’ve talked about this one before but it’s what separates the strong from the weak! Compartmentalizing is based around the idea that you’re constantly aware of what you’re working on, and as you find yourself building new features, you make a new COMP and isolate the feature you’re working on inside of an appropriately named COMP. Simple to say, hard to follow through with. If you’ve done the standardization tips and started to name and create structures that you use repeatedly, there is a simple example below:

If you have a component named COMM that holds all your communication-based features, and one of those features is fetching some data from a web API, I would create a new component inside of COMM named WEB, and then based on the complexity of the API call and the parsing I might make separate components inside of WEB named after the feature such as FETCH and PARSE.

This form of compartmentalization has a number of benefits including making it easier to navigate the network, making it easier to optimize isolated features, reducing the number of network breakages due to crazy references, and more. It’s a god-send part of the process.

Decouple

The killer feature of the core concepts is decoupling. What do we mean by decoupling? If you’ve done serious software development before, you may have heard different kinds of frameworks such as MVC (model-view-control) which are different ways of approaching software development. I keep my system a bit simpler: separate controls from interface. I’m militant about it.

What I usually do is make a kind of “settings operator” inside each of my compartmentalized networks, which is usually a Base COMP with custom parameters. I’ll add customer parameters for each other parameters that need controlling inside of the network. After I make that, no other operator from anywhere outside of that specific network is allowed to interact with any of the operators inside that network EXCEPT that one “settings operator” that I’ve made. As different operators interact with the settings operator, a Parameter CHOP or Parameter Execute DAT are controlling the internal parts of the network.

This essentially decouples the internals of the network from any of the controls that need to be exposed and fiddled with. This basically eliminates any and all breakages and errors that would occur from needing to update features or controls. Often what happens is we update one of the two and the other ends up breaking.

Wrap up

If you can be diligent and start introducing some self-reflection as you work and you combine the core concepts of standardization, compartmentalization, and decoupling, you’ll quickly find that developing projects becomes a breeze. You won’t believe how easy and mentally-non-exhaustive it is to work on projects with proper architecture. I was lucky in my career that after my first project, someone showed me the way to architect projects and from then on, the process has only been getting better.

If you want to dive deeper on the concepts of TouchDesigner project architecture, you should become a member of our TouchDesigner training program, The HQ PRO.