Havent heard this spoken of on here yet, but its something that will effect us all. Whether a legit user of plugins or not.

I saw this post somewhere before but couldnt find it via search on here.

Logic X may be getting sandboxed in a future update. This was brought to light by some plugin developers who received notice from apple about this impending threat.

Here the cut and paste of a post:



"as many expect.. logic pro will eventually be sandboxed per this tweet

https://twitter.com/Chris_Randall/status/380839048354750464

"At some point in the future Logic Pro X will be sandboxed; all Audio Unit plugins and audio hardware will need to be sandbox-safe."


now what that actually means in context of logic and the App store is anyone's guess. but if you read the rest of the posts you'll see that there's a new AU eval tool coming as well. I'm sure every developer is thrilled about the uncertainty and about having to rewrite all their plugs after many of them just did that to get to 64 bit to work in logicX.

anyway.. it's hard not to just get a little hysterical and write all kids of nonsense but reading the tweet.. that's what apple is telling developers... so i assume it's safe to say that's what apple's plans are.

if they really make everything require distribution thru the app store it'll have a big effect on all developers.. apple taking its cut.. don't they have enough billions?

i can see some just abandoning AU which really is only logic at this point.. DP can use VSTs and AUs.. so i can see some users abandoning logic if they can't use all the latest plugs because the developers say "sorry apple" we're not going for it..

speculation.. but we'll see if they really push it all into the app store."



This is a post by Chris Randall who is a plugin Dev who received a notice:

"The letter we received was entirely in relation to AudioUnit plug-ins in OS X, and how Logic deals with them. iOS was not mentioned. Several other devs received this letter, but I know of many that didn't. (For instance, I didn't directly; someone else in my company did.)

What I tweeted was a direct quote from the letter, other than cutting out the bit about Garageband. The actual, entire first paragraph is:

"I'm writing to inform you that the Logic team has posted Logic Pro X Developer Preview 1 build 2911.47. This special developer preview has the same functionality as version 10.0.2 and is being provided for your testing and continued development. At some point in the future Logic Pro X and GarageBand will be sandboxed, which means that all Audio Unit plugins and audio hardware will need to be sandbox-safe."

It is historically typical for Apple to send these sorts of letters about something "at some time in the future" approximately one year before the change occurs. Following that line of logic (pun intended) you can expect to see fully sandboxed versions of Logic and GarageBand at some point late next year.

I have the developer preview downloaded; I haven't installed it yet. I'll check all our products, as I usually do when there's a new Logic seed, and inform our customers of the status."




Essentially this is again a 'conform or forget you' kind of move by the Fruit. If this happens then plugin devs need to update all AU plugins which means we go through another 32-bit to 64-bit struggle, where we lose many of our plugins whos devs decide not to update.

Look at one of the latest OMNISPHERE update, 'Interim support for sandboxed audio unit hosts'. Ut-oh. This doesnt look good.



"Omnisphere Software 1.5.7d 12-09-13

Includes the following new enhancements:

• Support for Pro Tools AAX 64-bit platform
• "All Spectrasonics" Directory (browse all Spectrasonics sounds without third party tagging interference.)
• Directory Menu Separator between Factory/User Libraries
• Live and Stack dimming when not in use

Includes fixes for the following:

• Interim support for sandboxed audio unit hosts (Garageband X/Logic X)
• Browser view mode crash in Pro Tools 11
• Copy/paste layer not disabled on multi page
• OSX Cursor problems
• Waveshaper crash with high input levels
• Layer link status saved in patch
• Sustain 2 mode
• Live mode dragged slot save/restore
• Search field requiring multiple clicks
• Mixer pan routing after part effects
• Filter Modulation Aliasing
• Filter preset menus interference
• Multi browser steppers
• Reference Guide link to online manual"


Thoughts?

 

What does it mean if Logic gets 'sandboxed'? You sure sound anxious about it…

 

Think of it as if Logic is on its on island. And cant communicate with any other folders. Only plugins that are 'routed' by apples specifications can communicate with it. Meaning they have approved checks and balances kind of system. All plugins may have to be purchased through the App Store or In-App purchases for them to work. Thats sort of what this sounds like is going to happen. If devs dont go by apples sandboxing rule then the plugins will not work at all.


This is the explanation from the Chris Randall who is a plugin dev:

"Regarding the meaning of "sandboxed," it's kind of hard to describe in laymen's terms. Basically, the app lives on its own little island when it is running; it can't talk to anything else, and nothing can talk to it, without going through the kernel via approved pipelines. This is how iOS applications run, and Apple is trying to make it system-wide for OS X as well.

Nominally, this would be a problem with a DAW; a sandboxed application doesn't talk to your ~/Documents/ folder. It has its own. But they're not really doing it as a pure sandbox; rather, it is only partially sandboxed. The ostensible reason for sandboxing is twofold. First, if the app is subject to malware (say, an email app or a web browser) then the malware doesn't have any access to the rest of the system, and can only do minimal damage. Second, if the app has some crashy aspects (e.g. something like a DAW that runs plug-ins that may or may not be stable) then a crash in that app won't bring down the rest of the system. Just like if an app crashes in iOS, it doesn't cause the phone to lock up. It just goes away, as its instance is killed.

This is vastly oversimplified, but that's the general idea. For a plug-in to be "sandbox-ready," it has to be able to be instanced inside Logic's instance, without needing to talk to, say, the Internet, or some whacky system feature that Logic doesn't have access to. There is a big problem looming for non-CoreAudio audio interfaces, and I assume MIDI interfaces. But there aren't many of those.

Should be interesting, anyhow. It is, in effect, closing off all access to Logic except for stuff that has been pre-approved (through various means, including digital signing) by Apple. The general feeling among our peers is that it is the first step in making it so Logic can only see plug-ins purchased through the App Store. Personally, I don't see how this is a good thing, and we're not going to give Apple 30% of our business just for the honor of making value-added content for their DAW. Come to that, we'll remove the AU versions from our installers entirely, and basically only sell plug-ins for Live and Studio One."

 

Logic is the Best DAW on this Planet since I have started in the 80#s with C-Lab Creator/Notator!

Not really new for me....iOS APP's are also sandboxed...

 

Agreed, but this sandboxing with create an issue with users and devs alike. Apple is fiddling too much with plugins. If its not broken, why fix it?

 

if this happens i'm out. studio one and/or reaper will get a new user.

 

read about it a few months ago, basically, Apple trying to prevent other companies from creating software without first paying a licence and being given permission to use their OS and access through sandbox, plus a big share of profits, already happening on the iphone and ipad

 

I hate to say this, but ever since Steve passed away these new people running the show are pulling unbelievable stunts. They got Steve rolling over in his grave with all of this nonsense.

 

Sadly without Jobs it's not the same company anymore.
One of the biggest reasons I bought a Mac some years ago was Logic. The new update was not a milestone but more of a cosmetic change to say the least. I can't shake the notion of it gearing more towards the casual consumer than a professional musician. Like there wasn't Garage Band for that purpose. Don't get me wrong I still use it and will continue to do so but I can't help to worry where its all going.
I never considered Apple to be a money hungry corporation. Sure the prices were steap but I knew I was paying for quality. Now Apple comes up with a refresh of their line of products each year and charges us to pay a big sum for a slightly better GPU. I don't buy this.
[/ragemode=OFF]

 

I understand your concerns but I don't think a lot of developers are going to stop supporting 'AU', of course it's a pain in the ass for them to rewrite stuff 'every time', but as long as large numbers of customers still use this format, they just have to 'go with the flow'. Ofcourse it's debatable whether or not distributing plugins through the Appstore is a good move, but on the other hand I'm sure many people will also like the convenience of this system.

Have you heard/seen any signs that plugin devs will boycott this new system?

 

if they have to pay a licensing fee, then yes. they would also have to give up a portion of app store sales as well.

this is a big deal. think of all the free or extremely cheap au plugins out there. those would immediately be doa. you see the shake up with ax plugins? it would be worse if apple does this.

 

Why would they be DOA? There are also a lot of free apps in the Appstore, how do they manage themselves then?
I understand that there are some negative aspects, but maybe there are new ways for devs to sell their stuff too, think of in-App purchases of say extra presets etc. for example, I'm just saying…

 

It's just Apple's way of controlling everything you do when utilizing their platform that you paid for. The same way they bought eMagic in 2002 which at the time was multiplatform and closed it off to PC just so they could boost sales of overpriced Apple computers. I was looking into iPhone development because I had an interesting idea and came to the realization that it's a major pain in the ass.

 

Yes, the developer who received this notice said himself that his company (not sure what company however), would drop AU support. Thats just one of a lot of devs, but if the devs say NO then apple has to do something different. Either not change the system, or do it and say 'fuck you'. In my opinion you will see alot less devs for AU stuff. Due to the percent you give the Appstore, the percent you give apple, and probably for the certification/software for AU development.

The big companies with money will keep afloat (Omnisphere for example is already developing for this shift, but they have $$$), but those single man dev teams wont have much to work with (klanghelm for example? may have more than one person but itd be difficult).


Just my thoughts. Apple has changed. And its only going to get worse the more the world pushes towards total capitalism/commercialism. Do nothing if you dont make money off it, only in it for what you gain from it.


This is the exact response the dev gave to this notice:

"Should be interesting, anyhow. It is, in effect, closing off all access to Logic except for stuff that has been pre-approved (through various means, including digital signing) by Apple. The general feeling among our peers is that it is the first step in making it so Logic can only see plug-ins purchased through the App Store. Personally, I don't see how this is a good thing, and we're not going to give Apple 30% of our business just for the honor of making value-added content for their DAW. Come to that, we'll remove the AU versions from our installers entirely, and basically only sell plug-ins for Live and Studio One."


Another program for OSX that does AU is Numerology Pro. I havent used it but im doubtful it has the flow and design logic has received over the years.

 

Here we go. This will answer, BEYOND what most of you care to read. But a Sandboxing of Logic WILL be happening. Here is the ENTIRE AU Host Sandboxing developers guide from Apple posted earlier this year...

Here

And Here

Here is the cut and paste:

"Technical Note TN2312
Audio Unit Host Sandboxing Guide

This technical note provides an overview of the changes that an Audio Unit Host application needs to make in order to adopt the App Sandbox.

These changes include the following:

Adding the appropriate entitlements

Migrating to the Audio Component API

Checking to see if Audio Units are Sandbox Safe

Preflighting Audio Components using AudioComponentCopyConfigurationInfo

Writing and resolving Security-scoped bookmarks in AUPreset Files and Application documents

Prerequisites
Entitlements and System Resource Access
Using the Audio Component API
Checking to see if an Audio Unit is Sandbox-Safe
Preflighting Audio Components
Persistent File Access
Loading Audio Unit Preset Files
Writing Audio Unit Presets
Saving and Restoring Application Documents
Document Revision History
Prerequisites

Before reading this document, you should familiarize yourself with the following documents which explain general App Sandbox concepts and provide specific information about Audio Units in a sandboxed environment:

App Sandbox Design Guide

Enabling App Sandbox

App Sandbox Entitlement Keys

Enumerating Sandbox Safe Audio Components

Testing your custom Audio Unit in a sandboxed environment

Audio Components and the Application Sandbox

Back to Top
Entitlements and System Resource Access

An Audio Unit host needs access to specific system resources in order to open Audio Units, use MIDI, and read and write files. The Sandboxed host needs to declare its intentions to perform these actions via an entitlement.

An entitlement is a key-value pair that identifies a specific capability, such as the capability to use a built-in microphone, and is specified in a .entitlements property list file in Xcode.

Common entitlements that you may want to add to your sandboxed AU host application:
Table 1 Common Entitlements

Entitlement


Purpose

com.apple.security.temporary-exception.audio-unit-host


Allows opening of Audio Units that are not sandbox-safe

com.apple.security.files.user-selected.read-write


Enables reading and writing of user selected files

com.apple.security.files.bookmarks.document-scope


Enables reading and writing of document-scope security bookmarks

com.apple.security.files.bookmarks.app-scope


Enables reading and writing of application-scope security bookmarks

com.apple.security.temporary-exception.mach-lookup.global-name


Enables MIDI (Type is an array of two string values). See Table 2.
Table 2 com.apple.security.temporary-exception.mach-lookup.global-name Array String Values

String Values


Notes

com.apple.midiserver


Required

com.apple.midiserver.io


Optional

When you add the com.apple.security.temporary-exception.audio-unit-host entitlement, you gain the ability to load Audio Units that are not sandbox-safe (more on this later). When a non-sandbox-safe Audio Unit is loaded, the system will show the user a dialog indicating that the process is attempting to open an Audio Component that isn’t Sandbox Safe.

Important: Using the com.apple.security.temporary-exception.audio-unit-host key can cause the system to disable the host application's sandbox completely. It is therefore important to understand the ramifications of using this key in a sandbox compatibility testing scenario. See Audio Components and the Application Sandbox for more information.

For more information on entitlements see: Entitlements and System Resource Access
Back to Top
Using the Audio Component API

Audio Unit Host applications that run in an App Sandbox must migrate to the AudioComponent API and can no longer rely on the Component Manager to query, load, or manipulate components. Only Audio Component Plug-ins can declare themselves safe to open in a sandboxed process. All Component Manager components are assumed to be unsafe.
Back to Top
Checking to see if an Audio Unit is Sandbox-Safe

Audio Unit Hosts may need to check if an Audio Unit is Sandbox-safe before attempting to open it. A “Sandbox Safe Audio Component” is defined to be an Audio Component that can function correctly in a process that has the most severely restricting Sandbox- preventing access to the file system, network, and drivers in the kernel.

A Sandbox Safe Audio Component will have the kAudioComponentFlag_SandboxSafe flag set in the componentFlags field of its AudioComponentDescription. If this flag is not present, the Audio Unit may not be sandbox-safe.

See Technical Note TN2247 for a code snippet on Enumerating Sandbox Safe Audio Components.
Back to Top
Preflighting Audio Components

Many applications build up a list of the various Audio Components and their capabilities. Since querying an Audio Component to find out what it does requires opening the Audio Component, this may cause the application’s sandbox to drop even if the application never uses any of the queried Audio Components.

To avoid dropping the application’s sandbox while querying components, the new AudioComponentCopyConfigurationInfo API can be used.

Listing 1 Checking to see if an AudioComponent has a custom view without opening it.

AudioComponentDescription delayDescription;



delayDescription.componentType = kAudioUnitType_Effect;

delayDescription.componentSubType = kAudioUnitSubType_Delay;

delayDescription.componentManufacturer = kAudioUnitManufacturer_Apple;



AudioComponent delayReference = AudioComponentFindNext(NULL, &delayDescription);

NSDictionary *configDictionary;

OSStatus result = AudioComponentCopyConfigurationInfo(delayReference, &((CFDictionaryRef)configDictionary));



if (result != noErr && configDictionary) {

BOOL hasCustomView = [[configDictionary objectForKey:@kAudioUnitConfigurationInfo_HasCustomView] boolValue];



NSLog(@"The delay effect %@ have a custom view", hasCustomView ? @"does" : @"does not");

}

For more information about this API, see Technical Note TN2247.
Back to Top
Persistent File Access

Audio Unit hosts manage loading, saving, and restoring Audio Unit presets as well as Audio Unit state stored in their document files. As sandboxed hosts have restrictions on file access, care must be taken to ensure that files can be saved and reopened with a minimum of user interaction across launches and even by other Sandboxed Audio Unit Hosts.

This is further complicated by the fact that Audio Units may need access to external files, for example, a sample-based Instrument or a reverb effect that uses impulse response files to model its environments. The following sections discuss in detail changes that the host needs to make in order to load and save Audio Unit preset files and documents, ensuring that any external references are loadable by the Audio Unit.
Back to Top
Loading Audio Unit Preset Files

Audio Units that reference external files and need the host to manage their file access will have a section in their preset file in the following format:

<key>file-references</key>

<dict>

<key>File 1</key>

<string>/Users/Apple/Music/Samples/Boink.aiff</string>

</dict>

The file-references dictionary contains one or more key-value pairs where the value is the path to the file that needs to be accessed. If an Audio Unit Preset File does not contain this key, the host does not need to do any additional work.

In the above example, the file is accessible if the host has an entitlement to access the user’s Music folder. The host can load the AUPreset file since it has access to the file-reference used in the preset and by extension, so will the Audio Unit.

If however, the file system location is outside of the hosts’ container or in a location that is not accessible via an entitlement (such as on the desktop or an external volume), the host would have to ask permission from the user to access the file by going through Powerbox. See App Sandbox Design Guide for more information.

As this extra level of user interaction every time the preset is loaded may be undesirable to the user, the preset file has a standard mechanism for persistent secure file access. An additional key, file-secure-references, contains a dictionary that is similar to the file-references dictionary except that the value holds an NSData object that is a document-scoped security bookmark for the file specified by the key.

<key>file-secure-references</key>

<dict>

<key>File 1</key>

<data>

Ym9va9AC1THISISNOTVALIDDATAiVEKsUkH83gyyVB11mwqxk2XWd7RiOVDs

...

DAgBAAAAAAAAEcAAABQAAAAAAAAAEsAAABgBAAAAAAAAENAAAKgBAAAAAAAA

</data>

</dict>

If this key is present in the preset dictionary, the host can resolve the URL using CFURLCreateByResolvingBookmarkData and passing the URL to the preset file as the relativeToURL parameter. Note that a specific entitlement is required to be able to create security-scoped bookmarks.
Figure 1 Figure 1 Art/tn2312_PresetLoading.png

The host should verify that the URL that is resolved in the bookmark data refers to the same file that is contained in the file-references dictionary with the matching key. If these differ, then the host should assume that the bookmark is stale and ask the user for permission to access the file (via a standard file dialog). If the user grants permission to access the file, the host should update the secure-file-references section with a newly created document-scoped bookmark based on the file the user has chosen in order to ensure persistent access to the file. The host should also update the file-references path entry if the user selects a different file.

Important: For backwards compatibility, Audio Units will only ever read the file-references section of a preset file and it is the responsibility of the Host to keep it up to date and to ensure the path is accessible.

Document-scoped bookmarks can only reference a single file, not a directory. The user will have to individually grant access to every single file used by the preset. That is why it is very important to store document-scoped bookmarks for each file so the user only has to grant access the first time the preset file is used.
Back to Top
Writing Audio Unit Presets

The Host application needs to ensure that any newly created AUPreset files have a corresponding file-secure-references section for any file-references entries with valid document-scoped bookmarks. The document-scoped bookmark can be created by using either CFURLCreateBookmarkData or the corresponding methods in NSURL.
Back to Top
Saving and Restoring Application Documents

Application documents contain the saved state of every Audio Unit in its graph and they may also contain references to audio files. As with Audio Unit Presets, the host application is responsible for creating security-scoped bookmarks for each of these items that are outside of its accessible file-system so that documents can be reopened without user interaction. The bookmarks should be application-scoped as these files do not need to be opened by other hosts.
Back to Top

Document Revision History

Date Notes
2013-05-16

New document that this guide provides an overview of the changes that an Audio Unit Host application needs to make in order to adopt the App Sandbox."

This is from 2012:

"Technical Q&A QA1483
Audio Unit - Testing your custom Audio Unit in a sandboxed environment
Q: I want to test my custom Audio Unit in a host that is sandboxed to check its behavior. Where can I get a sandboxed host like AU Lab to test with?

A: You can sandbox AU Lab (or any other other application) yourself from the command line using the codesign tool.
Entitlements and Identity

There are a few steps you need to perform prior to signing the application:

1) Create an entitlements Property List file to specify the entitlements.

Note: A naming convention used for this property list file is to call it "Foo.entitlements" where "Foo" represents your Application or Project name.

The following set of suggested entitlements for AU Lab will place the application in the most restrictive sandbox while still allowing it to function. You may add or remove entitlements as needed to test your Audio Unit in a variety of sandbox conditions.

<dict>

<key>com.apple.security.app-sandbox</key>

<true/>

<key>com.apple.security.device.microphone</key>

<true/>

<key>com.apple.security.files.user-selected.read-write</key>

<true/>

<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>

<array>

<string>com.apple.midiserver</string>

<string>com.apple.midiserver.io</string>

</array>

<key>com.apple.security.temporary-exception.audio-unit-host</key>

<true/>

</dict>

com.apple.security.app-sandbox :- this key turns on the application sandbox.

com.apple.security.device.microphone :- this key allows the application to use audio input devices.

com.apple.security.files.user-selected.read-write :- this key allows the application to read and write files selected by the user via an Open/Save dialog.

com.apple.security.temporary-exception.mach-lookup.global-name :- in this case, this key/array value pair is used to enable communication with the MIDI server.

com.apple.security.temporary-exception.audio-unit-host :- this key allows the application to open Audio Components that are NOT sandbox safe thereby dropping the host application's sandbox, provided the user approves this action.

Important: Using the com.apple.security.temporary-exception.audio-unit-host key can cause the system to disable the host application's sandbox completely. It is therefore important to understand the ramifications of using this key in a sandbox compatibility testing scenario. See Audio Components and the Application Sandbox for more information.

2) Obtain a code signing identity by using the Certificate Assistant in the Keychain Access application.

You can also create a self-signed signing identity for testing purposes, or use the single character "-" (hyphen) for the identity for adhoc-signing. See the Code Signing Tasks section of the Code Signing Guide for more information.
Back to Top
Signing the Application

With the above tasks completed, you may now sign the application by using the command-line codesign tool:

codesign --entitlements /path/to/Foo.entitlements -f -s <identity> /path/to/AU\ Lab.app

Important: The -f option is required to overwrite the existing signature. If you don't specify this, you will get a message that the application is already signed.

For more information, see the Code Signing Guide and Audio Components and the Application Sandbox.
Back to Top

Document Revision History

Date Notes
2012-09-10

New document that discusses how to sandbox AULab so Audio Unit developers can test AU functionality in a fully sandboxed environment."