How to save audio data in DAW's memory block?

Hi there!

I’m building a synthesizer audio plugin and the user is able import some audio files from the disk but I’m having a really hard time deciding on which is the best approach on saving the plugin’s state. To be more concrete it’s not clear how to save the imported audio files. :confused:

Here are some different solutions:

  • Case 1: Save audio clips full paths to host’s memory block
    The main problem here is that I cannot have extra dependencies to the DAW session. Additionally, I should let the user locate the missing files (e.g when she deleted the audio files from the disk, or imported files from external disk). Also, in this case the DAW projects cannot be portable (e.g Ableton’s Live feature “Collect All and Save” won’t work correctly).

  • Case 2: Save imported audio data to host’s memory block
    Is there any limitation concerning the size of the given memory block in “getStateInformation”? I read this post but the answer in not so clear.
    What is more the save/load process might become heavy depending on the size of audio data and this certainly results to bad UX especially when auto-save is enabled in DAW or “Duplicate DAW track” is selected.

  • Case 3: Create temp files containing the imported audio data (as binary)
    A reference to this file is saved in getStateInformation and the plugin can restore its state by reading this file in setStateInformation.
    But when should I delete these files?
    Obviously it’s not a good technique to fill user’s disk with unnecessary files. I could delete the temp file when new audio data are imported.
    However when using the duplicate feature or the Save As… option from the DAW menu, the plugin instances will share the same temporary project files. If we overwrite any of these, we risk invalidating other instances that refer to them!

Has anyone faced a similar issue before? If yes, then which were the priorities to solve this? For example, what is more important from UX perspective? Is it more important to keep user’s disk clear from junk files or have a smooth save/load system?

1 Like

I am struggling with this too. :frowning_face: For one plugin I implemented a scheme where it stores the captured audio files into the user’s application settings folder. It didn’t take much time for people to complain about that. It’s a very tricky thing to solve satisfactorily. I am now a bit stuck with another plugin where I want to do a similar thing and I just can’t come up with a decent solution. Maybe make it a very configurable thing, but that then means writing a lot of boring GUI code…

What would probably help at least a bit : if there were official APIs in the plugin formats to get the host’s project file path…Then the files could at least be put by default into a location that makes some sense. But of course that wouldn’t solve all the possible issues.

However, if your plugin just imports already existing files and doesn’t write its own (for example by capturing the plugin input), the situation isn’t that bad, I would think? Or does the plugin do some processing that you want stored permanently?

However, if your plugin just imports already existing files and doesn’t write its own (for example by capturing the plugin input), the situation isn’t that bad, I would think? Or does the plugin do some processing that you want stored permanently?

Yes, the plugin processes the imported data. This is something that possibly I could restore when loading a DAW session but finally this will not solve one of the main problems to eliminate the dependency to external files. And in a future product version what will happen if I add an extra processing step that might be heavy?

Well to be honest the development of a “non-traditional” cross-platform audio plug-in is a real nightmare! If you try to report the callbacks of AudioProcessor class for the different plugin formats then you’ll realise how complicated things are. For example, the order of callbacks execution between AU and VST/VST3 is totally different (e.g during plugin instantiation) and this will lead to a complex code full of if-conditions. :tired_face:

Regarding using the plugin state data and that it isn’t known what’s the maximum for that is. It’s difficult to say because hosts have so different ways of handling that. Some hosts use text based project file formats where binary data will be encoded as text, so the data ends up using a lot more space than could be anticipated. They may compress the data before or after the text encoding, but that likely doesn’t end up in significant savings if the data contains audio.

Hosts may be saving plugin states in their undo history. That could potentially lead to horrifying memory use quickly, since there is not necessarily a way for the host to discern what changed in the state data. edit : Tested that in Reaper with the GRM Freeze plugin that stores audio into its state data. Moving a parameter in the plugin causes Reaper’s undo history memory usage to grow by 5 megabytes, even though only a single parameter’s value changes in the state…

That depends, if the audio file is already compressed. It’s true, that zipping a ogg or mp3 file doesn’t lead to much smaller sizes, but wav files could profit from zipping.

Nevertheless I agree, it’s not the best idea to put it into the sessions, if it is more than a few seconds. I just remember somebody complaining about a host, that is constantly saving after any activity…