after a whole day trying to setup my generative visuals system without presetting anything etc, I feel it very expressive, and nice but like not enough controllable.
Some ways for me, rebuild everything (hard considering time remaining), presetting it (hard as I didn’t start to do it at the beginning), recording output (I want to keep the audioreactivity) AND copy/pasting part of my network.
The latest way is the one I’ll choose considering remaining time I have.
I have a whole part of my network responsible of the big thing (process, feedback, audioreactivity etc)
I’d like to make multiple copy of it and to use a switch to branch them between my source and my video output. Like this, song 1 => I’ll switch this one, song two I’ll switch this other one etc etc.
BUT how can I be sure the copies which don’t have to work at a specific moment are not cooking ?
And second question, as some part of each copy are controlled by a master process (the sound, here), I have some export running which make my part of my unused network still working AND as I have some feedback top, I can also see these part cooking for nothing
Is there a strategy in that case for making my unused parts totally not cooking ?
Or am I going a wrong way ?
One of TouchDesigner’s super powers is how it handles cooking. It can also be somewhat confusing at first.
Basically, a node cooks on any given frame IF something asks it to AND IF any of it’s inputs have changed since last frame.
If you have a bunch of tops that are cooking while in network mode, that shouldn’t be, see if turning off their viewers fixes that. when a node viewer is on, td is asking it to cook so that you can see the node’s latest data.
If you have all the viewers turned off, and they are still cooking, then somewhere down stream something is asking that node to cook. So you’ll have to track that down.
Sometimes it’s as simple as a null TOP in a container somewhere that is visible. Or, maybe that top is used in a material/geometry/render somewhere that cooks every frame.
just travel down stream, disconnecting nodes and things until you see that top stream stop cooking, and eventually you’ll get to the source of the request.
switch on the left is trivial here, just for getting my single source to go to multiple Base TOPs (named SONGn)
I can see the wires from the switch output cooking (as the channels coming from below the snapshot)
:
I will create a small system enabling / disabling the base from cooking.
But, in that case, should I put some other switches for stopping channels going into the Base TOPs ?
If I follow what I read about cooking, if the Base is not cooking, it doesn’t request anything upstream. But I still can see the channels flowing (the source COMP is cooking)
Maybe this is just a very beginner not useful question. This is just for understanding and starting with good habits.
I don’t see the use of the left switch. The purpose of the switch is to select one input among multiple ones to switch it to the output. You could just use a null here as the switch has only one input.
As lucasm said, TD is a pull system : if a node on the right needs to be rendered, TD asks anything in the chain before this node to be processed (cooked). In your example if you display your bg TOP at the right, TD needs the network to cook to present you the result, so it processes the switch1. As a result, if the switch1 input is set to 0, TD will need to process SONG1 COMP and so on. If nothing happens on this chain, TD will not cook it… unless all other SONG COMPs have their display on.
Bare in mind that if the viewer of a node is active, TD needs the network to cook to display the result. So if every node display is on, every node needs to cook.
So in my example above, if every node BEFORE switch1 has their viewer (display) off, only the active input on switch1 and all the required nodes before will cook. In my example, only SONG1 will cook.
I understood well and the switch on the left, as mentioned, was a part still in progress.
I have a COMP (let’s say the 1), exporting permanently values from my sound analysis (which I want) to another COMP (let’s say 2)
The COMP2 is connected to all my BASE for which I build my small system making them cooking or not (works very well)
If a not cooking BASE “receives” channels from COMP2, will it cook ?
Considering all docs & informations, I think it doesn’t (especially because it is cooking disabled. (and nothing pops out too etc)
As TD is a pull system, as you explained well, I guess even if I push data from a COMP, as the BASE is not cooking, nothing will happen.
All of these is just for making sure I’m understanding well.
Not sure if I understand your intentions correctly but @julien please don’t try to optimize your network by disabling / enabling cooking on COMPs (as I see in your screenshot above where several base COMPs have their X pressed to disable cooking) . At first this seems like a good idea for fast results, but it’s not, and it will cause stutters and freezes and cooking ripples throughout your network once you enable cooking again.
Also you don’t need to do this because of the pull-logic in TD, just use a single Switch at the end to stop all cooking in all base COMPs before that Switch.
Also see here for a proper example how to setup a show system which prevents any non-active scenes from cooking.
In my BASEs I use feedbacks. As I see, even if I use a switch before this network for preventing it to pull frames upstream, it seems to cooking from the feedback loop to the output and still outputs something (but this is probably my mistake here) even if I use a switch in the end (I see the wire glowing like when something is happening between nodes.
The system I created (which works, but is my very first network in TD for a project occuring end of week) is based also on a script that, for each scenes, do this:
start cooking the scene
init variables of the scene
fade in the scene
when the previous scene ends (I overlap music+video for this performance), it fades out the previous scene and when fade out is finished, it disables cooking.
etc
I composite all my scene as I need them to be faded in / out and I LOVE the example you saw as it seems the best practices for what I did here.
I hope to get time to make my stuff evolving to this (easy) example.
Now, my system works fine (no hiccups or whatever) I’ll let it as it is until I finish to polish each scene (there is a complex sound analysis + midi cc parsing + inner TD rules I did inside of it)
Thanks again to all of you here.
still need to understand IF cooking really occurs when the feedback is working, even if everything is switched off upstream AND downstream
Responding to the kris-cross reference from the SceneChanger system. Every response in this thread is spot on. TouchDesiger processes recursively up the chain based on what is in demand. You can make things cook just by looking at them. You can also make things cook by making convoluted references across components, and the more references made like this the more cooking problems you will have.
The scenechanger.tox that Idzard pointed to is a good example of how to avoid these problems. If you have to manually force components off when they aren’t being used then something isn’t optimal.
Sometimes there is a bug and a feedback operation might not shutdown correctly when not being used. If you are seeing that and can issolate it please post it and I will take a look.
I just discovered the hard way that my off bases were still cooking because the switches Blend between inputs setting was on.
Once switched off it works fine. Im assuming this is a bug as once the switch is at its extent they should not cook.
I’m now using a blend after the switch as a workaround.
