Re: more AU info and plugins (should be "I need to share data")
Re: more AU info and plugins (should be "I need to share data")
- Subject: Re: more AU info and plugins (should be "I need to share data")
- From: Philippe Wicker <email@hidden>
- Date: Mon, 23 Jun 2003 08:14:53 +0200
On Monday, June 23, 2003, at 07:12 AM, Glenn Olander wrote:
That sounds like a definitive answer to my question about properties.
So, where did that guideline Marc mentioned about not passing pointers
between the DSP and GUI components come from? It is starting to look
like an urban myth :-).
I think Marc "guideline" was primarily about avoiding to exchange
pointers on the C++ objects which are embedded in the components (AU
and/or GUI). In that respect, this "guideline" do make sense because,
as he said, you (the component developer) don't master the life cycle
of these objects. The host can very well maintain an instance of an AU
for the whole session while the view may be created/destroyed at will
leaving your AU component instance with a dangling pointer and very
likely a crash of the whole app (host and components) at the end.
When dealing with data, the problem is different because these are
**your** data and you master their life cycle.
Of course, if you're looking for a way to significantly distinguish AU
from the VST/DX/MAS/RTAS crowd, offering a mechanism to put the GUI and
DSP components into separate processes would certainly qualify. In
other words, you may want to consider replacing the current property
and component system with one which _does_ support inter-process
communication. I don't have any illusions that this would be a small
job, but it would certainly be a significant step
forward for plugins.
Sure, the Urs idea of an AU farm is indeed a nice one. Some famous
musicians are thinking about such items. I remember of an article
posted on the Emagic site some months ago(I cannot remember the name of
this artist). This idea of an effects farm distributed on many machines
was foreseen. For sure, this really is not a trivial job.
Glenn
Chris Reed wrote:
I thought the last time this came up (or one of the previous times,
there have been several), it was determined that the OS X
implementation of the ComponentManager simply did not, and almost
certainly never would, support cross-process component instantiation.
Also, the current way properties are used really doesn't lend itself
to working across process boundaries. Passing pointers in the
Get/SetProperty calls that are then directly used within the AU code
just won't work, will it? I mean, for a wrapper to work it would have
to be aware of each property's data content and copy it between the
process. So there would have to be something sitting on top of the
ComponentManager that knows about the AU API. (Not impossible,
though, if you could work around the ComponentManager.)
_______________________________________________
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.
Philippe Wicker
email@hidden
_______________________________________________
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.