Load Executes from External File

So I know that the Execute family of DATs has an input, and that one option is to use an external text DAT that feeds into an execute DAT.

BUT - wouldn’t it just be so nice if any of the execute family could be external files?

BONUS Request:
The ability to set the pars for those DATs with a pulse parameter. That way my external file could correctly configure the execute DAT, and contain the script that it’s going to run.

It’s nice to have dreams. :slight_smile:

i like where your head’s at, it really calls into question the whole nature of hierarchy, who’s in control of who. The DAT loads the file, but then the file controls the DAT. :mindblown:

This would be really helpful for externalising all scripts when several people work on the same toe/tox files via git or similar.

+1

Would you be able to get at this using a File In DAT inside an COMP set to Load External Tox ?

@rob Can you elaborate the workflow that you are proposing?

Tox Files are binary and thus changes in the content can not be diffed using Git. We try to save as much code in plain text files, so we can have proper diffing. At the moment the Execute family of DAT operators content can not be saved/loaded from a file.

At the moment there are two workarounds that we use:

  1. an additional Text DAT for the code and use it as input for the Execute DATs;
  2. use extensions and python classes to contain most code (in a Text DAT) and within Execute DATs only call methods from the classes

Oh I see, you’re using the File capabilities of the Text DAT.
It’s a hidden feature that’s mostly migrated to File In and File Out DATs.

The reason I suggested the external tox is that it would reload any child parameters as well.

If the contents + parameters of a DAT were saved to disk in a single file, it would have to be a new format that’s git friendly as well I suppose.

The parameters part is what I’m not fully sure on. It begs the question if each operator should have a pulsable button to reload parameter sets from disk.

Hey Rob,

Sorry - it’s been a minute since I posted this RFE.

Where I’m going with that pulse request is in alignment with the script DAT’s Set-up pars pulse button. I often use that as a mechanism for setting pars that need to be turned off / on, etc. Having something like that on an execute would mean that I should be able to point to target ops, pars, or which methods should run. Like manuel_mitasch points out this is really about finding diffable mechanisms for configuring how operators are set-up / execute.

Does that help?