Happy monday!
In my current plugin project I need to use an "helper" AEGP for tasks my main effect plugin cannot accomplish (delayed tasks via AEGP idle hook, project modifications that will crash if performed inside the Effect logic, etc.)
I'm trying to figure out an elegant and robust architecture design for this cross-communication.
Heres the way I see it:
Effect passes info along to AEGP via custom suite data.
AEGP reads the data at idle, and performs some required task.
The success/fail of this work and the resulting products are communicated back to the Effect via AEGP_EffectCallGeneric.
My question is basically surrounding the data/info handoff. What kind of objects should I be passing back and forth? Is it considered poor design to simply pass along a pointer to the sequence or custom arb data to the AEGP via the custom suite? And vice versa when the GP sends EffectCallGeneric to the effect and passes a pointer, it could just be the same pointer that the effect originally sent the AEGP using the custom suite.
Aside from undo/redo, is there an advantage to using arb parameter data over sequence data for this task?
It seems to me that AEGP plugins are loaded once and only once in the session, so if multiple instances of my effect plugin are used in the project, and they are all calling the AEGP there is the potential for a race condition if the custom suite data is used to pass along information. Is this an accurate assessment of AEGPs? A simple example of this would be that the custom data suite has a variable that stores which effect plugin is calling the AEGP. If another instance of the effect starts talking to the AEGP, it would overwrite the suite var telling the AEGP which effect instance is calling it, thereby making the AEGP perform the work of one effect instance but sending the results to different instance.
Even if the AEGP is extremely simple and just performs small atomic operations each time the custom suite data tells it to, how do I prevent n+1 Effect instances from colliding when using the AEGP worker? Am I missing some key part of the Effect->AEGP communication that prevents this race condition situation?
This is the first time I've tried my hand at writing inter-process communication where I have the option to exchange actual in-memory objects. I'm hoping someone with more experience with this sort of problem can give some pointers(hah) or at least a few cautionary words about designs to avoid.
Thanks, sorry for such an open ended question, but this is the place to talk to the pros
-Andy