Re: audio unit deinstantiation thread
Re: audio unit deinstantiation thread
- Subject: Re: audio unit deinstantiation thread
- From: Olivier Tristan <email@hidden>
- Date: Wed, 13 Jul 2011 16:54:08 +0200
So the backend doesn't know anything about the GUI but still you ask the
plugin to know about its UI ?
Doesn't seem right.
Killing the engine before its UI is like killing a server before its
client. It shouldn't be the default behavior unless you have no choice
(crash in case of client/server)
On 7/13/2011 4:48 PM, Paul Davis wrote:
On Wed, Jul 13, 2011 at 10:39 AM, Olivier Tristan
<email@hidden> wrote:
On 7/13/2011 4:31 PM, Paul Davis wrote:
On Wed, Jul 13, 2011 at 10:18 AM, Jeremy Todd<email@hidden> wrote:
Hello,
We recently noticed that Soundtrack Pro 3.0.1 is instantiating our
plug-ins on the main thread, but in some cases (Render to Action)
deinstantiating them on a different thread. This is not something our
plug-ins expect, and I'm wondering if it's considered a valid host behavior?
We're also seeing that the component representing our Audio Unit is
closed before our UI is deallocated (we have a Cocoa view in this case).
This is also unexpected, although much easier to work around than the above
behavior.
Neither aspects are documented, since basically, being an AU host is
almost completely undocumented. I can tell you that both Ardour and
Mixbus will close your AU component before deallocating the GUI in
almost all cases.
Are you sure you didn't meant the opposite ?
I consider as well that deallocating the main plugin before its UI is very
strange.
* the user takes some action to delete the plugin
* the GUI sees this, and asks the backend ("engine" to some of you) to delete it
* the backend doesn't know anything about any GUI, but proceeds to
destroy the plugin
* destruction begins in the "wrapper" Plugin class that hides
internals of AU/VST/LADSPA/LV2 etc etc
* the AU plugin itself gets its component closed
* the Plugin class emits a signal (think "callback") to say that its
being destroyed
* the GUI object that has a handle on the AU plugin view sets about
destroying the view, and then itself
Remember that the plugin itself and the view are separate shared
objects that can have hold references to each other. If the view has a
reference to the plugin, the fact that the host drops its own
reference is not that much of a big deal - the shared object won't
get unloaded until all references to it are gone.
--
Olivier Tristan
Ultimate Sound Bank
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden