Re: Using This pointer for communication
Re: Using This pointer for communication
- Subject: Re: Using This pointer for communication
- From: Urs Heckmann <email@hidden>
- Date: Thu, 30 Sep 2004 02:04:05 +0200
Hiya,
it's late here, but I couldn't resist to assemble some thoughts...
Am 29.09.2004 um 23:05 schrieb William Stewart:
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.
Cool 8-) Tell me more!
I was just about to write a proposal about a way to aquire the info
within a context scheme. Well, I'll happily wait and see...
Please take into account that it is useful to pass data with a Property
request. Otherwise we'll end up coding flags and stuff into Property
IDs. And there are only 16 bit (ugh!) left above 64000...
Just curious, what do you do with the ComponentInstance pointer that
gets passed to the AUView?!? Kinda proxy type of thing?
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).
Hehehe, well, who says that trivial AUs are not useful?!?
I can still think of having the whole AU + AUView on the other machine
and using facilities like Remote Desktop (exchanging a compressed
WindowPort and remotely comitting mouse events) for the problematic
AUs. (If there's any speed benefit left then...)
On the other hand... if the distributed stuff works like a better
freeeze, one might not even need full access...
But... what about plugs that are processed on dedicated DSP Cards...
(2) The "is it worth it" problem that Stefan describes is a major
problem
Yes. We have yet to see how distributed stuff performs and if it's any
good ;-p
(3) AU's that depend on data (sample banks)
Indeed.
But if they conform to the specs, ClassInfo-wise, they would use the
FilePointer stuff you proposed some months ago... ->
AUPresetsAndFileReferences.rtf
If the GUI features any file handling, we'd need a Property (60000+
left) for that, so it could be translated 8-)
(4) AU's that require authorisation
Now... if a Logic node can work without an XSKey, it might come down to
a logistic (no pun intended) problem for those who use dongles or are
paranoid in other ways. (Arrrgh... side note: One can't debug a host
with certain plugins because some plugs just intentionally crash when
the host was launched in debug mode, so how would you debug
compatibility issues?!?...)
(5) How useful is this really to do this one AU at a time?
What do you mean?
I think... if Logic node can process a whole channel strip, bus,
whatever at once (dunno...) it is absolutely important to have the
choice to insert any plugin desired.
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.
No problem here ;-)
I confess, Zebra does use a pointer for the waveform view, but that's
it. I could as well copy values upon updates.
If a plugin does not support remote guiing, one could at least remotely
control the published parameters and ClassInfo, given that a plugin
does not depend on files...
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) -
Yes!
to that end some of the features we're doing in
Tiger have some interesting uses.
Must install... is it already visible in any way?!? Any hint?!?
For those that are planning on attending AES in San Francisco this
year, we
will be going through some of these.
Hope you'll have a paper 8-)
Cheers,
;) Urs
Bill
On 29/9/04 11:41 AM, "Urs Heckmann" <email@hidden> wrote:
Hiya Stefan,
ok, now I can see something coming up 8-))
Fortunately, I have made my design decisions so that I abstracted that
stuff. Hence I could easily change to passing data rather than
pointers. The largest struct I currently have has a size of less than
1
kB, so that should be cool.
But...
Properties like AudioUnitParameterStringFromValue do pass data to the
AU while fetching. This means, the entity that requests a property
from
the AU passes a pointer to a struct that already has some stuff
inside,
so the AU can take further decisions about what to pass back (In case
of AudioUnitParameterStringFromValue, that's the parameter ID for
instance).
Will this be available for all properties?
Cheers,
;) Urs
Am 29.09.2004 um 17:52 schrieb Stefan Gretscher:
Am 29.09.2004 um 16:56 schrieb Robert Grant:
So can any 3rd party AUs be distributed - you only mention Logic
built-in plugins?
At this point, it's alas only working for the Logic built-in
plug-ins.
We are doing some evaluation for AUs too, but there's several issues
that prevented
us from supporting this for AUs in the initial release, like for
example the this-pointer
based communication in many AUs, copy protection issues and the lack
of a mean
to predict the CPU load of plug-ins (needed to to balance the load
properly between
the master and the slave(s)).
Best,
Stefan
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
_______________________________________________________________________
___
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
_______________________________________________________________________
___
_______________________________________________
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