Creating Layers/ Altering pixels from raw data in an AEGP.

Okay! So, I think I came up with a solution, and Id be keen to hear your thoughts--

End Goal:
From my AEGP plugin, allow the user to script the creation of a "custom" effect. 

How I plan to do it:

On the AEGP & Effect Plugin Sides:

Embed a python intepreter. 

Expose classes like so;

// Slider class equivalent
class Slider {
public:
    Slider(const std::string& name, int minS, int maxS, int increment, int default_val)
        : name(name), minimum(minS), maximum(maxS), increment(increment), default_val(default_val) {}

    std::string name;
    int minimum, maximum, increment, default_val;
};

// Params class equivalent
class Params {
public:
    std::vector<Slider> sliders;
};

// CustomEffect class equivalent
class CustomEffect {
public:
    CustomEffect() : name(""), elements(), callback_function() {}

    std::string name;
    Params elements;
    py::function callback_function;
};

This way, I can provide a simple interface to dynamically change the UI elements, and what "effect" is being applied. 

From the Effect Plugin Side:

Create a "Pool" of UI elements, hidden when first applied. AFAIK I can't dynamically add/remove elements, but I can hide/show existing ones. 

Initialize a 'CustomEffect' instance within inData (This can be done through globalData, correct?)
Embed the python interpreter. To test things out initially I'm only working single-threaded, but my idea for multit-threading is as follows:

Determine the # of threads for the effect, and initialize that many python processes in a pool. 

When the render command is called, it will use the pool, adding and removing things from the queue as it finishes them. 

The Effect will receive PF_Cmd_COMPLETELY_GENERAL, which will contain the CustomEffect data sent from the AEGP.

It will then take this, modify the InData->GlobalData refcon we stored earlier.

The RespondtoAEGP function will update the UI with the required elements and arguments (keeping all others hidden). It will also cast the callback function to the refcon.

In the render function, it will conditionally check for a function there. If it exists, it will use it. (The assumption is that the order of params in the func matches the order and # of params in the UI, which will be documented and required in the API). If it doesn't exist, it'll just push input to output. 

From the AEGP Side:
After passing the Information over, the AEGP simply receives a response indicating success or failure, so that it may continue executing, if it needs to. From this point, we now have an entirely custom effect applied! (Though I'd like to figure out how to maintain state for the project somwhow)