Where’s this knowledge from?
As many of you may know, I’ve recently launched a new TouchDesigner educational and coaching resource, the Elburz.io Learn TouchDesigner HQ. I’ve already worked with a bunch of my subscribers to get through some of their TouchDesigner challenges, and a few of them I thought would be useful to share with the community at large. Some are useful tricks, and some are philosophies to approach TouchDesigner with. Without much more, let’s dive in!
Select DAT tricks
Select DATs can be a bit tricky to navigate even for advanced users. One of my subscribers asked:
Is it possible to get really specific on using the select dat?
For an example:
If I want to select rows 1, 8, 13, and 50 – 63, is there a way to type in those numbers for a precise method of selecting? there was an example on the wiki, but I can never get their example text, to replicate the results and it said it could do. Thanks
And my answer was “of course we can!” So I dive in with a quick example that is often overlooked. You could do this in many different ways, but one quick and easy way is to prepend a column of ID numbers to your table data. That way you can use the Select Rows by Value option in the Select DAT, then use all the nice pattern matching / pattern expansion methods to pick out any of rows you want all at once. You can download the example file below and play around with it! The trick here is that by adding a column of ID numbers that match our row numbers, we are able to search by “value” and our value just so happens to match our row. Easy peasy!
Project Startup + Lots of data DATs
Another subscriber had this question:
I use a ton of DAT content formatting in my project, lots of evals etc. As long as the formatting is not cooking during high process time, Im good to go right? If so what would my onStart component chain forcecook protocol look like so I can prevent any hangs or framedrops once it boots. is there a best practices around that?
My answer comes from a bunch of different angles. Firstly, DATs are a great way to hold a lot of data, whether it’s social media data, presets, keyframes, etc. When they start to cook though, they get slow. It’s very common to load a ton of data in via DATs, then either convert them to CHOP data or reference them via Python once it’s loaded. If you’re not sure about whether something is cooking or not, a good way to check cooking chains are to use the Probe tool from the palette. I go over it’s usage in my Optimization workshop, because it’s the best way to see how networks are cooking in a visual way, otherwise you can just watch wires and see if they’re animating or not.
In terms of onStart and initalization using Execute DATs, I usually follow an if-I-need-to philosophy, where I try not to over initialize. I test this by starting with a blank onStart in my Execute DAT. I save the project, open it, and look at the final output or run the network once from a UI, and I wait to see if frames drop for some reason or if things are in a bad state or if something is broken. Then I determine what is causing that issue, how it might have gotten to this state, and decide how to block against getting into that state from startup. Usually if you’re constantly opening and closing the project, you’ll notice little startup bugs like maybe transitions are broken if you accidentally save the project during a transition, so then I’d add a few lines of Python to make sure that when I start the project, I reset all the transition states. Rinse and repeat until the startup of the project is rock solid.
- Find the operator at the beginning of the chain (generally your data operator DAT) and use the op(‘name_of_op’).cook(force=True) script, which will cook that operator and usually do the heavy loading right at the project start, but it won’t prevent frame drops from maybe some further processing operators, for example if all your data passes through an Evaluate DAT doing some Python work on your data
- If you use a lot of Switch OPs (like I do) or you encounter the issue above, the safer option can often be to run something like this op(‘comp_name’).cook(force=True, recurse=True) on the whole COMP that is holding your DAT operators inside of them, because in this case the recurse argument makes all the children of that operator also cook, and with the force flag, you’re basically force cooking everything inside the COMP.
Error catching vs input processing
Another subscriber had a question about how to manage DATs, in this case Select DATs, that may select a row from a Table DAT that doesn’t exist. This then causes all the further operators in the chain to start throwing errors and freaking out. Their approach was to figure out a way to replace the non-existant rows with a row full of 0s if this case ever arose, and whether this was advisable and how to approach it.
Get Our 7 Core TouchDesigner Templates, FREE
We’re making our 7 core project file templates available – for free.
These templates shed light into the most useful and sometimes obtuse features of TouchDesigner.
They’re designed to be immediately applicable for the complete TouchDesigner beginner, while also providing inspiration for the advanced user.
I came at it from a different angle, that is a bit more philosophical. We all know it’s easy to get too complicated in TouchDesigner. This is a tricky one philosophically because error handling feels good. The way I would approach this is to insert a little bit of scripting logic right before your first Select DAT that might even find a non-existent row. I imagine there are incoming value referenced directly in the rowselect parameter of the Select DAT, and sometimes these overshoot, which leads to the issue. So instead of doing that, I would put a CHOP Exec DAT onto the value that is driving the Select DAT, set the CHOP Exec DAT to value change, and when the value changes you can first do a check to see if the row with that value even exists, if it does, write that new value to the rowselect parameter of the Select DAT, if it doesn’t, you can do whatever you need to block any errors from even happening further down the chain. Whether that means feeding in fake data, 0s, or whatever.
It is really just a different way to think about the problem. Usually input processing/logic is a lot simpler and more reliable than error catching/handling and that’s the mindset I try to take with work in TouchDesigner.
I think these tricks and concepts I outlined here are useful to developers of all skill levels. TouchDesigner can sometimes to be tough to learn without getting a solid conceptual foundation with which to approach working on projects. I hope these will be helpful in your projects and work, and if you want to join our new awesome community where I work daily with my subscribers to solve problems like these and more, you can get more information by clicking here!