Large COMP network FPS drop on new MacBook Pro

Hi there, I’m developing visuals for large a live-set (using tdAbleton) where each “Ableton scene” has a corresponding COMP (which in return, will have its own sub-network/combination of COMPS, TOPS, and CHOPS inside). I’m using a “select TOP” to navigate between the scenes/COMPS.

However, as I’m developing the set and introducing more scenes/COMPS, I’m running into CPU bottleneck issues and my FPS drops to 30-40 and becomes flakey - even though I’m using a brand new MacBook Pro (15 Inch, 2017, 2.9 GHz Core i7, 16 GB RAM / Radeon Pro 560 4096 MB + intel HD Graphics 630 1536 MB, which I thought should be pretty solid).

I was on the impression that when using Select TOP, only the selected COMP will be “enabled” and cook. However, when middle clicking on the “non”-selected COMPS it seems like their children are cooking, (which my guess is that has to do with the viewer active Tops on the inside or any other CPU involving activity?).

So after quite a bit of research, I came across the "“opset -c on (or off)” method, which kind of helps. Except that upon switching the COMPs on/off (i.e. triggering a new COMP/scene) there’s a very notable hiccup (FPS drops to 20-30 and ramps back up) which I guess has to do with all the sub-networks of the turned on COMP waking up and getting loaded into memory? I have also read that this method is a “dirty” way of doing it (which clearly is, with that giant lag every time a new COMP cooking is turned on even in Performance mode).

I suspect working with a large “live-set” and being able to trigger new networks and navigate between them is something that a lot of people deal with and think there should be a proper way of doing this (I got the new laptop specifically in order to be able to develop this live set). But I’m quite new to TouchDesigner and don’t seem to be able to figure out the solution.

Thank you so much for your help.

hi mhzareei,

Optimization is often a very tricky piece of the puzzle. Ideally you don’t want to enable / disable operators during a set as that will almost always cause frame drops. You’re on the right track using selects, but I’d bet that you probably have a CHOP network that’s propagating updates throughout your network unintentionally.

Do you have a small example of the problem that you can share? It’s often easier to help folks with optimization questions by referring to actual code examples. If you can isolate the issue to one or two smaller networks we can help point you in some optimization directions.

Thanks so much for your quick reply (is this THE Matthew Ragan btw? You’re an absolute legend! Have learnt so much from you in such a short period, as you’ll probably see in my attachments).

So I’ve been trying to isolate different areas, and as you’ll see in the attached examples, any of the individual networks of COMPs (which belong to a track within the live-set) work absolutely fine in isolation, not moving anywhere from 60FPS. But once you add them all together, that’s when trouble starts (you’ll get a bunch of errors due to not having my Ableton Live set of course).

Ok I had just somehow - naively - assumed that if a COMP is not selected, it’s essentially detached from CPU/memory/GPU. But you’re right, I have quite a few LFOs and Ramp TOPs across all subnetworks. You think that could be causing the problem? If yes, is there a way to “turn a CHOP off” when you’re done with it?

I’ve attached isolated "track"s, as well as the whole thing which currently only has 3 tracks of the 8 tracks in the live-set (my network is relatively well organised, so should be easy-ish to follow? Please let me know if you need any further info/explanation).

Thanks so much for your time! and for all your tutorials!
Mo
function_visuals.network1.toe (139 KB)
function_visuals.network3.toe (283 KB)
function_visuals.network2.toe (133 KB)
function_visuals.all3networks.toe (417 KB)

Hey, it is Matt - nice to meet you virtually. :smiley:

First off, I think your scope error is related to the fact that the topto1 is set to dowload type Next Frame. The constant TOP may have cooked, but the next frame download means the CHOP is one frame behind in time… in other words, it hasn’t caught up / cooked yet. If you change the download type to immediate (which is just fine for performance, especially if you change the size of the input TOP to a resolution of 1 x 1) you’ll see that the error doesn’t present anymore.

I haven’t used the TD Ableton component yet so I’m shooting from the hip here a little, but it does look like you’ve got a healthy set of ops that are all cooking a bit. The performance monitor is probably worth pulling up and going though op by op to track down what’s eating your cycles.

Worth trying right away is moving away from a switch TOP to a select TOP before your output - then using a python one-liner to change the path to what TOP is being used as your output. If I delete the switch TOP and replace it with a select the CPU cooktime drops in half. That seems like the easiest first thing to check, and might be enough right away - rather than revisiting the entire approach.

Hope that helps!

Hey, it is Matt - nice to meet you virtually. :smiley:

First off, I think your scope error is related to the fact that the topto1 is set to dowload type Next Frame. The constant TOP may have cooked, but the next frame download means the CHOP is one frame behind in time… in other words, it hasn’t caught up / cooked yet. If you change the download type to immediate (which is just fine for performance, especially if you change the size of the input TOP to a resolution of 1 x 1) you’ll see that the error doesn’t present anymore.

I haven’t used the TD Ableton component yet so I’m shooting from the hip here a little, but it does look like you’ve got a healthy set of ops that are all cooking a bit. The performance monitor is probably worth pulling up and going though op by op to track down what’s eating your cycles.

Worth trying right away is moving away from a switch TOP to a select TOP before your output - then using a python one-liner to change the path to what TOP is being used as your output. If I delete the switch TOP and replace it with a select the CPU cooktime drops in half. That seems like the easiest first thing to check, and might be enough right away - rather than revisiting the entire approach.

Hope that helps!

Thanks a lot Matt! And very nice to meet you too. I really appreciate your time and all the super helpful info. I’ll try these as the first next step. This is a big help.

Just as a general question, is disabling the viewer on TOPs (or OPs) that are housed inside COMPs a thing that one should consider? Or Performance Mode automatically takes care of that stuff and there’s nothing much to be gained?

The TD component thing is really amazing, if you use Ableton of course. It reports every single piece of information in your live-set (from Track volumes, to value of effect parameters, to clip names,) using OSC and that way you can isolate different "track"s in your live set to do real-time audiovisual stuff. But I guess I have to find a way to optimise their functionality, especially when they are not being used to generate output.

Yes and no. If you don’t start directly in perform mode then it’s worth considering if you’re really after saving memory - generally, I don’t worry about this too much unless the networks I’m working on are really huge.

The real trick is to start in perform mode - if you do that then none of the elements used for the UI / network view are cached or created. Back when VRAM was more precious, this alone could have a HUGE impact on how much memory you had available. It’s still good practice, and helps you think about how to work with UI pieces you’ve made or purposeful made available rather than relying on live patching - which we’ve all had go terribly wrong at one time or another during a live show.

Optimization is a tricky thing, and it’s worth thinking about how you might make pieces that are more reusable, or how you might make a more general component that can be adapted to fit more of your tracks. For me, that usually happens after I’ve made a few and really start to understand what I’m working towards. Don’t be afraid to refactor your project, but also don’t rush to wipe the slate clean and start over, the answer is probably in the middle somewhere.

I did a blog about this kind of thing a bit ago, and I don’t know if it’s useful for your current project, but it’s some of the ideas I try to keep in my mind while I’m working. Things like reusing components, making a preset system, having global assets, logging, unit testing - and the list goes on.

matthewragan.com/2017/08/07/pre … inger-099/

There are lots of great resources here and on the slack channel, so don’t be afraid to ask - we’ve all wrestled with questions and frustrations around optimization and cooking before.

Keep up the good work, and make sure to share what you end up making!

Thank you Matt. This is incredibly helpful. So many useful tips and such a clear breakdown of concepts.

These visuals I’m working on are for the premiere of my upcoming album which I’ll be performing at a festival in 1.5 months. While it’s usually not a great idea to jump on an entirely new platform a few months before a deadline/performance, the moment I realised TouchDesigner started a macOS version I knew immediately that that’s the way to go, and started with the wiki/forums and of course your tutorials. So still a noob in many ways (especially when it comes to tricky stuff like optimisation), but need to get the work done for the show. That’s why I really appreciate and value the useful tips and info that you shared with me.

Of course more than happy to share the work when it’s finished.
Thanks again!
Mo