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: Motti Shneor <email@hidden>
- Date: Mon, 19 Jul 2010 04:12:13 -0400
- Acceptlanguage: en-US
- Thread-topic: 2 AUCocoaView implementation questions: How to deal with uninitialized AU, and restrict Host to single view.
Thanks everyone. I know this very well --- and we're not fully AU-Standard compliant.
That's because we're both AU, VST2, VST3 and DAE compliant at the same time, on Mac, Windows and several embedded and hand-held system configurations. We have more than 200 Effect products, spanning more than 15 years of development with several million lines of code and our own cross-platform system that runs very well (hmmm... at least our many customers think so.)
We do advance though, and we try to leverage our cross-platform infrastructure wherever and whenever possible. Currently we're moving away from QD drawing (pre-carbon, mind you) into HIView and Cocoa implementations. But the actual visual representation is created very-close to the audio processing --- and yes --- within the AU. The Cocoa and Carbon views merely present graphics and virtual controls that were "half-cooked" in the AU.
Our users must experience very reliable sound-to-view relationship (Meters and Controls tightly bound to the audio) wherever they go (Mac, Windows, DSP, Whatever host).
Up till now, we could live with shared objects because in Pro-Audio the normal scenario is that both the AU and its UI are living within the same host process. We consider ways of breaking this tie --- but this is very complicated to do while preserving our cross-platform system, and user experience.
Still --- I need the technical info!
I could, by the way (and we do in Carbon Component-Manager based AU View components) simply fail on the second instantiation attempt.
This works well with all hosts. What I don't know is --- Is it OK to fail in the Cocoa AU-View factory and return a nil view pointer upon second attempt? Is this something A host should handle gracefully? Are there specific reasons NOT to do so? What behavior should I expect from a Host application when I refuse to create a new Cocoa View for it? After all, failure is a thing that does happen in most software situations!
On 18/07/2010, at 23:16, Brian Willoughby wrote:
>
> 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
>
Motti Shneor
------------------------------------------
Senior Software Engineer
Waves Audio ltd.
[mailto: email@hidden]
_______________________________________________
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