Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- Subject: Re: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
- From: Brian Willoughby <email@hidden>
- Date: Sun, 18 Jul 2010 13:16:37 -0700
On Jul 18, 2010, at 05:28, Motti Shneor wrote:
Pardon me --- But what happens first? is the AU uninitialized
first, then its view closed and deallocated, or the other way round?
This is important for us because of the strong connection of our
View and AU. There are several objects shared between the two
entities, whose ownership is not clear to us.
You cannot share objects between View and engine because there is no
guarantee that the two types of entities will be running in the same
address space, or even on the same machine. If you are literally
sharing the same object between View and audio engine, then you have
a broken AudioUnit implementation. You need to have separate objects
in each - you could just instantiate the same or similar objects
multiple times and then use properties (or parameters, if
appropriate) to keep the multiple object states in sync with each other.
All of this sounds like a plugin designed for the older VST model
which has not been properly re-designed for the more advanced
AudioUnit model.
As I stated, our specific implementation cannot currently support
more than one view (instance!, not class) per AU. This is because
they share some mutual state object (weird but that's how it is
now). Even if we DID support more than one view per AU, we must
limit this to a certain number for performance reasons (some AU's
we sell are very sensitive to view-refresh rates, and maintain
tight synchronization with the audio, so they can't afford more
than few views).
As Urs has pointed out, what you describe does not fit the definition
of an AudioUnit according to the spec. Not only must you be prepared
to have multiple Views per audio engine, but you must be prepared for
one or more Views to run in separate process address spaces or even
on separate machines from the audio engine. All communication
between View and engine must occur through parameters and properties.
Brian Willoughby
Sound Consulting
_______________________________________________
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