I’m developing a plugin which will definitely not compete with any sound radix plugin, and I probably will never release it, but I’m stuck. How did you guys manage to share information between different instances of the plugin without using the DAW’s sidechain? I’ve been looking all around and trying things, and everywhere it’s looking like every way can potentially glitch out like mad. I’ve never had a glitch with drum align but you’re managing to do what I’ve been stumped on. If someone can clue me in on the best way to go about this for DAW and OS compatibility that would be great. If not, I still love your plugins! Thanks.
First, where suitable, I’d prefer using side-chain or ARA which seems to be up-and-coming.
The reason we ended up not using side-chain in Auto-Align was that at the time we found that several hosts don’t implement side-chain perfectly in terms of sample-accurate timing which was crucial for AA.
So now on to how do AA (and Pi) communicate between instances, and what are this method’s limitations and down-sides:
C/C++ global (aka “static” in classes) variables are shared among instances of the same plugin.
Note: they may not be shared among different formats (AU/VST/VST3) in the same session unless the plugins load a common dynamic library for them, and Bitwig by default hosts each instance in a separate sandbox process also interfering with that, which can be worked around by tweaking its settings (and perhaps plugins could possibly work around it with inter-process shared memory).
You can for example have a global linked list of shared info structures for the different instances.
It is critical to properly lock access to these global variables to avoid threading-related corruption bugs. Also note that you don’t want to use any locks in the plugin’s audio processing functions, so this locked access should mostly be done in constructors, destructors, and responses to events in the GUI etc, along with very careful unlocked access occurring in the audio-processing pipeline. You need to design your structures so that any unlocked access is not going to dereference any pointers that may change etc.
Note that Auto-Align only needs this info for analysis/detection purposes (when you click “detect”) so it doesn’t have to rely on having the very latest samples from the other channel. Pi on the other hand does require to know the inputs on all channels before processing and that’s the main reason that Pi requires a lot of look-ahead, which unfortunately still doesn’t work perfectly on all hosts. Hopefully in the future DAWs and plugin formats would provide better APIs for this and then plugins like Pi could provide a better experience…
I hope my explanations are helpful. Cheers, Yair
Awesome! Thank you!