![]() |
AAX SDK
2.4.1
Avid Audio Extensions Development Kit
|
Specification for valid conversions between plug-in types.
The specification on this page defines the valid AAX plug-in type conversions. An AAX host may use this specification to perform automatic type conversions. For example:
In this specification the term "Type" refers to a specific configuration of an AAX plug-in.
Each Type is uniquely identified by a combination of five values:
Each Type is defined by a particular call to AAX_IComponentDescriptor::AddProcessProc_Native or AAX_IComponentDescriptor::AddProcessProc_TI in the plug-in's description method.
The Plug-In ID is defined as one of AAX_eProperty_PlugInID_Native or AAX_eProperty_PlugInID_TI.
In this specification, the format for describing an ID is:
[ ID triad + sample rate + architecture ]
Where the ID triad may be expanded to [ [Manufacturer ID] [Product ID] [Plug-In ID] ]
For example:
For the purposes of this specification we are not concerned with AudioSuite Types. Currently these Types are never type-converted.
In theory, an AAX host may apply a "partial" type conversion by swapping between different ProcessProcs without destroying and re-building any of the plug-in's objects (data model, GUI). For the purposes of this specification we are not concerned about whether a given conversion is "partial" or "total"; all conversions are treated the same.
Plug-in conversions are also required between Types of different stem formats. In fact, the supported stem format is an integral part of a Type's unique identifier. This specification ignores the question of stem formats entirely; we assume that each Type supports all necessary stem formats for legal conversion with other Types.
In general, type swapping rules for deprecated types and related types are equivalent. See Type deprecation for more information about the differences between related and deprecated types.
0x0 == sr_mask1 & sr_mask2
The AAX host should automatically convert between Types within the following IDs:
These conversions occur only if both Types are included in the plug-in when the conversion is made. Consider the following scenario:
In this scenario, if the plug-in had not been updated then an automatic conversion would occur. However, since the plug-in no longer includes the saved Type identifier, no automatic conversion occurs.
A plug-in can work around this situation by including the "old" Type identifier as a Related (or Deprecated) Type (see Explicit conversions.)
When a plug-in instance is saved after making an implicit conversion, plug-ins may be saved with the session using their new Type identifier. This is not required. For example, Pro Tools will prefer to save plug-in instances that were converted from DSP types as DSP, even if they were converted to corresponding Native types when the session was loaded onto and saved from a native Pro Tools system.
AAX includes properties that allow a plug-in to define explicit relationships between different Types. These properties only operate on ID triads. Each property can be associated with an array of ID triads to define a one-to-one or a many-to-one association between the given ID triads and the specific Type to which the property is attached.
The AAX host should convert between related Types within the following constraints:
These conversions will occur regardless of whether the related ID triad is used for any of the Types in the plug-in.
When a plug-in instance is saved after making an explicit conversion, all plug-ins are saved with the session using their new Type identifier.
There are two varieties of explicit plug-in type association: related types and deprecated types.
Properties that create a related type association:
Properties that create a deprecated type association:
With a few exceptions, these two types of explicit association are treated identically. These are the ways in which deprecated plug-in type association differs from related plug-in type association:
Type deprecation should only be used when a new version of an effect completely replaces an old version of the effect. For all other situations, type relationship should be used.