Re: Properties (was: more AU info and plugins (should be "I need to share data"))
Re: Properties (was: more AU info and plugins (should be "I need to share data"))
- Subject: Re: Properties (was: more AU info and plugins (should be "I need to share data"))
- From: Glenn Olander <email@hidden>
- Date: Mon, 23 Jun 2003 14:19:07 -0700
Thanks for the clarification Chris (I think I confused
Chris Rogers with Chris Reed in an earlier message).
So, it is safe to assume the GUI and DSP components
are in the same address space.
Your comments bring up a new topic however: what is the point
of using properties?
I presume the whole point of using
properties instead of direct calls is to support independent
deployment of subsystems. The one case we all deal with every
day is the deployment of a plugin from one vendor and a host from
another vendor. Using the loose coupling of the property system
to communicate between host and plugin allows this independent
deployment to occur with a minimum of hassle.
On the other hand, why use properties to communicate between the
DSP component and the GUI component? Who in their right mind would
deploy their GUI component independently of the corresponding
DSP component? That would lead to a nightmare of possible
version mismatches. You can imagine hypothetical cases where
that independent deployment might happen, but they're pretty
far-fetched.
There are costs associated with using the property system: performance,
loss of compile-time checking, and loss of type-safety. In the case of
host/plugin I can see benefits which help recoup that cost,
but in the case of GUI/DSP?
Glenn
P.S. I've mentioned this before, but the first shortcoming in the
SDK docs that I would recommend fixing is some overview of AU
design principles. Speaking as a plugin developer, I feel like I'm
trying to work backwards from the implementation details to
assemble some picture of the AU design objectives. Without that
overview, there doesn't seem to be any rhyme or reason to the
implementation.
Chris Rogers wrote:
I think the idea is to avoid having the UI component talking to the AudioUnit
by directly calling internal C++ objects deep inside the AudioUnit. Instead
private/custom properties can be defined for the AudioUnit which the UI
component calls. Don't take this to mean that we're planning on having
components talking across different address spaces, etc. Remember,
that AudioUnitGet/SetProperty() deal with void* pointers anyway
so this wouldn't be possible.
Calling the C++ objects directly is simply not recommended by us --
that's all we're saying -- use property calls
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.