Should I store presets in /Users/Shared, or ~/Documents?

MacOSX and iOS
1

Hi!

I’m developing a sampler plugin (VST/AU/AAX/Standalone) that has presets and close to 10GB sample content.

Because AAX has to be installed at system level, I’m also installing the VST and AU at system level.

A lot of sampler plugins store samples at /Library/Application Support

So I’m doing that too.

Now how about the presets folder? If at system-level, at /Library/Application Support/

Then there are permission issues I believe –You can’t write user presets there.

So, one option that I’ve seen other installers do, is putting presets at /Users/Shared/Documents

Because yeah, in a pkg, you can’t tell it to put a payload at /Users/<username>/Documents

Because pkg’s can’t do variable expansion like that.

Anybody have thoughts on using /Users/Shared for presets?

Looking around, I haven’t seen mention of that location much.

2

I install stuff into /Users/Shared/”company name” on Mac.

1 Like
3

None of the plug-ins on my system have installed anything in /Users/Shared/Documents but there’s a lot of stuff in /Users/Shared itself. :wink:

I think it’s fine to install your factory content in /Users/Shared/YourCompany/YourPlugin. The advantage is that it’s now available to all the user accounts on the system (most Mac users won’t have multiple accounts but there are who do).

Another option is /Users/<username>/Music/. The pkg can’t install there directly (although it does seem to work fine on most modern Macs) but you can use the trick of installing to /tmp and then using a postinstall script to move the files into the right place.

1 Like
4

Thanks. I’ve heard other people mention the /Music/ folder. Seems like the place you’d put music, rather than music tools :joy: But maybe there’s good reason.

It’d be nice to avoid postinstall scripts, although currently I am using a small one to install some user settings files in ~/Library/Application Support/<company>/<product>

If I put them in a system folder, users wouldn’t be able to write to them.

O wait, except I’m installing the presets in /Users/Shared and that’s a system folder.
Maybe I’ll put settings there too! Then not have a postinstall script at all. Decisions…

5

From a user’s perspective– NEITHER!

I hate finding presets folders and stuff like that in my Documents folder. OneDrive, DropBox, etc. all backup that folder to save my PERSONAL files. If I have an issue and need to restore my personal files, I don’t want presets taking up any space in there and confusing me like “Why did I save this shit?… I cant even open these files. What is this?” I’m gonna end up reinstalling all my software anyway. Just hide that stuff where I wont see if unless I have to.

With that said, I don’t want it buried where I cant quickly find it again after I make my own presets folder on a storage drive to back them up in case I have to reinstall someday and the file browser loses focus or whatever.

Instead, put it Program Files under your branded parent folder or even with the plugin when its installed into my VST3 folder. Thats what I prefer most, as a user.

1 Like
6

From memory the reason for suggesting ~/Music is because of AU plugins running in hosts that run in a sand-boxed environment (for example any non-Apple hosts distributed via the App Store), I think (at least at the time) this ended up being a common location they all had access to. If you install to a location they don’t already have access to, you risk not being able to access that location from your plugin!

It’s been some time since I’ve had to deal with this but if you plan on releasing an AU plugin and your plugin would ideally need access to these directories without user input, I would advise testing with a sand-boxed host.

7

I always thought presets were supposed to go in /Library/Audio/Presets/

I create a folder there in my installer and then make it world writable.

But if you have 10 GB of samples, the location needs to be customizable so users can install to external drive.

2 Likes
8

You’re right! for presets I think that should always work and certainly that should be the place for vstpreset and aupreset files as the hosts should look there too, so you would hope all hosts have access to that. Now I think about it I think the issue was more for other files such as a user config file that you might typically install in Application Support, but if I remember correctly, at the time that was the kind of thing that caused issue, maybe those issues are resolved now which is why I say test with some sand-boxed DAWs.