From the standpoint of a user, a view is an audio unit. From your standpoint as a developer, the situation is a bit more subtle.
You build a view to be logically separate from the audio unit executable code, yet packaged within the same bundle. To achieve this programmatic separation, Apple recommends that you develop your custom views so that they would work running in a separate address space, in a separate process, and on a separate machine from the audio unit executable code. For example, you pass data between the audio unit executable code and its view only by value, never by reference.
Without impinging on this formal separation, however, it’s often convenient to share a header file between an audio unit executable code and its view. You’ll see this done in the SDK’s FilterDemo project. A shared header file can provide, for example, data types and constants for custom properties that an audio unit’s executable code and its view can both use.
Both generic and custom views make use of a notification mechanism to communicate with their associated audio unit executable code, as described in “Parameter and Property Events.”
Last updated: 2007-10-31