@bozmillar - I’ve been working on building a server side cache layer for a neural network proxy in Node JS for several months.
Occasionally my mind wanders back into audio land. I was thinking about cache layers in the AU/VST world…
Question: When a user hits save or save as... in a DAW, is it the DAW or the instance of the plugin that stores the last recorded changes to the settings? Which engine (or file management system) bears the majority of the responsibility for storing and recalling each channel strips plugin settings?
Is this standardized across DAW’s and based on AU or VST protocol? I would imagine it’d have to be because then Devs would have to re-code their plugins for every different daw. Right?
I noticed that when you restore a very old session, sometimes the plugin settings can’t recall, and the plugin reverts to the default settings. Is this more likely caused by code regression in the DAW or in the plugins?
…And while I’m at it: I was also wondering if you typically unit test the codebase before shipping updates. How do you typically prioritize the design the tests?
The DAW saves it, but the plugin has to tell it what to save. When the plugin is closing, you basically write a chunk of data that the DAW saves in the project file. The next time you open the project, that data stream is sent back to the plugin and the plugin reloads its settings.
It depends on how the data is stored. For exampleIf you have a plugin with 2 knobs and you store the settings of those knobs as a raw binary stream, but then later update the plugin by adding an extra knob, the plugin might not know how to interpret the data correctly. So if a parameter is told to get set to a number that is out of range, it may just set itself to default instead.
But you can obviously be a bit smarter about how your store the info so this doesn’t happen. I store the version number of the plugin that was last used so that when it opens up, it can correct for any discrepancies if the version changes.
Most of the code in a plugin is pretty stock, and since I’m not working with a team, if there is a bug, it’s usually easy to track down. Generally, the only thing that is super custom is the algorithm itself and as long as you keep it clean while writing it, it’s pretty easy to keep bug free. The graphics side is where most of the bugs happen and a lot of that code is tweaking existing code, and it’s rarely catastrophic if something there is messed up. Usually by the time a plugin is ready to release, the algorithm itself is pretty solid and the tweaks at the end are all graphics related.
I can’t think of the last time I released a plugin that had a truly major bug that needed immediate fixing. Usually it’s something minor that is easily fixed. Or a typo.