So I’ve been working on a sampling engine plugin for about six months. The plugin is available for Mac (VST, VST3, AU, Sandboxed AUv3, and Sandboxed standalone), Windows (VST3), and iOS (app, Sandboxed AUv3). Of all the engineering challenges that the project has thrown at me, the thing that has given me the most headaches has been sandboxing on Mac and iOS. Here’s why:
My sampler’s sample libraries consist of multiple files: a core XML file (that contains info on which samples to load and how the engine should make use of them) and a bunch of random assets (WAV files, images, etc.). Users need to be able to click on a preset (using the File open dialog), the engine needs to load that XML, and then the engine needs to find and load the files referenced in that XML file. It’s like SFZ format, but it’s slightly different. Anyway, the way Apple sandboxing works, only files that were specified by the user can be accessed by a sandboxed app. In other words, after a user chooses an XML preset file, the engine no longer has access to the WAV files referenced in that XML file. So here are my options:
The app has access to any file in the user’s
~/Musicdirectory. The app also has access to any file in the user’s
Samplesdirectory (this is a directory that I force them to create when the app first runs). I store a URL bookmark to this directory which I reactivate every time the app starts up. So my option here is this: If they try to open a file that isn’t in their ~/Music or Samples directory, I pop up a warning that says “you should move this into your Samples” directory.
I could theoretically make them select the parent directory that contains the XML file. This would allow me to access any files under the tree, but this is weird and unusual request from an app to make. Also, what if there are multiple XML files in that directory, I would then need to have a secondary dialog that would pop up and asks them which preset they want.
I have created a .dsbundle package datatype. This allows macOS to display an entire directory as a single file. This would be my favorite solution except that my app also supports Windows. Windows would display these .dsbundle packages as regular directories which means I would need to have Windows users use an ugly directory selection dialog in order to open .dsbundle packages. Having a different user experience for Mac and PC strikes me as really crummy.
And this final one: I could give up on having an AUv3 on Mac. I could simply ship a non-sandboxed AU which seems to just work and allow them to load XML and accompanying files.
My question is this: Which of these sounds best? I’m personal torn between #1 (a short informational message to my users) and #4 (giving up on the format). Should I just give up on AUv3 for Mac? Is there any reason to support this format? On iOS I have no choice and will continue, but on desktop Mac? By the way, Logic users are very important to me. Is there a chance Logic may up its requirements and force everyone to release in sandboxed AuV3s? Because if so, I definitely want to ahead of the curve on that.