TouchDesigner Talk 2 - Reflection Piece / by Stephen Bontly

Happy 2017!

Today I watched a talk on methods and practices using TouchDesigner. Thanks to Ian Shelansky and Matthew Ragan for taking the time to share their practices with us. Open source communities are a beautiful thing. You can find the talk here if you are interested in getting into it. TouchDesigner talk

Keep in mind, Im not a computer programmer. Id like to think that I can be one, but time doesnt permit. What I do understand is the theory of object oriented programming. Which will get me far enough.

When I work on projects, currently they tend to be on the fly, 1 or 2 weeks prep time. Building my networks as fast as my brain can handle it, and perform. The hours begin to melt away. As I learn I build more tools of course, making my specific job easier. However as I grow, so do my projects. Complexity overwhelms my thoughts. I've finally learned to let somethings go, just to make room for the agenda. Its things like these that make rapid installations largely improvisation pieces. Quickly adapting to the environment. 

TD works best in a closed loop. Nothing in or out that it doesn't already understand. I am the master of fucking that up. How can I avoid it? 10 years later, maybe. Currently I use TD professionally, I enjoy the change while im working, and learning. How to manipulate and adapt. So my goal is to master its properties. Maybe im using TD in the wrong way? Im not so sure. But there are a few things outside of the obvious that I have learned, by keeping an ear out, from the professionals of this industry. Here are a few from this past talk.

Ian stated the session with a demonstration of how to apply physical data to a geometry using GLSL and ray marching. Something I wish I knew more about, and there will be another time. What Im beginning to see is that you must use the TD environment as a pair with GLSL for you to get the biggest benefits. Another thing I have been noticing is how pixel data can be used for position and texture mapping. A concept I feel will be very useful when working with projection mapping projects. The power of data translation can be the 'make' or 'break' of a good idea.

There have been a few patch releases for Matt's A/B switching render system, but I appreciated the breakdown. Very helpful hint about the renderpass TOP within the next output opposed to another network. Matt continued on to explain how using a base operator as the core for effects, creating a bin to load from. Then once all the back end work is cleaned up, you can reference the effects with the cloning parameter using python. This might be a rough idea of the final beauty, however the concept can go far.  Additionally, you can use the internal parameters on the base itself as a universally interchangeable controller. By setting these with a standardized dictionary keys, you can change out variables rapidly, even create a recall for the default setting when the effects change. I have created a system like this before, but with a different and less efficient workaround than Matthew. This is some great stuff! My only concern is about the transitions between the effects. I'm sure there is a solution; could be a good component to develop? 

The overall ideology of re-usability and generalization with each component/module to make it interchange seamlessly is where the magic happens. This is where I could optimize my own media server I use during performances. As I mentioned before, The best products run in a closed loop. I will definitely apply these ideas before next season. ( maybe not a closed loop though ;) ) Of course these practices are just as important as naming your operators and a proper network structure. 

Another idea that was brought to my attention during this talk was about preloading, and loading while performing. The larger the network and more intertwined in itself it becomes, the harder it is to bring new information into the mix. In the past I have notoriously moved between applications, dragging and dropping components and media into TD and other software. However, the smarter move is to make sure you keep your loop as closed as possible, using other methods to control your resources. A longer startup and a bit better management can prove to be a more resilient approach than constantly adding and subtracting information. My new years resolution, to internalize my projects. Less improvisation, and more consistency.

There were a few topics that definitely had practical applications, however on a much larger scale than I currently operate under. Ian talked about using an API to connect a local browser to TD, ultimately creating a controller that can be accessed through the TCP/IP network. Matt touched on the benefits of using strategies on the startup in larger systems, once again making use of the TCP/IP network.

Since the educational community for TD is quite small it is not so often we get development secrets. Thanks again. I look forward to the next talk. My questions lead towards latency control and maintenance. I have requested the next talk to dive into these problems that begin to rise on larger systems.

Thoughts: A patch was just released by Gregg for a scene component with its own timeline based layering system. Another sweet tool! By pairing this with Matthew's A/B switching system, as well as adding the internal parameter effects system, you could begin to have VJ nice VJ setup.

Stay tuned World.