Hola~
I’ve created a constant chop as a control panel for values I’d like to use to tweak a bunch of values throughout my network. For example, on a sphere, I set the expression to:
10.0 * chop("controller/globalscale")
I can set this on about 3 nodes before it wedges Touch. I then need to restart Touch, add the expression to another 3 nodes, (save in between setting), etc…
Anyone else have this problem?
MO
Have not seen this issue before. When it crashes, does it ever produce a .dmp file? If so, could you send these in and the programmers can have a look. Are you using build 3712?
Hola~
I’m using build 3534. It doesn’t core dump, just hang. Touch stops responding to all input, but doesn’t crash or generate a core file.
MO
I had the same problem quite a while ago (~ year), I believe I saw a fix in one of the builds or at least something that appeared to be associated enough that it would fix what I was seeing.
Anyway, just tried it out with 3712 and am not seeing the problem.
3534 was an experimental build, can you upgrade to 3712?
Hola~
Yeah, I’m still seeing some pretty wonky behavior as I much with chops that are plugged into other params using the chop() expression. I can get it to wedge pretty easily, but not reproducibly.
One thing that is causing problems consistently, is if I have a bunch of chop() methods all pointing at a single chop, and then I delete it. Touch just sits there, until I kill it.
MO
Hola~
Renaming the chop gives the same behavor as well.
MO
Hey, nobody else has reported anything else like this. Have you switched to a 64-bit OS, or started using the /3GB switch in Windows XP? I have a feeling all of these issues are caused by you running out of memory (assuming you are using still working on the same files that was close to your max memory limit). If you turn on the /3GB switch or switch to a 64-bit OS, I bet these will go away.
Hola~
Okay. The size of my file is due to the table dat serializing everything into the file. Can that node be made to be a reference to the text data instead of including it in the Touch file?
Here’s a file that’s indicative of the sort of thing I’m trying to do. If I remove or rename the node, the spheres do flag as errors. If I undo, the nodes don’t seem to recover. I haven’t figured out how to get the nodes to come back without restarting Touch.
MO
channel.toe (4.61 KB)
We are updatng our error reporting in TouchDesigner, but at this intermediate stage the error icons often get stuck. To fix this, you can “Force Cook” the node after you;ve fixed the error (or used undo) and this will fix its state. Force Cook is an option the node’s right-click menu.
If the error icon is still displayed after the Force Cook, simply zoom the network in/out a bit to refresh everything.
Hey, maybe we’re not using the same terminology here.
When you say Touch ‘wedges’, do you mean it totally freezes and you can’t interact with the UI at all? You are forced to restart it, right?
This is different than the case you just sent where the nodes go into error and don’t come out of it when the node the chop() expression is looking for comes back into existence, right?
For the issue with nodes going into error and not coming out of it, I’m looking into this right now. Ben’s suggestion to Force Cook the erroring nodes is the workaround in the meantime.
For your hangs, the problem isn’t the size of the .toe file, its the amount of memory that it takes up in RAM when it’s running. Even if we added the ability for DATs to store their contents externally, that would only reduce the size of the .toe file. The DATs data would still need to be loaded into RAM when the app starts up, so the RAM usage will be the same. This is what a 64-bit OS, or using the /3GB switch on XP 32-bit will help with. This is true even if you don’t physically add more RAM to the system.
Saving the DATs data out to a separate file would help with the corrupt file saving issue you were having (which I think is also caused by running low on RAM), but won’t stop other issues that running low on RAM can cause, like the app completely freezing.
I’ll try to get an error to come up when you run out of RAM, so at least this error is easier to detect in future.
The bug where nodes go into error but don’t come out of it is now fixed.