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 15:51:41 -0700
On 20/06/2006, at 12:03 PM, Robert Abernathy wrote:
I should have been more clear. In the instance where I pass data
to the AU from the UI, the structs are allocated and filled out in
the UI. I then pass a pointer to them in AudioUnitSetProperty.
When I get the corresponding call in the AU, I copy the data into a
local struct in the AU. It works flawlessly in my experience.
Sorry for adding any confusion.
OK - just make sure you aren't embedding pointers in structs and that
the size of the property call you make is actually the size of the
memory you have allocated. (That way, is someone was in the middle
between your AU and its view and was copying this memory, it could do
so across address or even machine boundaries). You're probably clear
on this, but I think its probably worth reiterating (as I've seen
this mistake a couple of times)
So, this would be bad:
struct MyStruct {
UInt32 sizeofData;
UInt32* data;
};
and the size of this when using the AU Property calls would of course
be sizeof(MyStruct)
Instead you would do this this way:
struct MyStruct {
UInt32 sizeofData;
UInt32 data[1]; //variable length size
};
and this would need to be allocated dynamically, and the size of the
this when passed in to the AU Property calls would be:
(sizeofData * sizeof(UInt32) + sizeof(UInt32))
and of course this is at least how much you allocated. You'll see
this pattern alot in some of the CA Structs - for instance some of
the music event structs in MusicPlayer.h
Bill
On the other point of VNC vs. X-Windows, can we please stick with
the architected solution? For one thing, what to do if the
processing node has no UI capability at all? What if the
processing node is actually a collection of nodes controlled by one
UI? It seems to me that the current solution can work in either of
these situations (and many others) with no problems. We just need
some hosts to do it.
Rob
On 20 Jun 2006, at 19:11, William Stewart wrote:
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:
40apple.com
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
_____________________________________________________________________
_____
--
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