How Extendscript/CEP actually works on the back end.
Long shot, and obviously don't expect any hyper-specific answers, but I was wondering if anyone might have some insight on how extendscript.dll, scripting.aex, and CEPManager.aex work together?
When doing some debugging, I notice that when extendscript is called, it loads both scripting.aex, and extendscript.dll.
Same with CEPManager.aex.
My assumption is that scripting.aex loads extendscript.dll, and performs script execution.
CEPManager.aex would probably do similar.
This being said, how exactly might all of this work together?
I'm working on a plugin that exposes python as an alternative, and I'm running into some issues when figuring out how to run concurrent scripts.
I've embedded a python module that wraps SDK calls, and have successfully created a python API as a (partial) alternative to extendscript. I can successfuly call into the plugin with a python script, which will then perform automations (making new project, comp, manipulating layers, etc).
However, I can only have one embedded python instance per process.
Since loading a new process gives a different address space, the embedded module is no longer available.
For example, I have the following class set up in c++.
```c++
//Project class definition
class Project {
public:
Project() = default; // Default constructor
explicit Project(const Result<AEGP_ItemH>& itemHandle)
: activeItem(std::make_shared<Item>(itemHandle)) {}
std::shared_ptr<Item> ActiveItem();
std::shared_ptr<Layer> GetActiveLayer();
std::string getName();
std::string getPath();
void saveAs(std::string path);
std::shared_ptr<ProjectCollection> ChildItems();
std::shared_ptr<ProjectCollection> SelectedItems();
private:
std::shared_ptr<Item> activeItem;
Result<AEGP_ProjectH> projH_;
};
```
It calls into the main AE thread through a messagequeue managed through mutexes.
This same class is exposed to python like so;
```
py::class_<Project, std::shared_ptr<Project>>(m, "Project")
.def(py::init<>())
.def_property_readonly("activeItem", &Project::ActiveItem, py::return_value_policy::reference)
.def_property_readonly("activeLayer", &Project::GetActiveLayer, py::return_value_policy::reference)
.def_property_readonly("name", &Project::getName)
.def_property_readonly("path", &Project::getPath)
.def_property_readonly("items", &Project::ChildItems, py::return_value_policy::reference)
.def_property_readonly("selectedItems", &Project::SelectedItems, py::return_value_policy::reference)
.def("saveAs", &Project::saveAs, py::arg("path"));
```
I don't think I can pass things like AEGP_ProjectH across processes without invalidating the original, so that being said, I think my only option would be refactoring the python bindings into a separate, importable library, but the problem here lies in how would I communicate complex classes and such between these processes?
I'm hoping that some insight into how the extendscript communication works might help out, or any other suggestions would be GREATLY appreciated. Thank you!!!
AdChoices