Reliable folder for shipping presets with a plugin

Hi everyone,

This is the first plugin I am shipping with presets and the loading and saving are working fine. I am using File::SpecialLocationType::commonApplicationDataDirectory as the directory for my presets. The documentation for this location is sort of vague in the sense that there are expressions like “could be something like” and “depending on the setup”. I would like to ship the plugin with the XML preset files and install them in a location where the plugin can find them reliably. Of course, I know where the commonAppDataDirectory is on my PC but will this be the same for every machine? I have noticed that almost all manufacturers install their presets in that very folder so should I just use this file path in the installer and hope for the best that every machine has it and that it isn’t read-only? So I guess what I am asking is how will I make sure that after the installation the file location where the presets are installed and the location the plugin is searching them from, match? Or should I take a different approach and create the preset files when the plugin is first opened therefore dynamically finding a good file location for each machine? Seems unnecessary to allocate all that memory for each instance of the plugin though. Any advice would be highly appreciated.

The documentation for this location is sort of vague in the sense that there are expressions like “could be something like” and “depending on the setup"

I noted that this week. I wanted to submit a PR to clean this up, as this is a good example of a place where the docs accidentally obscure instead of clarify, resulting in extra homework for every dev.

Of course, I know where the commonAppDataDirectory is on my PC but will this be the same for every machine?

Rabbit holing through the source, we can see Windows maps it as CSIDL_APPDATA

Windows has a couple dozen “Special Folders” and these CSIDL (Constant Special Item ID List) values are a proxy for where those special folders actually are on any version of windows.

Aside: CSIDL is what JUCE 6 uses, but starting with Vista, Windows deprecated these and switched to use KNOWNFOLDERID and calls them “Known Folders.” Not sure how far back JUCE 6/7 supports windows, but these could be updated when XP is no longer supported.

Anyway, the short story is that CSIDL_APPDATA maps to FOLDERID_RoamingAppData which has a “Default” value and a “Legacy” value:

So as of Vista, this means that File::SpecialLocationType::userApplicationDataDirectory will map to C:\Users\username\AppData\Roaming.

So I guess what I am asking is how will I make sure that after the installation the file location where the presets are installed and the location the plugin is searching them from, match? Or should I take a different approach

Even though these folders are pretty standard, it’s also common that people bundle their factory presets into their binary to avoid dealing with… questions like this. In some way it… feels like a bummer to be doing this in 2022, but this is the route I’m taking as well (for the same reason, to avoid needing to do anything fancy in the installer, check for the existence of files, etc). I’m using CMRC to load in folders of preset files in JSON and then storing my user presets in FOLDERID_RoamingAppData.

Whups, looks like I read your post wrong. You were looking for commonApplicationDataDirectory and not userApplicationDataDirectory.

commonApplicationDataDirectory maps to CSIDL_COMMON_APPDATA which maps to FOLDERID_ProgramData

I’m not sure where people are storing factory presets on the file system in Windows, but this seems like a fine candidate to me?

I have a blog post series I’m working on titled “Why are audio plugin presets so janky?” and this has motivated me to try and wrap it up :laughing:

2 Likes

Thank you Sudara for the reply. I’ll have to take a closer look. Bummer these things are always a little bit problematic.

I took a first crack at improving the documentation: Correct and clarify SpecialLocationType documentation by sudara · Pull Request #1058 · juce-framework/JUCE · GitHub