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: Sat, 21 Jun 2003 20:13:59 +0200
On Saturday, June 21, 2003, at 07:10 PM, Urs Heckmann wrote:
Am Samstag, 21.06.03, um 18:47 Uhr (Europe/Berlin) schrieb Airy Andri:
Le samedi, 21 juin 2003, ` 18:40 Europe/Paris, Urs Heckmann a icrit :
Am Samstag, 21.06.03, um 15:16 Uhr (Europe/Berlin) schrieb Marc
Poirier:
If you use pointer access between your audio and GUI components,
then you
are making a few assumptions (that the two components exist in the
same
address space, that there will not be more than one GUI component
for the
audio component, etc.).
You also assume that they run in the same process. But what if you
insert an AU (dsp) in a ReWire / Jack slave and want to control
(view) it from the master application?
I know at least one company that works on such behaviour.
Cheers,
;) Urs
Which one ? With AU ?
Airy
They wouldn't like it if I told you their name or anything more. Well,
the only thing I know is that they asked me about AU guidelines and
stuff. I had to tell them that, despite Apple's prayers, probably a
lot of AUs might be using direct view-dsp access, so maybe they buried
their plans immediately thereafter. I recommended asking Angus how the
VST-AU transformer deals with this.
However, there are lots of examples why the divorce of dsp and gui
should happen, and despite I have to rewrite some code, I hope that
Apple will be strict on this in the future (like a certificate or
something).
I've been told that Rewire installs Reason on the heap of the host
(master) application. So in that case, Reason, the AU-GUI, the AU and
the host app share the same address space.
Nonetheless host, AU and AU-GUI should use standardized Set/Get
Property/Parameter to communicate whenever it is possible. But It's
also true that sharing the same address space (which is not
contradictory) is more efficient than a call which have to cross
processes boundaries. It is also the simplest and the most efficient
way to share large data when needed.
An example is the sharing of sound samples. Another example is when the
AU-GUI has to draw an overview of the audio, or to plot an FFT which
must be computed from the actual audio (the dsp). In both cases, the
AU-GUI needs informations that cannot be obtained with the
GetProperty/Parameter mechanism.
To say the truth, this mechanism was not designed with these needs in
mind. A parameter may change frequently - it's in a way a real time
data - that must fit in a Float32, while a property is a "moderate"
size data which is not supposed to change frequently. Audio data is
neither one nor the other. In that case, sharing pointers on audio
buffers (or other specific data which makes sense for the couple AU<->
GUI) looks a reasonable way to solve the problem.
But maybe you had something else in mind when you mentioned "the
divorce of dsp and gui" ?
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.