Re: Using This pointer for communication
Re: Using This pointer for communication
- Subject: Re: Using This pointer for communication
- From: Philippe Wicker <email@hidden>
- Date: Thu, 30 Sep 2004 08:26:26 +0200
On Sep 29, 2004, at 11:05 PM, William Stewart wrote:
We've spec'd out an approach to how we'd do this (both for the builtin
properties and custom properties) and thus could also represent a way
for an
AU to say that it has this capability.
The real problem actually I think is:
(1) Many of the AU's that you'd really want to do this with are not
able to
do this without substantial re-working (but the trivial ones are easy,
but
not as useful).
What about a solution that distributes both the AU and its view
(something like the Steinberg V-Stack)?
(2) The "is it worth it" problem that Stefan describes is a major
problem
Some plugins requires quite a lot of resources. I think of a sample
based soft synth that needs to access possibly very large sounds bank
using disk streaming which competes with disk accesses needed by the
sequencer to read audio tracks. Those plugins may also consumes a lot
of CPU to process the samples (e.g. high quality pitch shifting).
Having such plugins running on a separate node is worth it :))
(3) AU's that depend on data (sample banks)
Some plugins may also share common resources when they are instantiated
several times (e.g. the loaded sample banks).
(4) AU's that require authorisation
(5) How useful is this really to do this one AU at a time?
The difficulty I see is to optimize data transfers between nodes and
master, that is to avoid calling multiple socket read and write for
each distributed AU. I suppose that such an optimization requires the
knowledge of the whole plugin graph (the host has such a knowledge).
Maybe you had another idea in mind when asking that question?
These are all beyond our ability to resolve directly (and given the
generally lax attitude people have shown to the general design goals
we've
promulgated since day 1), have led us to believe that (at least until
this
point), there's little direct benefit to resolving the basic problem.
I still remain to be convinced that there's any substantial benefit to
this
kind of one off AU "distribution", particularly as the desired end
result
can be achieved for multiple AU's today that I think ultimately has
more
benefits (have another machine/s in the studio and use other means to
get
audio and MIDI to/from that and the main host machines - many studios
in
fact do just this today) - to that end some of the features we're
doing in
Tiger have some interesting uses.
For those that are planning on attending AES in San Francisco this
year, we
will be going through some of these.
Bill
Philippe Wicker
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