RFE: Comp Class - loadByteArray() - Add additional named arguments to specify name and overwrite existing components

Recently Comp class gained the following feature in Build 2020.42700:

COMP Class - New methods saveByteArray() and loadByteArray() for saving and loading .tox files directly to and from memory.

Is is possible to add two additional named arguments to the loadByteArray() function to achieve something like the following:
name=str : Manually specify the name of the newly created component, instead of using the name that would otherwise be loaded from the tox file.
overwrite=bool : Using the tox name (OR the string specified in name if that named argument is used), if a component already exists in the target component with the same name, delete the existing base and create the new base in the same network location.

Both of these would be greatly helpful for systems with smaller sets of toxes that are repetitively unloaded and reloaded.

What are you looking to avoid by deleting the one you want to replace first, or renaming the newly generated one afterwards instead?

@malcolm Right now since the name of a tox doesn’t necessarily correlate to the name of the base loaded when the tox is dropped into TouchDesigner, there is no way to guarantee that you can safely delete the base and then have the exact same one replaced, if you are not the author of the tox and therefore can not ensure it has the same name.

Adding the new base, then deleting the old base, then renaming the new one could have several implications:

  1. Max cpu/gpu mem usage is ( old base + new base ) instead of ( max(old base, new base) ).
  2. Global Op shortcuts may collide and cause issues between the addition and deletion steps.
  3. Similarly, relative and absolute Select operators may fail between the deletion and renaming steps.
  4. Having the same Extension loaded twice in between the addition and deletion steps may lead to issues if external systems are accessed with said systems
  5. SharedMem / Spout / VideoDeviceIn/Out / Hardware specific operators could collide in between the addition and deletion steps.

Most of these issues would easily be avoided with deletion then addition (for proper destruction then re-initialization for operators and extensions) , but that brings us back to the point that the name of the loaded base may not match, so deleting before loading ‘feels dangerous’ for systems relying heavily on selects, parent, and global shortcuts instead of wires.

Thanks for taking the time to take a look at this RFE! :+1:

There’s nothing different between you deleting a node before loading a .tox, vs. us doing it internally.
For now can you try doing a delete (if name already exists), load, rename? If you run into issues with that workflow let’s look at them. It’s possible the name=str argument is worth adding, but I don’t think the overrwrite is.

1 Like

After thinking about this some more, I think I’m overlapping several separate issues that would not be completely solved by my RFE.

I agree with you, I think overwrite=bool is overkill / not necessary. However, the name=str does seem like a good idea, if it’s not difficult to implement. And I realized for now, I can work with delete/load/renaming, but doing that nested one layer deeper within an empty base. That way there shouldn’t be any conflicting names on the hierarchy level that the component delete/load workflow is happening on.

Ok agreed. I’ve added it to our RFE tracker

1 Like

Thank you, Malcolm! :slight_smile: