Q: How do Audio Unit plugins and Audio Unit hosts negotiate the resizing of the Audio Unit's UI? A: Some Audio Unit plugins may want to resize their UI within the hosting application. These changes can be based on the internal parameter state (and many other UI considerations) within each Audio Unit plugin.A: A plugin should never resize its view's window, but instead resize the control it returns to the host when the plugin's view is first created. It is the host's responsibility to listen for changes to the bounds of that control, and then resize the view for the Audio Unit to fit within the confines of the application. The Audio Unit's Carbon control is received by the host when the view is first created by using AudioUnitCarbonViewCreate . The host should create a listener for changes to the Audio Unit's view bounds by using AudioUnitCarbonViewSetEventListener with the event kEventControlBoundsChanged . Thus, when an Audio Unit needs to change its view size all it needs to do is resize the view's control. The host is setup to listen for changes to this control. When the kEventControlBoundsChanged event is received by the host, it can resize the Audio Unit window within the application. Note: The host must check against receiving control bounds changed notifications with a size of (0,0). Some Audio Units will temporarily resize their root control to (0, 0) as a temporary state before setting a new final size. In this case, the host should ignore this control bounds changed notification. Document Revision History| Date | Notes |
|---|
| 2004-03-23 | Discusses the host's responsibilities when resizing Audio Units. |
Posted: 2004-03-23
| 