Well, our desktop and iOS plugs are identical, so I just write the presets on the desktop version, then put them in the binary. I tried several other methods (some of which are discussed above) but I figured having them in both the binary and appex was no biggie, since the whole payload is only like 20K or something.
So I effectively have two complete preset mechanisms: one that reads XML files from a folder, and one that reads XML files from the binary; these look identical to the user, and the User/Factory button toggles between them. It’s simpler than it sounds, and in general works fine. I started with the code that Randy from Madrona Labs and Sean from Valhalla worked out elsewhere on the forum, although I’ve heavily modified it by this point. The only real divergence I had to do from their basic idea was that the appex can’t spawn alert windows (which are system windows, and a sandboxed app can’t make those) so I had to make custom components for file naming, deleting, etc.
thanks! i have got it working using fabian’s approach. So nice that auv3 and garageband finally make ios music interesting, shame these auv3s are such a PITA to debug!
And don‘t forget the 350MB memory limit for ALL instances, I found this to be the most annoying thing I‘ve encountered so far in my programming experience.
That’s actually a bit of a grey area. The AUM and Beatmaker 3 guys have discovered that if they chain-open the UIs of all instanced AUv3s (which they do in the background) they can run far more than 350mb worth of instances.
Grab a copy of AUM and load it up and you’ll see. They start with the first channel, and open each AUv3’s UI in sequence and close it again; they do this behind their main window so the user doesn’t see it. But you can watch it happen plain as day. One of the devs explained why it worked to me, but I can’t find the email.
Sure, but watching an app open some windows doesn’t really explain what or why it’s doing that.
But the main thing here is Apple deliberately impose that memory limit on an app. If there’s some bug in the enforcement of their policy in the current OS versions, which these apps are exploiting to work around the limit, then that isn’t really a solution that’s of any long-term use!
Getting out of my comfort zone. I can only report what I know to be true, and that’s that AUM et al have a workaround in place for hosting multiple AUv3s. Should you use a 349mb TIFF as your background image? No. Should you release an AUv3 and think you’re never going to have to touch it again, and it’ll have the same lifespan as a 32-bit Windows VST2.4? No.
Common sense applies, and common sense tells me there’s no such thing as “a solution that’s of any long-term use” in iOS. “Works right now, and will probably work for a few months” is generally the best one can hope for.
I’ve figured out “the fuss” here. A bit of a misunderstanding on Fabian’s part. Your code does, in point of fact, work fine for accessing shared resources. Unless you want to write to the folder. (As in saving user presets.) The user can’t write to the bundle.
With Fabian’s method, both the appex and the app can read from the main bundle’s folder, assuming the app groups are activated. If they are not, the appex has no awareness of the bundle at all. Per the Apple docs, as I noted above, we clearly do not have any write access to this folder at all, either from the main app or the appex.
The user documents folder (which is bare to the main app, and appears in the File Sharing tab of iTunes if we activate that capability) is opaque to the appex. The main app bundle can both read and write to this folder, in the usual way (File::getSpecialLocation(File::userDocumentsDirectory)). The appex is entirely unaware of it.
The security group, accessed as I have noted above. Both the app and the appex have full read and write access to this folder, and it is persistent through updates and is backed up. It is, however, a shit place for storing audio, and you may have your app not pass review. (Apple generally doesn’t like apps that store large audio files anywhere but the user docs folder, and even then they’re not happy about it, in my experience.)
So, the long and short of it: to make a JUCE method that can both read and write, and doesn’t need the shenannigans I’ve noted above, the Roli boys will need to roll in a special iOS-only method just for app groups (this will also work with AUv3 on desktop, but who cares, really? That’s such an obscene format, we do our customers a disservice by supporting it.)
The short-term workaround: use Fabian’s method for factory presets and other static shared resources, and my method for user presets and dynamic resources, with an option in the main app to marry the contents of the security group folder to the documents folder now and again. That is, best I can tell, the only currently working methodology.
I’m not sure it is an obscene a format as you think. Based on discussions I had with Apple in the past I gather AUv3 for some will be the only way they can make particular plugins sandbox safe. Currently Logic and FCP are the only apps on the app store that are not sandbox safe, and the feature to drop security that you see in GarageBand is temporary, neither will be the case forever.
All depends on how you look at it. Your points are true, but then we get to the “in the app store” discussion as it relates to desktop software, and the overwhelming problem (note my dripping sarcasm, in case it wasn’t obvious) of audio effect plugins and sample sets as a malware vector.
Apple is actively working to make our tools less useful and open so that a niche software suite and methodology that is inherently unsandboxable matches some grandma in Des Moines’ Candy Crush install, so they can say “sandbox safe!!!” That’s fine. It’s their OS and they’re welcome to do what they’d like. This entire discussion thread is about the confusion that relatively intelligent people are having with trying to save a damn preset file in a sandboxed plugin. Getting more complex than that is going to be a real hoot.
Yesterday I spent the whole day trying this for an AUv3 on Mac OSX.
Did anyone already test to read the apps Resource folder from the appex in OSX? With Fabians method (which we use successfully with iOS), I could localise my files and even the file.exists () method would return true, but reading doesn’t seem to be possible. I added an App Group for the Standalone and the AUv3, but it doesn’t change anything (and it looks differently, because there is no checkbox to “activate” the App Group like in iOS).
If someone has an idea, please let me know.
If not, I think there is no other possibility than to copy the files on first start of the Standalone to
Anything new added to JUCE about this? Even though I can specify the App Group ID in the Projucer, I don’t see any way to get access to the shared Documents folder from within both the standalone app and the .appex plugin.
