Re: Using This pointer for communication
Re: Using This pointer for communication
- Subject: Re: Using This pointer for communication
- From: William Stewart <email@hidden>
- Date: Wed, 29 Sep 2004 14:05:22 -0700
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).
(2) The "is it worth it" problem that Stefan describes is a major problem
(3) AU's that depend on data (sample banks)
(4) AU's that require authorisation
(5) How useful is this really to do this one AU at a time?
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
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