Understanding how JUCE interacts with filesystem: generated VSTs, XML and so on

Hi, just starting with JUCE (and XCode), so I have a silly question.

How can I find where XCode sets the location to save, say, VST3 or AU plugins to? Where XML saved state for plugins gets saved? Is this a ProJUCEr setting and are there some docs around it?

I’m trying to understand the files JUCE/Xcode puts out and how it interfaces with a DAW like Ableton.

The projucer project keeps the build directory under /MyProject/Builds/, the Xcode project is under Builds/MacOSX. The built plugins will be in this directory under /MacOSX/build/Debug/ or MacOSX/build/Release depending on whether it’s a debug/release build.

There’s an option in the projucer to copy the plugin binaries to the platform plugin directories, which the default on MacOS is $HOME/Library/Audio/Plug-Ins/Components for AU and $HOME/Library/Audio/Plug-Ins/VST3 for vst3. System wide plugins (installed for all users) have the same path without $HOME. There’s a field for a custom output directory as well, the option is under the Debug/Release exporters in the Projucer.

In most DAWs users can select where to search for plugins, this is useful for debugging when you don’t want to pollute the default plugin directories during your write/build/debug cycle.

The plugins’ state is saved in the project file for the host. It doesn’t have to be XML. When the host saves state for presets through its preset interface, wherever those go depends on the host. When you want to save state for presets you have to decide where it gets saved.


wonderful, thank you!

RE: the plugin state being saved in the project file for host…I have Live, and what I see looks like this

The .cfg file is in plain text, but doesn’t have anything related to the plugin.

When I open the .als file, it’s binary so not sure how to parse it. You’re saying that likely the XML is serialized into binary somewhere in this .als file (19kB)? Is there no nice way to parse it just to check that saving is working as supposed to? I wonder how you’d write a unit test for this without.

You’d instantiate your AudioProcessor in the unit test, set some parameters, then request the plugin state from it. Then kill and re-instantiate the AudioProcessor and ask it to load the previously stored plugin state. Then check equality of the parameters that should have been saved with the plugin state.

All the rest is handled by the JUCE plugin format wrappers that wrap your AudioProcessor in a VST / AU / … format. You can safely assume that they work fine.

If you really want to do full automated tests in a DAW, I would suggest you try SikuliX. We’re currrently testing our plugins on a farm of virtual machines running all sorts of DAWs with corresponding SikuliX scripts that render test tones to a wav file which we can then compare to a reference file. It’s complicated because the rendering is not deterministic (so the comparison to the reference file has to allow some margin of error) but as a “smoke test” it should do the trick and let you know when something is completely broken.

1 Like

Many DAWs don’t just write the binary data to the project file. Usually it gets mangled in some way (e.g. encoded to base64 or similar) to make it fit into XML format or to attach metadata to it.
I think it’s a bad idea to make your tests depend on the file format of a DAW. I would try to test it in a small scope (as I wrote before: Unit test the AudioProcessor, where most of the bugs will probably be coming from) and use a full DAW integration test as a smoke test.

1 Like

ok, this is super helpful, thank you!!