chop exports corrupt

Hola~

I have a file that I’ve been using the chop export dialog quite a bit to connect chops to channels. At some point, Touch saved a corrupt version of the file. Now, when I open my file, one of the chop/ch connections is broken. It’s just not there according to the interface. The one that is broken is different every time I open the file.

However, if I try to connection a totally unrelated chop/ch, Touch pops a dialog about two chops being exported to the same destination (point back to the chop that was broken).

Any advice on how to recoup my file? I’d love to not redo the work.

MO

If you go to the parameter the channel was previously exporting to, is the parameter still affected? Another thing to do is open the CHOP Exporter at the CHOP in question and double check all the export paths. If nothing can be determined from that, then I would recommend toggling the export flag OFF on that CHOP, then you will be able to connect other CHOPs without getting the “same destination” warning.

Can you email me the .toe file, and I’ll try to figure out where the corruption occurs? I dont think I’ll need any media for this one

Hola~

Try the following:

noise --> sphere radiusx
noise --> sphere radiusy
noise --> sphere radiusz

using the chop exporter dialog.

Select the noise and sphere. Copy. Paste. You should get a dialog about a chop going to two values. The original sphere is affected, which it shouldn’t be.

As far as I can tell, the file is corrupt at this point. I’ll send that file to support.

Save this file, then open it in a fresh Touch, you are asked to resolve the export issue again. If you try to export a different chop to one of the radiusx/y/z values, they all change.

MO

So after looking at this I don’t see any corruption pre-se, but I do see how the various confusing things about CHOP export conflicts can make it seem so.
So I’ve revamped the CHOP export conflict resolution to make it much more user friendly.

  1. When copying and pasting groups of nodes that have exports between each other (Noise->Sphere in this example). The newly created CHOP will attempt to setup it’s exports to the node that was created with it, instead of continuing to export to the original node (which is what caused the conflict). There are of course cases where this isn’t possible, such automatic export by channel name, or CHOP exporting using wildcards.

  2. When a conflict occurs you will be required to resolve it right then (one of the issues is that it let you press X, which left the file in a conflicted state). The resolution will attempt to remove the export from the source CHOP’s export table, instead of just turning off the export flag for that CHOP. This will avoid the conflict reappearing when you export again from that CHOP (since it was previously left in the CHOP export table).