![]() |
AAX SDK
2.4.1
Avid Audio Extensions Development Kit
|
How to transfer data between different parts of an AAX plug-in.
AAX is a highly modular architecture. This section describes the various means by which AAX plug-in modules may communicate with one another and with the host.
There are two fundamental categories of communication in AAX:
Most communication between the AAX host and the plug-in is accomplished via the AAX_IController interface. This interface contains methods for such things as:
In addition, the GUI uses a separate interface for managing view and event details with the host. This interface, AAX_IViewContainer, includes methods for:
Often it is necessary to transmit arbitrary blocks of custom plug-in data between different plug-in modules. In AAX, this is accomplished by "pushing" data to and "pulling" it from the plug-in's data model.
The abstract data model interface includes two custom data methods for this:
It is the data model's job to act as a go-between when custom data must be transmitted between a plug-in's other modules.
For example, a plug-in may wish to send analysis data from its direct data module to its GUI. In this situation, the Direct Data object would call SetCustomData() to update the data model whenever new data was available, while the GUI would "pull" the most up-to-date data via GetCustomData() whenever an update was required.
Note that the default implementations of these methods are empty and thus all implementation details, including thread safety guards, are left to the plug-in.
The data model and GUI interfaces include notification hook methods. These methods used for host-to-Effect notifications by default, but may also be called with custom notification IDs in order to create custom notifications within a plug-in.
If co-location is guaranteed, plug-in modules may directly share data pointers. For example, a non-real-time plug-in's Host Processor object may share a this
pointer with its data model object.
To guarantee co-location between modules that could normally be placed into different memory spaces by the host, use "constraint" properties:
To help avoid forwards-compatibility issues with future devices that support AAX, these constraints should be set whenever a plug-in requires co-location of its components. Note, however, that using a design that relies on co-location will prevent the plug-in from running in distributed environments and should therefore be avoided when possible.
An AAX plug-in's algorithm is essentially a stateless callback and, therefore, all of its state data must at some level be managed by the host. This model is fundamentally different from the other plug-in modules, which are each objects with their own memory and state.
Most algorithmic data management is performed via the algorithm's context structure. More information about memory management in AAX real-time algorithms can be found here.
The most common form of communication with a plug-in's real-time algorithm callback is the transmission of read-only data from the data model to the context structure.
AAX includes a dedicated API for this task that provides buffered, optimized delivery of read-only data packets to the algorithm. For more information, see Communicating with the algorithm .
Algorithms can also send data to the host and receive environment information through dedicated context fields. For example, the host can provide access to DMA facilities through an object accessed via a DMA field, and a plug-in can report meter values to the host via a dedicated meter field. For more information, see Communicating with the algorithm .
When other modules in the plug-in must interact directly with the algorithm's state information this is accomplished via the Direct Data interface. This interface provides an idle-time context in which the plug-in may read from or write to the algorithm's private data memory. These transfers are unbuffered and therefore the plug-in must handle any appropriate thread-safety considerations.