Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- Subject: Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- From: William Stewart <email@hidden>
- Date: Tue, 20 Jun 2006 11:11:32 -0700
The Filter's view allocates a block of memory that points to an array
of typedef struct FrequencyResponse (defined in Filter.h)
When retrieving the values for these, the view passes a pointer to
this block of memory and sets the size of the property to be the
allocated size of this memory. The AU then sets the frequency
response values into that memory.
In this scheme, there is no assumption that a view and its AU are
running in the same address space. Some code can intervene in the
middle of this process and pass the memory to/from the view/AU. The
AU does not hold onto this pointer for later use, so it has no
assumptions about it except as some address to write data too when it
is called.
As a side note, the property is also implemented as an "on demand"
property - the AU is not precalculating these values and storing them
in local memory, but rather when queried the AU does the work,
writing the results of that work to the supplied memory location.
All of the standard AU properties are implemented in this manner -
the AU will either use the passed in value or copy the struct (for
instance SetFormat) so that there are no dependencies or questions of
ownership.
By "passing pointers" what is being referred to is the deliberate
passing of a pointer (for example a this pointer) between the AU and
the view and then what happens to the usage of that pointer. For
instance, a View retrieves the this pointer from the AU, then
proceeds to make method calls on this this pointer (or directly
access data members). To take the example above, it would also be
problematic if the AU having been given a pointer from this property
call, would then turn around and cache this pointer internally and at
some later time read or write to that memory. In both of these cases,
the code that uses the pointer after the call completes assumes that
the pointer is still valid, that the pointer is always in the same
address space, etc..
Bill
On 20/06/2006, at 8:46 AM, Robert Abernathy wrote:
In a couple of my AU's, I use properties to pass data (in both
directions AU->UI and UI->AU depending on the situation). I just
pass a struct. It works really well. If you take the care to pass
the data in formats like CFSwappedFloat64 and decoding with
CFConvertFloat64SwappedToHost, you might save some possible future
pains with your processes running on two different processor
architectures as well. I'm not sure how legit it is to do this,
but I save my properties to the presets using Save/RestoreState and
using these calls was needed for the presets to work with universal
binaries.
The property mechanism is pretty clean and just works once you get
all of the calls and notifications set up.
Rob
On 20 Jun 2006, at 16:22, Richard Burnett wrote:
I'm confused, this is what the 'Filter' example is doing in the
CoreAudio SDK. Specifically, I believe it is passing a pointer
from the UI class back to the AU and then setting values in memory
being pointed to.
It would seem to me that probably a lot of people do this, and
what the property feature of the AU api would be used for, since
it is specifically passing a void pointer.
Now, I agree, that I too would REALLY like to be able to run
distributed AU's, as I run Digital Performer 5. How far is this
feature off? 10.5?
What would be the suggestion? Not use properties and just keep
two copies of my data, one in the AU and one in the UI and update
them both on any changes from the host or UI?
Rick
Please don't - AUs are generally designed so that the view code and
the processing code can live in separate address space or even on
separate machines, and exchanging pointers between UI and core
breaks
this design.
Consider an environment like Logic Nodes where the audio processing
can be distributed to remote machines for utilizing additional CPU
resources, while the UI is working on the main machine - there's no
way to exchange pointers there.
(Logic Nodes are currently limited to Logics built-in plug-ins, but
there's a strong user demand to open up this technology for AUs as
well.)
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:
40musicunfolding.com
This email sent to 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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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